如何保證測試用例又少又準確?

01-25

謝邀請。這個事兒吧，我打賭很多人會說xx方法xx方法，但是其實真正落地起來沒有那麼的簡單。

測試用例又少又準確，那麼我們換而言之，就是怎麼讓所有的用例都變成有效用例嘛。

1. 你可以使用feature的checklist和用例去做對比，然後按照業務，功能來劃分，做一定的刪減

2. 你可以使用code coverage來衡量你的用例到底是好還是不好，然後一步一步去完善。

以上這些方法是能夠再項目中落地的，當然我相信肯定會有xx方法xx方法，而且也肯定沒有xx方法xx方法那麼高大上

首先這個問題確實曾經困擾過筆者很長時間，相信大家都碰到過類似的問題，版本發出去後總是在客戶那裡暴漏出問題，而我們內部測試一下時候又總是執行了一堆無效用例（用例的冗餘）或者發現一些無效的bug（客戶那裡根本不可能碰到）。

現在採取的一個辦法是：除了功能用例外，再增加了一套完善的用戶場景測試用例（去模擬真實的用戶場景測試）。通過這類用例去保證按照客戶真實的操作和業務不會出現問題。

真實用戶場景肯定是沒有冗餘的，因為客戶就是這樣用的。

當然，用戶場景的搜集也是需要花費一定時間的（現在移動app和web應該都有去搜集用戶的行為的，用戶群上去後就很容易整理出來了）。

等到用戶場景完善後，實際上功能的用例也沒有那麼重要了，當時還一個比較好的方式就是藉助強大的自動化。這樣完全不用去關注用例的冗餘給我們帶來的測試成本增加。貌似微軟的測試就是這樣的。

聽說說以上可以裝逼

以上

首先，謝邀。

其次，問題的語句本身就有問題，「保證」是什麼意思，怎麼判斷「保證了」或者「沒有保證到」？「少」，怎樣是少，數量？「準確」又是怎麼判斷的呢？

我不認為有任何辦法可以保證，這個問題太泛了。測試是無法窮盡的，所以你永遠無法保證，而只能夠無限接近你想要的結果。所以了，你想要的結果到底是什麼？

如果你想要的是測試的用例數量盡量少，但又能夠有一定的效果，那麼RBT（Risk Based Testing，基於風險的測試）可能是你想要尋找的，主要思想是基於風險來判斷並選擇所需要的測試。不管怎樣，關鍵在於，不能漏掉關鍵、重要的測試用例，而減少重要性低或出問題幾率低的用例，而這些都依賴於經驗，方法最多是為你提供一些參考的框架來分析或者篩選，但真正把握某些用例是否可以被移除，還是在於測試人員的經驗和對系統的理解。

可以參考《探索式軟體測試 (豆瓣)》和《探索吧！深入理解探索式軟體測試 (豆瓣)》書中介紹的方法。

另一方面，提高自動化測試比例吧，減少你對數量的焦慮。不過，要尤其注意自動化的實現，糟糕的實現反而會耗費你更多的時間。

貌似保證不了！

為啥呢？因為啊，有的業務就是特別地複雜，為保證能盡量全面覆蓋所有的業務流程，就得多寫點兒用例了，

在寫測試用例之前，先把需求捋清楚了，可以把需求分為幾個「獨立」的功能模塊，再針對各個功能模塊寫測試用例，寫完以後，自己再精簡精簡，剔除冗餘的，就可以了。

測試用例少而精是我在對一個項目走了很多歷程後做到的，因此說廣泛的正常用例和異常用例才能換取最後的結果。當然一些類似的項目的測試用例是需要提煉和總結的

1.測試用例設計有些最基礎的方法，如等價類劃分，邊界值，可以減少冗餘用例。有時候會遇到輸入組合參數的情況，如第一步輸入的參數有6種類型，第二步輸入的參數有6種類型，在不考慮自動化的情況下，如何選擇測試用例個數？6個兩兩組合，6*6=36個？測試時間充裕，你可以這麼搞，但是總得講成本，時間成本，人力成本等，決定了你不能這麼搞。怎麼辦？業界對於這類情況早有研究，2-3個兩兩組合帶來的性價比最高，以2個兩兩組合為例，需要12個用例，比36少了24個用例，以3個兩兩組合為例，需要18個用例，少了一半。

2.測試設計層次要清晰，ui，正向，逆向，性能，兼容性等等，分開寫。

3.通過代碼走查，增加遺漏的用例，刪除多餘的，可以很大程度上提高測試用例的覆蓋率和精度。

4.同行評審，基於團隊的力量，發現一些個人沒考慮到的場景，也許有些測試場景其它成員能輕易想到。

5.通常，一個優秀的測試lead或者經理，是需要比所有測試人員更了解被測系統，至少站在整個系統的層面，理解的更透徹，所以他的評審也很重要，比如可能會告訴你和其它模塊有關聯，需要增加用例進行覆蓋。

6.來自開發人員，需求人員的評審，在正規的測試流程中不可避免，開發也許會發現有些測試用例根本沒必要，有些新增代碼分支沒有相關的測試用例覆蓋，通過這一輪評審，也能提高用例的覆蓋率和較少不必要的用例。

首先剖析下問題：

目標：用例少（相對數量），用例精（缺陷/用例總數的值高）

再讓我們進一步細化目標

1. 用例少，因為測試是沒有窮盡的，這一條只有在特殊的情況下才會發生，比如：

（1）測試前期做測試設計時，寫出的用例就少。

------出現這種情況，基本是項目時間特別緊，或者人力嚴重不足，才會採取這樣的思路。

那麼思路的核心就是抓住業務重點

辦法1：分清主次，優先覆蓋核心模塊，核心場景，低頻模塊只做基本功能測試。

認真分析用戶使用場景，Scenario級別的Test case重點覆蓋。

辦法2：若對項目業務內容和團隊挖坑方式極其了解，並有一定的前期測試經驗積累，用 RBT（Risk Based Testing，基於風險的測試）

無論用什麼辦法，可以看出，副作用都是很大的。什麼？你想又快又好沒有副作用？

兄弟，你醒醒，工頭喊你去板磚了。。。

（2）測試後期我們去收縮用例數量。

------出現這種情況，基本是項目質量趨於平穩，考慮後期維護成本，或者是版本改動不大時，提高測試效率。

辦法1：用例分級，按照影響範圍，出現頻率等要素，將用例分級（一般分4級），當版本改動不大，或部分模塊沒有改動時，只要Level1-2的Testcase。

辦法2：有人提到通過代碼覆蓋率分析，優化部分冗餘的用例。

其實這個辦法的代價非常的大，做之前一定要考慮好性價比，到底是維護一堆自動化腳本的成本高，還是摸代碼覆蓋率去優化腳本的成本高。

2. 用例精，這一點上，確實是可以大做文章的。

（1）按照28原則，80%的問題集中在20%的模塊里，分析找到這個模塊（or 這塊業務範圍），進行火力重點關照。

（2）按照28原則，80%的問題是由20%的坑爹選手寫出來的，請找出那個坑爹的選手，他負責的部分，進行火力重點關照。

------其實第2點，有點玩笑的意思，但是固定的團隊，開發習慣是有的，有些方面做得特別好，但有些方面可能會集體薄弱考慮。找到這個薄弱的領域，火力重點關照。

暫時先寫這麼多，想到再答，手動碼字辛苦，希望您能點贊支持，另外歡迎討論。

少而精準，這個是傳統軟體來評估測試用例價值的重要環節。

作用區域：黑盒，自動化。

我覺得這個保證的前提是，需要進行n輪測試後，這份用例被維護多次後，才有可能（安全區的部分可以不納入測試用例）。

也是一種理想化的。

需要把GUI,基礎功能，界面邏輯，行為邏輯分開。我們可以只把行為邏輯的部分進行考評測試用例的效能高，既價值高。

如果需要把所有的內容加進去，來保證，有點本末倒置。

ps:測試用例只是來確定不會漏測和確保功能完整的及降低版本維護風險的，是1個輔助的。

從測試的經濟學角度來說，是不可能達到完全測試的。

業務精之又精。

若可以把業務用一語道破，用例少而精何難？

沒答案，最好手工用例全部自動化，就不用考慮這些了。

當寫測試用例的時候，恨不得把重複的測試用例排除掉，但也只有在寫的時候才會突然想到某個可能會存在的bug；常規性的bug誰都會，結合以往碰到的bug也會寫，愈發感覺缺少的當初的那種不一樣的思維，可能是剛接觸一個新測試，想法設法整出bug來，更多的是從用戶體驗的角度出發的。但是對一個長期維護的系統進行測試，很容易疲倦，再讓你找出bug就沒那麼激情了，但這是工作，每天都要面對這個系統，體驗方面是熟的不能再熟了。這個時候就是真正要去從用戶、需求、資金預算、使用者等方面考慮優化。用例少又如何，精準又如何，一個需求的更改或者開發的理解錯誤，用例就是白寫。

提這個問題的應該不是做測試的。