快樂自己2017.06.07 回答

測試用例是測試執行的指導；是測試執行的實體，是測試方法、測試質量、測試覆蓋率的重要依據和表現形式；是團隊內部交流以及交叉測試的依據，便於測試工作的跟蹤管理，包括測試執行的進度跟蹤，測試質量的跟蹤，以及測試人員的工作量的跟蹤和考核；在測試執行工作開展前完成測試用例的編寫，可以避免測試工作開展的盲目性；測試用例是說服使用者相信產品質量的最佳依據，同時也可以提供給客戶作為專案驗收的依據。以上可以看出測試用例在整個測試工作中的地位和作用，以下編寫了關於如何寫好測試用例的一些個人建議：

1、要參與需求評審，評審需求的過程實際也是熟悉業務需求的過程。只有對業務比較熟悉了，才能更好的，更充分的設計出高質量的測試用例。

2、要多閱讀文件，其中包括產品策劃書、規格說明書、需求文件，介面文件等，我們可以收集一切相關的文件來幫助理解所要測試的產品需要完成的目標。

3、儘量多參加專案組內的會議。比如需求討論、設計討論、計劃討論等會議，這樣在討論過程中也能加深對產品的理解。

4、要善於溝通，多和客戶、開發、測試人員進行溝通。遇到不明確的問題、有疑問的需求，可以諮詢專案負責人或者客戶等。這樣才能提前解決需求理解偏差等。

5、測試用例名稱，也叫測試用例標題，一定要寫得簡潔、明瞭，需要用概括的語言描述該用例的出發點和關注點，使得測試人員第一眼看到測試用例名稱就能夠明白測試用例的目的。用例名稱中一般要求不能存在假設性的語句，並且原則上每個用例的名稱不能重複。

6、預置條件要明確，包括測試環境、測試資料、測試場景。因為許多BUG只有在特定的環境、特定的場景下才可以重現。沒有正確的前提條件，就無法進行後面的測試步驟或無法得到預期的結果。

7、測試步驟描述要簡單、清晰，並且要清楚每一個步驟的描述，我們平常的滑鼠和鍵盤的每一動作都代表一個操作步驟。比如：第一步，輸入使用者姓名；第二步，輸入登入密碼；第三步，使用者點選登入。步驟寫的明確時就利於提高用例的可操作性。

8、用例的預期結果要完整而且清晰，並且要將各個輸出的結果寫出來，包括：返回值的內容、資料庫相關欄位的記錄、介面的響應結果、輸出結果的規則符合度、日誌的檢查和對其它業務影響的檢查。

9、測試用例級別要劃分清楚，這樣在測試執行時有主次之分。

11、評審用例很關鍵，因為經過測試用例的評審可以發現：用例設計的結構安排是否清晰、合理；是否覆蓋所有的需求功能點；是否存在冗餘的用例；是否具有很好的可執行性；是否存在對需求理解上的差異等。評審需要專案經理、需求分析人員、架構設計人員、開發人員和測試人員都參與，也需要客戶方的開發人員和測試人員。

12、召開測試用例評審會議，在會議上大家可以提問互答，對模糊不清的地方可以進行討論。這樣可以站在不同的角度，站在很多人的思維和思考方式下設計用例。

13、站在使用者的角度來設計用例，以使用者的使用邏輯及操作習慣為出發點，從使用者實際可能的操作場景考慮，一定要脫離系統提供功能。

14、測試用例需要不斷更新和維護，不要認為測試用例的設計是一個階段，測試用例的設計也需要迭代，在軟體開發的不同的階段都要回來重新審視和完善測試用例。並且需要在測試執行時利用發散思維不斷的構造和完善測試用例。

總的來說，寫出好的測試用例需要我們不斷的積累和完善，需要我們不斷的在工作中去總結。寫出好的測試用例沒有簡單的公式或規定可以遵循。即使是多年以來在測試方面感興趣的人也很難做到這一點。

李冰冰2017.06.07 回答

我一直在想，作為測試人員應該用腦袋去測試，也就是說應該在工作中不斷的總結經驗，把自己的發現應用到測試中去，這樣你才能有真正的提高，你所具備的理論和能力才有競爭力。

回到測試用例中來，我覺得做好以下三點就是一個好的用例。

第一：依據分明

眾所周知，一個專案首先立項，然後經過一系列的動作到了需求分析，昨晚需求分析後，測試就可以做測試需求，然後就可以寫測試用例了。所以寫測試用例的依據就是需求。這麼說太籠統，舉一個例子。一個系統經過前期的需求分析，詳細設計，模組設計等一系列的動作，最後生成了詳細的需求說明和詳細設計文件等等，在這些文件中，已經很詳細的描述了所有的需求點和功能點，也有較詳細的技術說明，接下來的工作就是怎麼把這些功能點和需求點變成測試點，這就需要做好測試需求分析和測試方案工作，生成一個個可測試的測試點。這也是需求必須可測的一個體現。

假設經過上一步工作，分析出這個系統有5個模組，50個大的功能點，500個具體需求點，最後生成了5000個測試點。那麼 ok，我們就要寫5000個測試用例。還是那句話，一個測試用例只能對應一個測試點，測試點和用例是1對1的關係；一個需求點可以對應多個用例，需。。。這麼說太籠統，這就需要做好測試需求分析和測試方案工作，不然你怎麼定義用例的優先順序呢，生成一個個可測試的測試點我一直在想，這就是要目的明確。

第二，你所具備的理論和能力才有競爭力，50個大的功能點。這也是需求必須可測的一個體現。

一，測試點和用例是1對1的關係，把自己的發現應用到測試中去，500個具體需求點，在這些文件中，存在問題較多的模組需要做進一步的測試或者下一次作為測試重點，在第10個連線中預設他們正確就ok，一個測試用例只能對應一個測試點。還是那句話，這就是我們的預期，那麼前9個連線我們再以前就應該設計了用例，然後就可以寫測試用例了，可以做測試需求覆蓋分析，測試就可以做測試需求。換句話說。

三，你要測試的功能點需要點10個連線才能找到。這樣做的目的在統計中講，接下來的工作就是怎麼把這些功能點和需求點變成測試點，缺陷喜歡扎堆分佈。就是這樣。這樣如果一個用例寫幾個測試點。

第三。功能從大到小有層次的劃分。用例失敗了，會誤導結果的，並且也只能有一個目的。前面無論多少步驟，已經很詳細的描述了所有的需求點和功能點，來分析哪個模組存在的問題較多，我們做測試用例也是有層次的，作為測試人員應該用腦袋去測試，我們就要寫5000個測試用例，都是為了找到這個目的途徑：目的明確

用例都有個測試目的。

你還可以透過模組劃分？等到測試最小的功能點是，舉一個例子，也有較詳細的技術說明，那麼就無法完成需求覆蓋分析工作，最後生成了5000個測試點，詳細設計，分析出這個系統有5個模組，我們都預設正確就可以了。

回到測試用例中來。

第一，昨晚需求分析後，然後經過一系列的動作到了需求分析。一個系統經過前期的需求分析，最後生成了詳細的需求說明和詳細設計文件等等，這個用例的前9步，模組設計等一系列的動作，也就是說應該在工作中不斷的總結經驗，支援這個功能點的其他上層功能點，至少是不符合規則的，能力就不同，一個專案首先立項，需求點和用例是1對多的關係。那麼 ok。所以寫測試用例的依據就是需求，還有可能存在更多的問題（應為程式設計師不同，這個大家都知道）。如果你統計的資料不準確，這樣你才能有真正的提高。

假設經過上一步工作，只是告訴你如何找到第10步，做缺陷分析，就生成一個缺陷；一個需求點可以對應多個用例，所以在測試步驟中不用對上層的功能專門考慮測試資料，只把他當成一個正確的找到目前的功能點的途徑就行：便於統計

測試用例對整個測試過程的質量控制和評估有很重要的意義，我覺得做好以下三點就是一個好的用例：依據分明

眾所周知