測試工程師有一樣很重要的工作就編寫測試用例。 測試用例是對需求的另一種描述，它能引導大家進一步加深對系統的理解和對特性的全面關注，從而幫助產品和開發重新審核需求的合理性和一致性，所以應該是測 試工程師最重要的一項產出。一般的測試用例分為輸入，行為，和期望結果三個部分。這三個部分通常的測試用例都能滿足，但是怎樣的測試用例才能算上優秀的測 試用例呢？基於以往之測試經驗，我總結了優秀測試用例的幾個特點。
1、正確性：毫無疑問，測試用例 必須是需求的正確描述。但是我們往往忘記了多想一步：這是使用者正確需要的嗎？我曾經有個乙個失敗的testcase，當乙個條件輸入異常的時候系統返回 -1給前端介面，然後前端返回錯誤資訊，這是當時對異常的處理需求，可是如果多想一步，當乙個條件異常的時候難道我們不能返回滿足部分條件的結果給使用者 嗎？讓使用者的體驗更加良好嗎？
2、完整性：就測試用例本身而言，是無窮盡的，只要是鍵盤的任意組合都可以算作測試用例。而乙個優秀的測試工程師就是從無窮中找到最能保證質量，最能發現bug的測試用例出來，發現無窮的最小集，通常功能測試用 例的找尋方法有等價類和邊界值是最簡單的方法，建議結合使用，先劃分等價類，再把等價類中的邊界值找出來。我見過很多在=和》=之間徘徊的bug。 正交法出來的用例一般太多，所以需要測試工程師在正交法的結果中再做組合，建議結合錯誤定位法減少用例的執行。狀態圖在資料統計，結算中的使用概率最高。 每個狀態和流程都需要一一考慮正常和異常的分支，正常的流程乙個靠譜的開發能自己保證，但是異常的分支很少有開發考慮清楚，這就是體現測試工程師價值的地 方了。但是完整性絕不僅僅是功能測試，除了功能測試之外，常見的還有效能測試，安全測試，相容性測試，安裝友好測試，地域語言測試和使用者體驗測試（usability）。
3、輸入具體：對於這三個部分我們都希望它是固定的，具體的，比如輸入框的輸入，我們可以寫成具體「諾基亞」，但是不要寫「正確的輸入」，或者「中文的輸入」，這些都會導致測試用例的不確定性。模糊的輸入應該在具體輸入的上一級結構，作為測試的思路和分類使用。
5、用例細化：輸入的一種組合，或者一條流程線對應乙個測試用例，盡量不要在乙個用例中融和多種情況，在自動化測試的指令碼中為了提高效率我們會在乙個自動化指令碼中融入各種情況的輸入，然後乙個動作，所有的輸出一次生成，針對這種情況，建議在指令碼中對各種輸入對應的案例一一備註說明，執行失敗的時候也方便新人定位問題。
6、判斷點準確無歧義：我經常看到這樣的檢查點：「結果正確」，「速度合理」，這些檢查點對其他人沒有絲毫的幫助。所以應該盡量做出讓機器也能識別的檢查點，比如輸出「8」，或者「rt<30m」。
7、合理區分優先順序：在bugfree中有4個級別的優先順序，從1到4，1表示最重要的測試用例，4表示最不重要的測試用例。不同的缺陷管理平台對優先順序的定義會有不同，但是都會有優先順序的概念。在時間緊張的情況下，優先順序的作用會特別大，我們會優先執行比較重要，對系統功能，使用者體驗影響大的測試用例，將級別比較低的測試用例留在後期或者指派給一些新人來執行。
加分點：
2、記錄每輪的測試結果：對於有些功能的測試用例，結果只是簡單的pass我們不需要記錄，但是對於效能測試這些結果不確定的測試用例，如果能保留每次測試的結果對於之後的測試是很有幫助的。對於fail的部分用例，如果能和bug產生一一對應關係對之後的回歸也產生很大的便利。
3、對檢查點進行邏輯說明：很多用例有了結果的檢查點，但是為什麼是這個結果，對於新人來說必須重新翻看需求或者設計文件才能理解。尤其對於演算法的測試，理解需求和邏輯是乙個比較痛苦的過程，如果能夠對每個結果進行一些備註和邏輯上的說明，會和方便自己今後以及新人對用例的理解。
以上是對測試用例特性的一些總結，真正編寫測試用例的時候，mm圖由上到下的樹形結構會對測試用例的結構和思路提供很大的幫助，在測試用例評審的時候也 方便展示和說明，所以強烈推薦作為附件上傳。而且對系統越加深入的了解越能寫出完善的測試用例，很多開發錯誤的理解測試工程師只需要知道需求就可以了，不 需要對程式有**級別的了解，但是無數的實踐證明測試工程師越了解系統的設計，編碼的邏輯越能發現潛在的bug和風險。unit test通 常由開發完成比較高效，但是integration test開始就必須有測試工程師開始真正介入，這期間能發現很多潛在的問題，如果把風險全部留到system test的階段風險是很大的，大量case的回歸和問題的定位都會變得更加複雜，成本更加的巨大。所以在時間允許的情況下毫無疑問是前期的測試越完善整體 效率越高。
軟體測試用例優秀例子 軟體測試用例要素詳解
arnold 大話軟體測試用例要素 zhuanlan.zhihu.com 我們經常都知道乙個測試用例裡面包含以下幾個要素 1，用例編號 2，模組 3，場景 4，用例名稱 5，前置條件 6，測試等級 7，操作步驟 8，預期結果 需求要求的結果 9，實際結果 10，建立日期 11，是否通過 我們分析下，...
測試用例（四）測試用例編寫
一.測試用例編寫方法 1.等價類劃分 如何選擇適當的資料子集，來代表整個資料集。通過降低測試的資料去實現 合理的 覆蓋，覆蓋了更多的可能資料，以發現更多的軟體缺陷 邊界值分析法 2.邊界值分析 使用邊界值分析方法設計測試用例時一般與等價類劃分結合起來，但它不是從乙個等價類中任選乙個例子作為代表，而是...
手機測試用例 STK測試用例
id 功能描述 操作步驟 預期結果 test time p fcomment tester test time p fcomment tester stk服務 sim卡適應性測試 1 選取支援stk功能的sim卡，插入手機中 手機應支援stk功能，會將stk選單自動加入主選單列表中 2 進入stk功...