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

移動APP測試流程及測試點

1.APP測試基本流程

1.1.測試周期

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

1.2.測試資源

測試任務開始前，檢查各項測試資源。

--產品功能需求文檔；

--產品原型圖；

--產品效果圖；

--行為統計分析定義文檔；

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

--其他。

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

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

2）測試日報所包含的內容為：

--對當前測試版本質量進行分級（高中低）；

--對較嚴重的問題進行例舉，提示開發人員優先修改；

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

3）APP上線前，測試人員發送APP上線報告。4）上線報告所包含的內容為：

--對當前版本質量進行分級；

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

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

2.APP測試點

2.1.安全測試

2.1.1.軟件權限

1）扣費風險：包括發送短信、撥打電話、連接網絡等；

2）隱私泄露風險：包括訪問手機信息、訪問聯系人信息等；

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

4）限制/允許使用手機功能接人互聯網；

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

6）限制/允許應用程序來注冊自動啟動應用程序；

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

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

9）限制/允許使用手機讀取用戶數據；

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

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

1）應用程序應能正確安裝到設備驅動程序上；

2）能夠在安裝設備驅動程序上找到應用程序的相應圖標；

3）是否包含數字簽名信息；

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

5）JAD文件顯示的資料內容與應用程序顯示的資料內容應一致；

6）安裝路徑應能指定；

7）沒有用戶的允許, 應用程序不能預先設定自動啟動；

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

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

10）其修改的配置信息是否復原；

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

12）卸載應該移除所有的文件。

2.1.3.數據安全性

1）當將密碼或其他的敏感數據輸人到應用程序時, 其不會被儲存在設備中, 同時密碼也不會被解碼；

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

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

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

5）當將敏感數據輸人到應用程序時, 其不會被儲存在設備中；

6）在數據刪除之前，應用程序應當通知用戶或者應用程序提供一個“取消”命令的操作；

7）“取消”命令操作能夠按照設計要求實現其功能；

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

9）當進行讀或寫用戶信息操作時, 應用程序將會向用戶發送一個操作錯誤 的提示信息；

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

11）應用程序讀和寫數據正確；

12）應用程序應當有異常保護；

13）如果數據庫中重要的數據正要被重寫, 應及時告知用戶；

14）能合理地處理出現的錯誤；

25）意外情況下應提示用戶。

2.1.4.通訊安全性

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

2）當創立連接時, 應用程序能夠處理因為網絡連接中斷, 進而告訴用戶連接中斷的情況；

3）應能處理通訊延時或中斷；

4）應用程序將保持工作到通訊超時, 進而發送給用戶一個錯誤信息指示有連接錯誤；

5）應能處理網絡異常和及時將異常情況通報用戶；

6）應用程序關閉或網絡連接不再使用時應及時關閉)斷開；

7)HTTP、HTTPS覆蓋測試

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

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

2.1.5.人機接口安全性

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

2）命令有優先權順序；

3）聲音的設置不影響應用程序的功能；

4）應用程序必需利用目標設備適用的全屏尺寸來顯示上述內容；

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

2.2.安裝卸載測試

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

2.2.1.安裝

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

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

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

4)）軟件安裝向導的UI測試；

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

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

8）安裝后沒有生成多余的目錄結構和文件；

9）對于需要通過網絡驗證之類的安裝，在斷網情況下嘗試一下；

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

2.2.2.卸載

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

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

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

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

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

6）系統直接卸載UI測試，是否有卸載狀態進度條提示。

2.3.UI測試

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

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

2.3.1.導航測試

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

2）是否易于導航，導航是否直觀； 3）是否需要搜索引擎；

4）導航幫助是否準確直觀；

5）導航與頁面結構、菜單、連接頁面的風格是否一致。

2.3.2.圖形測試

1）橫向比較。各控件操作方式統一；

2）自適應界面設計，內容根據窗口大小自適應；

3）頁面標簽風格是否統一；

4）頁面是否美觀；

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

6）圖片質量要高且圖片尺寸在設計符合要求的情況下應盡量小；

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

2.3.3.內容測試

1）輸入框說明文字的內容與系統功能是否一致；

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

3）文字內容是否表意不明；

4）是否有錯別字；

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

6）是否有敏感性詞匯、關鍵詞；

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

2.4.功能測試

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

2)根據被測功能點的特性列丼出相應類型的測試用例對其進行覆蓋，如；涉及輸入的地方需要考慮等價、邊界、負面、異?；蚍欠ā鼍盎貪L、關聯測試等測試類型對其進行覆蓋。

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

2.4.1.運行

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

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

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

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

5）注冊

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

--注冊后的提示頁面；

--前臺注冊頁面和后臺的管理頁面數據是否一致；

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

6）登錄

--使用合法的用戶登錄系統；

--系統是否允許多次非法的登陸，是否有次數限制；--使用已經登陸的賬號登陸系統是否正確處理；

--使用禁用的賬號登陸系統是否正確處理；

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

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

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

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

7）注銷

--注銷原模塊，新的模塊系統能否正確處理；

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

--注銷原用戶，新用戶系統能否正確處理；

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

2.4.2.APP前后臺切換

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

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

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

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

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

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

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

2.4.3.自動登陸

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

2)考慮無網絡情況時能否正常進入免登錄狀態；

3)切換用戶登錄后，要校驗用戶登錄信息及數據內容是否相應更新，確保原用戶退出；

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

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

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

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

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

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

2.4.4.數據更新

根據應用的業務規則，以及數據更新量的情況，來確定最優的數據更新方案。

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

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

3)根據業務、速度及流量的合理分配，確定哪些內容需要實時更新，哪些需要 定時更新；

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

5)檢查有數據交換的地方，均有相應的異常處理。

2.4.5.離線瀏覽

很多應用會支持離線瀏覽，即在本地客戶端會緩存一部分數據供用戶查看。

1)在無網絡情況可以瀏覽本地數據；

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

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

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

5)在對服務端的數據有更新時會給予離線的相應提示

2.4.6.APP更新

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

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

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

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

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

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

2.4.7.定位、照相機服務

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

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

3)當定位服務沒有開啟時，使用定位服務，會友好性彈出是否允許設置定位提示。當確定允許開啟定位時，能自動跳轉到定位設置中開啟定位服務；

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

2.4.8.時間測試

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

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

1)檢查push消息是否按照指定的業務規則發送；

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

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

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

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

2.5.性能測試

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

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

--內存滿時安裝App；

--運行App時手機斷電；

--運行App時斷掉網絡；

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

--App安裝、卸載的響應時間；

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

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

--App反復進行安裝卸載，查看系統資源是否正常；

--其他功能反復進行操作，查看系統資源是否正常；

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

2.6.兼容測試

主要測試內部和外部兼容性：

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

2）基于開發環境和生產環境的不同，檢驗在各種網絡連接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等)，App的數據和運用是否正確；

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

--不同操作系統的兼容性，是否適配；

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

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

2.7.回歸測試

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

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

2.8.用戶體驗測試

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

1）是否有空數據界面設計，引導用戶去執行操作；

2）是否濫用用戶引導；

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

4）菜單層次是否太深；

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

6）相關的選項是否離得很遠；

7）一次是否載入太多的數據；

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

9）標簽頁是否跟內容沒有從屬關系，當切換標簽的時候，內容跟著切換；

10）操作應該有主次從屬關系；

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

12）是否有橫屏模式的設計，應用一般需要支持橫屏模式，即自適應設計

2.9.硬件環境測試

2.9.1.網絡環境測試

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

1)無網絡時，執行需要網絡的操作，給予友好提示，確保程序不出現crash； 2)內網測試時，要注意選擇到外網操作時的異常情況處理；

3)在網絡信號不好時，檢查功能狀態是否正常，確保不因提交數據失敗而造成crash；

4)在網絡信號不好時，檢查數據是否會一直處于提交中的狀態，有無超時限制。如遇數據交換失敗時要給予提示；

5)在網絡信號不好時，執行操作后，在回調沒有完成的情況下，退出本頁面或者執行其他操作的情況，有無異常情況。此問題也會經常出現程序crash。2.9.2.服務器壘機或者出現404、500的情況下測試

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

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

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

主要內容：軟件測試計劃；軟件測試方案；軟件風險分析

1.軟件測試計劃

1.1 軟件測試計劃的簡介

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

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

1.2 如何編寫軟件測試計劃

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

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

3避免測試任務的安排超前于開發任務

4避免有些系統測試類型無法按期進入測試

5不正確的變更測試計劃

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

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

險分析。

2.軟件測試方案

2.1 軟件測試方案的概念

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

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

? 細化測試特征

? 測試用例的規劃

? 測試環境的規劃

? 自動化測試框架的設計

? 測試工具的設計和選擇

2.2 軟件測試計劃于軟件測試方案的區別

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

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

? 回報的對象不同，測試計劃向領導匯報，測試方案是組員共享該文檔

3.軟件測試的風險

? 軟件需求風險

? 人員的風險

? 測試環境的風險

? 測試工程師對產品的業務不熟悉

補充：

回歸測試：把以前檢查過的已經修復好的缺陷，拿來另測看有無帶來新的缺陷 反側：把開發人員已經處理的缺陷拿來測，看是否修復

第三篇：可復用測試用例研究

可復用測試用例研究

0、引言

軟件測試的關鍵環節是設計和執行測試用例。測試用例的質量與測試人員的技能、經驗以及對被測軟件的理解密切相關。如果測試人員對被測軟件不甚了解，很難在短時間內設計出有效的測試用例；有的測試用例雖然面面俱到，但冗余現象嚴重，浪費時間、人力和物力。

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

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

1、可復用測試用例特性

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

1）通用性。通用性是指可復用測試用例并不局限于具體的應用，不過分依賴于被測軟件的需求、設計和環境，能夠在某一類型、某一領域的相似軟件的測試中廣泛使用。

當前絕大多數的測試用例都不具有通用性，這樣的測試用例只能用于被測軟件和其當前環境，不可能用到其他軟件中。

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

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

如果測試用例之間存在著相互聯系，或測試用例的運行環境取決于其他測試用例的執行狀態，那么，其中的測試用例不能復用時，與之相關的測試用例的可復用性也不復存在。

如何將測試用例的關聯性降至最低，是設計可復用測試用例必須解決的問題。首先，每個測試用例的目標應盡量獨立、單一；其次，測試用例不包含過多的具體實現細節。

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

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

2、面向復用的測試用例設計過程

當前，測試用例設計都砥向不同的具體應用，與被測軟件是緊耦合的。考慮到復用的目的，測試用例的設計應不同于以往。本文提出了面向復用的測試用例設計過程，給出了設計過程中應實施的各項活動，主要包括被測軟件（系統）共性分析、測試策略分析、設計測試用例、測試用例評審、測試用例執行和修改、測試用例入庫共六個步驟，如圖l所示。該過程對現有測試用例的復用處理也是適用的。

2．1共性分析

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

這項活動需要領域專家、軟件專家、設計人員、測試專家等人員參與。

2．2 測試策略分析

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

2．3 設計測試用例

根據前兩個步驟的分析結果對每個可復用點設計測試用例。在設計時，應使所設計的測試用例滿足可復用測試用例的特性，特別要注意以下幾方面：

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

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

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

需要說明的是，對于一個具體的測試項目，因為面向復用，所以以上所設計的測試用例可能不完全滿足被測軟件的測試需求，為此，應針對被測軟件的需求補充新的用例或對現有用例進行充實完善。

2．4 測試用例評審

可復用測試用例設計完成后，組織領域專家、軟件專家、測試專家、軟件設計人員對其進行評審，確保所設計的測試用例是正確的，滿足可復用測試用例的特性。

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

2．5 測試用例執行和修改

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

2．6 測試用例入庫

將經過測試執行確認的可復用測試用例統一納入測試用例庫中，供測試人員在后續軟件測試或以后的項目中查詢使用。測試用例庫應是按照一定的組織結構形成的測試用例集合。

3、基于復用的軟件測試模型

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

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

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

“定義測試策略”中，測試人員根據測試目標和上一步的結果定義測試策略，包括測試方法、測試類型、測試環境等內容。

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

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

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

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

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

該模型的優點為：1）對已有的可復用的測試用例進行了復用，避免了大量的重復性工作，提高了測試質量和效率；2）考慮了面向復用的測試用例設計，避免再次產生大量的不可復用的測試用例。

4、可復用測試用例描述要素

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

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

2）ID：該ID在數據庫中是唯一的。

3）版本號：用于測試用例的版本管理，每個測試用例應按照定義的規則設定一個版本號。

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

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

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

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

8）應用領域：說明被測軟件所屬領域。

9）系統類型：描述被測軟件所在系統的架構，如B／S、C／S、嵌入式軟件、非嵌入式軟件等。

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

11）測試環境：描述該測試用例執行的軟硬件環境。

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

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

14）操作步驟：說明執行該測試用例的一系列相關聯的操作。

15）預期結果：說明測試用例執行后的期望結果。每一操作步驟也可有自己的預期結果。

16）評估標準：描述評判測試用例執行中產生的中間和最后結果是否正確的準則。

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

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

5、應用

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

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

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

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

1．測試計劃的要點

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

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

2．制定測試策略

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

基于測試技術的測試策略，根據軟件系統的技術構成和層次結構，著重考慮如何分層測試、選擇哪些測試工具、如何將白盒測試和黑盒測試有機地結合起來等。

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

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

全面細致地了解產品的項目信息：應用領域、測試范圍、市場需求、產品特點、主要功能和技術架構；

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

根據軟件單元在系統結構的重要性差異和一旦發生故障將給客戶造成的損失大小，來確定軟件測試的等級、重點和先后次序；

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

3．確定測試范圍

測試主要依據 “產品設計規格說明書”、代碼所發生的變化及其影響的區域，來確定哪些功能和特性要測試，哪些功能和特性不需要測試。在確定測試范圍時，主要考慮的因素有：

優先級最高的需求功能

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

容易出現問題的部分功能

過去測試不夠充分的地方

經常被用戶使用的功能和配置（占20%）

4．所需資源和日程安排

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

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

5．編制測試計劃的技巧

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

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

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

測試項目的輸入、輸出和質量標準，應與各方達成一致；

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

6．測試項目計劃的評審

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

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

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

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

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

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

1）測試用例的重要性是毋庸置疑的，它是軟件測試全部過程的核心，是測試執行環節的基本依據，如果這個依據不能足夠發揮它應起的作用，那是不是說這個依據不明確、依據設計的不合理呢？答案是肯定的！

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

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

2.改進測試用例執行過程

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

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

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

項目的測試負責人和測試工程師在 需求階段 的任務有：

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

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

2）軟件分析設計階段：

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

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

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

3）軟件開發階段： 編寫測試用例。應該遵守的原則是：

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

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

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

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

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

l 是測試用例要有 狀態跟蹤，可根據用例執行狀態索引用例（測試通過、測試失敗、測試中斷等）；

l 是執行失敗的用例要 鏈接到相應的缺陷報告，如有根據缺陷報告檢索測試用例的試圖更妙，可評估該缺陷影響范圍的大??；

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

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

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

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

C）測試負責人每日負責跟蹤本測試子周期或階段的測試用例執行情況，以及每日提交的缺陷報告，根據執行進展狀態以及缺陷數量或嚴重等級與項目高層或其他人員展開交流，商議解決途徑，并確定或調整未來時間的測試任務。

D）測試執行者負責執行自己區域的測試用例，還要負責跟蹤該區域軟件缺陷的修改進展，根據其狀態 不斷驗證軟件功 能點。

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

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

l 是選擇恰當的測試工具品牌，并要求提供培訓；

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

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

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

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

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

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

新員工來做，那就死翹翹了?。┢渌f明：加強測試部門內部人員的培訓教育很重要，包括工作技能與個人素質兩方面，可通過國內主要的培訓機構，也可是購買工具廠商的直接培訓。應該說，很多測試新人對于測試用例的書寫還存在問題，更別提及測試用例的管理或執行；以此可見，我們的測試工程師需要培訓的空間還很大。

3.總結

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

第五篇：做好測試計劃和測試用例工作的關鍵

做好測試計劃和測試用例的工作的關鍵

做好測試計劃和測試用例的工作的關鍵（轉）

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

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

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

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

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

寫好測試方案的關鍵在于：有一個合理的測試計劃熟悉相關業務深入體會用戶的實際需求

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

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

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

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

所以我的看法是：對業務理解的深入程度經驗有自己的文檔

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

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

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

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

完整的大綱應該是：

目錄

測試計劃標識符

目錄表

參考文獻

詞匯表

介紹

測試項

軟件風險問題

待測特征

不予測試的特征

方法

測試項通過/失敗準則

掛起準則和恢復需求

測試交付物

測試任務

環境需求

職責

人員安排與培訓需求

進度表

計劃風險與應急措施

審批