測試用例設計流程

　　測試用例是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程式路徑或核實是否滿足某個特定需求。小編給大家整理了關於測試用例流程，希望你們喜歡!

　　1.測試需求分析從軟體需求文件中，找出待測試軟體/模組的需求，通過自己的分析、理解，整理成為測試需求，清楚被測試物件具有哪些功能。測試需求的特點是：包含軟體需求，具有可測試性。測試需求應該在軟體需求基礎上進行歸納、分類或細分，方便測試用例設計。測試用例中的測試集與測試需求的關係是多對一的關係，即一個或多個測試用例集對應一個測試需求。

　　2.業務流程分析軟體測試，不單純是基於功能的黑盒測試，還需要對軟體的內部處理邏輯進行測試。為了不遺漏測試點，需要清楚的瞭解軟體產品的業務流程。建議在做複雜的測試用例設計前，先畫出軟體的業務流程。如果設計文件中已經有業務流程設計，可以從測試角度對現有流程進行補充。如果無法從設計中得到業務流程，測試工程師應通過閱讀設計文件，與開發人員交流，最終畫出業務流程圖。業務流程圖可以幫助理解軟體的處理邏輯和資料流向，從而指導測試用例的設計。

　　3.測試用例設計完成了測試需求分析和軟體流程分析後，開始著手設計測試用例。測試用例設計的型別包括功能測試，邊界測試，異常測試，效能測試，壓力測試等。在用例設計中，除了功能測試用例外，應儘量考慮邊界、異常、效能的情況，以便發現更多的隱藏問題。

　　4.測試用例評審測試用例設計完成後，為了確認測試過程和方法是否正確，是否有遺漏的測試點，需要進行測試用例的評審。測試用例評審一般是由測試leader安排，參加的人員包括：測試用例設計者、測試leader、專案經理、開發工程師、其它相關開發測試工程師。測試用例評審完畢，測試工程師根據評審結果，對測試用例進行修改，並記錄修改日誌。

　　5.測試用例更新完善測試用例編寫完成之後需要不斷完善，軟體產品新增功能或更新需求後，測試用例必須配套修改更新;在測試過程中發現設計測試用例時考慮不周，需要對測試用例進行修改完善;在軟體交付使用後客戶反饋的軟體缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進行完善。一般小的修改完善可在原測試用例文件上修改，但文件要有更改記錄。軟體的版本升級更新，測試用例一般也應隨之編制升級更新版本。測試用例是“活”的，在軟體的生命週期中不斷更新與完善。

　　測試用例重要原因

　　測試用例構成了設計和制定測試過程的基礎。

　　測試的“深度”與測試用例的數量成比例。由於每個測試用例反映不同的場景、條件或經由產品的事件流，因而，隨著測試用例數量的增加，您對產品質量和測試流程也就越有信心。

　　判斷測試是否完全的一個主要評測方法是基於需求的覆蓋，而這又是以確定、實施和/或執行的測試用例的數量為依據的。類似下面這樣的說明：“95 % 的關鍵測試用例已得以執行和驗證”，遠比“我們已完成 95 % 的測試”更有意義。

　　測試工作量與測試用例的數量成比例。根據全面且細化的測試用例，可以更準確地估計測試周期各連續階段的時間安排。

　　測試設計和開發的型別以及所需的資源主要都受控於測試用例。

　　測試用例通常根據它們所關聯關係的測試型別或測試需求來分類，而且將隨型別和需求進行相應地改變。最佳方案是為每個測試需求至少編制兩個測試用例：

　　一個測試用例用於證明該需求已經滿足，通常稱作正面測試用例;

　　另一個測試用例反映某個無法接受、反常或意外的條件或資料，用於論證只有在所需條件下才能夠滿足該需求，這個測試用例稱作負面測試用例。

　　一、測試用例是軟體測試的核心

　　軟體測試的重要性是毋庸置疑的。但如何以最少的人力、資源投入，在最短的時間內完成測試，發現軟體系統的缺陷，保證軟體的優良品質，則是軟體公司探索和追求的目標。每個軟體產品或軟體開發專案都需要有一套優秀的測試方案和測試方法。

　　影響軟體測試的因素很多，例如軟體本身的複雜程度、開發人員***包括分析、設計、程式設計和測試的人員***的素質、測試方法和技術的運用等等。因為有些因素是客觀存在的，無法避免。有些因素則是波動的、不穩定的，例如開發隊伍是流動的，有經驗的走了，新人不斷補充進來;一個具體的人工作也受情緒等影響，等等。如何保障軟體測試質量的穩定?有了測試用例，無論是誰來測試，參照測試用例實施，都能保障測試的質量。可以把人為因素的影響減少到最小。即便最初的測試用例考慮不周全，隨著測試的進行和軟體版本更新，也將日趨完善。

　　因此測試用例的設計和編制是軟體測試活動中最重要的。測試用例是測試工作的指導，是軟體測試的必須遵守的準則。更是軟體測試質量穩定的根本保障。