NOKIA手機軟件測試
首先講解了手機的基本知識如基本術(shù)語、硬件及軟件結(jié)構(gòu)，之后是測試的整個流程，詳細(xì)講解了不同的測試方法：如性能測試、易用性測試、文檔測試等，最后是測試相關(guān)文檔說明
目錄
1 手機知識
1.1 手機的主要功能
1.1.1 通話功能
1.1.2 消息功能
1.1.3 電話本
1.1.4 增值服務(wù)
1.1.5 其他功能
1.1.6 為特定語言定做的功能
1.1.7 附件
1.2 手機的軟件結(jié)構(gòu)
1.3 手機的硬件結(jié)構(gòu)
1.4 Nokia手機相關(guān)知識
1.4.1 Project Line of Nokia
2 測試基礎(chǔ)
2.1 測試與開發(fā)
2.1.1 軟件開發(fā)的一般流程
2.1.2 測試在軟件開發(fā)中的作用
2.1.3 測試與開發(fā)對應(yīng)圖
2.1.4 Nokia手機軟件測試介入開發(fā)的時間
2.1.5 Nokia手機的開發(fā)流程
2.2 測試的流程
2.2.1 制定測試計劃
2.2.2 測試準(zhǔn)備
2.2.3 測試執(zhí)行
2.2.4 測試評估
2.2.5 文檔收集
2.2.6 測試總結(jié)報告
2.3 測試的分類
2.3.1 按測試的手段分
2.3.2 按測試發(fā)生的時間和目標(biāo)分
2.3.3 按測試的任務(wù)分
2.3.4 其他測試
2.4 黑盒測試詳細(xì)介紹
2.4.1 Release Test
2.4.2 System Test
2.4.3 Focus Test
2.4.4 Stress Test
2.4.5 Free Test
2.5 測試相關(guān)文檔說明
2.5.1 測試計劃
2.5.2 測試用例
2.5.3 錯誤報告
2.5.4 進(jìn)度報告
2.5.5 總結(jié)報告
3 手機相關(guān)
3.1 GSM
3.2 GPRS
3.3 CDMA
3.4 3G
4 手機軟件測試工程師必備素質(zhì)
4.1 Team Leader的任務(wù)和必備能力
4.2 QA的工作內(nèi)容
4.3 測試工程師應(yīng)有素質(zhì)
1.1 手機的主要功能
1.1.1 通話功能
對撥入撥出電話的管理
對通話記錄的管理
呼叫轉(zhuǎn)接、呼叫等待、通話計時計費等方便用戶使用的功能
1.1.2 消息功能
文字短消息（SMS）的編輯、發(fā)送、接收、轉(zhuǎn)發(fā)和存儲等；
多媒體短消息（MMS）的編輯、發(fā)送、接收、轉(zhuǎn)發(fā)、存儲和配置；
1.1.3 電話本
名片的管理
存在SIM卡上的名片
存在手機內(nèi)存中的名片
一個名字多項內(nèi)容（如傳真、固話、手機、Email等）
名片的新建、修改、拷貝、轉(zhuǎn)存、刪除
名片以紅外或短消息形式發(fā)送給其它手機
單鍵撥號（Speed Dialing）
號碼分組（Caller Groups）
1.1.4 增值服務(wù)
Business cards 的管理 (如發(fā)送和接收: 通過紅外線或SMS. )
書簽的管理 (如發(fā)送和接收: 通過紅外線或SMS或書簽形式. 以及編輯,存儲,新增和進(jìn)入.)
服務(wù)信箱 (自動存儲服務(wù)信息. 服務(wù)信息有點播鈴聲,下載彩色圖片和COD文件等.)
服務(wù)設(shè)置 ( GPRS上網(wǎng)設(shè)置,WAP服務(wù)設(shè)置.)
多模式瀏覽器 ( GPRS上網(wǎng),WAP服務(wù).)
OTA待機圖片 (通過無線下載待機圖片)
OTA鈴聲
V-calendar
XHML
移動夢網(wǎng)
動感地帶
1.1.5 其他功能
鬧鐘（Alarm）
日歷（Calendar）
計算器（Calculator）
定時器（Count Down Timer）
屏保（Screen Saver）
待辦事項（To-Do List）
游戲（Games）
1.1.6 為特定語言定做的功能
中文輸入（拼音/筆劃）
中文菜單
農(nóng)歷（Lunar Calendar）
1.1.7 附件
充電器（Charger）
耳機（Headset）
車載免提（Car Kit）
照相頭（Camera）
1.1.8 數(shù)據(jù)連通
GPRS 應(yīng)用程序
同步應(yīng)用程序 (同步應(yīng)用, 同步設(shè)置)
紅外線應(yīng)用程序
數(shù)據(jù)線
手機Flash程序
Trace Log
1.1.9 JAVA 程序
電子郵件
QQ程序
應(yīng)用程序
游戲程序
1.2 手機的軟件結(jié)構(gòu)
DCT = Digital Core Technology
DCT3和DCT4的區(qū)別主要在硬件結(jié)構(gòu)和UI上
1.3 手機的硬件結(jié)構(gòu)
RF是手機的射頻接受和發(fā)送設(shè)備，是手機本機與無線網(wǎng)絡(luò)的接口
UEM是手機對外設(shè)備聯(lián)接的接口，包括SIM卡，充電器，電池，RF，數(shù)據(jù)線借口，紅外接口等，并提供對上述數(shù)據(jù)和信號的處理。無線信號在這里進(jìn)行調(diào)制和解調(diào)。
UPP是手機的核心處理模塊。其中，DSP負(fù)責(zé)數(shù)字信號和模擬信號的轉(zhuǎn)換。UPP和UEM之間存在著接口，兩者之間的通信是通過接口進(jìn)行的。UPP除了負(fù)責(zé)整個手機的操作系統(tǒng)外，還負(fù)責(zé)手機本身設(shè)備的運作，如耳機，麥克風(fēng)，顯示屏等。除此之外，還負(fù)責(zé)緩存和Flash(相當(dāng)于硬盤)的運作。
Flash是手機的數(shù)據(jù)存儲區(qū)，非臨時數(shù)據(jù)都存在這里。一般包括以下幾個方面：Core Code, DSP Code, HW data, PPM, PMM。
1.4 Nokia手機相關(guān)知識
1.4.1 Project Line of Nokia
1.4.2 手機類型
MEP = Mobile Entry Phone
MP = Mobile Phone
MSW = Mobile Software
SWEP = software engineer product
2.1 測試與開發(fā)
2.1.1 軟件開發(fā)的一般流程
Marketing
Requirement Analysis
High Level Design
Low Level Design
Coding
2.1.2 測試在軟件開發(fā)中的作用
由于現(xiàn)在軟件的規(guī)模越來越大，一個人或者少數(shù)幾個人已經(jīng)不可能在一定的時間內(nèi)完成一個軟件，所以軟件開發(fā)的過程越來越復(fù)雜，層次越來越深。這就導(dǎo)致開發(fā)人員之間的溝通有了一定的隔閡。所以，軟件測試越來越有單立出來的必要和重要性。
由于軟件開發(fā)的過程的復(fù)雜性，軟件必然存在著無數(shù)的Bug。而且大多數(shù)是在軟件上市前必須解決的，而開發(fā)者有不定能發(fā)現(xiàn)這些問題，故而測試就顯得非常必要。測試是開發(fā)成功的必要保障。
由于軟件開發(fā)的層次性，所以開發(fā)的結(jié)果很可能與初衷不一樣，這就需要測試者去發(fā)現(xiàn)這些差異。因此，測試是軟件成功的重要保證。
軟件不僅要實現(xiàn)一些功能，更要完善它的性能。這就需要測試人員對軟件進(jìn)行評測，從而不斷地完善軟件的性能。
2.1.3 測試與開發(fā)對應(yīng)圖
2.1.4 Nokia手機軟件測試介入開發(fā)的時間
在制定開發(fā)計劃的同時就要制定測試計劃
測試在進(jìn)行結(jié)構(gòu)設(shè)計時就已經(jīng)進(jìn)行了
2.1.5 Nokia手機的開發(fā)流程
E-1
During this period, an idea box will appear. The ideas in the idea box are collected from Region Marketing and have a certain priority (The lower the priority number is, the higher the priority is). For example:0, 1, 2.
E0
During this period, the HW designer must make out the B0-HW version.That is to say, B0 must be put out after E0 period.
E0.5
綜合考慮HW, SW and Cost
E1
From E0 to E1, Design and Test Plan, Risk, Organization, Schedule must be discussed and made out.
E1.5
全體討論Design and Test Specification
E1.9
From E1 to E2, Design and Test Specification must be made out.
During E1.9, Last version of Specification should be made out and be approved.
E2
During E2, The formal draft SW should be made out.
E3
From E2 to E3, 對SW進(jìn)行精美化、完美化測試和改良
Purpose: No fatal error (市場部可以接受的Fatal Error不算)
E5
From E3 to E5, 進(jìn)行LCD以及其他HW的改動
During E5, 可以讓生產(chǎn)工廠進(jìn)行大批量生產(chǎn)
Before E5, the test stays in the CE (concurrent engineer)
After E5, the test goes into PE (production engineer)
2.2 測試的流程
2.2.1 制定測試計劃
開啟測試項目
在接了一個測試項目后，要在一定的期限內(nèi)制定好測試的詳細(xì)計劃以及日程安排表
2.2.2 測試準(zhǔn)備
在計劃制定好之后，在執(zhí)行之前，必須將測試所需的人力資源，硬件資源，軟件資源，文檔資源以及環(huán)境和人文資源準(zhǔn)備充分
2.2.3 測試執(zhí)行
測試組根據(jù)測試計劃和測試日程安排進(jìn)行測試，并輸出測試結(jié)果
2.2.4 測試評估
有測試結(jié)果評估小組或評估人員對測試結(jié)果進(jìn)行評測，分析，并輸出分析結(jié)果
2.2.5 文檔收集
將從測試計劃開始到評估結(jié)束的所有文檔進(jìn)行整理收集。
對整個測試過程進(jìn)行總結(jié)，并對測試結(jié)果進(jìn)行總結(jié)
2.2.6 測試總結(jié)報告
提交測試結(jié)果
歸還所借相關(guān)資源
文檔入庫
關(guān)閉測試項目
2.3 測試的方法
2.3.1 正確性測試
正確性測試又稱功能測試，它檢查軟件的功能是否符合規(guī)格說明。
測試基本的方法是構(gòu)造一些合理輸入（在定義域內(nèi)），檢查是否得到期望的輸出。
由于定義域是一個連續(xù)區(qū)間，所以不可能枚舉所有可能的值，那么等價測試就很必要了（將定義域分成若干個等價區(qū)間）。
等價區(qū)間的概念可表述如下：
記（A, B）是命題f(x) 的一個等價區(qū)間，在（A, B）中任意取x1進(jìn)行測試
如果f (x1) 錯誤，那么f (x) 在整個（A, B）區(qū)間都將出錯。
如果f (x1) 正確，那么f (x) 在整個（A, B）區(qū)間都將正確。
2.3.2 容錯性測試
容錯性測試是檢查軟件在異常條件下的行為（輸入不同的數(shù)據(jù)類型或者定義域之外的值進(jìn)行測試）。
2.3.3 邊界性測試
因為邊界一直是比較敏感的地方，而且是程序員最容易忽略的地方，所以，這種測試也往往最容易奏效。
2.3.4 性能與效率測試
性能與效率測試主要是測試軟件的運行速度和對資源的利用率。
性能與效率測試中很重要的一項是極限測試，因為很多軟件系統(tǒng)會在極限測試中崩潰。
2.3.5 易用性測試
易用性測試沒有一個量化的指標(biāo)，主觀性較強。這主要是從End User的角度去考慮軟件是否會有一定的使用缺陷。如果對此有任何看法，可以向Team Leader反應(yīng)或者與客戶負(fù)責(zé)人直接交流。
2.3.6 文檔測試
文檔測試主要檢查文檔的正確性、完備性和可理解性。好多人甚至不知道文檔是軟件的一個組成部分。
我們的工作中的文檔主要是UI Spec.和Test Case。UI Spec使我們無法改變的，但是Test Case
是我們測試的對象。Test Case是我們用來測試手機軟件的參考文檔，但是它本身也有一定的局限性。所以，在測試的過程中，如果發(fā)現(xiàn)Test Case不正確或者不充分，可以直接補充，或者和Team Leader商議后把不足的地方補充起來。
2.4 測試的分類
2.4.1 按測試的手段分
黑盒測試(White-box Test)
Release Test
(Full Round)SystemTest
Focus Test
Stress Test---No Test Case
Free Test----No Test Case
白盒測試(Black-box Test)
Module Test
Sub-System Test
Sub-System Integration Test
System Integration Test
Integration Test
The feature groups for Integration Test are decided by Integrator and provided by SW
Component Factory.
2.4.2 按測試發(fā)生的時間和目標(biāo)分
單元測試(Module Test/Unit Test)
集成測試(Integration Test)
系統(tǒng)測試(System Test)
2.4.3 按測試的任務(wù)分
現(xiàn)場測試(Field Test)
互操作測試(Inter-Operatability Test)
2.4.4 其他測試
可接受性測試(Acceptance Test)
測試 -----------手機研發(fā)公司自己做的測試
測試 -----------非手機研發(fā)公司做的測試
2.5 黑盒測試詳細(xì)介紹
2.5.1 Release Test
Purpose:
測試手機的基本功能是否實現(xiàn)，是否有進(jìn)一步測試的必要性
Input:
測試工程師
Release Test Cases (較少，一般為200左右)
手機以及相關(guān)附件
測試環(huán)境
Output:
Test result of Release Test
No Error reports (Optional)
Attention:
Release Test的Test Case具有一定的典型性，主要是反映手機最基本功能的Test Case
本類測試只需要依據(jù)Test Case進(jìn)行測試，不需要進(jìn)一步發(fā)揮
如果有發(fā)現(xiàn)與Case無關(guān)的Error, 在測試通過后才可以填報Error Report
此類測試有一門檻值，即Test Case的Pass率達(dá)到一定值（如95%）才能宣布版本發(fā)布成功，進(jìn)入進(jìn)一步的測試，否則此版本無效。
除了門檻值外，如果重要功能模塊的Test Case沒通過，也會終止這個版本。
2.5.2 System Test
Full Round System Test
Purpose
對手機的所有功能進(jìn)行全面的測試(所有語言包)
由于Case不可能包含所有方面，所以測試時應(yīng)適度發(fā)揮，盡力完成全面測試
Input:
測試工程師
Test Cases(較多，一般為25000左右)
手機以及相關(guān)附件
測試環(huán)境
Schedule
Output:
Daily Report of test cases (number & percent of Pass, Error, NA, NT)
Summary Report
Error list and Error reports
Common System Test (Medium or Minor)
Purpose:
對手機的一部分的功能進(jìn)行全面的測試
由于Case不可能包含所有方面，所以測試時應(yīng)適度發(fā)揮，盡力完成全面測試
Input:
測試工程師
Test Cases(較多，取決于測試的目的和范圍)
手機以及相關(guān)附件
測試環(huán)境
Schedule
Output:
Daily Report of test cases (number & percent of Pass, Error, NA, NT)
Summary Report
Error list and Error reports
Attention:
System Test一般分為兩個部分，“跑Case”和Free Test。
在測試初期，一般只需要按照Test Case測，把一些不可重現(xiàn)的Error都記錄下來。同時遇到Test Case的問題或者不充分，應(yīng)該立即解決（和Team Leader或者Special List討論，補寫Test Case）。在這一階段結(jié)束后，一般要寫一個Summary Report。把這一階段的測試結(jié)果和遇到的問題、自己的見解都寫在里面（當(dāng)然是用English）。
當(dāng)所有Test Case都測完后，就進(jìn)入Free Test期間。這里的Free Test具有明確的目的性和范圍。一般來說，這段時間的Free Test只需要測自己負(fù)責(zé)的模塊。而且Free Test還負(fù)責(zé)重現(xiàn)前期“跑Case”是遺留的不可重現(xiàn)的Error。
2.5.3 Focus Test
Purpose:
集中于一個或幾個點進(jìn)行測試(同System Test)
Input:
測試工程師
Test Cases
手機以及相關(guān)附件
測試環(huán)境
Output:
Test Result
Error Reports
2.5.4 Stress Test
Purpose:
為了解決市場上發(fā)現(xiàn)的重大Error，而進(jìn)行的有針對性的強度測試
主要是利用邊緣測試（臨界測試）手段
Input:
測試工程師
手機以及相關(guān)附件
測試環(huán)境
Focus List of Phone Features
Output:
Expected result: find out the reproducible steps of these errors
Decrease the steps as possible as we can
Attention:
壓力測試，顧名思義，是給手機施加一定壓力，從而找出手機軟件上的Error。一般來說，對手
機施加的壓力主要有：
存儲壓力：由于手機采用的是棧式存儲，所以當(dāng)一個存儲塊滿了之后，如果程序員不做相應(yīng)處理或者處理不好的話，很容易造成其他存儲區(qū)被擦除，從而在UI上出現(xiàn)問題（其他功能無法正常使用）。
邊界壓力：邊界一直是程序員最容易忽略的地方。
響應(yīng)能力壓力：有時候某個操作可能處理的時間很長，在處理期間如果測試者再不斷地進(jìn)行其他操作的話，很容易出現(xiàn)問題。
網(wǎng)絡(luò)流量壓力（如在接電話時進(jìn)行短信服務(wù)）等等。
在項目中，Stress Test有時也會用來重現(xiàn)不可重現(xiàn)的Error。
由于有不少不可重現(xiàn)的Error是由于Memory Leak(內(nèi)存泄漏)引起的，所以不停的重復(fù)同一個操作是重現(xiàn)一個不可重現(xiàn)的Error的一個好方法。
2.5.5 Free Test
Purpose:
測試System Test中沒有做完的不可重現(xiàn)Error
尋找平時沒有找到的忽略的Error
Input:
測試工程師
手機以及相關(guān)附件
測試環(huán)境
Error List of System Test (especially the irreproducible errors)
Output:
Error List and Error Reports
Attention:
在System Test階段所用的Free Test具有明顯的目的性和范圍
平時的Free Test從理論上應(yīng)該對所測試的范圍窮盡所有的測試方法。但是，這是不現(xiàn)實的。在實際項目中，主要有兩個方面是Free Test所需要重視的。
一是從UI Spec上找靈感。應(yīng)為Test Case是依據(jù)UI Spec寫的，所以從UI Spec上突破是一個行之有效的方法。UI Spec有一定的探索深度，加大探索深度，是一種突破的途徑；另外同一個功能用其他不同的方法去實現(xiàn)，也是一種突破途徑。
二是多關(guān)注不同F(xiàn)eature之間的Interaction。這是手機軟件相對比較容易出問題，而Test Case又很少能反映的地方。這是一個很大的Free Test空間。
2.6 測試相關(guān)文檔說明
2.6.1 測試計劃
測試的任務(wù)
即需要測試什么和不需要測試什么；
工作量估算
需要多少人，測試多少天，測試幾個周期；
日程表
每人每天需要做什么；
測試方法和流程
采用什么方法，遵循哪些流程；
測試資源
需要多少人、設(shè)備、工具、文檔等資源，以及對上述資源都有哪些要求。
測試輸出
測試中需完成的錯誤報告（Error Report）和進(jìn)度報告（Progress Report），測試完成后需完成的總結(jié)報告（Summary Report）。
2.6.2 測試用例
Title
標(biāo)題一般會描述出當(dāng)前要執(zhí)行的case是哪個功能模塊的，能實現(xiàn)怎樣的一個操作。標(biāo)題下面有當(dāng)前case的ID號和軟件的版本號，如Phonebook-Memory Save-Selected memory is Phone and SIM
ID: EK20010829094907
Version: 1.1.0
Description
整體地描述這個case的測試目的，能實現(xiàn)什么功能。例如：
The purpose of this test case is check out that the phone number can be saved to phonebook
when selected memory is Phone and SIM.
Required test environment and accessories
必需的測試環(huán)境和附件。測試環(huán)境包括硬件環(huán)境和軟件環(huán)境。例如：HW, ESIM，Headset.
Precondition
描述執(zhí)行case的前提條件。例如：
Select memory in use to be Phone and SIM.
Return to the Idle State.
Action
詳細(xì)描述執(zhí)行case時的每一步操作。一般每一步操作都對應(yīng)著一個期望中的結(jié)果。執(zhí)行時可參照下面的期望結(jié)果。例如：
Start the procedure to add a new item to the Phonebook.
Enter some name and press Ok.
Enter some number such as 12345 and press Ok.
Expected result
描述執(zhí)行該case的期望中的結(jié)果，與上面的操作Action是相對應(yīng)的。例如：
Name: query is displayed.
Number: query is displayed.
Saved to phone memory information note is shown. Phone goes to detailed memory screen.
2.6.3 錯誤報告
Title:
標(biāo)題是Error Report中非常重要的一部分，它要求簡單明了地對Error作一個整體的描述，讓不知道這個Error的人看了之后能夠很清楚地知道這是個怎樣的Error。記得曾經(jīng)有人提過“3W1H”的概念。也就是說，標(biāo)題里面應(yīng)該包括What is the error, When will the error appear, Where may the error appear and How to make the error appear. 在Title后面，一般要寫上Feature Group的名字。
例如：
Title: Call register: The phone doesn’t remain in the same state after rejecting a call
when viewing items under full window choice items in call register.
Severity (Fatal/Severe/Minor):
Severity用來描述Error的嚴(yán)重程度，有三個級別：較小的、嚴(yán)重的、致命的。Fatal Error一般來說是指影響手機系統(tǒng)工作的Error；Server Error指的是影響用戶操作的或者某些功能實現(xiàn)的Error；Minor Error指的是微小的、不影響手機功能正常使用的Error。一般的Error如中文界面中的某個字不正確，或者是英文界面中的某個單詞拼寫不正確；左右功能鍵顯示有誤等等都屬于Minor。若手機的某個功能不能實現(xiàn)，如不能發(fā)短信，不能存電話號碼，不能進(jìn)行充電等等都屬于Severe；若手機開不了機，或經(jīng)常死機
、重啟等則是Fatal。Severe和Fatal兩種Error對手機來說都是很嚴(yán)重的問題，這個具體在做項目時可請示項目經(jīng)理。
例如：Minor
Reproducible Error? (Yes/No, if No, how many times?) in English UI or Chinese UI?
描述Error是否可再現(xiàn)，如果每次操作都能出現(xiàn)，就是可再現(xiàn)的。如果只是某一次操作才會出現(xiàn)這個Error
，則是不可再現(xiàn)的。如果是不可再現(xiàn)錯誤，要記錄一共出現(xiàn)過多少次，是在英文界面還是在中文界面。每
個Error都有發(fā)生的前提條件和操作步驟。嚴(yán)格的說，每個Error都是可重現(xiàn)的。但是，發(fā)現(xiàn)這個Error的
人可能沒有能夠找到這個error的完整的前提條件或者完整的操作步驟。所以，現(xiàn)實中就有了很多不可重
現(xiàn)的Error。對于一個手機而言，硬件，軟件，語言包和SIM卡都是其重要的組成部分。所以，在一個手機
中用某種SIM卡在某種語言的UI上發(fā)現(xiàn)了某個Error，有可能在同樣的手機，同樣的SIM卡，不同的語言的
UI上就沒有這個Error;也有可能在同樣得手機上用不同的SIM卡也會沒有這個Error；同樣，在不同的手機
上也有可能發(fā)現(xiàn)不了這個Error�？傊痪湓挘欠窨芍噩F(xiàn)，要考慮手機硬件、軟件版本、SIM卡類型、UI
類型等等相關(guān)的影響，不能簡單的說某個Error可重現(xiàn)，有的時候要加上注釋。
例如：Yes, both in English UI and Chinese UI
Precondition:
這里寫的是在錯誤發(fā)生之前，手機的狀態(tài)。為了保證步驟的簡潔，這里要盡可能的詳細(xì)。當(dāng)然，也不要寫
的很羅嗦。
How did you get to the state just before the error:
詳細(xì)描述在錯誤發(fā)生之前你是如何到達(dá)這個狀態(tài)的，要具體到每一步的操作。在這個部分，步驟一定要清
晰、簡潔，讓別人能夠輕松的理解并完成操作這個可以分成幾個步驟來寫，如步驟1、步驟2、步驟3等。
例如：
1. Menu --> Call register --> enter one of full window choice items;
2. Receive a call;
3. Reject it or remote end terminats the call.
Description of the error:
對發(fā)生錯誤的描述，用簡明易懂的話詳細(xì)地把這個Error描述清楚。注意幾個要點：“詳細(xì)”、“簡明”
、“清晰易懂”。例如：
After rejecting a call or having a missed call when viewing items under full window choice
items in call register. The phone goes back to the full window choice items under call
register.
Description of expected result:
描述期望的操作結(jié)果，這個在case中一般都有說明，一般情況下，case的執(zhí)行結(jié)果就是期望的操作結(jié)果。
這里描述的是，期望情況下，“應(yīng)該”是什么結(jié)果.例如：
The phone should remain in the same state just as before receiving a call.
SIM card used:
所用的SIM卡是中國移動（CMCC）還是中國聯(lián)通(CHN-CUGSM)。例如：CMCC
SW version and Language package:
所測手機軟件的版本號可通過在待機狀態(tài)下按“*#0000#”來獲得。
我們現(xiàn)在所測的手機語言包大部分都是C包，語言包可通過下面的方法來獲得：
把手機恢復(fù)出廠設(shè)置，進(jìn)入短信的編輯窗口，此時默認(rèn)的輸入法如果是“拼音”
，則語言包為C包。例如：V5.20C
2.6.4 進(jìn)度報告
工作時間（小時數(shù)）；
測試用例執(zhí)行情況：
Total:已經(jīng)完成的測試用例數(shù)目；
Fail:其中出錯的測試用例數(shù)目；
Pass:通過的測試用例數(shù)目；
Not Test:未測的測試用例數(shù)目；
Not Available:無法測試的測試用例數(shù)目；
發(fā)現(xiàn)的所有錯誤的列表；
執(zhí)行的所有測試用例及其結(jié)果的列表。
2.6.5 總結(jié)報告
測試活動的時間
測試投入的人力
測試效果和結(jié)論
測試用例通過情況列表
發(fā)現(xiàn)所有錯誤的列表
所有仍未關(guān)閉的錯誤報告列表
3.1 GSM
3.2 GPRS
見上面文件。
3.3 CDMA
3.4 3G
4.1 Team Leader的任務(wù)和必備能力
熟悉本組成員，包括知識、能力、經(jīng)驗、愛好等等
是客戶方和本組成員的接口，負(fù)責(zé)兩者之間的溝通
負(fù)責(zé)分配本組的任務(wù)，包括制定計劃和日程安排
總結(jié)每天的工作結(jié)果，若有重要的Error須匯報客戶方負(fù)責(zé)人
新進(jìn)測試工程師的培訓(xùn)
回答本組內(nèi)其他測試人員的問題
制作工作進(jìn)度表，隨時報告本組工作進(jìn)度
監(jiān)督協(xié)調(diào)本組成員的工作
收集本組成員的建議和要求
部分測試工作
檢查測試條件是否滿足
控制工作質(zhì)量
4.2 Error Manager的工作內(nèi)容
確認(rèn)Error的真實性
確定Error的Priority和Severity
遇到問題時需要和客戶方負(fù)責(zé)人商量
The daily work of an error manager is handling errors and answer questions asked by
testers, engineers.
To finish the work well, an error manager must have the following skills.
1. An error manager must be more familiar with the UI spec than the others.
2. An error manager must be familiar with the process of handling errors.
For example:
If there is an error needing to be handled, the error manager should do the following
things.
a. Check whether the error report is complete or not.
b. Make sure the error report is clear and clean.
c. Using all the related knowledge to judge whether it is a real error.
d. If not, set it to be ignored. If yes, search all the errors in the database to find
whether it is a known error.
e. If yes, set it to be duplicated. If not, try to reproduce it and add more information
to the report.
f. During the above steps, a manager should keep more communication with the reporter.
g. Finally, check who is the SCF that the error should be sent to.
3. An error manager must be familiar with the process of an error's living.
4. Be familiar with the tools, such as Lotus Notes, PC suite, Phoenix and so on.
4.3 測試工程師職責(zé)和應(yīng)有素質(zhì)
Read UI Specification
學(xué)習(xí)數(shù)據(jù)庫里的Error Report（格式、內(nèi)容和別人的思路）
測試工作
寫Error Report和Test Case
熟練使用相應(yīng)的軟件和工具
態(tài)度明確、端正，有責(zé)任心，嚴(yán)謹(jǐn)?shù)墓ぷ髯黠L(fēng)
良好的溝通和協(xié)調(diào)能力，積極主動地與別人交流
技術(shù)能力
測試知識和技術(shù)
編程知識和技術(shù)
無線協(xié)議知識
軟件知識
硬件知識
語言水平
英語水平
喜歡 
頂
難過
囧
圍觀
無聊
