https://blog.csdn.net/lionking0318/article/details/83988889
編寫測試用例是測試人員的基本功，可是在學校的時候我們好像也沒有相應的課程來教我們相應的設計方法。后來我們從網上或是一些軟件測試相關的書上會看到不少介紹編寫測試用例的方法，如：等價類划分，邊界值分析法，錯誤推測法，判定表法，正交實驗法等，可是我們工作后這些方法好像不太好用。
曾經我面試過一個同學，在面試過程中讓他寫了一個登錄功能的測試用例。他使用等價類划分法來編寫測試用例，寫的超級多，我不能說不正確，可是最后還是把他給passed掉了。為什么呢？真正工作中是要以需求為主，從實際出發，不能以書本知識照本宣科的嘛！
一，編寫覆蓋全面的測試用例
在測試工作中，我們應該事實求是，接到需求后然后按如下幾個方面來設計測試用例：
1，分別設計不同類別的測試用例
測試用例需要先區分類別，然后再進行設計。如冒煙測試用例，主要用來支持開發自測試，以及開發提測后，測試人員用來驗證提測質量。冒煙測試用例主要覆蓋需求核心業務流程，如果測試用例通過不過，會影響測試工作的正常開展。全功能測試用例，覆蓋整個需求的測試用例，用來在測試過程中執行用例，來驗證開發的代碼是否符合產品的需求，發現可能存在的問題。不同類別的測試用例有不同的用途，需要分別來對待的。
2，從用戶角度出發，編寫測試用例
雖然我們了解到很多設計測試用例的方法，可是在實際工作中不能完全按着這些方法來實施的。這個需求的目的是什么？比如說一個活動頁，需要展示給用戶我們推薦的商品優惠活動，從而增加商品的銷量。所以我們的測試用例就要從這個目的出發，檢測商品信息展示情況，商品的優惠信息，商品相關的操作，跳轉與交互信息是否符合要求。活動頁的兼容性如何，是否符合各種場景，活動頁的並發性以及相關交易的安全性，都是測試用例設計的出發點。
3，邊界值，意外情況，異常用例的編寫
從用戶角度出發編寫用例后，再需要輔助邊界值法，將意外情況，邊界值等異常測試用例添加進來。如上面提到的活動頁需求，對於活動時間邊界，庫存邊界，優惠限制條件邊界等等，都需要補充相應的測試用例去驗證的；同時，性能邊界，安全邊界也是我們需要考慮的地方，只有補充了這些邊界，才不會造成遺漏的地方。
4，根據業務流程，編寫流程相關的用例
有的時候我們的新需求只是一個業務流程的一部分，在通過相應的方法編寫測試用例，驗證了本次需求的核心功能，邊界條件后，還需要考慮相關的具體業務流程。編寫業務流程相關的測試用例，來驗證本次需求對業務流程上下游的影響，能否正確傳遞數據。本次需求可能影響到的地方，測試用例也必須覆蓋得到。
5，根據代碼實現方案編寫用例
根據代碼實現的方案編寫測試用例，如編碼采取前后端分離的方式實現的。我們就可以分開測試，后端接口和服務從代碼層來保證接口或是服務功能的正確性和完整性。然后前端的測試用例主要關注業務邏輯，數據和樣式的顯示即可。根據接口和服務的使用場景，來設定測試用例的側重點和粒度，這樣也可以做到測試前置。
6，根據業務經驗編寫用例，新業務，影響到的業務
測試人員必須對你的業務有充分的了解，這也是一個測試人員必備的能力。然后地遇到新的需求的時候，可以從參加需求評審的時候快速評估出本次需求可能影響的范圍，從而對相關要影響的地方添加用例覆蓋，進行回歸測試。如一個需求是對某接口響應時間的調優，我們就需要對調用這個接口的所有業務進行相關用例覆蓋，測試的時候進行回歸測試。有這樣的技術敏感度，業務熟悉度，才能做到不會遺漏影響到的功能。
二，測試用例設計工具
測試用例設計工具很多，常用的有FreeMind,Excel,testlink和公司自主研發的用例管理平台。
1，FreeMind，思維導圖，用來設計測試用例，按用例涉及的功能模塊，用例場景進行分別設計。中心主題為本次需求的名稱，分支主題為各個功能模塊，子主題為每個測試用例的名稱，下面可以為各個測試點，最終節點為預期結果。
2，Excel,來組織測試用例。不同的公司有不同的用例模板，通常情況下有下面幾個列內容：用例ID,用例名，用例級別，用例描述，前置條件，測試步驟，預期結果和測試結果等。當然還有各個公司重點關注的列內容，按要求進行設計用例即可。
3，testlink,開源用例管理平台。左側樹型結構管理用例和測試用例，右側顯示具體的用例信息，有名稱，摘要，編碼，步驟動作，期望的結果，執行方式等等，不過現在使用的公司不多了。
4，公司自主研發的用例管理平台。不少大型公司，有相應的技術積累的公司，會開發自己的測試管理平台，當然也少不了用例管理功能。測試用例記錄信息和上面介紹的Excel差不多，不過可能會和其他功能有相應的對接，增加一些兒信息。按要求進行填寫用例即可！
三，積極組織用例評審
通過上面介紹的幾種方法，我們編寫了功能測試用例，自認為覆蓋比較全面。可是我們對需求理解有沒有出入，真的是覆蓋到了需求涉及的方方面面嗎？其實在測試之前，我們是不太容易確定的，所以進行用例評審是非常必要的。
1，用例評審的重要性
進行用例評審最重要的目的就是，通過用例評審，讓開發，產品對我們編寫的用例進行查漏補缺，同時達到三方理解一致。以便開發同學能很好地使用冒煙測試用例進行自測，同時大家也能對通過我們測試用例測試過的產品的質量充滿信心。不會在測試完成后，對我們的測試范圍，測試覆蓋率產生懷疑，提早發現測試用例設計中可能存在的問題。
2，如何組織用例評審？
在需求評審結束后，測試人員開始編寫相關的測試用例，同時在開發提測前必須完成測試用例評審工作。選擇大家都合適的時候，組織測試用例評審會議。保證項目參與人員，測試，產品，開發，項目負責人，如果有跨部門協作，其他部門相關參與人員最好也能參加。通過用例評審，再次驗證大家對需求的理解是否有出入，同時對用例設計提出不同的意見。
3，用例評審要做的工作及注意事項
在會議上，測試人員講解測試用例設計的依據，方法，以及具體到每一個測試用例的執行過程和作用。在講解的時候，與會人員，產品，開發可以隨時提出不同的意見，大家進行討論，同時提出測試用例的優化方案。會議主持人做好記錄，分析出有異議的地方產生的原因，優化的方案，需要調整的地方。會后通知相關人員進行相應的調整，同時根據用例評審的結果，優化測試用例，並將修改完成的測試用例發給相關人員，尤其是冒煙測試用例必須發給開發，作為開發自測試的標准。
4,用例評審成功的考評點
組織測試用例評審的時候，什么時候算成功呢？測試人員在講解完測試用例后，產品，開發和其他相關人員提出了自己的建議；測試人員根據建議給出修改方案，最終得到了大家的認可。開發人員自測試時執行冒煙測試沒有困難；測試用例覆蓋內容沒有遺漏；測試用例存在異議的地方完美解決；測試用例修改優化點都有合適的優化方法。
四，用例評審后的測試用例管理
1，測試用例共享：產品，RD，QA
測試用例評審完成后，測試根據評審時的各種建議，優化測試用例。優化完成后，將冒煙測試用例發送給產品，開發人員，供開發人員提測之前進行自測。同時，將測試用例通過項目管理工具，平台等分享給項目的相關人員。
2，測試用例的維護及管理
在項目實施的過程中，難免會出現各種意外的情況；如產品在項目實施過程中，對需求進行了調整，當然這種情況要嚴格控制；開發人員因為技術問題，如果做了相應的調整；測試過程中發現了bug,修復方案和最初的需求有出入等情況下，測試用例也必須同步進行調整，否則測試用例便失去了價值。
3，產品上后的測試用例管理
產品上線后對線上進行回歸測試，以保證新功能上線后對其他功能沒有任何影響。同時完成需求上線后，需要召開項目總結大會，大家一起討論項目實施過程中遇到的問題，解決方案，以及對后續如何避免這樣的問題的產生。在項目評審完成后，反向優化測試相關文檔，測試用例，項目總結文檔等，做好項目文檔的管理和傳承工作。
五，總結
通過上面的介紹，我們介紹了一下如何編寫測試用例，如何進行用例評審，以及測試用例評審完成后要做的后續工作。當然如何編寫覆蓋更加全面的測試用例，以及測試用例得到相關參與同事的高度認可，這個是一個長期的過程。本文介紹的只是相關的理論方法，具體的實施措施，需要根據具體業務場景，對業務的理解程度，不斷提升，這也是高級測試工程師的成長之路喲！
————————————————
版權聲明：本文為CSDN博主「潛龍9527」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/lionking0318/article/details/83988889