第一篇：APP測試流程,測試用例,計劃,報告可參照（寫寫幫推薦）

移動APP測試流程及測試點

1.APP測試基本流程

1.1.測試周期

測試周期可按項目的開發(fā)周期來確定測試時間，一般測試時間為兩三周（即15個工作日），根據(jù)項目情況以及版本質(zhì)量可適當(dāng)縮短或延長測試時間。正式測試前先向負責(zé)人確認項目排期。

1.2.測試資源

測試任務(wù)開始前，檢查各項測試資源。

--產(chǎn)品功能需求文檔；

--產(chǎn)品原型圖；

--產(chǎn)品效果圖；

--行為統(tǒng)計分析定義文檔；

--測試設(shè)備（ios7.1-ios9.2；Android4.0-Android6.0；）；

--其他。

1.3.日報、周報及APP上線報告

1）測試人員每天需對所測項目發(fā)送測試日報。

2）測試日報所包含的內(nèi)容為：

--對當(dāng)前測試版本質(zhì)量進行分級（高中低）；

--對較嚴重的問題進行例舉，提示開發(fā)人員優(yōu)先修改；

--對版本的整體情況進行評估。

3）APP上線前，測試人員發(fā)送APP上線報告。4）上線報告所包含的內(nèi)容為：

--對當(dāng)前版本質(zhì)量進行分級；

--附上測試報告（功能測試報告、兼容性測試報告、性能測試報告以及app可用性能標準結(jié)果）；

--總結(jié)上線版本的基本情況。若有遺留問題必須列出并記錄解決方案。5）周報作為匯總本周所有的情況，以及開發(fā)人員修改情況與回歸測試。

2.APP測試點

2.1.安全測試

2.1.1.軟件權(quán)限

1）扣費風(fēng)險：包括發(fā)送短信、撥打電話、連接網(wǎng)絡(luò)等；

2）隱私泄露風(fēng)險：包括訪問手機信息、訪問聯(lián)系人信息等；

3）對App的輸入有效性校驗、認證、授權(quán)、敏感數(shù)據(jù)存儲、數(shù)據(jù)加密等方面進行檢測；

4）限制/允許使用手機功能接人互聯(lián)網(wǎng)；

5）限制/允許使用手機發(fā)送接受信息功能；

6）限制/允許應(yīng)用程序來注冊自動啟動應(yīng)用程序；

7）限制或使用本地連接；

8）限制/允許使用手機拍照或錄音；

9）限制/允許使用手機讀取用戶數(shù)據(jù)；

10)限制/允許使用手機寫人用戶數(shù)據(jù)；

11)檢測App的用戶授權(quán)級別、數(shù)據(jù)泄漏、非法授權(quán)訪問等。2.1.2.安裝與卸載的安全性

1）應(yīng)用程序應(yīng)能正確安裝到設(shè)備驅(qū)動程序上；

2）能夠在安裝設(shè)備驅(qū)動程序上找到應(yīng)用程序的相應(yīng)圖標；

3）是否包含數(shù)字簽名信息；

4）JAD文件和JAR包中包含的所有托管屬性及其值必需是正確的；

5）JAD文件顯示的資料內(nèi)容與應(yīng)用程序顯示的資料內(nèi)容應(yīng)一致；

6）安裝路徑應(yīng)能指定；

7）沒有用戶的允許, 應(yīng)用程序不能預(yù)先設(shè)定自動啟動；

8）卸載是否安全, 其安裝進去的文件是否全部卸載；

9）卸載用戶使用過程中產(chǎn)生的文件是否有提示；

10）其修改的配置信息是否復(fù)原；

11）卸載是否影響其他軟件的功能；

12）卸載應(yīng)該移除所有的文件。

2.1.3.數(shù)據(jù)安全性

1）當(dāng)將密碼或其他的敏感數(shù)據(jù)輸人到應(yīng)用程序時, 其不會被儲存在設(shè)備中, 同時密碼也不會被解碼；

2）輸人的密碼將不以明文形式進行顯示；

3）密碼, 信用卡明細, 或其他的敏感數(shù)據(jù)將不被儲存在它們預(yù)輸人的位置上；

4）防止應(yīng)用程序異常終止而又沒有刪除它的臨時文件, 文件可能遭受人侵者的襲擊, 然后讀取這些數(shù)據(jù)信息；

5）當(dāng)將敏感數(shù)據(jù)輸人到應(yīng)用程序時, 其不會被儲存在設(shè)備中；

6）在數(shù)據(jù)刪除之前，應(yīng)用程序應(yīng)當(dāng)通知用戶或者應(yīng)用程序提供一個“取消”命令的操作；

7）“取消”命令操作能夠按照設(shè)計要求實現(xiàn)其功能；

8）應(yīng)用程序應(yīng)當(dāng)能夠處理當(dāng)不允許應(yīng)用軟件連接到個人信息管理的情況；

9）當(dāng)進行讀或?qū)懹脩粜畔⒉僮鲿r, 應(yīng)用程序?qū)蛴脩舭l(fā)送一個操作錯誤 的提示信息；

10）在沒有用戶明確許可的前提下不損壞刪除個人信息管理應(yīng)用程序中的任 何內(nèi)容；

11）應(yīng)用程序讀和寫數(shù)據(jù)正確；

12）應(yīng)用程序應(yīng)當(dāng)有異常保護；

13）如果數(shù)據(jù)庫中重要的數(shù)據(jù)正要被重寫, 應(yīng)及時告知用戶；

14）能合理地處理出現(xiàn)的錯誤；

25）意外情況下應(yīng)提示用戶。

2.1.4.通訊安全性

1）在運行其軟件過程中, 如果有來電、SMS、EMS、MMS、藍牙、紅外等通訊或充電時, 是否能暫停程序，優(yōu)先處理通信, 并在處理完畢后能正?；謴?fù)軟件, 繼續(xù)其原來的功能；

2）當(dāng)創(chuàng)立連接時, 應(yīng)用程序能夠處理因為網(wǎng)絡(luò)連接中斷, 進而告訴用戶連接中斷的情況；

3）應(yīng)能處理通訊延時或中斷；

4）應(yīng)用程序?qū)⒈３止ぷ鞯酵ㄓ嵆瑫r, 進而發(fā)送給用戶一個錯誤信息指示有連接錯誤；

5）應(yīng)能處理網(wǎng)絡(luò)異常和及時將異常情況通報用戶；

6）應(yīng)用程序關(guān)閉或網(wǎng)絡(luò)連接不再使用時應(yīng)及時關(guān)閉)斷開；

7)HTTP、HTTPS覆蓋測試

--App和后臺服務(wù)一般都是通過HTTP來交互的，驗證HTTP環(huán)境下是否正常；

--公共免費網(wǎng)絡(luò)環(huán)境中（如：麥當(dāng)勞、星巴克等）都要輸入用戶名和密碼，通過SSL認證來訪問網(wǎng)絡(luò)，需要對使用HTTP Client的library異常作捕獲處理。

2.1.5.人機接口安全性

1）返回菜單總保持可用；

2）命令有優(yōu)先權(quán)順序；

3）聲音的設(shè)置不影響應(yīng)用程序的功能；

4）應(yīng)用程序必需利用目標設(shè)備適用的全屏尺寸來顯示上述內(nèi)容；

5）應(yīng)用程序必需能夠處理不可預(yù)知的用戶操作, 例如錯誤的操作和同時按下多個鍵。

2.2.安裝卸載測試

驗證App是否能正確安裝、運行、卸載及操作過程和操作前后對系統(tǒng)資源的使用情況。

2.2.1.安裝

1）軟件在不同操作系統(tǒng)（Android、iOS）下安裝是否正常；

2）軟件安裝后的是否能夠正常運行，安裝后的文件夾及文件是否寫到了指定的目錄里；

3）軟件安裝各個選項的組合是否符合概要設(shè)計說明；

4)）軟件安裝向?qū)У腢I測試；

5）軟件安裝過程是否可以取消，點擊取消后，寫入的文件是否如概要設(shè)計說明處理；

6）軟件安裝過程中意外情況的處理是否符合需求（如死機，重啟，斷電）； 7）安裝空間不足時是否有相應(yīng)提示；

8）安裝后沒有生成多余的目錄結(jié)構(gòu)和文件；

9）對于需要通過網(wǎng)絡(luò)驗證之類的安裝，在斷網(wǎng)情況下嘗試一下；

10）還需要對安裝手冊進行測試，依照安裝手冊是否能順利安裝。

2.2.2.卸載

1）直接刪除安裝文件夾卸載是否有提示信息；

2）測試系統(tǒng)直接卸載程序是否有提示信息；

3）測試卸載后文件是否全部刪除所有的安裝文件夾；

4）卸載過程中出現(xiàn)的意外情況的測試（如死機、斷電、重啟）；

5）卸載是否支持取消功能，單擊取消后軟件卸載的情況；

6）系統(tǒng)直接卸載UI測試，是否有卸載狀態(tài)進度條提示。

2.3.UI測試

測試用戶界面(如菜單、對話框、窗口和其它可規(guī)控件)布局、風(fēng)格是否滿足客戶要求、文字是否正確、頁面是否美觀、文字、圖片組合是否完美、操作是否友好等。

UI測試的目標是確保用戶界面會通過測試對象的功能來為用戶提供相應(yīng)的訪問或瀏覓功能。確保用戶界面符合公司或行業(yè)的標準。包括用戶友好性、人性化、易操作性測試。

2.3.1.導(dǎo)航測試

1）按鈕、對話框、列表和窗口等；或在不同的連接頁面之間需要導(dǎo)航；

2）是否易于導(dǎo)航，導(dǎo)航是否直觀； 3）是否需要搜索引擎；

4）導(dǎo)航幫助是否準確直觀；

5）導(dǎo)航與頁面結(jié)構(gòu)、菜單、連接頁面的風(fēng)格是否一致。

2.3.2.圖形測試

1）橫向比較。各控件操作方式統(tǒng)一；

2）自適應(yīng)界面設(shè)計，內(nèi)容根據(jù)窗口大小自適應(yīng)；

3）頁面標簽風(fēng)格是否統(tǒng)一；

4）頁面是否美觀；

5）頁面的圖片應(yīng)有其實際意義而要求整體有序美觀；

6）圖片質(zhì)量要高且圖片尺寸在設(shè)計符合要求的情況下應(yīng)盡量?。?/p>

7）界面整體使用的顏色不宜過多。

2.3.3.內(nèi)容測試

1）輸入框說明文字的內(nèi)容與系統(tǒng)功能是否一致；

2）文字長度是否加以限制；

3）文字內(nèi)容是否表意不明；

4）是否有錯別字；

5）信息是否為中文顯示；

6）是否有敏感性詞匯、關(guān)鍵詞；

7）是否有敏感性圖片，如：涉及版權(quán)、專利、隱私等圖片。

2.4.功能測試

根據(jù)軟件說明或用戶需求驗證App的各個功能實現(xiàn)，采用如下方法實現(xiàn)并評估功能測試過程： 1)采用時間、地點、對象、行為和背景五元素或業(yè)務(wù)分析等方法分析、提煉App的用戶使用場景，對比說明或需求，整理出內(nèi)在、外在及非功能直接相關(guān)的需求，構(gòu)建測試點，并明確測試標準，若用戶需求中無明確標準遵循，則需要參考行業(yè)或相關(guān)國際標準或準則。

2)根據(jù)被測功能點的特性列丼出相應(yīng)類型的測試用例對其進行覆蓋，如；涉及輸入的地方需要考慮等價、邊界、負面、異?；蚍欠?、場景回滾、關(guān)聯(lián)測試等測試類型對其進行覆蓋。

3)在測試實現(xiàn)的各個階段跟蹤測試實現(xiàn)與需求輸入的覆蓋情況，及時修正業(yè)務(wù)或需求理解錯誤。

2.4.1.運行

1）App安裝完成后的試運行，可正常打開軟件；

2）App打開測試，是否有加載狀態(tài)進度提示；

3）App打開速度測試，速度是否可觀；

4）App頁面間的切換是否流暢，邏輯是否正確；

5）注冊

--同表單編輯頁面--用戶名密碼長度；

--注冊后的提示頁面；

--前臺注冊頁面和后臺的管理頁面數(shù)據(jù)是否一致；

--注冊后，在后臺管理中頁面提示；

6）登錄

--使用合法的用戶登錄系統(tǒng)；

--系統(tǒng)是否允許多次非法的登陸，是否有次數(shù)限制；--使用已經(jīng)登陸的賬號登陸系統(tǒng)是否正確處理；

--使用禁用的賬號登陸系統(tǒng)是否正確處理；

--用戶名、口令（密碼）錯誤或漏填時能否登陸；

--刪除或修改后的用戶，原用戶登陸；

--不輸入用戶口令和用戶、重復(fù)點（確定或取消按鈕）是否允許登陸；

--登陸后，頁面中登陸信息；--頁面中有注銷按鈕；--登陸超時的處理；

7）注銷

--注銷原模塊，新的模塊系統(tǒng)能否正確處理；

--終止注銷能否返回原模塊，原用戶；

--注銷原用戶，新用戶系統(tǒng)能否正確處理；

--使用錯誤的賬號、口令、無權(quán)限的被禁用的賬號進行注銷。

2.4.2.APP前后臺切換

1)APP切換到后臺，再回到app，檢查是否停留在上一次操作界面；

2)APP切換到后臺，再回到app，檢查功能及應(yīng)用狀態(tài)是否正常，安卓和IOS的版本的處理機制有的不一樣；

3)app切換到后臺，再回到前臺時，注意程序是否崩潰，功能狀態(tài)是否正常，尤其是對于從后臺切換回前臺數(shù)據(jù)有自動更新的時候；

4)手機鎖屏解屏后進入app注意是否會崩潰，功能狀態(tài)是否正常，尤其是對于從后臺切換回前臺數(shù)據(jù)有自動更新的時候；

5)當(dāng)App使用過程中有電話進來中斷后再切換到app，功能狀態(tài)是否正常； 6)當(dāng)殺掉app進程后，再開啟app，app能否正常啟動；

7)出現(xiàn)必須處理的提示框后，切換到后臺，再切換回來，檢查提示框是否還存在，有時候會出現(xiàn)應(yīng)用自動跳過提示框的缺陷；

8)對于有數(shù)據(jù)交換的頁面，每個頁面都必需要進行前后臺切換、鎖屏的測試，這種頁面最容易出現(xiàn)崩潰。

2.4.3.自動登陸

很多應(yīng)用提供自動登錄功能，當(dāng)應(yīng)用開啟時自動以上一次登錄的用戶身份來使用app.1)app有免登錄功能時，需要考慮IOS與安卓版本差異；

2)考慮無網(wǎng)絡(luò)情況時能否正常進入免登錄狀態(tài)；

3)切換用戶登錄后，要校驗用戶登錄信息及數(shù)據(jù)內(nèi)容是否相應(yīng)更新，確保原用戶退出；

4)根據(jù)MTOP的現(xiàn)有規(guī)則，一個帳戶只允許登錄一臺機器。所以，需要檢查一個帳戶登錄多臺手機的情況。原手機里的用戶需要被踢出，給出友好提示；

5)app切換到后臺，再切回前臺的校驗；

6)切換到后臺，再切換回前臺的測試

7)密碼更換后，檢查有數(shù)據(jù)交換時是否進行了有效身份的校驗；

8)支持自動登錄的應(yīng)用在進行數(shù)據(jù)交換時，檢查系統(tǒng)是否能自動登錄成功并且數(shù)據(jù)操作無誤；

9)檢查用戶主動退出登錄后，下次啟動app，應(yīng)停留在登錄界面

2.4.4.數(shù)據(jù)更新

根據(jù)應(yīng)用的業(yè)務(wù)規(guī)則，以及數(shù)據(jù)更新量的情況，來確定最優(yōu)的數(shù)據(jù)更新方案。

1)需要確定哪些地方需要提供手動刷新，哪些地方需要自動刷新，哪些地方需要手動+自動刷新；

2)確定哪些地方從后臺切換回前臺時需要進行數(shù)據(jù)更新；

3)根據(jù)業(yè)務(wù)、速度及流量的合理分配，確定哪些內(nèi)容需要實時更新，哪些需要 定時更新；

4)確定數(shù)據(jù)展示部分的處理邏輯，是每次從服務(wù)端請求，還是有緩存到本地，這樣才能有針對性的進行相應(yīng)測試；

5)檢查有數(shù)據(jù)交換的地方，均有相應(yīng)的異常處理。

2.4.5.離線瀏覽

很多應(yīng)用會支持離線瀏覽，即在本地客戶端會緩存一部分數(shù)據(jù)供用戶查看。

1)在無網(wǎng)絡(luò)情況可以瀏覽本地數(shù)據(jù)；

2)退出app再開啟app時能正常瀏覽；

3)切換到后臺再切回前臺可以正常瀏覽；

4)鎖屏后再解屏回到應(yīng)用前臺可以正常瀏覽；

5)在對服務(wù)端的數(shù)據(jù)有更新時會給予離線的相應(yīng)提示

2.4.6.APP更新

1)當(dāng)客戶端有新版本時，有更新提示；

2)當(dāng)版本為非強制升級版時，用戶可以取消更新，老版本能正常使用。用戶在下次啟動app時，仍能出現(xiàn)更新提示；

3)當(dāng)版本為強制升級版時，當(dāng)給出強制更新后用戶沒有做更新時，退出客戶端。下次啟動app時，仍出現(xiàn)強制升級提示。

4)當(dāng)客戶端有新版本時，在本地不刪除客戶端的情況下，直接更新檢查是否能正常更新；

5)當(dāng)客戶端有新版本時，在本地不刪除客戶端的情況下，檢查更新后的客戶端功能是否是新版本；

6)當(dāng)客戶端有新版本時，在本地不刪除客戶端的情況下，檢查資源同名文件如圖片是否能正常更新成最新版本。如果以上無法更新成功的，也都屬于缺陷。

2.4.7.定位、照相機服務(wù)

1)App有用到相機，定位服務(wù)時，需要注意系統(tǒng)版本差異；

2)有用到定位服務(wù)、照相機服務(wù)的地方，需要進行前后臺的切換測試，檢查應(yīng)用是否正常；

3)當(dāng)定位服務(wù)沒有開啟時，使用定位服務(wù)，會友好性彈出是否允許設(shè)置定位提示。當(dāng)確定允許開啟定位時，能自動跳轉(zhuǎn)到定位設(shè)置中開啟定位服務(wù)；

4)測試定位、照相機服務(wù)時，需要采用真機進行測試。

2.4.8.時間測試

客戶端可以自行設(shè)置手機的時區(qū)、時間，因此需要校驗該設(shè)置對app的影響。

--中國為東8區(qū)，所以當(dāng)手機設(shè)置的時間非東8區(qū)時，查看需要顯示時間的地方，時間是否展示正確，應(yīng)用功能是否正常。時間一般需要根據(jù)服務(wù)器時間再轉(zhuǎn)換成客戶端對應(yīng)的時區(qū)來展示，這樣的用戶體驗比較好。比如發(fā)表一篇微博在服務(wù)端記錄的是10：00，此時，華盛頓時間為22：00，客戶端去瀏覽時，如果設(shè)置的是華盛頓時間,則顯示的發(fā)表時間即為22:00,當(dāng)時間設(shè)回東8區(qū)時間時，再查看則顯示為10：00。（另：如果時間不統(tǒng)一，由于semp服務(wù)器的緣故，會導(dǎo)致APP無法正常使用，遇到這種情況，請及時更新手機時間，或者通知開發(fā)人員修改服務(wù)器時間，謝謝大家配合）。2.4.9.PUSH消息推送測試

1)檢查push消息是否按照指定的業(yè)務(wù)規(guī)則發(fā)送；

2)檢查不接受推送消息時，檢查用戶不會再接收到push；

3)如果用戶設(shè)置了免打擾的時間段，檢查在免打擾時間段內(nèi)，用戶接收不到PUSH。在非免打擾時間段，用戶能正常收到push；

4)當(dāng)push消息是針對登錄用戶的時候，需要檢查收到的push與用戶身份是否相符，沒有錯誤地將其它人的消息推送過來。一般情況下，只對手機上最后一個登錄用戶進行消息推送；

5)測試push時，需要采用真機進行測試。

2.5.性能測試

評估App的時間和空間特性：

1)極限測試：在各種邊界壓力情況下，如電池、存儲、網(wǎng)速等，驗證App是否能正確響應(yīng)。

--內(nèi)存滿時安裝App；

--運行App時手機斷電；

--運行App時斷掉網(wǎng)絡(luò)；

2)響應(yīng)能力測試：測試App中的各類操作是否滿足用戶響應(yīng)時間要求。

--App安裝、卸載的響應(yīng)時間；

--App各類功能性操作的影響時間；

3)壓力測試：反復(fù)/長期操作下、系統(tǒng)資源是否占用異常。

--App反復(fù)進行安裝卸載，查看系統(tǒng)資源是否正常；

--其他功能反復(fù)進行操作，查看系統(tǒng)資源是否正常；

4)性能評估：評估典型用戶應(yīng)用場景下，系統(tǒng)資源的使用情況。

2.6.兼容測試

主要測試內(nèi)部和外部兼容性：

1）與本地及主流App是否兼容；

2）基于開發(fā)環(huán)境和生產(chǎn)環(huán)境的不同，檢驗在各種網(wǎng)絡(luò)連接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等)，App的數(shù)據(jù)和運用是否正確；

3）與各種設(shè)備是否兼容，若有跨系統(tǒng)支持則需要檢驗是否在各系統(tǒng)下，各種行為是否一致；

--不同操作系統(tǒng)的兼容性，是否適配；

--不同手機屏幕分辨率的兼容性；

--不同手機品牌的兼容性。

2.7.回歸測試

1）Bug修復(fù)后且在新版本發(fā)布后需要進行回歸測試。

2）Bug修復(fù)后的回歸測試在交付前、要進行全量用例的回歸測試。

2.8.用戶體驗測試

以主觀的普通消費者的角度去感知產(chǎn)品或服務(wù)的舒適、有用、易用、友好親切程度。通過不同個體、獨立空間和非經(jīng)驗的統(tǒng)計復(fù)用方式去有效評價產(chǎn)品的體驗特性修改意見提升產(chǎn)品的潛在客戶滿意度。

1）是否有空數(shù)據(jù)界面設(shè)計，引導(dǎo)用戶去執(zhí)行操作；

2）是否濫用用戶引導(dǎo)；

3）是否有不可點擊的效果，如：你的按鈕此時處于不可用狀態(tài)，那么一定要灰掉，或者拿掉按鈕，否則會給用戶誤導(dǎo)；

4）菜單層次是否太深；

5）交互流程分支是否太多；

6）相關(guān)的選項是否離得很遠；

7）一次是否載入太多的數(shù)據(jù)；

8）界面中按鈕可點擊范圍是否適中；

9）標簽頁是否跟內(nèi)容沒有從屬關(guān)系，當(dāng)切換標簽的時候，內(nèi)容跟著切換；

10）操作應(yīng)該有主次從屬關(guān)系；

11）是否定義Back的邏輯。涉及軟硬件交互時，Back鍵應(yīng)具體定義；

12）是否有橫屏模式的設(shè)計，應(yīng)用一般需要支持橫屏模式，即自適應(yīng)設(shè)計

2.9.硬件環(huán)境測試

2.9.1.網(wǎng)絡(luò)環(huán)境測試

手機的網(wǎng)絡(luò)目前主要分為2G、3G、4G、wifi。目前2G的網(wǎng)絡(luò)相對于比較慢，測試時尤其要注意此塊的測試。

1)無網(wǎng)絡(luò)時，執(zhí)行需要網(wǎng)絡(luò)的操作，給予友好提示，確保程序不出現(xiàn)crash； 2)內(nèi)網(wǎng)測試時，要注意選擇到外網(wǎng)操作時的異常情況處理；

3)在網(wǎng)絡(luò)信號不好時，檢查功能狀態(tài)是否正常，確保不因提交數(shù)據(jù)失敗而造成crash；

4)在網(wǎng)絡(luò)信號不好時，檢查數(shù)據(jù)是否會一直處于提交中的狀態(tài)，有無超時限制。如遇數(shù)據(jù)交換失敗時要給予提示；

5)在網(wǎng)絡(luò)信號不好時，執(zhí)行操作后，在回調(diào)沒有完成的情況下，退出本頁面或者執(zhí)行其他操作的情況，有無異常情況。此問題也會經(jīng)常出現(xiàn)程序crash。2.9.2.服務(wù)器壘機或者出現(xiàn)404、500的情況下測試

后臺服務(wù)牽涉到DNS、空間服務(wù)商的情況下會影響其穩(wěn)定性，如：當(dāng)出現(xiàn)域名解析故障時，你對后臺API的請求很可能就會出現(xiàn)404錯誤，拋出異常。這時需要對異常進行正確的處理，否則可能會導(dǎo)致程序不能正常工作。是否有友好的提示。

第二篇：編寫測試用例和測試計劃

第六章 編寫測試用例和測試計劃

主要內(nèi)容：軟件測試計劃；軟件測試方案；軟件風(fēng)險分析

1.軟件測試計劃

1.1 軟件測試計劃的簡介

1測試計劃概念：測試計劃在測試中處于中心位置，它闡述了測試準備工作和執(zhí)行測試的必要條件，同時也形成了測試過程質(zhì)量保證的基礎(chǔ)。

2測試計劃的作用：組織和管理測試；使測試工作和整個開發(fā)工作整合起來；資源和變更事先最為一個可控制的風(fēng)險。

1.2 如何編寫軟件測試計劃

1認識測試項目不僅僅只有單一測試計劃

2避免不分析直接進行測試階段日程安排

3避免測試任務(wù)的安排超前于開發(fā)任務(wù)

4避免有些系統(tǒng)測試類型無法按期進入測試

5不正確的變更測試計劃

6測試計劃里明確更新周期和暫停測試原則

7測試計劃不是一成不變的1.3 測試計劃包括：簡介，目的，范圍，測試策略，進度，缺陷的嚴重程度的定義，風(fēng)

險分析。

2.軟件測試方案

2.1 軟件測試方案的概念

軟件測試方案描述測試的特征，測試的方法，測試環(huán)境的規(guī)劃，測試工具的設(shè)計和選擇，測試用例的設(shè)計方法，測試代碼的設(shè)計方案。即包括以下幾點：

? 明確測試策略（黑盒，白盒，灰盒等）

? 細化測試特征

? 測試用例的規(guī)劃

? 測試環(huán)境的規(guī)劃

? 自動化測試框架的設(shè)計

? 測試工具的設(shè)計和選擇

2.2 軟件測試計劃于軟件測試方案的區(qū)別

? 測試計劃是組織管理層面的文檔。測試方案是技術(shù)層面的文檔。

? 測試方案需要在測試計劃的指導(dǎo)下進行，測試計劃提出“做什么”，測試方案明確“怎么做”

? 回報的對象不同，測試計劃向領(lǐng)導(dǎo)匯報，測試方案是組員共享該文檔

3.軟件測試的風(fēng)險

? 軟件需求風(fēng)險

? 人員的風(fēng)險

? 測試環(huán)境的風(fēng)險

? 測試工程師對產(chǎn)品的業(yè)務(wù)不熟悉

補充：

回歸測試：把以前檢查過的已經(jīng)修復(fù)好的缺陷，拿來另測看有無帶來新的缺陷 反側(cè)：把開發(fā)人員已經(jīng)處理的缺陷拿來測，看是否修復(fù)

第三篇：可復(fù)用測試用例研究

可復(fù)用測試用例研究

0、引言

軟件測試的關(guān)鍵環(huán)節(jié)是設(shè)計和執(zhí)行測試用例。測試用例的質(zhì)量與測試人員的技能、經(jīng)驗以及對被測軟件的理解密切相關(guān)。如果測試人員對被測軟件不甚了解，很難在短時間內(nèi)設(shè)計出有效的測試用例；有的測試用例雖然面面俱到，但冗余現(xiàn)象嚴重，浪費時間、人力和物力。

隨著軟件復(fù)用技術(shù)的發(fā)展，測試復(fù)用引起了人們的極大關(guān)注，特別是對測試用例復(fù)用的研究。所謂測試用例復(fù)用，就是對一個軟件的已執(zhí)行的測試用例，將其不同程度地應(yīng)用于該軟件新的測試中或其他軟件的測試中。測試用例復(fù)用是可行和必要的，表現(xiàn)在：1）軟件測試對測試人員的經(jīng)驗和技能要求高，通過復(fù)用，可提高測試人員技能，解決其經(jīng)驗不足的問題，同時提高軟件測試質(zhì)量；2）軟件測試是當(dāng)前保證軟件質(zhì)量的一種有效手段，但其占用軟件開發(fā)周期時間長，通過復(fù)用，可避免大量重復(fù)性勞動，縮短測試周期，提高效率；3）伴隨著同一個軟件的生存周期，軟件經(jīng)歷了單元測試、集成測試、確認測試和系統(tǒng)測試，這一過程產(chǎn)生了成百上千的經(jīng)過執(zhí)行確認的高質(zhì)量的測試用例，在前一測試階段執(zhí)行過的一些測試用例可在后續(xù)測試階段中使用，包括在回歸測試、維護階段的版本升級和糾錯測試中都可使用；4）同一領(lǐng)域或相同系統(tǒng)架構(gòu)的不同軟件，存在著測試用例復(fù)用的可能性，且隨著軟件復(fù)用技術(shù)的發(fā)展，很多有價值的組件可供使用，這也使測試用例復(fù)用成為可能。

由于軟件的抽象性、復(fù)雜性和多樣性，使得軟件測試成為一項復(fù)雜的、需要智慧和創(chuàng)造性的工作，要實現(xiàn)測試用例復(fù)用并不是一件簡單的事情。但測試用例復(fù)用是軟件測試發(fā)展的一個必然趨勢。本文從可復(fù)用測試用例的評估、描述、設(shè)計和使用四個方面對測試用例進行了系統(tǒng)研究，提出了可復(fù)用測試用例應(yīng)具有的特性，為評估測試用例的可復(fù)用性提供準則；給出了可復(fù)用測試用例的系統(tǒng)描述要素，為規(guī)范和使用可復(fù)用測試用例提供了基礎(chǔ)；提出了面向復(fù)用的測試用例設(shè)計過程和基于復(fù)用的軟件測試模型，為測試用例復(fù)用提供了方法和實現(xiàn)策略。本文的研究內(nèi)容在某類實時系統(tǒng)軟件測試中進行了應(yīng)用，證明是有效和科學(xué)的。

1、可復(fù)用測試用例特性

文獻中定義了可復(fù)用測試用例的六個特性：通用性、簡潔性、獨立性、有效性、靈活性和檢索方便。本文對大量測試用例和測試用例復(fù)用的各種應(yīng)用情況進行了分析，認為可復(fù)用測試用例應(yīng)具有以下特性：通用性、有效性、獨立性、標準化和完整性，它們對可復(fù)用測試用例而言是充分的也是必要的。上述特性可作為評判一個測試用例是否具有可復(fù)用性的準則。

1）通用性。通用性是指可復(fù)用測試用例并不局限于具體的應(yīng)用，不過分依賴于被測軟件的需求、設(shè)計和環(huán)境，能夠在某一類型、某一領(lǐng)域的相似軟件的測試中廣泛使用。

當(dāng)前絕大多數(shù)的測試用例都不具有通用性，這樣的測試用例只能用于被測軟件和其當(dāng)前環(huán)境，不可能用到其他軟件中。

2）有效性。測試用例的目標是發(fā)現(xiàn)軟件問題，因此，可復(fù)用測試用例也必須是能夠發(fā)現(xiàn)軟件問題的，并且是可靠和高效的。

3）獨立性?？蓮?fù)用測試用例的獨立性是指，對于測試需求R1和R2，測試用例集分別為cl和C2，c1和c2的交集為空，并且，每個可復(fù)用測試用例能夠獨立運行。測試用例是否具有獨立性，決定了測試用例可復(fù)用能力的強弱。

如果測試用例之間存在著相互聯(lián)系，或測試用例的運行環(huán)境取決于其他測試用例的執(zhí)行狀態(tài)，那么，其中的測試用例不能復(fù)用時，與之相關(guān)的測試用例的可復(fù)用性也不復(fù)存在。

如何將測試用例的關(guān)聯(lián)性降至最低，是設(shè)計可復(fù)用測試用例必須解決的問題。首先，每個測試用例的目標應(yīng)盡量獨立、單一；其次，測試用例不包含過多的具體實現(xiàn)細節(jié)。

4）標準化。測試用例通常用自然語言來描述，充分體現(xiàn)了測試人員的創(chuàng)造性和個人風(fēng)格。但對于可復(fù)用測試用例，太多的個人風(fēng)格不利于其他測試人員對測試用例的理解，必然影響其復(fù)用。因此可復(fù)用測試用例的標準化程度也反映了其易理解和可復(fù)用的能力。為此可復(fù)用測試用例應(yīng)遵循統(tǒng)一或規(guī)范的格式或結(jié)構(gòu)，規(guī)范的命名規(guī)則，使用術(shù)語、用簡明、易懂、無歧義的語言來描述，并且具有詳細的文檔。

5）完整性。每個可復(fù)用測試用例應(yīng)包括全部應(yīng)有的要素，不能有缺失，并且每個要素的描述是充分的。文獻規(guī)定了測試用例應(yīng)包括的要素，但對于可復(fù)用測試用例而言是不夠的，應(yīng)加以補充。

2、面向復(fù)用的測試用例設(shè)計過程

當(dāng)前，測試用例設(shè)計都砥向不同的具體應(yīng)用，與被測軟件是緊耦合的?？紤]到復(fù)用的目的，測試用例的設(shè)計應(yīng)不同于以往。本文提出了面向復(fù)用的測試用例設(shè)計過程，給出了設(shè)計過程中應(yīng)實施的各項活動，主要包括被測軟件（系統(tǒng)）共性分析、測試策略分析、設(shè)計測試用例、測試用例評審、測試用例執(zhí)行和修改、測試用例入庫共六個步驟，如圖l所示。該過程對現(xiàn)有測試用例的復(fù)用處理也是適用的。

2．1共性分析

同一領(lǐng)域或相同架構(gòu)的軟件存在著共性需求。通過共性分析或領(lǐng)域分析，并結(jié)合任務(wù)分析等方法，梳理出被測軟件所屬領(lǐng)域或相同類型軟件的相同或相似特征及需求，例如，工作流程、共性場景、功能、性能等，從而挖掘出可復(fù)用點，例如，相對獨立且類似的功能、相同的構(gòu)件、相似的業(yè)務(wù)流程。該步驟實質(zhì)上要抽象出被測軟件應(yīng)用領(lǐng)域的概念，類似于設(shè)計模式中的共性分析。

這項活動需要領(lǐng)域?qū)＜?、軟件專家、設(shè)計人員、測試專家等人員參與。

2．2 測試策略分析

針對共性分析挖掘出的可復(fù)用點，分析各復(fù)用點的測試策略，包括測試類型、測試方法、測試環(huán)境、測試覆蓋率等內(nèi)容。

2．3 設(shè)計測試用例

根據(jù)前兩個步驟的分析結(jié)果對每個可復(fù)用點設(shè)計測試用例。在設(shè)計時，應(yīng)使所設(shè)計的測試用例滿足可復(fù)用測試用例的特性，特別要注意以下幾方面：

1）每個測試用例的目的要盡量獨立、單一，以滿足可復(fù)用測試用例獨立性的要求。

2）對一項明確的測試需求，應(yīng)關(guān)注“測試思想”，即測試思路，以滿足可復(fù)用測試用例通用性要求。當(dāng)前，為了使測試用例是可操作的、可復(fù)現(xiàn)的，一般都要求測試用例要設(shè)計得非常詳細，例如，每一操作步驟的輸入數(shù)據(jù)、操作等信息都要具體描述。這樣的測試用例和被測軟件是緊耦合的，只有在同一軟件的回歸測試和版本升級維護測試中可能會復(fù)用到，在其他情況下復(fù)用是很困難的。在設(shè)計可復(fù)用測試用例時，測試用例的可操作性、可復(fù)現(xiàn)性要弱化，即，對測試用例進行通用化處理，排除和特定應(yīng)用相關(guān)的具體信息，以降低測試用例和被測軟件的相關(guān)度，例如，參數(shù)化或公式來代替具體的輸入數(shù)據(jù)，抽象出共同或關(guān)鍵的操作等。但為了加強測試用例的可操作性和可復(fù)現(xiàn)性，在設(shè)計可復(fù)用測試用例時，應(yīng)對一些差異之處進行預(yù)測，即進行可變性分析mJ，并用適當(dāng)?shù)姆绞矫枋龀鰜怼Ｖ挥羞@樣，當(dāng)復(fù)用該測試用例時，測試人員可以在原有基礎(chǔ)上對其進行完善，使其能夠滿足特定的測試情況。

3）將設(shè)計出的測試用例用規(guī)范而精煉的自然語言清晰地描述出來，保證其完整、標準。軟件評測組織或機構(gòu)應(yīng)定義本組織使用的規(guī)范和術(shù)語。

需要說明的是，對于一個具體的測試項目，因為面向復(fù)用，所以以上所設(shè)計的測試用例可能不完全滿足被測軟件的測試需求，為此，應(yīng)針對被測軟件的需求補充新的用例或?qū)ΜF(xiàn)有用例進行充實完善。

2．4 測試用例評審

可復(fù)用測試用例設(shè)計完成后，組織領(lǐng)域?qū)＜?、軟件專家、測試專家、軟件設(shè)計人員對其進行評審，確保所設(shè)計的測試用例是正確的，滿足可復(fù)用測試用例的特性。

評審?fù)瑫r應(yīng)關(guān)注以下幾點：每個共性需求的測試策略是否合適；每個共性需求是否被可復(fù)用測試用例所覆蓋；每個共性需求是否被可復(fù)用測試用例進行了充分測試，例如，某一共性功能，不能僅測試正常情況，還應(yīng)測試邊界和異常情況。如果測試用例沒有通過評審，則需要重新回到設(shè)計測試用例步驟。

2．5 測試用例執(zhí)行和修改

將通過評審確認的測試用例用于被測軟件，尋找其不正確或不完善之處并糾正完善。

2．6 測試用例入庫

將經(jīng)過測試執(zhí)行確認的可復(fù)用測試用例統(tǒng)一納入測試用例庫中，供測試人員在后續(xù)軟件測試或以后的項目中查詢使用。測試用例庫應(yīng)是按照一定的組織結(jié)構(gòu)形成的測試用例集合。

3、基于復(fù)用的軟件測試模型

文獻給出了一個測試用例復(fù)用流程：首先定義被測軟件的測試用例類型；再根據(jù)所定義的從測試用例庫中檢索是否有適合的用例；如果可以找到，則提取出測試用例，程序結(jié)束；否則，需要設(shè)計測試用例，驗證其正確性，如果正確，則添加到庫中以便再次復(fù)用，程序結(jié)束。這個流程只適用于完全不需要進一步完善的可復(fù)用的測試用例，由于可復(fù)用測試用例的通用性，該流程顯然不適用于實際情況。文獻[12]給出了另一個測試用例復(fù)用模型，該模型建立在沒有測試用例庫的基礎(chǔ)上，且將測試用例分為內(nèi)外兩類，本文認為這種劃分是不必要的。

本文提出了基于復(fù)用的軟件測試模型。該模型面向一個軟件測試項目，但不同于以往的測試模型，主要表現(xiàn)在模型中融合了面向復(fù)用的測試用例設(shè)計以及對測試用例的復(fù)用上，模型如圖2所示。

“測試需求分析和共性分析”中，測試人員一方面要根據(jù)被測試軟件需求分析、設(shè)計說明等文檔或軟件代碼梳理出被測軟件的測試需求，另一方面要針對被測軟件所屬領(lǐng)域及軟件類型進行面向復(fù)用的共性分析。

“定義測試策略”中，測試人員根據(jù)測試目標和上一步的結(jié)果定義測試策略，包括測試方法、測試類型、測試環(huán)境等內(nèi)容。

“定義測試用例”中，測試人員根據(jù)測試需求和共性分析結(jié)果及所定義的測試策略，定義所需要的測試用例。這里定義的測試用例只是給出一個測試用例名稱及其測試目的。

“查詢可復(fù)用測試用例庫”中，測試人員用多字段檢索功能從可復(fù)用測試用例庫中查找滿足要求的測試用例。對測試用例的查詢是不確定的，查詢結(jié)果通常是一個相似的測試用例集合。如果可以找到，則“提取測試用例”并對其進行分析，確定出最合適的測試用例；如果沒有，則“設(shè)計”新的測試用例。找到的測試用例，往往因其通用性，并不能完全滿足測試需求，要對其“補充完善”。在設(shè)計新的測試用例時，要考慮到上節(jié)“設(shè)計測試用例”要求。

在傳統(tǒng)模型評審的基礎(chǔ)上，本模型“測試評審”還包括對新設(shè)計的可復(fù)用測試用例是否滿足要求的審查；對復(fù)用的測試用例是否補充完善的審查；所有測試用例是否滿足被測軟件的測試需求的審查。

“執(zhí)行測試用例”中，測試人員將所設(shè)計的測試用例逐用例逐步驟地執(zhí)行。在執(zhí)行過程中，認真觀察并詳實地記錄測試過程、測試結(jié)果和發(fā)現(xiàn)的錯誤，形成測試記錄。如果在執(zhí)行過程中發(fā)現(xiàn)測試用例有不正確和不完善之處，則糾正；如果測試用例不充分，則補充。

測試人員在“測試總結(jié)”中對所有測試結(jié)果進行分析總結(jié)，將通過測試執(zhí)行驗證的可復(fù)用測試用例放入可復(fù)用測試用例庫中，以便后續(xù)復(fù)用。

該模型的優(yōu)點為：1）對已有的可復(fù)用的測試用例進行了復(fù)用，避免了大量的重復(fù)性工作，提高了測試質(zhì)量和效率；2）考慮了面向復(fù)用的測試用例設(shè)計，避免再次產(chǎn)生大量的不可復(fù)用的測試用例。

4、可復(fù)用測試用例描述要素

測試用例的輸入、操作、預(yù)期結(jié)果和評估標準、前提條件是測試用例不可少的要素，但對于可復(fù)用測試用例而言，這是不夠的。本文在文獻規(guī)定的測試用例要素基礎(chǔ)上，增加了新的內(nèi)容。從而從多個角度完整地對可復(fù)用測試用例進行了描述，為可復(fù)用測試用例的標準化提供了模板，為建立可復(fù)用測試用例庫并對測試用例實施有效管理提供了基礎(chǔ)，也為測試用例檢索提供了多個檢索字段。

1）測試用例名稱：名稱能清晰且簡潔地表達測試用例的功能。

2）ID：該ID在數(shù)據(jù)庫中是唯一的。

3）版本號：用于測試用例的版本管理，每個測試用例應(yīng)按照定義的規(guī)則設(shè)定一個版本號。

4）測試需求：對要驗證的測試需求的描述和測試要求，例如，功能、性能等。

5）測試階段：被測軟件所處的測試階段，包括單元測試、部件測試、配置項測試、系統(tǒng)測試，或者單元測試、集成測試、確認測試、系統(tǒng)測試。

6）測試方法：黑盒測試中的等價類劃分、因果圖，白盒測試中的語句覆蓋、分支覆蓋等。

7）測試類型：有功能測試、性能測試、安全測試、用戶界面測試、接口測試、安裝測試等，可選擇多項。

8）應(yīng)用領(lǐng)域：說明被測軟件所屬領(lǐng)域。

9）系統(tǒng)類型：描述被測軟件所在系統(tǒng)的架構(gòu)，如B／S、C／S、嵌入式軟件、非嵌入式軟件等。

lO）軟件編碼：描述被測軟件的編碼語言。

11）測試環(huán)境：描述該測試用例執(zhí)行的軟硬件環(huán)境。

12）前提條件：測試用例執(zhí)行前必須滿足的條件，或稱之為約束條件。

13）測試輸入：對輸入值的抽象描述或參數(shù)化描述，不能是具體的數(shù)據(jù)值。

14）操作步驟：說明執(zhí)行該測試用例的一系列相關(guān)聯(lián)的操作。

15）預(yù)期結(jié)果：說明測試用例執(zhí)行后的期望結(jié)果。每一操作步驟也可有自己的預(yù)期結(jié)果。

16）評估標準：描述評判測試用例執(zhí)行中產(chǎn)生的中間和最后結(jié)果是否正確的準則。

17）附件：對測試用例附加的一些描述信息，可任意表示，例如文本、圖像、模型、與測試用例有關(guān)的一些文檔，方便測試人員進一步理解測試用例。

上述要素對可復(fù)用測試用例而言是必要的，不可缺少。而且要注意的是，測試人員在描述測試用例各要素時，應(yīng)盡可能地使用規(guī)范語言和術(shù)語，以使測試用例規(guī)范化和易于理解。

5、應(yīng)用

本文的研究內(nèi)容在航天測控領(lǐng)域進行了應(yīng)用。在航天測控計算機系統(tǒng)中，有一類實時系統(tǒng)軟件。在不同型號任務(wù)中，該類軟件的功能、性能、接口和運行環(huán)境都有區(qū)別，但不同任務(wù)對該類軟件有共性需求。更多細節(jié)信息的子帶圖像予以了更多地保留，恢復(fù)了圖像的邊緣輪廓，而且經(jīng)圖像分解后的子帶圖像含有相同尺寸的大小，也更易于處理。本文算法的缺陷則是執(zhí)行速度較慢，不如前三種算法，而且對分解后所得到系數(shù)處理也比較簡單，這些都需作進一步的改進。

第四篇：做好測試計劃和測試用例的工作的關(guān)鍵是什么？

一、測試計劃的有效性和全面性

無論做什么工作，都是計劃先行，然后按照所制定的計劃去執(zhí)行、跟蹤和控制。軟件測試也一樣，先要制定測試計劃，是做好整個測試工作的前提。所以在進行實際測試之前，應(yīng)制定良好的、切實可行的、有效的測試計劃。軟件測試計劃的目標是提供一個測試框架，不斷收集產(chǎn)品特性信息，對測試的不確定性（測試范圍、測試風(fēng)險等）進行分析，將不確定性的內(nèi)容慢慢轉(zhuǎn)化為確定性的內(nèi)容，該過程最終使得我們對測試的范圍、用例數(shù)量、工作量、資源和時間等進行合理的估算，從而對測試策略、方法、人力、日程等做出決定或安排。

1．測試計劃的要點

測試規(guī)劃與軟件開發(fā)活動同步進行，在需求分析時，就開始測試策劃，確定測試需求、目標、資源等。測試計劃可以按不同的測試階段（集成測試、系統(tǒng)測試等）來組織，也可以為每個測試任務(wù)或目標(安全性、性能、可靠性等測試)進行考慮。

測試計劃主要集中在測試目標、質(zhì)量標準、測試策略、測試范圍、測試用例設(shè)計方法、所需資源和日程安排等，其關(guān)鍵是制定有效的測試策略，界定清楚地測試范圍，識別出測試中所存在的各種風(fēng)險并找出風(fēng)險回避、監(jiān)控和管理的方法，針對不同的測試目標或階段確定測試方法，對測試工作量及所需的資源、時間進行合理的估算。所有這些，都是為了兩個根本目的：測試的質(zhì)量和效率。

2．制定測試策略

制定測試策略主要分析測試的目標和質(zhì)量指標、確定測試的對象和依據(jù)，測試的重點和所采用的方法，包括在規(guī)定的時間內(nèi)哪些測試內(nèi)容要完成，軟件產(chǎn)品的特性或質(zhì)量在哪些方面得到確認。測試策略可以分為：

基于測試技術(shù)的測試策略，根據(jù)軟件系統(tǒng)的技術(shù)構(gòu)成和層次結(jié)構(gòu)，著重考慮如何分層測試、選擇哪些測試工具、如何將白盒測試和黑盒測試有機地結(jié)合起來等。

基于測試方案的綜合測試策略，根據(jù)測試的目標和范圍，著重考慮如何更好地滿足測試需求、如何讓功能測試、適用性測試和兼容性測試等進行有機結(jié)合、如何充分利用測試資源、如何更有效地完成回歸測試等。

為了更好地制定好測試策略，要做到：

全面細致地了解產(chǎn)品的項目信息：應(yīng)用領(lǐng)域、測試范圍、市場需求、產(chǎn)品特點、主要功能和技術(shù)架構(gòu)；

基于模塊、功能、系統(tǒng)、版本、性能、配置和安裝等各個因素對產(chǎn)品質(zhì)量的影響，客觀地、全面地展開測試計劃；

根據(jù)軟件單元在系統(tǒng)結(jié)構(gòu)的重要性差異和一旦發(fā)生故障將給客戶造成的損失大小，來確定軟件測試的等級、重點和先后次序；

需要在測試用例數(shù)和測試覆蓋率上進行權(quán)衡而獲得一個平衡點，以便能使用盡可能少的有效測試用例去發(fā)現(xiàn)盡可能多的程序錯誤。測試不足意味著讓用戶承擔(dān)隱藏錯誤帶來的危險；同時反過來看，過度測試則又會浪費許多寶貴的資源或耽誤軟件產(chǎn)品的發(fā)布時間。

3．確定測試范圍

測試主要依據(jù) “產(chǎn)品設(shè)計規(guī)格說明書”、代碼所發(fā)生的變化及其影響的區(qū)域，來確定哪些功能和特性要測試，哪些功能和特性不需要測試。在確定測試范圍時，主要考慮的因素有：

優(yōu)先級最高的需求功能

新增加的功能和編碼改動較大的已有功能

容易出現(xiàn)問題的部分功能

過去測試不夠充分的地方

經(jīng)常被用戶使用的功能和配置（占20%）

4．所需資源和日程安排

為了合理、準確地安排日程，對測試工作量要進行正確的估計。除了對工作量的估計之外，還要正確評估參與該項目人員的培訓(xùn)時間、適應(yīng)過程和工作能力等。由于涉及到不同的項目、不同的測試人員、不同的前期介入方式，要對每人每天能夠完成的平均測試用例數(shù)目做出一個準確的估計確實很困難，但是可以根據(jù)以前一些項目測試的經(jīng)驗或歷史積累下來的數(shù)據(jù)進行判斷推理，并適當(dāng)增加10%-20%的余量，估算結(jié)果就比較準確了。

在估算的基礎(chǔ)上，進行有效的、合理的資源安排。在不同的測試階段人力資源的需求是不一樣的，所以人力資源的計劃要有一定的靈活性和動態(tài)性，形成有機的動態(tài)平衡，保證測試的進度和資源的使用的效率。

5．編制測試計劃的技巧

要做好測試計劃，測試設(shè)計人員要仔細閱讀有關(guān)資料，包括用戶需求規(guī)格說明書、設(shè)計文檔等，全面熟悉系統(tǒng)，并建議注意以下方面：

讓所有合適的相關(guān)人員參與測試項目的計劃制定，特別是在測試計劃早期；

測試所需的時間、人力及其它資源的預(yù)估，盡量做到客觀、準確、留有余地；

測試項目的輸入、輸出和質(zhì)量標準，應(yīng)與各方達成一致；

建立變化處理的流程規(guī)則，識別出在整個測試階段中哪些是內(nèi)在的、不可避免的變化因素，加以控制。

6．測試項目計劃的評審

測試項目的計劃不可能一氣呵成，而是要經(jīng)過計劃初期、起草、討論、審查等不同階段，才能將測試計劃制定好。測試計劃的評審是完成測試計劃關(guān)鍵的一個環(huán)節(jié)，包括測試組織內(nèi)部的自我評審、討論和修改，然后交到評審會進行正式的評審，直至測試計劃得到審批。

測試計劃的正式評審，項目中的每個人（產(chǎn)品經(jīng)理、項目經(jīng)理、開發(fā)工程師等）都應(yīng)當(dāng)參與。計劃的審查是必不可少的，每一個參與者都可能根據(jù)其經(jīng)驗及專長提出問題或建議，彌補在測試范圍、工作量、風(fēng)險等各方面的不足，進一步完善測試計劃。

二、測試用例在測試活動中的作用：

1.強化測試用例在測試活動中的作用

測試用例在實際中沒有起多大作用 , 在實際測試時根本沒有按測試用例執(zhí)行，測試執(zhí)行后沒有把新的測試用例補充到用例庫中等等。

為何如此？ 根本原因是對測試用例重要性的認識不夠，測試流程不完善，針對測試用例的管理流程更不完善，其實，從三個方面具體來說：

1）測試用例的重要性是毋庸置疑的，它是軟件測試全部過程的核心，是測試執(zhí)行環(huán)節(jié)的基本依據(jù)，如果這個依據(jù)不能足夠發(fā)揮它應(yīng)起的作用，那是不是說這個依據(jù)不明確、依據(jù)設(shè)計的不合理呢？答案是肯定的！

2）制定了完備有效的測試用例，為什么不按測試用例執(zhí)行測試呢？首先是因為企業(yè)沒有嚴格和良好的機制促使和保證測試執(zhí)行者這樣做；其次是個別測試人員投機取巧心理作祟的表現(xiàn)。

3）測試用例設(shè)計得不可能天衣無縫，不可能完全滿足軟件需求的覆蓋要求，測試執(zhí)行過程里肯定會發(fā)現(xiàn)有些 測試路徑或數(shù)據(jù)在用例里沒有體現(xiàn)，那么事后該將其補充到用例庫里，以方便他人和后續(xù)版本的測試；如果沒有這樣做，那么測試部門負責(zé)人和每個測試員都難辭其疚，是該重新坐下來思考一下公司的測試用例管理規(guī)范和測試流程了。

2.改進測試用例執(zhí)行過程

那么究竟如何做，才能盡量避免上述問題呢？

我們不妨從軟件開發(fā)周期的每個階段就把這些問題考慮進去，以便從初始就力爭將問題縮到最小，將問題扼殺在萌芽階段。

1）軟件需求分析階段，測試人員從軟件生命周期的需求階段就開始介入。通常測試人員的測試工作開展在開發(fā)周期的末尾，如果前期不涉入，如何通曉整個系統(tǒng)的需求和架構(gòu)而對其充分測試呢？

項目的測試負責(zé)人和測試工程師在 需求階段 的任務(wù)有：

a.參與軟件需求調(diào)研，以測試角度分析需求的可測性，可構(gòu)思將來對其測試的方法、原則等；更重要的是，對不可測或難以測試性問題要及時與客戶或項目經(jīng)理協(xié)調(diào)解決。

b.全面了解系統(tǒng)需求，從客戶角度考慮軟件測試需要達到的驗證狀態(tài)，即何些功能點需重點測試、何些無需，以便將來制定測試計劃。

2）軟件分析設(shè)計階段：

l 測試人員除制定測試計劃書等基本工作外，還有一個相當(dāng)必要的任務(wù)，那就是將系統(tǒng)的可測性落實到書面文檔，以備將來編寫測試用例。（之所以要這么做，是因為考慮到很多企業(yè)編寫測試用例直接參考需求規(guī)格說明書或者分析流程圖，這樣跨度大，難度也大，是造成測試用例不完備、覆蓋范圍小的重要原因）。

l 測試人員更要編寫一份《軟件功能點測試描述書》，它是軟件的詳細測試分析文檔，其主旨是將系統(tǒng)分析人員的開發(fā)分析文檔加工成以測試為角度的功能點分析文檔，重要的是描述對系統(tǒng)分解后每個功能點逐一的校驗描述，包括何種方法測試、何種數(shù)據(jù)測試、期望測試結(jié)果等，這些信息都是描述性的，無須具體數(shù)據(jù)；它的作用是據(jù)此編寫測試用例，以及測試執(zhí)行時的參考依據(jù)，基于它直接來源于需求，覆蓋當(dāng)然最全，也最能貼近客戶要求。

l 當(dāng)然該文檔不是非要不可，如果有類似的替代文檔或有工具可自動實現(xiàn)此功能，則會倍加受推崇！

3）軟件開發(fā)階段： 編寫測試用例。應(yīng)該遵守的原則是：

n 首先，從覆蓋率來說，測試用例庫的用例要達到最大覆蓋軟件系統(tǒng)的功能點。編寫測試用例時，基本上就是將《軟件功能點測試描述書》中的每個功能點進行操作上的細化：一是從步驟上描述到達校驗點的方式，二是從內(nèi)容上描述以何種數(shù)據(jù)校驗功能點；如此可實現(xiàn)趨向最大需求覆蓋率。

n 其次，從數(shù)量來講，一個多于半年開發(fā)周期（指從編碼開始直到提交客戶的時間段）的軟件系統(tǒng)，它的用例數(shù)量不要低于 4000 個，甚至更多?。↖BM 等大公司測試過程的人士會認為 4000 還是很少的數(shù)目。我們試想，對于一個中小型軟件系統(tǒng)，如果設(shè)計出 5000 個用例，那它的測試覆蓋率還怕不高么）！

n 再次，如此眾多測試用例的管理問題。是的，最好是需要測試用例管理工具軟件。以 word 或 excel 來編寫測試用例也可以。）測試用例 格式上一般內(nèi)容以外的幾個要點：

l 制定適合本公司的測試用例模版；

l 是用例模版里要有關(guān)鍵字索引，以方便按關(guān)鍵字分類查找，如測試方法（分手工 / 自動兩種）；

l 是測試用例要有 狀態(tài)跟蹤，可根據(jù)用例執(zhí)行狀態(tài)索引用例（測試通過、測試失敗、測試中斷等）；

l 是執(zhí)行失敗的用例要 鏈接到相應(yīng)的缺陷報告，如有根據(jù)缺陷報告檢索測試用例的試圖更妙，可評估該缺陷影響范圍的大小；

l [FS:PAGE] 是測試用例的修改，以及每個測試周期的運行都有 日志記錄，以便后期追蹤

和新員工參考；）軟件測試階段，測試負責(zé)人劃分不同的測試階段（如集成測試、系統(tǒng)測試、回歸測試、性能測試等），再劃分不同的子測試周期（如前兩個星期做 冒煙測試，測試方式是手工 / 自動，測試版本是 **，測試環(huán)境是 **，包括服務(wù)器端與客戶端等；接著做第一模塊功能測試；如此順次。），再為項目組測試人員分配測試用例（通常原則是每個人負責(zé)幾塊區(qū)域的測試任務(wù)），測試人員則按照詳細的用例文檔去執(zhí)行測試，測試失敗則提交軟件缺陷報告。這里要遵循的幾個原則是：

A）有健全且嚴格的體制保證測試執(zhí)行者嚴格按照測試用例執(zhí)行測試。這并不妨礙測試者創(chuàng)造力的發(fā)揮，因為前期用例的設(shè)計和編寫就是項目全體測試人員智慧的結(jié)晶！我們一直苦苦追尋眾多測試工程師加班加點辛苦工作的原因，其實大都發(fā)生這一階段；如此實施，即便沒有解決根本問題，也會大大提高測試執(zhí)行效率。

B）如有對測試用例認識模糊或內(nèi)容遺漏的地方，可暫做記錄待后期解決，或經(jīng)測試負責(zé)人與項目其他管理人員同意方可更新用例庫。

C）測試負責(zé)人每日負責(zé)跟蹤本測試子周期或階段的測試用例執(zhí)行情況，以及每日提交的缺陷報告，根據(jù)執(zhí)行進展?fàn)顟B(tài)以及缺陷數(shù)量或嚴重等級與項目高層或其他人員展開交流，商議解決途徑，并確定或調(diào)整未來時間的測試任務(wù)。

D）測試執(zhí)行者負責(zé)執(zhí)行自己區(qū)域的測試用例，還要負責(zé)跟蹤該區(qū)域軟件缺陷的修改進展，根據(jù)其狀態(tài) 不斷驗證軟件功 能點。

E）通過缺陷管理工具來 管理軟件缺陷 ；這樣的集成工具都提供了清晰的報告模版及強大的追蹤功能，測試團隊的每一成員按照自己的角色和權(quán)限訪問缺陷管理工具，并不斷跟蹤軟件缺陷的狀態(tài)。

F）對于自動測試（包括自動化功能測試和性能、壓力測試），有一些特殊要點。是自動化測試無須編寫測試用例，只要在編寫時將用例庫里適合或需要自動測試的用例的測試方法（不同工具可能名稱不同）設(shè)為自動即可，故而到此階段才提及自動化測試。自動化測試的實施方案有所不同，每款測試工具的使用和測試流程也不同，但都可以從在這一階段編寫測試腳本，并運行自動測試。這里要提的其他幾個基本原則是：

l 是選擇恰當(dāng)?shù)臏y試工具品牌，并要求提供培訓(xùn)；

l 是項目的自動化測試工作有專人負責(zé)跟蹤，以保證工作質(zhì)量，他們可不參與日常測試；l 是確定自動化測試成員在項目中的角色，一般自動化測試成員隸屬于項目測試負責(zé)人，負責(zé)人同樣跟蹤其工作狀態(tài)；

l 是選擇最簡單、最重用的測試用例使用自動測試方法；

l 是使用工具廠商提供的測試框架編寫腳本，千萬別采用單純錄制回放的方式，要開發(fā)出健壯且重用性強的測試腳本 ；

l 是有專人更新腳本，也有專人跟蹤自動測試結(jié)果；

l 一般選擇的測試工具品牌和缺陷管理工具品牌是同一廠商，以方便不同類型缺陷的集中管理；

l 是在多人協(xié)作開發(fā)測試腳本、代碼量相對較大情況下，應(yīng)考慮使用配置管理工具來管理測試腳本。）由于不同公司開發(fā)產(chǎn)品的特殊性，也許需要特殊類型的測試，如安全測試、甚至代碼級單元測試等，這些內(nèi)容需要酌情考慮測試用例的編寫，以及測試的執(zhí)行。）軟件驗收階段 ：除了提交軟件測試評估報告（各種類型測試結(jié)果的評估都應(yīng)有報告）這些基本工作外，對于測試用例，此時要集中時間更新，更新整個測試周期中一切需要更新的內(nèi)容，以方便未來新版本的測試。即便您開發(fā)的是項目軟件--提交客戶后沒有新版本--那也需要后期維護，維護階段需要重新測試某功能點，然而用例如果不準確，碰巧又是一個

新員工來做，那就死翹翹了！）其他說明：加強測試部門內(nèi)部人員的培訓(xùn)教育很重要，包括工作技能與個人素質(zhì)兩方面，可通過國內(nèi)主要的培訓(xùn)機構(gòu)，也可是購買工具廠商的直接培訓(xùn)。應(yīng)該說，很多測試新人對于測試用例的書寫還存在問題，更別提及測試用例的管理或執(zhí)行；以此可見，我們的測試工程師需要培訓(xùn)的空間還很大。

3.總結(jié)

綜上所述，我們得出結(jié)論--測試用例在測試中沒起到應(yīng)有的作用，是因為測試用例編寫質(zhì)量不高，覆蓋不夠，執(zhí)行不利；測試執(zhí)行時不遵循測試用例，執(zhí)行后不更新用例庫，是測試部門的整體工作流程不健全、不規(guī)范。

第五篇：做好測試計劃和測試用例工作的關(guān)鍵

做好測試計劃和測試用例的工作的關(guān)鍵

做好測試計劃和測試用例的工作的關(guān)鍵（轉(zhuǎn)）

對于目前大部分公司存在的狀況，很多測試計劃文檔只是一種形式而已

所以我的理解是：怎樣讓測試計劃對整個測試工作真正具有指導(dǎo)作用

這里把測試計劃和測試方案分開來講（計劃對應(yīng)于管理層面的問題，方案對應(yīng)于技術(shù)方面的問題）

測試計劃中最重要的內(nèi)容包括： 進度安排；人力、物力資源分配（包括組織結(jié)構(gòu)等）、風(fēng)險假設(shè)和規(guī)避措施。（其他像軟件版本號之類的，只要是個人都會寫，這里不列了）寫好測試計劃的關(guān)鍵在于：充分了解你的團隊的整體實力和團隊中每個成員的特點充分理解為當(dāng)前軟件制訂的整個研發(fā)活動過程

帶過項目的人都知道：在實際項目中，往往進度才是第一位的，但是對進度的把握和估算卻是極其困難的。只有做到這兩點才有可能對進度有比較準確的把握，對人員有一個合理的分配。否則所謂的進度，所謂的資源分配，都是拍腦袋得出的結(jié)果，風(fēng)險假設(shè)更是無從談起，這樣的測試計劃文檔只能流于形式也就不足為奇了。

寫好測試方案的關(guān)鍵在于：有一個合理的測試計劃熟悉相關(guān)業(yè)務(wù)深入體會用戶的實際需求

這個不想多解釋了，不難理解。

至于測試用例，看到上面不少朋友認為關(guān)鍵在于理解用戶需求。

其實理解用戶實際需求是一切的根本，并且對于有些測試（比如像單元測試）對應(yīng)的測試用例通常和用戶需求之間的關(guān)系可能并不直接或是十分密切。

當(dāng)然，如果有一份好的需求和設(shè)計文檔的話，什么事情都解決了?？墒乾F(xiàn)實往往是不存在這樣的文檔的。

所以我的看法是：對業(yè)務(wù)理解的深入程度經(jīng)驗有自己的文檔

前兩條不解釋了。自己的文檔包括兩方面：一個是常用的特殊測試數(shù)據(jù)，比如一些特殊字符，極限長度的輸入等等。這個在項目時間緊迫的時候是非常有幫助的（有的時候甚至可以當(dāng)成check list）。另一個就是自己測試模塊對應(yīng)的相關(guān)需求和設(shè)計文檔。服務(wù)器上的標準文檔拖到本地來并且記得及時更新。然后在測試過程中，需要什么內(nèi)容文檔上沒有，最直接的方法是和開發(fā)人員溝通。（其實我很反對這么做。你想，按開發(fā)人員自己說的標準

去測他們自己開發(fā)的模塊能測出因為需求或者設(shè)計錯誤導(dǎo)致的問題么??應(yīng)該是和客戶和designer去溝通，可惜一般沒有這條件-_-）任何標準文檔上缺少的內(nèi)容，只要是和你有關(guān)的，一定要記得做記錄。當(dāng)然你有時間有精力把整個系統(tǒng)的需求和設(shè)計文檔都搗鼓出來最好，不過通常是沒這可能性的。

補充說明：lz最后提到的“完全憑借自己的經(jīng)驗在執(zhí)行測試活動”不如說是完全憑借自己的感覺在執(zhí)行測試活動。

項目需要的用例詳盡程度可以商量，但是必須要有。如果進度很緊，可以用一部分用例加上check list進行測試活動（比如很多日本外包項目的UI測試，相當(dāng)一部分可以用check list來代替具體的用例，效果并不差)

完整的大綱應(yīng)該是：

目錄

測試計劃標識符

目錄表

參考文獻

詞匯表

介紹

測試項

軟件風(fēng)險問題

待測特征

不予測試的特征

方法

測試項通過/失敗準則

掛起準則和恢復(fù)需求

測試交付物

測試任務(wù)

環(huán)境需求

職責(zé)

人員安排與培訓(xùn)需求

進度表

計劃風(fēng)險與應(yīng)急措施

審批