1、測試用例是什么？
測試用例的設計就是如何覆蓋所有軟件表現出來的狀態，即在滿足輸入/輸出的一組條件下，軟件運行時一系列有次序的、受控制的狀態變化過程
2、設計用例是否有必要？
將測試內容記錄下來，避免了在執行的時候部分測試點被遺漏，另外也便於用例評審，用例總結，對后期測試工作起到改進作用，因此，測試用例必須要寫，顆粒度可以視情況而定，針對測試人員少，上線時間緊的項目，可做思維導圖載出測試點
3、如何寫測試點？
根據需求及設計交互稿，先列功能點，后擴展功能點為測試點（作為測試的標題），有必要的時候借助產品、開發、后端的力量，保證用例的覆蓋度、學會借力
測試點（注：這里不是測試用例，用例一般都比較詳細，開發不一定會花費很多時間去做自測）寫完后，可發給開發做自測，部分遺漏點可以在測試時進行記錄與補充
4、設計用例的益處？
設計用例的過程可以更深刻的理解需求，熟悉各功能點，保證盡可能全的覆蓋到各測試點，也便於用例評審
5、測試用例有哪些測試方法？
等價類划分法，邊界值法，功能圖法、錯誤推測法、因果圖法、場景法，詳細介紹見我下篇文章
6、如何保證用例的覆蓋度？
首先一定要熟悉需求，需求分析，拆解非常重要，需要熟悉過程中，不理解或者有疑問的地方，一定要找產品進行及時溝通，確定結果，其次項目開發過程中，每期的測試用例都要不短總結，學會總結，盡可能的保證少漏，其實這個與測試
思維密切相關，工作經驗的積累，以及測試思維的形成，都有助於你設計一份較完整的測試用例
7、用例寫完，我們先要做什么？
先自檢，自檢完畢，列出仍有疑問的點，評審之前，把用例提前發給相關的開發，產品，預留時間告訴他們先看，在統一時間進行評審
8、哪些人應該參加用例評審？
產品。開發（客戶端、后端、前端等，每個公司情況不一，可按實際來），測試需一起進行用例評審，評審力度需要加大，不能只是走個過場，需要有產出，否則有可能體會不出用例評審的作用。如果開發不重視，可拉上研發總監一起評審，我之前評審過的用例，每次在評審時，產品不同崗位的人員，都能提出相關的一些用例中沒有包含的問題，都需重新調整用例，最后在進行二次評審，在用例的評審過程中，針對大家提出的問題，可以簡單的進行記錄，評審后再進行詳細補充，第一次評審過的用例重新整理完成之后，再次通知相關的評審參與人，這樣做的目的是告訴大家，我們做了什么事，做的結果如何，后續還有什么改進的地方，及時總結，目標明確，可帶動大家積極參與。
9、用例評審有必要逐條念嗎？
用例評審沒有必要逐條念標題和預期結果，這樣很浪費時間，比如，一個項目的用例整理之后都是上百條，如果逐條念很耗費時間，建議可以根據條件總結性的過，大部分用例結果是已知的，步驟和預期結果是不用講的，除非個別有疑惑的測試點，可以花費時間一起討論溝通下（建議：使用思維導圖進行用例的講解，對某些特殊說明點可以參照用例進行）
10、對於開發不自測的，我們該如何做？
建議加入提測環節，測試給出提測標准，沒達標就打回，或者先給產品進行功能主流程驗收（設計對UI進行驗收），產品說通過驗收了再給測試提測，要開發自測可自上而下進行推動，加入某個環節也需要技術總監的支持。開發自測可以使測試人員輕松點，一些比較容易發現的問題可在進入測試人員測試階段可避免，這樣下來整體節約了時間，而測試也有更多的時間去測試復雜的邏輯問題，而不是只測需求功能問題，同時，給研發一點壓力，開發的功能模塊質量也會有提高，多次提測不通過也可作為研發考核的一個標准。
今早在上班途中看到了簡尚中總結的測試人員在測試用例中常見的問題梳理，覺得寫得非常好，我們在工作中經常遇到，並且也在潛移默化的執行，只是很少去進行總結梳理，在這里我將感謝總結梳理的那位人士！