手機軟件測試范本.doc

手機軟件測試目錄1 手機知識31.1 手機的主要功能31.1.1 通話功能31.1.2 消息功能31.1.3 電話本31.1.4 增值服務31.1.5 其他功能41.1.6 為特定語言定做的功能41.1.7 附件41.1.8 數(shù)據(jù)連通41.1.9 JAVA 程序41.2 手機的軟件結(jié)構(gòu)51.3 手機的硬件結(jié)構(gòu)61.4 Nokia手機相關(guān)知識71.4.1 Project Line of Nokia71.4.2 手機類型72 測試基礎(chǔ)82.1 測試與開發(fā)82.1.1 軟件開發(fā)的一般流程82.1.2 測試在軟件開發(fā)中的作用82.1.3 測試與開發(fā)對應圖92.1.4 Nokia手機軟件測試介入開發(fā)的時間102.1.5 Nokia手機的開發(fā)流程102.2 測試的流程112.2.1 制定測試計劃112.2.2 測試準備112.2.3 測試執(zhí)行112.2.4 測試評估112.2.5 文檔收集122.2.6 測試總結(jié)報告122.3 測試的方法122.3.1 正確性測試122.3.2 容錯性測試122.3.3 邊界性測試132.3.4 性能與效率測試132.3.5 易用性測試132.3.6 文檔測試132.4 測試的分類132.4.1 按測試的手段分132.4.2 按測試發(fā)生的時間和目標分142.4.3 按測試的任務分142.4.4 其他測試142.5 黑盒測試詳細介紹142.5.1 Release Test142.5.2 System Test152.5.3 Focus Test162.5.4 Stress Test162.5.5 Free Test172.6 測試相關(guān)文檔說明172.6.1 測試計劃172.6.2 測試用例182.6.3 錯誤報告182.6.4 進度報告202.6.5 總結(jié)報告203 手機相關(guān)213.1 GSM213.2 GPRS213.3 CDMA213.4 3G214 手機軟件測試工程師必備素質(zhì)214.1 Team Leader的任務和必備能力214.2 Error Manager的工作內(nèi)容224.3 測試工程師職責和應有素質(zhì)221 手機知識1.1 手機的主要功能1.1.1 通話功能l 對撥入撥出電話的管理l 對通話記錄的管理l 呼叫轉(zhuǎn)接、呼叫等待、通話計時計費等方便用戶使用的功能1.1.2 消息功能l 文字短消息（SMS）的編輯、發(fā)送、接收、轉(zhuǎn)發(fā)和存儲等；l 多媒體短消息（MMS）的編輯、發(fā)送、接收、轉(zhuǎn)發(fā)、存儲和配置；1.1.3 電話本l 名片的管理l 存在SIM卡上的名片l 存在手機內(nèi)存中的名片l 一個名字多項內(nèi)容（如傳真、固話、手機、Email等）l 名片的新建、修改、拷貝、轉(zhuǎn)存、刪除l 名片以紅外或短消息形式發(fā)送給其它手機l 單鍵撥號（Speed Dialing）l 號碼分組（Caller Groups）1.1.4 增值服務l Business cards 的管理 (如發(fā)送和接收: 通過紅外線或SMS. )l 書簽的管理 (如發(fā)送和接收: 通過紅外線或SMS或書簽形式. 以及編輯,存儲,新增和進入.)l 服務信箱 (自動存儲服務信息. 服務信息有點播鈴聲,下載彩色圖片和COD文件等.)l 服務設(shè)置 ( GPRS上網(wǎng)設(shè)置,WAP服務設(shè)置.)l 多模式瀏覽器 ( GPRS上網(wǎng),WAP服務.)l OTA待機圖片 (通過無線下載待機圖片)l OTA鈴聲l V-calendarl XHMLl 移動夢網(wǎng)l 動感地帶1.1.5 其他功能l 鬧鐘（Alarm）l 日歷（Calendar）l 計算器（Calculator）l 定時器（Count Down Timer）l 屏保（Screen Saver）l 待辦事項（To-Do List）l 游戲（Games）1.1.6 為特定語言定做的功能l 中文輸入（拼音/筆劃）l 中文菜單l 農(nóng)歷（Lunar Calendar）1.1.7 附件l 充電器（Charger）l 耳機（Headset）l 車載免提（Car Kit）l 照相頭（Camera）1.1.8 數(shù)據(jù)連通l GPRS 應用程序l 同步應用程序 (同步應用, 同步設(shè)置)l 紅外線應用程序l 數(shù)據(jù)線l 手機Flash程序l Trace Log1.1.9 JAVA 程序l 電子郵件l QQ程序l 應用程序l 游戲程序1.2 手機的軟件結(jié)構(gòu)DCT = Digital Core TechnologyDCT3和DCT4的區(qū)別主要在硬件結(jié)構(gòu)和UI上1.3 手機的硬件結(jié)構(gòu)l RF是手機的射頻接受和發(fā)送設(shè)備，是手機本機與無線網(wǎng)絡(luò)的接口l UEM是手機對外設(shè)備聯(lián)接的接口，包括SIM卡，充電器，電池，RF，數(shù)據(jù)線借口，紅外接口等，并提供對上述數(shù)據(jù)和信號的處理。無線信號在這里進行調(diào)制和解調(diào)。l UPP是手機的核心處理模塊。其中，DSP負責數(shù)字信號和模擬信號的轉(zhuǎn)換。UPP和UEM之間存在著接口，兩者之間的通信是通過接口進行的。UPP除了負責整個手機的操作系統(tǒng)外，還負責手機本身設(shè)備的運作，如耳機，麥克風，顯示屏等。除此之外，還負責緩存和Flash(相當于硬盤)的運作。l 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 Nokia1.4.2 手機類型l MEP = Mobile Entry Phonel MP = Mobile Phonel MSW = Mobile Softwarel SWEP = software engineer product2 測試基礎(chǔ)2.1 測試與開發(fā)2.1.1 軟件開發(fā)的一般流程l Marketingl Requirement Analysisl High Level Designl Low Level Designl Coding2.1.2 測試在軟件開發(fā)中的作用l 由于現(xiàn)在軟件的規(guī)模越來越大，一個人或者少數(shù)幾個人已經(jīng)不可能在一定的時間內(nèi)完成一個軟件，所以軟件開發(fā)的過程越來越復雜，層次越來越深。這就導致開發(fā)人員之間的溝通有了一定的隔閡。所以，軟件測試越來越有單立出來的必要和重要性。l 由于軟件開發(fā)的過程的復雜性，軟件必然存在著無數(shù)的Bug。而且大多數(shù)是在軟件上市前必須解決的，而開發(fā)者有不定能發(fā)現(xiàn)這些問題，故而測試就顯得非常必要。測試是開發(fā)成功的必要保障。l 由于軟件開發(fā)的層次性，所以開發(fā)的結(jié)果很可能與初衷不一樣，這就需要測試者去發(fā)現(xiàn)這些差異。因此，測試是軟件成功的重要保證。l 軟件不僅要實現(xiàn)一些功能，更要完善它的性能。這就需要測試人員對軟件進行評測，從而不斷地完善軟件的性能。2.1.3 測試與開發(fā)對應圖2.1.4 Nokia手機軟件測試介入開發(fā)的時間l 在制定開發(fā)計劃的同時就要制定測試計劃l 測試在進行結(jié)構(gòu)設(shè)計時就已經(jīng)進行了2.1.5 Nokia手機的開發(fā)流程l E-1During 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.l E0During this period, the HW designer must make out the B0-HW version.That is to say, B0 must be put out after E0 period.l E0.5綜合考慮HW, SW and Costl E1From E0 to E1, Design and Test Plan, Risk, Organization, Schedule must be discussed and made out. l E1.5全體討論Design and Test Specificationl E1.9From 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.l E2During E2, The formal draft SW should be made out.l E3From E2 to E3, 對SW進行精美化、完美化測試和改良Purpose: No fatal error (市場部可以接受的Fatal Error不算)l E5From E3 to E5, 進行LCD以及其他HW的改動During E5, 可以讓生產(chǎn)工廠進行大批量生產(chǎn)l Before E5, the test stays in the CE (concurrent engineer)After E5, the test goes into PE (production engineer)2.2 測試的流程2.2.1 制定測試計劃l 開啟測試項目l 在接了一個測試項目后，要在一定的期限內(nèi)制定好測試的詳細計劃以及日程安排表2.2.2 測試準備l 在計劃制定好之后，在執(zhí)行之前，必須將測試所需的人力資源，硬件資源，軟件資源，文檔資源以及環(huán)境和人文資源準備充分2.2.3 測試執(zhí)行l(wèi) 測試組根據(jù)測試計劃和測試日程安排進行測試，并輸出測試結(jié)果2.2.4 測試評估l 有測試結(jié)果評估小組或評估人員對測試結(jié)果進行評測，分析，并輸出分析結(jié)果2.2.5 文檔收集l 將從測試計劃開始到評估結(jié)束的所有文檔進行整理收集。l 對整個測試過程進行總結(jié)，并對測試結(jié)果進行總結(jié)2.2.6 測試總結(jié)報告l 提交測試結(jié)果l 歸還所借相關(guān)資源l 文檔入庫l 關(guān)閉測試項目2.3 測試的方法2.3.1 正確性測試l 正確性測試又稱功能測試，它檢查軟件的功能是否符合規(guī)格說明。l 測試基本的方法是構(gòu)造一些合理輸入（在定義域內(nèi)），檢查是否得到期望的輸出。l 由于定義域是一個連續(xù)區(qū)間，所以不可能枚舉所有可能的值，那么等價測試就很必要了（將定義域分成若干個等價區(qū)間）。l 等價區(qū)間的概念可表述如下：記（A, B）是命題f(x) 的一個等價區(qū)間，在（A, B）中任意取x1進行測試如果f (x1) 錯誤，那么f (x) 在整個（A, B）區(qū)間都將出錯。如果f (x1) 正確，那么f (x) 在整個（A, B）區(qū)間都將正確。2.3.2 容錯性測試l 容錯性測試是檢查軟件在異常條件下的行為（輸入不同的數(shù)據(jù)類型或者定義域之外的值進行測試）。2.3.3 邊界性測試l 因為邊界一直是比較敏感的地方，而且是程序員最容易忽略的地方，所以，這種測試也往往最容易奏效。2.3.4 性能與效率測試l 性能與效率測試主要是測試軟件的運行速度和對資源的利用率。l 性能與效率測試中很重要的一項是極限測試，因為很多軟件系統(tǒng)會在極限測試中崩潰。2.3.5 易用性測試l 易用性測試沒有一個量化的指標，主觀性較強。這主要是從End User的角度去考慮軟件是否會有一定的使用缺陷。如果對此有任何看法，可以向Team Leader反應或者與客戶負責人直接交流。2.3.6 文檔測試l 文檔測試主要檢查文檔的正確性、完備性和可理解性。好多人甚至不知道文檔是軟件的一個組成部分。l 我們的工作中的文檔主要是UI Spec.和Test Case。UI Spec使我們無法改變的，但是Test Case是我們測試的對象。Test Case是我們用來測試手機軟件的參考文檔，但是它本身也有一定的局限性。所以，在測試的過程中，如果發(fā)現(xiàn)Test Case不正確或者不充分，可以直接補充，或者和Team Leader商議后把不足的地方補充起來。2.4 測試的分類2.4.1 按測試的手段分l 黑盒測試(White-box Test)n Release Testn (Full Round)SystemTestn Focus Testn Stress Test-No Test Casen Free Test-No Test Casel 白盒測試(Black-box Test)n Module Testn Sub-System Testn Sub-System Integration Testn System Integration Testn Integration TestThe feature groups for Integration Test are decided by Integrator and provided by SW Component Factory.2.4.2 按測試發(fā)生的時間和目標分l 單元測試(Module Test/Unit Test)l 集成測試(Integration Test)l 系統(tǒng)測試(System Test)2.4.3 按測試的任務分l 現(xiàn)場測試(Field Test)l 互操作測試(Inter-Operatability Test)2.4.4 其他測試l 可接受性測試(Acceptance Test)l a測試 -手機研發(fā)公司自己做的測試l b測試 -非手機研發(fā)公司做的測試2.5 黑盒測試詳細介紹2.5.1 Release Testl Purpose:n 測試手機的基本功能是否實現(xiàn)，是否有進一步測試的必要性l Input:n 測試工程師n Release Test Cases (較少，一般為200左右)n 手機以及相關(guān)附件n 測試環(huán)境l Output:n Test result of Release Testn No Error reports (Optional)l Attention:n Release Test的Test Case具有一定的典型性，主要是反映手機最基本功能的Test Casen 本類測試只需要依據(jù)Test Case進行測試，不需要進一步發(fā)揮n 如果有發(fā)現(xiàn)與Case無關(guān)的Error, 在測試通過后才可以填報Error Reportn 此類測試有一門檻值，即Test Case的Pass率達到一定值（如95%）才能宣布版本發(fā)布成功，進入進一步的測試，否則此版本無效。n 除了門檻值外，如果重要功能模塊的Test Case沒通過，也會終止這個版本。2.5.2 System Testl Full Round System Testn Purposeu 對手機的所有功能進行全面的測試(所有語言包)u 由于Case不可能包含所有方面，所以測試時應適度發(fā)揮，盡力完成全面測試n Input:u 測試工程師u Test Cases(較多，一般為25000左右)u 手機以及相關(guān)附件u 測試環(huán)境u Schedulen Output:u Daily Report of test cases (number & percent of Pass, Error, NA, NT)u Summary Reportu Error list and Error reportsl Common System Test (Medium or Minor)n Purpose:u 對手機的一部分的功能進行全面的測試u 由于Case不可能包含所有方面，所以測試時應適度發(fā)揮，盡力完成全面測試n Input:u 測試工程師u Test Cases(較多，取決于測試的目的和范圍)u 手機以及相關(guān)附件u 測試環(huán)境u Schedulen Output:u Daily Report of test cases (number & percent of Pass, Error, NA, NT)u Summary Reportu Error list and Error reportsl Attention:n System Test一般分為兩個部分，“跑Case”和Free Test。n 在測試初期，一般只需要按照Test Case測，把一些不可重現(xiàn)的Error都記錄下來。同時遇到Test Case的問題或者不充分，應該立即解決（和Team Leader或者Special List討論，補寫Test Case）。在這一階段結(jié)束后，一般要寫一個Summary Report。把這一階段的測試結(jié)果和遇到的問題、自己的見解都寫在里面（當然是用English）。n 當所有Test Case都測完后，就進入Free Test期間。這里的Free Test具有明確的目的性和范圍。一般來說，這段時間的Free Test只需要測自己負責的模塊。而且Free Test還負責重現(xiàn)前期“跑Case”是遺留的不可重現(xiàn)的Error。2.5.3 Focus Testl Purpose:n 集中于一個或幾個點進行測試(同System Test)l Input:n 測試工程師n Test Casesn 手機以及相關(guān)附件n 測試環(huán)境l Output:n Test Resultn Error Reports2.5.4 Stress Testl Purpose:n 為了解決市場上發(fā)現(xiàn)的重大Error，而進行的有針對性的強度測試n 主要是利用邊緣測試（臨界測試）手段l Input:n 測試工程師n 手機以及相關(guān)附件n 測試環(huán)境n Focus List of Phone Featuresl Output:n Expected result: find out the reproducible steps of these errorsn Decrease the steps as possible as we canl Attention:n 壓力測試，顧名思義，是給手機施加一定壓力，從而找出手機軟件上的Error。一般來說，對手機施加的壓力主要有：u 存儲壓力：由于手機采用的是棧式存儲，所以當一個存儲塊滿了之后，如果程序員不做相應處理或者處理不好的話，很容易造成其他存儲區(qū)被擦除，從而在UI上出現(xiàn)問題（其他功能無法正常使用）。u 邊界壓力：邊界一直是程序員最容易忽略的地方。u 響應能力壓力：有時候某個操作可能處理的時間很長，在處理期間如果測試者再不斷地進行其他操作的話，很容易出現(xiàn)問題。u 網(wǎng)絡(luò)流量壓力（如在接電話時進行短信服務）等等。n 在項目中，Stress Test有時也會用來重現(xiàn)不可重現(xiàn)的Error。n 由于有不少不可重現(xiàn)的Error是由于Memory Leak(內(nèi)存泄漏)引起的，所以不停的重復同一個操作是重現(xiàn)一個不可重現(xiàn)的Error的一個好方法。2.5.5 Free Testl Purpose:n 測試System Test中沒有做完的不可重現(xiàn)Errorn 尋找平時沒有找到的忽略的Errorl Input:n 測試工程師n 手機以及相關(guān)附件n 測試環(huán)境n Error List of System Test (especially the irreproducible errors)l Output:n Error List and Error Reportsl Attention:n 在System Test階段所用的Free Test具有明顯的目的性和范圍n 平時的Free Test從理論上應該對所測試的范圍窮盡所有的測試方法。但是，這是不現(xiàn)實的。在實際項目中，主要有兩個方面是Free Test所需要重視的。u 一是從UI Spec上找靈感。應為Test Case是依據(jù)UI Spec寫的，所以從UI Spec上突破是一個行之有效的方法。UI Spec有一定的探索深度，加大探索深度，是一種突破的途徑；另外同一個功能用其他不同的方法去實現(xiàn)，也是一種突破途徑。u 二是多關(guān)注不同F(xiàn)eature之間的Interaction。這是手機軟件相對比較容易出問題，而Test Case又很少能反映的地方。這是一個很大的Free Test空間。2.6 測試相關(guān)文檔說明2.6.1 測試計劃l 測試的任務即需要測試什么和不需要測試什么；l 工作量估算需要多少人，測試多少天，測試幾個周期；l 日程表每人每天需要做什么；l 測試方法和流程采用什么方法，遵循哪些流程；l 測試資源需要多少人、設(shè)備、工具、文檔等資源，以及對上述資源都有哪些要求。l 測試輸出測試中需完成的錯誤報告（Error Report）和進度報告（Progress Report），測試完成后需完成的總結(jié)報告（Summary Report）。2.6.2 測試用例l Title標題一般會描述出當前要執(zhí)行的case是哪個功能模塊的，能實現(xiàn)怎樣的一個操作。標題下面有當前case的ID號和軟件的版本號，如Phonebook-Memory Save-Selected memory is Phone and SIMID:EK20010829094907Version:1.1.0l 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.l Required test environment and accessories必需的測試環(huán)境和附件。測試環(huán)境包括硬件環(huán)境和軟件環(huán)境。例如：HW, ESIM，Headset.l Precondition描述執(zhí)行case的前提條件。例如：Select memory in use to be Phone and SIM. Return to the Idle State.l Action詳細描述執(zhí)行case時的每一步操作。一般每一步操作都對應著一個期望中的結(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.l Expected result描述執(zhí)行該case的期望中的結(jié)果，與上面的操作Action是相對應的。例如：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 錯誤報告l Title:標題是Error Report中非常重要的一部分，它要求簡單明了地對Error作一個整體的描述，讓不知道這個Error的人看了之后能夠很清楚地知道這是個怎樣的Error。記得曾經(jīng)有人提過“3W1H”的概念。也就是說，標題里面應該包括What is the error, When will the error appear, Wheremay the error appear and Howto make the errorappear. 在Title后面，一般要寫上Feature Group的名字。例如：Title: Call register: The phone doesnt remain in the same state after rejecting a call when viewing items under full window choice items in call register.l Severity (Fatal/Severe/Minor):Severity用來描述Error的嚴重程度，有三個級別：較小的、嚴重的、致命的。Fatal Error一般來說是指影響手機系統(tǒng)工作的Error；Server Error指的是影響用戶操作的或者某些功能實現(xiàn)的Error；Minor Error指的是微小的、不影響手機功能正常使用的Error。一般的Error如中文界面中的某個字不正確，或者是英文界面中的某個單詞拼寫不正確；左右功能鍵顯示有誤等等都屬于Minor。若手機的某個功能不能實現(xiàn)，如不能發(fā)短信，不能存電話號碼，不能進行充電等等都屬于Severe；若手機開不了機，或經(jīng)常死機、重啟等則是Fatal。Severe和Fatal兩種Error對手機來說都是很嚴重的問題，這個具體在做項目時可請示項目經(jīng)理。例如：Minorl 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ā)生的前提條件和操作步驟。嚴格的說，每個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?？傊痪湓?，是否可重現(xiàn)，要考慮手機硬件、軟件版本、SIM卡類型、UI類型等等相關(guān)的影響，不能簡單的說某個Error可重現(xiàn)，有的時候要加上注釋。例如：Yes, both in English UI and Chinese UIl Precondition:這里寫的是在錯誤發(fā)生之前，手機的狀態(tài)。為了保證步驟的簡潔，這里要盡可能的詳細。當然，也不要寫的很羅嗦。l How did you get to the state just before the error:詳細描述在錯誤發(fā)生之前你是如何到達這個狀態(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.l Description of the error:對發(fā)生錯誤的描述，用簡明易懂的話詳細地把這個Error描述清楚。注意幾個要點：“詳細”、“簡明”、“清晰易懂”。例如：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.l Description of expected result:描述期望的操作結(jié)果，這個在case中一般都有說明，一般情況下，case的執(zhí)行結(jié)果就是期望的操作結(jié)果。這里描述的是，期望情況下，“應該”是什么結(jié)果.例如：The phone should remain in the same state just as before receiving a call.l SIM card used:所用的SIM卡是中國移動（CMCC）還是中國聯(lián)通(CHN-CUGSM)。例如：CMCCl SW version and Language package:所測手機軟件的版本號可通過在待機狀態(tài)下按“*#0000#”來獲得。我們現(xiàn)在所測的手機語言包大部分都是C包，語言包可通過下面的方法來獲得：把手機恢復出廠設(shè)置，進入短信的編輯窗口，此時默認的輸入法如果是“拼音”，則語言包為C包。例如：V5.20C2.6.4 進度報告l 工作時間（小時數(shù)）；l 測試用例執(zhí)行情況：n Total:已經(jīng)完成的測試用例數(shù)目；n Fail:其中出錯的測試用例數(shù)目；n Pass:通過的測試用例數(shù)目；n Not Test:未測的測試用例數(shù)目；n Not Available:無法測試的測試用例數(shù)目；l 發(fā)現(xiàn)的所有錯誤的列表；l 執(zhí)行的所有測試用例及其結(jié)果的列表。2.6.5 總結(jié)報告l 測試活動的時間l 測試投入的人力l 測試效果和結(jié)論l 測試用例通過情況列表l 發(fā)現(xiàn)所有錯誤的列表l 所有仍未關(guān)閉的錯誤報告列表3 手機相關(guān)3.1 GSM3.2 GPRS見上面文件。3.3 CDMA3.4 3G 4 手機軟件測試工程師必備素質(zhì)4.1 Team Leader的任務和必備能力l 熟悉本組成員，包括知識、能力、經(jīng)驗、愛好等等l 是客戶方和本組成員的接口，負責兩者之間的溝通l 負責分配本組的任務，包括制定計劃和日程安排l 總結(jié)每天的工作結(jié)果，若有重要的Error須匯報客戶方負責人l 新進測試工程師的培訓l 回答本組內(nèi)其他測試人員的問題l 制作工作進度表，隨時報告本組工作進度l 監(jiān)督協(xié)調(diào)本組成員的工作l 收集本組成員的建議和要求l 部分測試工作l 檢查測試條件是否滿足l 控制工作質(zhì)量4.2 Error Manager的工作內(nèi)容l 確認Error的真實性l 確定Error的Priority和Severityl 遇到問題時需要和客戶方負責人商量l The daily work of an error manager is handling errors and answer questions asked by testers, engineer