為什麼要寫測試用例，測試用例寫給誰看？

01-22

謝邀！

最主要的當然是給自己看。

當然了，看測試用例的人都有產品、開發、和測試自己

所謂測試用例就像是藥方，你必須要開出藥方抓藥吃藥醫好病人，不然誰知道你醫術高明。再者，你醫死人了是要找你負責的，藥方是你保命也是定罪的證據好么！

說正經的，測試用例最大的作用是

1.幫測試人員理清測試過程以及測試步驟;

2.記錄測試所覆蓋的測試內容

3.為後續的測試提供可參考的依據，如：哪些是有影響的需要回歸的。

4.在突發情況下，你被調離以及離職的情況，迅速了解測試進度以及系統測試覆蓋程度。

就像開發一樣，不會只留下封裝後的程序；必定會有自己的源碼庫。對於測試來說，測試用例就是自己源碼庫。

測試用例可以用來衡量一個項目測試質量。測試用例的健壯性，完整性，覆蓋程度等，都對項目測試質量有影響。主要是給測試人員和開發人員看。其中開發人員本身就要寫測試用例代碼，對開發代碼驗證，也可以開發人員之間互相測試。測試人員寫的測試用例，主要是測試人員執行。測試用例一般都要跟項目代碼一起保存，項目工作人員變動以後不影響項目進展，項目變更和修改bug後，相關測試用例還要重新測試一次。

首先給自己看，如果項目延續比較長，測試用例寫得好，後面回歸的時候就省心，照著用例一個個執行就能保證版本迭代不出屎。如果沒有測試用例，在測試新需求的時候你無法保證哪些東西你沒漏測，哪些東西你是不是測重複了；在回歸的時候沒有測試用例，那麼就相當於重複進行一遍新功能測試，這時候就是加班加班加班。

其次是用於評審，主要項目組的人看看測試的方向是否正確。很多時候測試人員寫的用例很多屎，要大家挑出來扔掉。

還有一個是給領導和客戶看。領導需要看到測試用例，確定項目是有質量的；客戶需要有測試用例，確保拿到的產品是有質量的。

還有一些就是行業強制需要的。比如銀行和保險系統，政府規定必須通過系統測試，其中的文檔當然不能少。

不寫測試用例，你執行了什麼？

憑空臆測測試場景，隨機構建測試環境，拍腦袋決定測試輸入，拍大腿獲取測試輸出，拍屁股決定怎麼驗證成功失敗嗎。。。

測試最重要的是記錄。

因為有了記錄，所有你的動作才能復現，出現bug才有信息量來debug；同時產品和研發也可以知道你交付的測試結論是否可信，測試是否全面。

測試相當於用一個表格來說明質量。

測試計劃就是你在設計表格的表頭，環境，輸入準備，數據採集，驗證。

測試用例就是填入有多少行，每行的自變數是什麼，通常是環境，輸入，操作場景。

測試執行就是填入每行的其他列，每行的因變數是什麼，通常是輸出，通過與否。

第二個問題的回答：

第一給自己，第二給產品，第三給研發。項管或者負責人想看也可以看看。

感謝邀請~

贊同「雄霸」的描述~~

測試用例要給所有項目成員看。

測試人員可以根據用例分配任務，預估測試需要時間，執行測試，收集數據。開發人員要通過用例查看測試的覆蓋範圍，顆粒度，根據測試數據查看有沒有達到發布的標準。

1.增加測試人員對需求的理解。

編寫用例的過程也是梳理需求的過程，其對需求的理解度遠遠深於需求解讀和反解讀。

2.保證功能的覆蓋度。

直接測試時被忽略掉的功能不易察覺，寫用例不同，往往可以從各反面入手，且經過評審可以保證功能的覆蓋度

3.方便不同的測試人員上手。

有新的人員來協助測試或者是來了新員工，一份清晰的測試用例就很重要了，他們可以直接按用例來執行，不至於出現大的錯誤

4.預估測試時間

篩選出用例數之後基本上就能確定測試需要的時間了

5.後期出現漏測時追源

寫用例的人有沒有考慮到這個功能，如果有執行用例有沒有執行對，防止有人渾水摸魚

6.方便後續優化。

有了漏測或者用戶反饋問題，轉換成同類的測試用例，以後就不會有同樣的錯誤

越想越多，有一份好的測試用例對測試人員來說實在是太重要了。

瀉藥

測試用例首先是給自己看，產品經理寫出Prd後，測試工程師必然是要對這個需求十分清晰的，那麼通過梳理需求，拆分成更加直觀的測試用例，對自己在測試過程中避免漏測少測是有很大幫助的，一個測試工程師牛不牛逼不是看他什麼自動化寫的多溜，是看他的用例寫的全不全，一個需求我寫200條用例，另一個人400條，當然他要比我測得更完全

另一方面，給其它的測試工程師看，假設在進行一個大版本最後的回歸時，有的公司會把很多人叫道一起，那麼有的人是測過這需求的，有的沒測過，這時有一套完全的測試用例，省去了協助人員閱讀需求的時間

最後，給開發看，測試用例寫的複雜，開發在編寫中也就會更注意，畢竟提測前負責一點的開發都會拿著case略微的自測以下的

功能測試三年半，以下是我的理解：

寫用例是測試人員梳理需求的一個重要手段，經驗豐富的測試人員在寫的過程中中會加入自己的思考即分析需求，消化需求的同時經常會發現需求文檔中存在的未被提及的問題，可以幫助產品經理細化需求；

在寫用例的過程中測試人員自己對需求也有了更深入的理解，執行測試時可以更順暢，提高測試效率，很常見的一種現象是測試人員比產品經理都了解所做的產品，一方面是因為測試人員經常會測很多遍，另一方面便是測試人員在寫用例的過程中對需求進行了剖析，深入骨髓的那種。

用例寫完後要進行用例評審，至少三方人員參與：相關產品經理，相關開發，相關測試。這就是寫給誰看的對象，產品經理通過測試用例評審發現需求存在的漏洞會按優先順序對需求進行補償；開發同學則是通過測試用例評審加深對產品的正確理解，及時糾正理解上的偏差；測試同學將自己對產品的理解寫在用例中，經與產品確認後方可在測試時直接執行，不需要再反覆確認。

提測階段，測試用例是開發提測的標準，P1級別的用例需開發自測後才能提測，當然特殊情況可以特殊處理。

提測後執行測試階段，測試用例則是測試人員執行測試的依據，逐條執行，遍歷所有功能，降低了漏測率，達到有效執行測試的目的。

哎，好久不做測試了，不過就我理解的測試相關的文檔中的測試用例來說下吧，首先能夠嚴格按照流程走的想必不會是太小的公司，如此測試人員也不會就一兩個而已，即使是同一個項目也是如此，作為測試人員要各司其職，比如測試用例由專門的測試人員通過研究需求分析及詳細開發文檔找出每一個測試點編寫成測試用例，然後交由專門執行測試的人員去按照文檔測試，就會節省出很大人力及時間，就好比開發人員按照詳細開發文檔中的內容去實現每一個節點的功能是一樣的，執行者不需要參入自己過多的思考及個人想法，如此往複的測試填寫結果測試填寫結果，就好比有人一說編程人員好高大上的時候，只有他們自己知道，作為最底層的編程人員，做的永遠都是重複的機械運動而已，

所以說，每個編寫文檔的人不能說是設計者但也需要具備足夠的思維縝密及考慮問題的全面性的能力，因為編寫文檔的人思維有疏漏，那執行的人就做不到全面，如此這個項目就會存在疏漏

其實呢每個人都是由底層開始的，直到你一步一步上升由機械的執行者到流水線的上一層，再上一層，再上一層人員，直到有一天領導說你來做這個項目的測試用例吧這也是你工作上的一種進步，領導對你工作的一種肯定

在者來說，測試用例作為文檔的形勢也有利於該項目結束後的歸檔存檔，以便日後查閱方便或供新來人員的學習研究使用，或者在有的情況下一個測試人員沒有做完離職了或者請假了，總之就是缺勤了，不至於導致該項目無法繼續或繼續的時候做重複工作無用功，接替人員甚至都不需要交接，按照文檔繼續進行後續工作就可以（所以要知道，誰也不是誰的誰，誰也不是別人無法代替了，不要想著哪個公司離了你就不能繼續下去）

最後再說一下，測試用例作為諸多文檔中的一員，在最後交付項目的時候都是要一同交付並做驗收的

別的就先這麼多吧想到以後再來做補充

一開始也是覺得寫測試用例沒有用，但是漸漸的，即使沒有要求我也會自己默默去寫完用例再測試

1.寫用例的過程其實是深入理解產品需求的過程，這個過程中不僅要根據自己對需求的了解進行梳理和細化需求，也可以從測試角度去幫助產品完善需求

2.測試過程中可以不用再重複的去翻需求說明文檔、UI文檔等一堆東西，只需要看用例，根據用例去進行測試，節省測試自己的時間

3.測試用例有必要存檔，尤其是需要進行很多輪迭代的產品，既是一個對原有需求的參考，也是後期項目更換人員配置時交接的參考依據

4.測試用例不僅給測試人員看，也給產品經理，開發人員，項目經理，領導，甚至客戶看。可以說測試用例是測試人員少量的可以作為工作量評估的參考依據，如果有公司非要去考評測試人員的績效之類的話。當然，產品提測之前開發人員多少需要進行自測，可以讓他們參考測試用例先自測主要流程，減少那種提測後流程都沒法跑通的情況，也算是提高工作效率吧

大概寫的有點啰嗦，只是自己的一點理解

出門在外，無利不起早。

我覺得最主要的好處還是鍛煉自己的思維邏輯和業務認識。

用例寫多後，你會發現很對產品想不到，開發炸眼的業務BUG，後期與產品撕逼時，派得上大用場！

當然用例執行時一目了然，相關人員也可以快速上手。但是太花時間，太注重形式，嚴重不符合快速迭代的社會主義國情。

若是只是給自己人看，測試內部通用思維圖就行了，寫起來快又方便，與用例作用完全一樣，執行時能夠更快執行。

若是想體現工作量，那還是老老實實寫測試用例吧(◎o◎)

（題外話，老闆更在乎產品質量。。。）

測試用例，是測試設計者對需求文檔的理解，梳理出來，寫清測試路徑，提供給測試人員。便於測試者測試，不至於東忘西忘的。也是根據測試用例數量對工作量的一個大概估算。

給執行測試的人看

謝邀。

我個人認為測試用例有2個作用：

給開發者自己用，所謂 DevOps。
程序在持續化改進更新的過程中，勢必更新老功能或者添加新功能，會影響到原來正常的功能的行為，導致原來正常的功能錯誤或者偶爾錯誤。不可能每次改進、更新都重新手動測試原來的全部功能，特別是程序很大的時候。所以對每個功能寫測試用例相當於替代手動全部測一遍的效果，給你的後續程序更新提供更多信心。
舉個例子，Node.js core 有上萬個測試用例，改一些底層模塊可能會影響到上層功能，這個時候只要跑一邊測試用例就知道對錯了。
給別人看。
覆蓋率100%說明你的程序非常重視測試，別人使用你的開源軟體/模塊會有更多的信心。