測試用例規(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.1系統(tǒng)性1、對于系統(tǒng)業(yè)

2、務流程要能夠完整說明整個系統(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、應考慮存在跨年、跨月的數(shù)據4、大量數(shù)據并發(fā)測試的準備5、系統(tǒng)中各功能、業(yè)務的異常情況2.4正確性1、輸入用戶實際數(shù)據

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

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

5、6. 正交實驗設計方法主要步驟是：(1) 對軟件需求規(guī)格說明中的功能要求進行劃分(層層分解與展開)，分解成具體的、相對獨立的基本功能。(2) 根據基本功能的質量需求，找出影響其功能實現(xiàn)的操作對象和外部因素，每個因素的取值可以看作水平，多個取值就存在多個水平。(3) 確定待測試軟件中所有因素及其權值，這是測試用例設計的關鍵，確保全面、準確。權值是依據各因素的影響范圍、發(fā)生的頻率和質量的需求來確定的。(4) 加權篩選，生成因素分析表。(5) 利用正交表構造測試數(shù)據集，正交表的每一行，就是一條測試用例。考慮交互作用不可忽略的處理因素和不可混雜的原則，有交互作用的組合優(yōu)先安排。利用正交實驗設計方法設計

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

7、相關文檔列出本用例的規(guī)則、邏輯關系或需求點。² 操作描述（輸入動作）：描述本條測試用例的輸入步驟，首先簡要描述本條測試用例的測試點，再對本測試點進行詳細步驟描述或輸入數(shù)據設置（需要詳細進行描寫）。² 預期結果（輸出）：描述輸入數(shù)據后程序應該輸出的結果。² 前提條件數(shù)據準備：執(zhí)行測試用例前需先要執(zhí)行的操作或配置。最基本的要求1.具有清晰名稱、前提條件、操作步驟、期望結果的；2.可被他人理解的；3.可被他人執(zhí)行的；具體元素要求1.用例名稱1）一定要包含測試的業(yè)務流程。（鑒于公司使用的TD在Test）2）名稱簡潔易懂，不要包括具體操作步驟；2.前置條件1）執(zhí)行用例測試步

8、驟前需要做的所有必備條件，原則上所有用例都有前置條件；2）不可將其他用例作為前置條件，前置條件需要語言描述；3）完整清楚，包括入口、帳號類型、賬號權限、數(shù)據準備等，具體要求如下：3.1）入口：覆蓋所有功能入口，包含URL直接訪問；3.2）賬號類型和權限：覆蓋全部會員類型，注意業(yè)務權限控制，比如子賬號權限，disable會員權限；3.3）數(shù)據準備：數(shù)據準備完整正確，覆蓋到線上環(huán)境的所有情況；標識出業(yè)務流程處于的條；件，寫明數(shù)據庫表字段值，如OFFER.status=TBD；對于復雜的數(shù)據準備，寫清具體SQL3.操作步驟1）操作步驟描述清晰。如：在什么頁面，點擊什么鏈接或按鈕；頁面入口、鏈接、按鈕

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