測試用例編寫流程
測試用例是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程式路徑或核實是否滿足某個特定需求。以下是小編為大家整理的關於，給大家作為參考，歡迎閱讀!
測試用例三要素：
1、標題：條件及結果 2、步驟：操作步驟 3、預期：輸出結果
測試基礎：輸入***方法***--->輸出***結果***
常用測試方法：
1.等價類劃分
常見的軟體測試面試題劃分等價類:?等價類是指某個輸入域的子集合.在該子集合中,各個輸入資料對於揭露程式中的錯誤都是等效的.併合理地假定:測試某等價類的代表值就等於對這一類其它值的測試.因此,可以把全部輸入資料合理劃分為若干等價類,在每一個等價類中取一個數據作為測試的輸入條件,就可以用少量代表性的測試資料.取得較好的測試結果.等價類劃分可有兩種不同的情況:有效等價類和無效等價類.
2.邊界值分析法
邊界值分析方法是對等價類劃分方法的補充。測試工作經驗告訴我,大量的錯誤是發生在輸入或輸出範圍的邊界上,而不是發生在輸入輸出範圍的內部.因此針對各種邊界情況設計測試用例,可以查出更多的錯誤.
使用邊界值分析方法設計測試用例,首先應確定邊界情況.通常輸入和輸出等價類的邊界,就是應著重測試的邊界情況.應當選取正好等於,剛剛大於或剛剛小於邊界的值作為測試資料,而不是選取等價類中的典型值或任意值作為測試資料
3.錯誤推測法
基於經驗和直覺推測程式中所有可能存在的各種錯誤,從而有針對性的設計測試用例的方法.錯誤推測方法的基本思想:列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例.例如,在單元測試時曾列出的許多在模組中常見的錯誤.以前產品測試中曾經發現的錯誤等,這些就是經驗的總結。還有,輸入資料和輸出資料為0的情況。輸入表格為空格或輸入表格只有一行.這些都是容易發生錯誤的情況。可選擇這些情況下的例子作為測試用例.
4.因果圖方法
前面介紹的等價類劃分方法和邊界值分析方法,都是著重考慮輸入條件,但未考慮輸入條件之間的聯絡,相互組合等.考慮輸入條件之間的相互組合,可能會產生一些新的情況.但要檢查輸入條件的組合不是一件容易的事情,即使把所有輸入條件劃分成等價類,他們之間的組合情況也相當多.因此必須考慮採用一種適合於描述對於多種條件的組合,相應產生多個動作的形式來考慮設計測試用例.這就需要利用因果圖***邏輯模型***.因果圖方法最終生成的就是判定表.它適合於檢查程式輸入條件的各種組合情況.
5.正交表分析法
有時候，可能因為大量的引數的組合而引起測試用例數量上的激增，同時，這些測試用例並沒有明顯的優先順序上的差距，而測試人員又無法完成這麼多數量的測試，就可以通過正交表來進行縮減一些用例，從而達到儘量少的用例覆蓋儘量大的範圍的可能性。
6.場景分析方法
指根據使用者場景來模擬使用者的操作步驟，這個比較類似因果圖，但是可能執行的深度和可行性更好。
另外設計眾多小功能的業務，一個一個進行測試
測試用例設計一般步驟
測試需求分析從軟體需求文件中，找出待測試軟體/模組的需求，通過自己的分析、理解，整理成為測試需求，清楚被測試物件具有哪些功能。測試需求的特點是：包含軟體需求，具有可測試性。測試需求應該在軟體需求基礎上進行歸納、分類或細分，方便測試用例設計。測試用例中的測試集與測試需求的關係是多對一的關係，即一個或多個測試用例集對應一個測試需求。
業務流程分析軟體測試，不單純是基於功能的黑盒測試，還需要對軟體的內部處理邏輯進行測試。為了不遺漏測試點，需要清楚的瞭解軟體產品的業務流程。建議在做複雜的測試用例設計前，先畫出軟體的業務流程。如果設計文件中已經有業務流程設計，可以從測試角度對現有流程進行補充。如果無法從設計中得到業務流程，測試工程師應通過閱讀設計文件，與開發人員交流，最終畫出業務流程圖。業務流程圖可以幫助理解軟體的處理邏輯和資料流向，從而指導測試用例的設計。
測試用例設計完成了測試需求分析和軟體流程分析後，開始著手設計測試用例。測試用例設計的型別包括功能測試，邊界測試，異常測試，效能測試，壓力測試等。在用例設計中，除了功能測試用例外，應儘量考慮邊界、異常、效能的情況，以便發現更多的隱藏問題。
測試用例評審測試用例設計完成後，為了確認測試過程和方法是否正確，是否有遺漏的測試點，需要進行測試用例的評審。測試用例評審一般是由測試leader安排，參加的人員包括：測試用例設計者、測試leader、專案經理、開發工程師、其它相關開發測試工程師。測試用例評審完畢，測試工程師根據評審結果，對測試用例進行修改，並記錄修改日誌。
測試用例更新完善測試用例編寫完成之後需要不斷完善，軟體產品新增功能或更新需求後，測試用例必須配套修改更新;在測試過程中發現設計測試用例時考慮不周，需要對測試用例進行修改完善;在軟體交付使用後客戶反饋的軟體缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進行完善。一般小的修改完善可在原測試用例文件上修改，但文件要有更改記錄。軟體的版本升級更新，測試用例一般也應隨之編制升級更新版本。測試用例是“活”的，在軟體的生命週期中不斷更新與完善。