測試用例規(guī)范

1、本文檔如對你有幫助，請幫忙下載支持！1. 概述1.1 目的統(tǒng)一測試用例編寫的規(guī)范，為測試設計人員提供測試用例編寫的指導，提高編寫的測試用例的可讀性，可執(zhí)行性、合理性。為測試執(zhí)行人員更好執(zhí)行測試，提高測試效率，最終提高公司整個產品的質量。1.2 使用范圍適用于對產品的業(yè)務流程、功能測試用例的編寫。1.3 名詞解釋系統(tǒng)測試： 是對已經集成好的軟件系統(tǒng)進行徹底的測試，以驗證軟件系統(tǒng)的正確性和性能等滿足其規(guī)約所指定的要求，檢查軟件的行為和輸出是否正確并非一項簡單的任務，它被稱為測試的“先知者問題” 。測試分析： 對重要業(yè)務、重要流程進行測試前的分析。業(yè)務流程測試用例： 關于產品業(yè)務、重要流程的測試用例

2、。2. 測試用例編寫原則2.1 系統(tǒng)性1、對于系統(tǒng)業(yè)務流程要能夠完整說明整個系統(tǒng)的業(yè)務需求、系統(tǒng)由幾個子系統(tǒng)組成以及它們之間的關系；2、對于模塊業(yè)務流程要能夠說明清楚子系統(tǒng)內部功能、重要功能點以及它們之間的關系；2.2 連貫性1、對于系統(tǒng)業(yè)務流程來說，各個子系統(tǒng)之間是如何連接在一起，如果需要接口，各個子系統(tǒng)之間是否有正確的接口；如果是依靠頁面鏈接，頁面鏈接是否正確；2、對于模塊業(yè)務流程來說，同級模塊以及上下級模塊是如何構成一個子系統(tǒng)，其內部功能接口是否連貫；2.3 全面性1、應盡可能覆蓋程序的各種路徑2、應盡可能覆蓋系統(tǒng)的各個業(yè)務3、應考慮存在跨年、跨月的數據4、大量數據并發(fā)測試的準備5、系統(tǒng)

3、中各功能、業(yè)務的異常情況2.4 正確性1、輸入用戶實際數據以驗證系統(tǒng)是否滿足需求規(guī)格說明書的需求。2、測試用例中的測試點應保證至少覆蓋需求規(guī)格說明書中的各項功能。2.5 符合正常業(yè)務慣例1、測試數據應符合用戶實際工作業(yè)務流程2、兼顧各種業(yè)務變化的可能3、要符合當前業(yè)務行業(yè)法律，法規(guī)。2.6 仿真性人名、地名、電話號碼等應具有模擬功能，符合一般的命名慣例。2.7 容錯性（健壯性）程序能夠接收正確數據輸入并且產生正確（預期）的輸出，輸入非法數據（非法類型、不符合要求的數據、溢出數據等） ，程序應能給出提示并進行相應處理。3. 測試用例設計方法1. 等價類劃分法：將所有可能的輸入數據（有效的和無效的

4、）劃分成若干個等價類。2. 邊界值分析法：指對輸入的邊界條件進行分析，設計出針對邊界值的測試用例。3. 因果圖法：就是利用圖解法分析軟件輸入 （ 原因 ） 和輸出條件（ 結果 ） 之間的關系，以設計測試用例的方法。因果圖法適合于檢查程序輸入條件的多種情況的組合，并最終生成判定表，來獲得對應的測試用例。4. 功能圖法功能圖是描述程序狀態(tài)變化、轉移的過程，因為軟件運行或操作的過程可以看作是其狀態(tài)不斷發(fā)生變化的過程。測試用例的設計就是如何覆蓋所有軟件表現出來的狀態(tài)，即在滿足輸入 / 輸出的一組條件下，軟件運行是一系列有次序的、受控制的狀態(tài)變化過程。5. 錯誤推測法推測法主要依賴經驗、直覺來作出簡單的

5、判斷甚至是猜測，給出可能存在缺陷的條件、場景等，在找到缺陷后，設計出相應的測試用例。6. 正交實驗設計方法主要步驟是：（1） 對軟件需求規(guī)格說明中的功能要求進行劃分（ 層層分解與展開） ，分解成具體的、相對獨立的基本功能。（2） 根據基本功能的質量需求，找出影響其功能實現的操作對象和外部因素，每個因素的取值可以看作水平，多個取值就存在多個水平。（3） 確定待測試軟件中所有因素及其權值，這是測試用例設計的關鍵，確保全面、準確。權值是依據各因素的影響范圍、發(fā)生的頻率和質量的需求來確定的。（4） 加權篩選，生成因素分析表。（5） 利用正交表構造測試數據集，正交表的每一行，就是一條測試用例?？紤]交互作

6、用不可忽略的處理因素和不可混雜的原則，有交互作用的組合優(yōu)先安排。利用正交實驗設計方法設計測試用例，可控制生成的測試用例數量，覆蓋率高且測試效率高。7. 接口間測試測試各個模塊相互間的協(xié)調和通信情況，數據輸入輸出的一致性和正確性。8. 數據庫測試依據數據庫設計規(guī)范對軟件系統(tǒng)的數據庫結構、數據表及其之間的數據調用關系進行測試。9. 可理解（操作）性理解和使用該系統(tǒng)的難易程度（界面友好性） 。10. 可移植性在不同操作系統(tǒng)及硬件配置情況下的運行性。4. 測試用例編寫規(guī)范4.1 測試用例書寫規(guī)則用例元素說明用例名稱： 指明要測試的內容，如被測模塊名稱、業(yè)務流程名稱等。功能（業(yè)務）描述、規(guī)則、邏輯： 對

7、要進行測試的功能或業(yè)務進行簡要的描述。根據需求規(guī)格說明書、實際業(yè)務情況或其它相關文檔列出本用例的規(guī)則、邏輯關系或需求點。操作描述（輸入 動作） ： 描述本條測試用例的輸入步驟，首先簡要描述本條測試用例的測試點，再對本測試點進行詳細步驟描述或輸入數據設置（需要詳細進行描寫） 。預期結果（輸出） ： 描述輸入數據后程序應該輸出的結果。本文檔如對你有幫助，請幫忙下載支持!前提條件 數據準備：執(zhí)行測試用例前需先要執(zhí)行的操作或配置。最基本的要求1 .具有清晰名稱、前提條件、操作步驟、期望結果的；2 .可被他人理解的；3 .可被他人執(zhí)行的；具體元素要求1 .用例名稱1） 一定要包含測試的業(yè)務流程。（鑒于公

8、司使用的TD在Test）2）名稱簡潔易懂，不要包括具體操作步驟；2 .前置條件3 ）執(zhí)行用例測試步驟前需要做的所有必備條件，原則上所有用例都有前 置條件；4 ）不可將其他用例作為前置條件，前置條件需要語言描述；5 ）完整清楚，包括入口、帳號類型、賬號權限、數據準備等，具體要求 如下：3.1） 入口：覆蓋所有功能入口，包含 URL直接訪問；3.2） 賬號類型和權限：覆蓋全部會員類型，注意業(yè)務權限控制，比如子賬 號權限，disable會員權限；3.3） 數據準備：數據準備完整正確，覆蓋到線上環(huán)境的所有情況；標識出 業(yè)務流程處于的條；件，寫明數據庫表字段值，如OFFER.status=TBD;對于復

9、雜的數據準備，寫滿具體SQL3.4） 步驟1）操作步驟描述清晰。如：在什么頁面，點擊什么鏈接或按鈕；頁面入 口、鏈接、按鈕名稱都要寫清楚；2）操作和結果是 對應的，但操作中不要包含結果的檢查；3）用例描述中不允許存在連詞、介詞，比如：而且，和，還（這種情況 可以拆分為多個點）；4）用例描述中不允許出現假設性詞匯，比如：假如，或許，可能， 的 時候等；5）用例描述中不允許出現二義性語句；3.5） 結果1）原則上每個用例必需要有預期結果，結果不能為空；2）結果中只能包含結果，不能有步驟；3） 一個結果有多個檢查點時，確保檢查點完整：3.1） 結果含需要驗證的所有結果輸出，如頁面檢查、存儲檢查、消 息檢查等；3.2） 結果涉及頁面，需明確頁面提示結果、數據變化；3.3） 結果涉及存儲：需明確關鍵值變化、數據庫具體的表和關鍵字 字段值變化；3.4） 結果涉及消息：需明確關鍵查看內容；3.5） 結果對應不同輸入數據有差別時需分別對應描述清晰；用例維護規(guī)范測試用例編寫完成后，應對測試用例進行持續(xù)的維護：1 .新項目需求變更，應及時對測試用例進行修改；2 .維護期項目，可根據項目組情況周期對用例進行維護；3 .所有發(fā)現的bug和故障，基于測試用例無法