諾基亞手機(jī)軟件測(cè)試基礎(chǔ)知識(shí)、術(shù)語(yǔ)和流程

360寶盒諾基亞(s60v3v5塞班3)2.7通用版

• 類型：塞班平臺(tái)應(yīng)用大小：1.4M語(yǔ)言：中文 評(píng)分：5.0
• 標(biāo)簽：

立即下載

NOKIA手機(jī)軟件測(cè)試
首先講解了手機(jī)的基本知識(shí)如基本術(shù)語(yǔ)、硬件及軟件結(jié)構(gòu)，之后是測(cè)試的整個(gè)流程，詳細(xì)講解了不同的測(cè)試方法：如性能測(cè)試、易用性測(cè)試、文檔測(cè)試等，最后是測(cè)試相關(guān)文檔說(shuō)明
目錄
1 手機(jī)知識(shí)
1.1 手機(jī)的主要功能
1.1.1 通話功能
1.1.2 消息功能
1.1.3 電話本
1.1.4 增值服務(wù)
1.1.5 其他功能
1.1.6 為特定語(yǔ)言定做的功能
1.1.7 附件
1.2 手機(jī)的軟件結(jié)構(gòu)
1.3 手機(jī)的硬件結(jié)構(gòu)
1.4 Nokia手機(jī)相關(guān)知識(shí)
1.4.1 Project Line of Nokia
2 測(cè)試基礎(chǔ)
2.1 測(cè)試與開(kāi)發(fā)
2.1.1 軟件開(kāi)發(fā)的一般流程
2.1.2 測(cè)試在軟件開(kāi)發(fā)中的作用
2.1.3 測(cè)試與開(kāi)發(fā)對(duì)應(yīng)圖
2.1.4 Nokia手機(jī)軟件測(cè)試介入開(kāi)發(fā)的時(shí)間
2.1.5 Nokia手機(jī)的開(kāi)發(fā)流程
2.2 測(cè)試的流程
2.2.1 制定測(cè)試計(jì)劃
2.2.2 測(cè)試準(zhǔn)備
2.2.3 測(cè)試執(zhí)行
2.2.4 測(cè)試評(píng)估
2.2.5 文檔收集
2.2.6 測(cè)試總結(jié)報(bào)告
2.3 測(cè)試的分類
2.3.1 按測(cè)試的手段分
2.3.2 按測(cè)試發(fā)生的時(shí)間和目標(biāo)分
2.3.3 按測(cè)試的任務(wù)分
2.3.4 其他測(cè)試
2.4 黑盒測(cè)試詳細(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 測(cè)試相關(guān)文檔說(shuō)明
2.5.1 測(cè)試計(jì)劃
2.5.2 測(cè)試用例
2.5.3 錯(cuò)誤報(bào)告
2.5.4 進(jìn)度報(bào)告
2.5.5 總結(jié)報(bào)告
3 手機(jī)相關(guān)
3.1 GSM
3.2 GPRS
3.3 CDMA
3.4 3G
4 手機(jī)軟件測(cè)試工程師必備素質(zhì)
4.1 Team Leader的任務(wù)和必備能力
4.2 QA的工作內(nèi)容
4.3 測(cè)試工程師應(yīng)有素質(zhì)

1.1 手機(jī)的主要功能
1.1.1 通話功能
 對(duì)撥入撥出電話的管理
 對(duì)通話記錄的管理
 呼叫轉(zhuǎn)接、呼叫等待、通話計(jì)時(shí)計(jì)費(fèi)等方便用戶使用的功能
1.1.2 消息功能
 文字短消息（SMS）的編輯、發(fā)送、接收、轉(zhuǎn)發(fā)和存儲(chǔ)等；
 多媒體短消息（MMS）的編輯、發(fā)送、接收、轉(zhuǎn)發(fā)、存儲(chǔ)和配置；
1.1.3 電話本
 名片的管理
 存在SIM卡上的名片
 存在手機(jī)內(nèi)存中的名片
 一個(gè)名字多項(xiàng)內(nèi)容（如傳真、固話、手機(jī)、Email等）
 名片的新建、修改、拷貝、轉(zhuǎn)存、刪除
 名片以紅外或短消息形式發(fā)送給其它手機(jī)
 單鍵撥號(hào)（Speed Dialing）
 號(hào)碼分組（Caller Groups）
1.1.4 增值服務(wù)
 Business cards 的管理 (如發(fā)送和接收: 通過(guò)紅外線或SMS. )
 書(shū)簽的管理 (如發(fā)送和接收: 通過(guò)紅外線或SMS或書(shū)簽形式. 以及編輯,存儲(chǔ),新增和進(jìn)入.)
 服務(wù)信箱 (自動(dòng)存儲(chǔ)服務(wù)信息. 服務(wù)信息有點(diǎn)播鈴聲,下載彩色圖片和COD文件等.)
 服務(wù)設(shè)置 ( GPRS上網(wǎng)設(shè)置,WAP服務(wù)設(shè)置.)
 多模式瀏覽器 ( GPRS上網(wǎng),WAP服務(wù).)
 OTA待機(jī)圖片 (通過(guò)無(wú)線下載待機(jī)圖片)
 OTA鈴聲
 V-calendar
 XHML
 移動(dòng)夢(mèng)網(wǎng)
 動(dòng)感地帶
1.1.5 其他功能
 鬧鐘（Alarm）
 日歷（Calendar）
 計(jì)算器（Calculator）
 定時(shí)器（Count Down Timer）
 屏保（Screen Saver）
 待辦事項(xiàng)（To-Do List）
 游戲（Games）
1.1.6 為特定語(yǔ)言定做的功能
 中文輸入（拼音/筆劃）
 中文菜單
 農(nóng)歷（Lunar Calendar）
1.1.7 附件
 充電器（Charger）
 耳機(jī)（Headset）
 車載免提（Car Kit）
 照相頭（Camera）
1.1.8 數(shù)據(jù)連通
 GPRS 應(yīng)用程序
 同步應(yīng)用程序 (同步應(yīng)用, 同步設(shè)置)
 紅外線應(yīng)用程序
 數(shù)據(jù)線
 手機(jī)Flash程序
 Trace Log
1.1.9 JAVA 程序
 電子郵件
 QQ程序
 應(yīng)用程序
 游戲程序
1.2 手機(jī)的軟件結(jié)構(gòu)

DCT = Digital Core Technology
DCT3和DCT4的區(qū)別主要在硬件結(jié)構(gòu)和UI上
1.3 手機(jī)的硬件結(jié)構(gòu)

 RF是手機(jī)的射頻接受和發(fā)送設(shè)備，是手機(jī)本機(jī)與無(wú)線網(wǎng)絡(luò)的接口
 UEM是手機(jī)對(duì)外設(shè)備聯(lián)接的接口，包括SIM卡，充電器，電池，RF，數(shù)據(jù)線借口，紅外接口等，并提供對(duì)上述數(shù)據(jù)和信號(hào)的處理。無(wú)線信號(hào)在這里進(jìn)行調(diào)制和解調(diào)。
 UPP是手機(jī)的核心處理模塊。其中，DSP負(fù)責(zé)數(shù)字信號(hào)和模擬信號(hào)的轉(zhuǎn)換。UPP和UEM之間存在著接口，兩者之間的通信是通過(guò)接口進(jìn)行的。UPP除了負(fù)責(zé)整個(gè)手機(jī)的操作系統(tǒng)外，還負(fù)責(zé)手機(jī)本身設(shè)備的運(yùn)作，如耳機(jī)，麥克風(fēng)，顯示屏等。除此之外，還負(fù)責(zé)緩存和Flash(相當(dāng)于硬盤(pán))的運(yùn)作。
 Flash是手機(jī)的數(shù)據(jù)存儲(chǔ)區(qū)，非臨時(shí)數(shù)據(jù)都存在這里。一般包括以下幾個(gè)方面：Core Code, DSP Code, HW data, PPM, PMM。
1.4 Nokia手機(jī)相關(guān)知識(shí)
1.4.1 Project Line of Nokia

1.4.2 手機(jī)類型
 MEP = Mobile Entry Phone
 MP = Mobile Phone
 MSW = Mobile Software
 SWEP = software engineer product

2.1 測(cè)試與開(kāi)發(fā)
2.1.1 軟件開(kāi)發(fā)的一般流程

 Marketing
 Requirement Analysis
 High Level Design
 Low Level Design
 Coding
2.1.2 測(cè)試在軟件開(kāi)發(fā)中的作用
 由于現(xiàn)在軟件的規(guī)模越來(lái)越大，一個(gè)人或者少數(shù)幾個(gè)人已經(jīng)不可能在一定的時(shí)間內(nèi)完成一個(gè)軟件，所以軟件開(kāi)發(fā)的過(guò)程越來(lái)越復(fù)雜，層次越來(lái)越深。這就導(dǎo)致開(kāi)發(fā)人員之間的溝通有了一定的隔閡。所以，軟件測(cè)試越來(lái)越有單立出來(lái)的必要和重要性。
 由于軟件開(kāi)發(fā)的過(guò)程的復(fù)雜性，軟件必然存在著無(wú)數(shù)的Bug。而且大多數(shù)是在軟件上市前必須解決的，而開(kāi)發(fā)者有不定能發(fā)現(xiàn)這些問(wèn)題，故而測(cè)試就顯得非常必要。測(cè)試是開(kāi)發(fā)成功的必要保障。
 由于軟件開(kāi)發(fā)的層次性，所以開(kāi)發(fā)的結(jié)果很可能與初衷不一樣，這就需要測(cè)試者去發(fā)現(xiàn)這些差異。因此，測(cè)試是軟件成功的重要保證。
 軟件不僅要實(shí)現(xiàn)一些功能，更要完善它的性能。這就需要測(cè)試人員對(duì)軟件進(jìn)行評(píng)測(cè)，從而不斷地完善軟件的性能。
2.1.3 測(cè)試與開(kāi)發(fā)對(duì)應(yīng)圖

2.1.4 Nokia手機(jī)軟件測(cè)試介入開(kāi)發(fā)的時(shí)間

 在制定開(kāi)發(fā)計(jì)劃的同時(shí)就要制定測(cè)試計(jì)劃
 測(cè)試在進(jìn)行結(jié)構(gòu)設(shè)計(jì)時(shí)就已經(jīng)進(jìn)行了
2.1.5 Nokia手機(jī)的開(kāi)發(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, 對(duì)SW進(jìn)行精美化、完美化測(cè)試和改良
Purpose: No fatal error (市場(chǎng)部可以接受的Fatal Error不算)
 E5
From E3 to E5, 進(jìn)行LCD以及其他HW的改動(dòng)

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 測(cè)試的流程
2.2.1 制定測(cè)試計(jì)劃
 開(kāi)啟測(cè)試項(xiàng)目
 在接了一個(gè)測(cè)試項(xiàng)目后，要在一定的期限內(nèi)制定好測(cè)試的詳細(xì)計(jì)劃以及日程安排表
2.2.2 測(cè)試準(zhǔn)備
 在計(jì)劃制定好之后，在執(zhí)行之前，必須將測(cè)試所需的人力資源，硬件資源，軟件資源，文檔資源以及環(huán)境和人文資源準(zhǔn)備充分
2.2.3 測(cè)試執(zhí)行
 測(cè)試組根據(jù)測(cè)試計(jì)劃和測(cè)試日程安排進(jìn)行測(cè)試，并輸出測(cè)試結(jié)果
2.2.4 測(cè)試評(píng)估
 有測(cè)試結(jié)果評(píng)估小組或評(píng)估人員對(duì)測(cè)試結(jié)果進(jìn)行評(píng)測(cè)，分析，并輸出分析結(jié)果
2.2.5 文檔收集
 將從測(cè)試計(jì)劃開(kāi)始到評(píng)估結(jié)束的所有文檔進(jìn)行整理收集。
 對(duì)整個(gè)測(cè)試過(guò)程進(jìn)行總結(jié)，并對(duì)測(cè)試結(jié)果進(jìn)行總結(jié)
2.2.6 測(cè)試總結(jié)報(bào)告
 提交測(cè)試結(jié)果
 歸還所借相關(guān)資源
 文檔入庫(kù)
 關(guān)閉測(cè)試項(xiàng)目

2.3 測(cè)試的方法
2.3.1 正確性測(cè)試
 正確性測(cè)試又稱功能測(cè)試，它檢查軟件的功能是否符合規(guī)格說(shuō)明。
 測(cè)試基本的方法是構(gòu)造一些合理輸入（在定義域內(nèi)），檢查是否得到期望的輸出。
 由于定義域是一個(gè)連續(xù)區(qū)間，所以不可能枚舉所有可能的值，那么等價(jià)測(cè)試就很必要了（將定義域分成若干個(gè)等價(jià)區(qū)間）。
 等價(jià)區(qū)間的概念可表述如下：
記（A, B）是命題f(x) 的一個(gè)等價(jià)區(qū)間，在（A, B）中任意取x1進(jìn)行測(cè)試
如果f (x1) 錯(cuò)誤，那么f (x) 在整個(gè)（A, B）區(qū)間都將出錯(cuò)。
如果f (x1) 正確，那么f (x) 在整個(gè)（A, B）區(qū)間都將正確。
2.3.2 容錯(cuò)性測(cè)試
 容錯(cuò)性測(cè)試是檢查軟件在異常條件下的行為（輸入不同的數(shù)據(jù)類型或者定義域之外的值進(jìn)行測(cè)試）。
2.3.3 邊界性測(cè)試
 因?yàn)檫吔缫恢笔潜容^敏感的地方，而且是程序員最容易忽略的地方，所以，這種測(cè)試也往往最容易奏效。
2.3.4 性能與效率測(cè)試
 性能與效率測(cè)試主要是測(cè)試軟件的運(yùn)行速度和對(duì)資源的利用率。
 性能與效率測(cè)試中很重要的一項(xiàng)是極限測(cè)試，因?yàn)楹芏嘬浖�系統(tǒng)會(huì)在極限測(cè)試中崩潰。
2.3.5 易用性測(cè)試
 易用性測(cè)試沒(méi)有一個(gè)量化的指標(biāo)，主觀性較強(qiáng)。這主要是從End User的角度去考慮軟件是否會(huì)有一定的使用缺陷。如果對(duì)此有任何看法，可以向Team Leader反應(yīng)或者與客戶負(fù)責(zé)人直接交流。
2.3.6 文檔測(cè)試
 文檔測(cè)試主要檢查文檔的正確性、完備性和可理解性。好多人甚至不知道文檔是軟件的一個(gè)組成部分。
 我們的工作中的文檔主要是UI Spec.和Test Case。UI Spec使我們無(wú)法改變的，但是Test Case
是我們測(cè)試的對(duì)象。Test Case是我們用來(lái)測(cè)試手機(jī)軟件的參考文檔，但是它本身也有一定的局限性。所以，在測(cè)試的過(guò)程中，如果發(fā)現(xiàn)Test Case不正確或者不充分，可以直接補(bǔ)充，或者和Team Leader商議后把不足的地方補(bǔ)充起來(lái)。
2.4 測(cè)試的分類
2.4.1 按測(cè)試的手段分
 黑盒測(cè)試(White-box Test)
 Release Test
 (Full Round)SystemTest
 Focus Test
 Stress Test---No Test Case
 Free Test----No Test Case
 白盒測(cè)試(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 按測(cè)試發(fā)生的時(shí)間和目標(biāo)分
 單元測(cè)試(Module Test/Unit Test)
 集成測(cè)試(Integration Test)
 系統(tǒng)測(cè)試(System Test)
2.4.3 按測(cè)試的任務(wù)分
 現(xiàn)場(chǎng)測(cè)試(Field Test)
 互操作測(cè)試(Inter-Operatability Test)
2.4.4 其他測(cè)試
 可接受性測(cè)試(Acceptance Test)
 測(cè)試 -----------手機(jī)研發(fā)公司自己做的測(cè)試
 測(cè)試 -----------非手機(jī)研發(fā)公司做的測(cè)試
2.5 黑盒測(cè)試詳細(xì)介紹
2.5.1 Release Test
 Purpose:
 測(cè)試手機(jī)的基本功能是否實(shí)現(xiàn)，是否有進(jìn)一步測(cè)試的必要性
 Input:
 測(cè)試工程師
 Release Test Cases (較少，一般為200左右)
 手機(jī)以及相關(guān)附件
 測(cè)試環(huán)境
 Output:
 Test result of Release Test
 No Error reports (Optional)
 Attention:
 Release Test的Test Case具有一定的典型性，主要是反映手機(jī)最基本功能的Test Case
 本類測(cè)試只需要依據(jù)Test Case進(jìn)行測(cè)試，不需要進(jìn)一步發(fā)揮
 如果有發(fā)現(xiàn)與Case無(wú)關(guān)的Error, 在測(cè)試通過(guò)后才可以填報(bào)Error Report
 此類測(cè)試有一門(mén)檻值，即Test Case的Pass率達(dá)到一定值（如95%）才能宣布版本發(fā)布成功，進(jìn)入進(jìn)一步的測(cè)試，否則此版本無(wú)效。
 除了門(mén)檻值外，如果重要功能模塊的Test Case沒(méi)通過(guò)，也會(huì)終止這個(gè)版本。
2.5.2 System Test
 Full Round System Test
 Purpose
 對(duì)手機(jī)的所有功能進(jìn)行全面的測(cè)試(所有語(yǔ)言包)
 由于Case不可能包含所有方面，所以測(cè)試時(shí)應(yīng)適度發(fā)揮，盡力完成全面測(cè)試
 Input:
 測(cè)試工程師
 Test Cases(較多，一般為25000左右)
 手機(jī)以及相關(guān)附件
 測(cè)試環(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:
 對(duì)手機(jī)的一部分的功能進(jìn)行全面的測(cè)試
 由于Case不可能包含所有方面，所以測(cè)試時(shí)應(yīng)適度發(fā)揮，盡力完成全面測(cè)試
 Input:
 測(cè)試工程師
 Test Cases(較多，取決于測(cè)試的目的和范圍)
 手機(jī)以及相關(guān)附件
 測(cè)試環(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一般分為兩個(gè)部分，“跑Case”和Free Test。
 在測(cè)試初期，一般只需要按照Test Case測(cè)，把一些不可重現(xiàn)的Error都記錄下來(lái)。同時(shí)遇到Test Case的問(wèn)題或者不充分，應(yīng)該立即解決（和Team Leader或者Special List討論，補(bǔ)寫(xiě)Test Case）。在這一階段結(jié)束后，一般要寫(xiě)一個(gè)Summary Report。把這一階段的測(cè)試結(jié)果和遇到的問(wèn)題、自己的見(jiàn)解都寫(xiě)在里面（當(dāng)然是用English）。
 當(dāng)所有Test Case都測(cè)完后，就進(jìn)入Free Test期間。這里的Free Test具有明確的目的性和范圍。一般來(lái)說(shuō)，這段時(shí)間的Free Test只需要測(cè)自己負(fù)責(zé)的模塊。而且Free Test還負(fù)責(zé)重現(xiàn)前期“跑Case”是遺留的不可重現(xiàn)的Error。
2.5.3 Focus Test
 Purpose:
 集中于一個(gè)或幾個(gè)點(diǎn)進(jìn)行測(cè)試(同System Test)
 Input:
 測(cè)試工程師
 Test Cases
 手機(jī)以及相關(guān)附件
 測(cè)試環(huán)境
 Output:
 Test Result
 Error Reports
2.5.4 Stress Test
 Purpose:
 為了解決市場(chǎng)上發(fā)現(xiàn)的重大Error，而進(jìn)行的有針對(duì)性的強(qiáng)度測(cè)試
 主要是利用邊緣測(cè)試（臨界測(cè)試）手段
 Input:
 測(cè)試工程師
 手機(jī)以及相關(guān)附件
 測(cè)試環(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:
 壓力測(cè)試，顧名思義，是給手機(jī)施加一定壓力，從而找出手機(jī)軟件上的Error。一般來(lái)說(shuō)，對(duì)手
機(jī)施加的壓力主要有：
 存儲(chǔ)壓力：由于手機(jī)采用的是棧式存儲(chǔ)，所以當(dāng)一個(gè)存儲(chǔ)塊滿了之后，如果程序員不做相應(yīng)處理或者處理不好的話，很容易造成其他存儲(chǔ)區(qū)被擦除，從而在UI上出現(xiàn)問(wèn)題（其他功能無(wú)法正常使用）。
 邊界壓力：邊界一直是程序員最容易忽略的地方。
 響應(yīng)能力壓力：有時(shí)候某個(gè)操作可能處理的時(shí)間很長(zhǎng)，在處理期間如果測(cè)試者再不斷地進(jìn)行其他操作的話，很容易出現(xiàn)問(wèn)題。
 網(wǎng)絡(luò)流量壓力（如在接電話時(shí)進(jìn)行短信服務(wù)）等等。
 在項(xiàng)目中，Stress Test有時(shí)也會(huì)用來(lái)重現(xiàn)不可重現(xiàn)的Error。
 由于有不少不可重現(xiàn)的Error是由于Memory Leak(內(nèi)存泄漏)引起的，所以不停的重復(fù)同一個(gè)操作是重現(xiàn)一個(gè)不可重現(xiàn)的Error的一個(gè)好方法。
2.5.5 Free Test
 Purpose:
 測(cè)試System Test中沒(méi)有做完的不可重現(xiàn)Error
 尋找平時(shí)沒(méi)有找到的忽略的Error
 Input:
 測(cè)試工程師
 手機(jī)以及相關(guān)附件
 測(cè)試環(huán)境
 Error List of System Test (especially the irreproducible errors)
 Output:
 Error List and Error Reports
 Attention:
 在System Test階段所用的Free Test具有明顯的目的性和范圍
 平時(shí)的Free Test從理論上應(yīng)該對(duì)所測(cè)試的范圍窮盡所有的測(cè)試方法。但是，這是不現(xiàn)實(shí)的。在實(shí)際項(xiàng)目中，主要有兩個(gè)方面是Free Test所需要重視的。
 一是從UI Spec上找靈感。應(yīng)為T(mén)est Case是依據(jù)UI Spec寫(xiě)的，所以從UI Spec上突破是一個(gè)行之有效的方法。UI Spec有一定的探索深度，加大探索深度，是一種突破的途徑；另外同一個(gè)功能用其他不同的方法去實(shí)現(xiàn)，也是一種突破途徑。
 二是多關(guān)注不同F(xiàn)eature之間的Interaction。這是手機(jī)軟件相對(duì)比較容易出問(wèn)題，而Test Case又很少能反映的地方。這是一個(gè)很大的Free Test空間。
2.6 測(cè)試相關(guān)文檔說(shuō)明
2.6.1 測(cè)試計(jì)劃
 測(cè)試的任務(wù)
即需要測(cè)試什么和不需要測(cè)試什么；
 工作量估算
需要多少人，測(cè)試多少天，測(cè)試幾個(gè)周期；
 日程表
每人每天需要做什么；
 測(cè)試方法和流程
采用什么方法，遵循哪些流程；
 測(cè)試資源
需要多少人、設(shè)備、工具、文檔等資源，以及對(duì)上述資源都有哪些要求。
 測(cè)試輸出
測(cè)試中需完成的錯(cuò)誤報(bào)告（Error Report）和進(jìn)度報(bào)告（Progress Report），測(cè)試完成后需完成的總結(jié)報(bào)告（Summary Report）。
2.6.2 測(cè)試用例
 Title
標(biāo)題一般會(huì)描述出當(dāng)前要執(zhí)行的case是哪個(gè)功能模塊的，能實(shí)現(xiàn)怎樣的一個(gè)操作。標(biāo)題下面有當(dāng)前case的ID號(hào)和軟件的版本號(hào)，如Phonebook-Memory Save-Selected memory is Phone and SIM
ID: EK20010829094907
Version: 1.1.0
 Description
整體地描述這個(gè)case的測(cè)試目的，能實(shí)現(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
必需的測(cè)試環(huán)境和附件。測(cè)試環(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時(shí)的每一步操作。一般每一步操作都對(duì)應(yīng)著一個(gè)期望中的結(jié)果。執(zhí)行時(shí)可參照下面的期望結(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是相對(duì)應(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 錯(cuò)誤報(bào)告
 Title:
標(biāo)題是Error Report中非常重要的一部分，它要求簡(jiǎn)單明了地對(duì)Error作一個(gè)整體的描述，讓不知道這個(gè)Error的人看了之后能夠很清楚地知道這是個(gè)怎樣的Error。記得曾經(jīng)有人提過(guò)“3W1H”的概念。也就是說(shuō)，標(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后面，一般要寫(xiě)上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用來(lái)描述Error的嚴(yán)重程度，有三個(gè)級(jí)別：較小的、嚴(yán)重的、致命的。Fatal Error一般來(lái)說(shuō)是指影響手機(jī)系統(tǒng)工作的Error；Server Error指的是影響用戶操作的或者某些功能實(shí)現(xiàn)的Error；Minor Error指的是微小的、不影響手機(jī)功能正常使用的Error。一般的Error如中文界面中的某個(gè)字不正確，或者是英文界面中的某個(gè)單詞拼寫(xiě)不正確；左右功能鍵顯示有誤等等都屬于Minor。若手機(jī)的某個(gè)功能不能實(shí)現(xiàn)，如不能發(fā)短信，不能存電話號(hào)碼，不能進(jìn)行充電等等都屬于Severe；若手機(jī)開(kāi)不了機(jī)，或經(jīng)常死機(jī)
、重啟等則是Fatal。Severe和Fatal兩種Error對(duì)手機(jī)來(lái)說(shuō)都是很嚴(yán)重的問(wèn)題，這個(gè)具體在做項(xiàng)目時(shí)可請(qǐng)示項(xiàng)目經(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)的。如果只是某一次操作才會(huì)出現(xiàn)這個(gè)Error
，則是不可再現(xiàn)的。如果是不可再現(xiàn)錯(cuò)誤，要記錄一共出現(xiàn)過(guò)多少次，是在英文界面還是在中文界面。每
個(gè)Error都有發(fā)生的前提條件和操作步驟。嚴(yán)格的說(shuō)，每個(gè)Error都是可重現(xiàn)的。但是，發(fā)現(xiàn)這個(gè)Error的
人可能沒(méi)有能夠找到這個(gè)error的完整的前提條件或者完整的操作步驟。所以，現(xiàn)實(shí)中就有了很多不可重
現(xiàn)的Error。對(duì)于一個(gè)手機(jī)而言，硬件，軟件，語(yǔ)言包和SIM卡都是其重要的組成部分。所以，在一個(gè)手機(jī)
中用某種SIM卡在某種語(yǔ)言的UI上發(fā)現(xiàn)了某個(gè)Error，有可能在同樣的手機(jī)，同樣的SIM卡，不同的語(yǔ)言的
UI上就沒(méi)有這個(gè)Error;也有可能在同樣得手機(jī)上用不同的SIM卡也會(huì)沒(méi)有這個(gè)Error；同樣，在不同的手機(jī)
上也有可能發(fā)現(xiàn)不了這個(gè)Error�？傊�一句話，是否可重現(xiàn)，要考慮手機(jī)硬件、軟件版本、SIM卡類型、UI
類型等等相關(guān)的影響，不能簡(jiǎn)單的說(shuō)某個(gè)Error可重現(xiàn)，有的時(shí)候要加上注釋。

例如：Yes, both in English UI and Chinese UI
 Precondition:
這里寫(xiě)的是在錯(cuò)誤發(fā)生之前，手機(jī)的狀態(tài)。為了保證步驟的簡(jiǎn)潔，這里要盡可能的詳細(xì)。當(dāng)然，也不要寫(xiě)
的很羅嗦。
 How did you get to the state just before the error:
詳細(xì)描述在錯(cuò)誤發(fā)生之前你是如何到達(dá)這個(gè)狀態(tài)的，要具體到每一步的操作。在這個(gè)部分，步驟一定要清
晰、簡(jiǎn)潔，讓別人能夠輕松的理解并完成操作這個(gè)可以分成幾個(gè)步驟來(lái)寫(xiě)，如步驟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:
對(duì)發(fā)生錯(cuò)誤的描述，用簡(jiǎn)明易懂的話詳細(xì)地把這個(gè)Error描述清楚。注意幾個(gè)要點(diǎn)：“詳細(xì)”、“簡(jiǎn)明”
、“清晰易懂”。例如：
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é)果，這個(gè)在case中一般都有說(shuō)明，一般情況下，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卡是中國(guó)移動(dòng)（CMCC）還是中國(guó)聯(lián)通(CHN-CUGSM)。例如：CMCC
 SW version and Language package:
所測(cè)手機(jī)軟件的版本號(hào)可通過(guò)在待機(jī)狀態(tài)下按“*#0000#”來(lái)獲得。
我們現(xiàn)在所測(cè)的手機(jī)語(yǔ)言包大部分都是C包，語(yǔ)言包可通過(guò)下面的方法來(lái)獲得：
把手機(jī)恢復(fù)出廠設(shè)置，進(jìn)入短信的編輯窗口，此時(shí)默認(rèn)的輸入法如果是“拼音”
，則語(yǔ)言包為C包。例如：V5.20C
2.6.4 進(jìn)度報(bào)告
 工作時(shí)間（小時(shí)數(shù)）；
 測(cè)試用例執(zhí)行情況：
 Total:已經(jīng)完成的測(cè)試用例數(shù)目；
 Fail:其中出錯(cuò)的測(cè)試用例數(shù)目；
 Pass:通過(guò)的測(cè)試用例數(shù)目；
 Not Test:未測(cè)的測(cè)試用例數(shù)目；
 Not Available:無(wú)法測(cè)試的測(cè)試用例數(shù)目；
 發(fā)現(xiàn)的所有錯(cuò)誤的列表；
 執(zhí)行的所有測(cè)試用例及其結(jié)果的列表。
2.6.5 總結(jié)報(bào)告
 測(cè)試活動(dòng)的時(shí)間
 測(cè)試投入的人力
 測(cè)試效果和結(jié)論
 測(cè)試用例通過(guò)情況列表
 發(fā)現(xiàn)所有錯(cuò)誤的列表
 所有仍未關(guān)閉的錯(cuò)誤報(bào)告列表

3.1 GSM

3.2 GPRS
見(jiàn)上面文件。
3.3 CDMA

3.4 3G

4.1 Team Leader的任務(wù)和必備能力
 熟悉本組成員，包括知識(shí)、能力、經(jīng)驗(yàn)、愛(ài)好等等
 是客戶方和本組成員的接口，負(fù)責(zé)兩者之間的溝通
 負(fù)責(zé)分配本組的任務(wù)，包括制定計(jì)劃和日程安排
 總結(jié)每天的工作結(jié)果，若有重要的Error須匯報(bào)客戶方負(fù)責(zé)人
 新進(jìn)測(cè)試工程師的培訓(xùn)
 回答本組內(nèi)其他測(cè)試人員的問(wèn)題
 制作工作進(jìn)度表，隨時(shí)報(bào)告本組工作進(jìn)度
 監(jiān)督協(xié)調(diào)本組成員的工作
 收集本組成員的建議和要求
 部分測(cè)試工作
 檢查測(cè)試條件是否滿足
 控制工作質(zhì)量
4.2 Error Manager的工作內(nèi)容
 確認(rèn)Error的真實(shí)性
 確定Error的Priority和Severity
 遇到問(wèn)題時(shí)需要和客戶方負(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 測(cè)試工程師職責(zé)和應(yīng)有素質(zhì)
 Read UI Specification
 學(xué)習(xí)數(shù)據(jù)庫(kù)里的Error Report（格式、內(nèi)容和別人的思路）
 測(cè)試工作
 寫(xiě)Error Report和Test Case
 熟練使用相應(yīng)的軟件和工具
 態(tài)度明確、端正，有責(zé)任心，嚴(yán)謹(jǐn)?shù)墓ぷ髯黠L(fēng)
 良好的溝通和協(xié)調(diào)能力，積極主動(dòng)地與別人交流
 技術(shù)能力
 測(cè)試知識(shí)和技術(shù)
 編程知識(shí)和技術(shù)
 無(wú)線協(xié)議知識(shí)
 軟件知識(shí)
 硬件知識(shí)
 語(yǔ)言水平
 英語(yǔ)水平