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

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

• 類型：塞班平臺應(yīng)用大�。�1.4M語言：中文 評分：5.0
• 標(biāo)簽：

立即下載

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)一些功能，更要完善它的性能。這就需要測試人員對軟件進行評測，從而不斷地完善軟件的性能。
2.1.3 測試與開發(fā)對應(yīng)圖

2.1.4 Nokia手機軟件測試介入開發(fā)的時間

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

During E5, 可以讓生產(chǎ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)制定好測試的詳細計劃以及日程安排表
2.2.2 測試準備
 在計劃制定好之后，在執(zhí)行之前，必須將測試所需的人力資源，硬件資源，軟件資源，文檔資源以及環(huán)境和人文資源準備充分
2.2.3 測試執(zhí)行
 測試組根據(jù)測試計劃和測試日程安排進行測試，并輸出測試結(jié)果
2.2.4 測試評估
 有測試結(jié)果評估小組或評估人員對測試結(jié)果進行評測，分析，并輸出分析結(jié)果
2.2.5 文檔收集
 將從測試計劃開始到評估結(jié)束的所有文檔進行整理收集。
 對整個測試過程進行總結(jié)，并對測試結(jié)果進行總結(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進行測試
如果f (x1) 錯誤，那么f (x) 在整個（A, B）區(qū)間都將出錯。
如果f (x1) 正確，那么f (x) 在整個（A, B）區(qū)間都將正確。
2.3.2 容錯性測試
 容錯性測試是檢查軟件在異常條件下的行為（輸入不同的數(shù)據(jù)類型或者定義域之外的值進行測試）。
2.3.3 邊界性測試
 因為邊界一直是比較敏感的地方，而且是程序員最容易忽略的地方，所以，這種測試也往往最容易奏效。
2.3.4 性能與效率測試
 性能與效率測試主要是測試軟件的運行速度和對資源的利用率。
 性能與效率測試中很重要的一項是極限測試，因為很多軟件系統(tǒng)會在極限測試中崩潰。
2.3.5 易用性測試
 易用性測試沒有一個量化的指標(biāo)，主觀性較強。這主要是從End User的角度去考慮軟件是否會有一定的使用缺陷。如果對此有任何看法，可以向Team Leader反應(yīng)或者與客戶負責(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 黑盒測試詳細介紹
2.5.1 Release Test
 Purpose:
 測試手機的基本功能是否實現(xià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進行測試，不需要進一步發(fā)揮
 如果有發(fā)現(xiàn)與Case無關(guān)的Error, 在測試通過后才可以填報Error Report
 此類測試有一門檻值，即Test Case的Pass率達到一定值（如95%）才能宣布版本發(fā)布成功，進入進一步的測試，否則此版本無效。
 除了門檻值外，如果重要功能模塊的Test Case沒通過，也會終止這個版本。
2.5.2 System Test
 Full Round System Test
 Purpose
 對手機的所有功能進行全面的測試(所有語言包)
 由于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:
 對手機的一部分的功能進行全面的測試
 由于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都測完后，就進入Free Test期間。這里的Free Test具有明確的目的性和范圍。一般來說，這段時間的Free Test只需要測自己負責(zé)的模塊。而且Free Test還負責(zé)重現(xiàn)前期“跑Case”是遺留的不可重現(xiàn)的Error。
2.5.3 Focus Test
 Purpose:
 集中于一個或幾個點進行測試(同System Test)
 Input:
 測試工程師
 Test Cases
 手機以及相關(guān)附件
 測試環(huán)境
 Output:
 Test Result
 Error Reports
2.5.4 Stress Test
 Purpose:
 為了解決市場上發(fā)現(xiàn)的重大Error，而進行的有針對性的強度測試
 主要是利用邊緣測試（臨界測試）手段
 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)能力壓力：有時候某個操作可能處理的時間很長，在處理期間如果測試者再不斷地進行其他操作的話，很容易出現(xiàn)問題。
 網(wǎng)絡(luò)流量壓力（如在接電話時進行短信服務(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）和進度報告（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
詳細描述執(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的嚴重程度，有三個級別：較小的、嚴重的、致命的。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)理。
例如：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ā)生的前提條件和操作步驟。嚴格的說，每個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 UI
 Precondition:
這里寫的是在錯誤發(fā)生之前，手機的狀態(tài)。為了保證步驟的簡潔，這里要盡可能的詳細。當(dāng)然，也不要寫
的很羅嗦。
 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.
 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.
 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è)置，進入短信的編輯窗口，此時默認的輸入法如果是“拼音”
，則語言包為C包。例如：V5.20C
2.6.4 進度報告
 工作時間（小時數(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)閉的錯誤報告列表