1.測試用例是什麼？
答：測試用例的設計就是如何覆蓋所有軟體表現出來的狀態，即在滿足輸入/輸出的一組條件下，軟體執行是一系列有次序的、受控制的狀態變化過程。
2.設計用例是否有必要？
答：如果不記下來，很可能到執行的時候測試點就遺漏了，另外也不便於用例評審，用例總結，對後期測試工作沒大的改進作用。所以測試用例一定要寫，顆粒度視情況而定。針對測試人員少，上線時間緊的專案，可只做思維導圖列出測試點。
3.設計用例的益處？
答：設計用例的過程可以更深刻的理解需求，熟悉各功能點，保證盡可能全的覆蓋到各測試點。也便於用例評審。
4.一定要寫測試用例嗎？
答：對於大中型任務，還是要寫詳細的測試用例；對於緊急小型任務，可以寫測試點；對於新人負責的模組，一定要寫測試用例（本人寫或者老人寫完，新人執行）。
5.測試用例怎麼寫？
答：（1）根據需求文件，拆分測試點；
（2）根據測試用例設計方法 + 經驗 + 拆分後的測試點 + 通用用例約束。來設計最終的詳細測試用例；
（3）寫用例的思路：產品需求-測試需求-測試點-測試用例；
6.用例必備4個方面？
答：預置條件、執行步驟、預期結果、測試結果；用例要點：需包括與其他模組耦合關係、用例的級別（level0、level1），考慮哪些需求必須完成，哪些需求可以後續完成。
7.用例設計理念？
答：首先要保證產品的質量，測試用例的數量並不能決定質量的好壞，要做到覆蓋全面，提倡高質量的自動化測試。
8.沒有需求文件，如何測試，如何設計測試用例？
b.盡量多參加專案組內的會議，比如需求討論、設計討論、計畫討論等，能夠加深對產品的理解；
c.諮詢相關人員-專案負責人、市場人員；
e.如果是一款已經上線的產品，可以多使用產品，有不懂的問產品經理；
f.也可以去看歷史bug，可以了解到一些需要關注的東西。
9.測試用例有哪些設計方法？
答：等價類劃分法、邊界值分析法、功能圖法、錯誤推測法、因果圖法、場景法等。
10.寫用例，用什麼形式寫，什麼工具寫?
答：excel、word，也可以是工具，如testlink、zentao、xmind。
11.寫用例，是否有通用的用例模板？
答：用例只需包含幾個主要元素：用例唯一編號、用例型別、模組、功能項、輸入、預期結果、實際結果、測試結論、備註，就ok。
12.如何保證用例的覆蓋度？
答：首先一定要熟悉需求，需求分析，拆解非常重要，需求熟悉過程中，不理解的地方，一定要找產品進行及時溝通，確定結果。其次專案開發過程中，每期的用例都要不斷總結，學會總結，盡可能的保證少漏。其實這個與測試思維關係密切，工作經驗的積累，以及測試思維的形成，都有助於你設計乙份較完整的測試用例。
13.何時開始設計測試用例？
答：需求文件定版後，即可開始陳列測試點和編寫測試用例
14.測試用例評審
答：a.什麼是用例評審？用例評審主要是產品、開發和測試人員，針對測試用例能否用於專案的測試而做的工作。
b.用例評審的目的：為了減少測試人員執行階段做無效工作（執行無效case，提交無效問題）；為了避免三方需求理解不一致；為了每個測試人員的質量標準與專案要求標準達成一致。
c.評審前需要做哪些工作：用xmind，將測試點梳理出來；在腦圖上，補全預期結果和實際測試結果，便於測試結果跟進；用例寫完後，先做自檢，有疑問的點羅列出來，可事先跟產品開發討論，確定結果後完善用例，仍有疑問的可先做標記，評審會上丟擲一起討論；和評審人員（開發和產品）確定好具體的評審時間並提前把測試用例發給參會人員檢視。
d.用例參加人員：主要是產品、開發、測試、專案負責人、運營;
f.用例評審形式：先對功能複雜，優先順序高、疑問多的用例進行評審，再評審功能簡單，優先順序低的功能點。對於評審過程中，還沒有結論的問題，可以記錄下來，作為會後討論跟進的重點。另外，整個評審會主次分明，有高潮有緩點，可以更高效地達到我們評審的目的。
g.正式評審：評審要按用例的優先順序，功能的複雜程度進行；評審時間盡量做到，思路清晰，用最簡潔的語言闡述每乙個功能點；超過5分鐘無法確定結果的問題留作會後討論跟進。
h.評審結束後需要做些什麼事：第一時間整理測試用例，把修正的內容重新整理補全；會上未確定的內容，會後繼續跟進，直到確定結果；沒有問題了，做個簡單的用例評審總結（如修正了哪些功能點，補全了哪些，哪些模組功能有變動？哪些功能推遲到下一期做？）。
15.用例寫完，我們要先做什麼？
16.測試用例的更新？
答：評審後需要更新、測試過程中需要更新、測試結束後根據線上反饋情況進行更新。
17.什麼時候寫測試點，什麼時候寫用例？
答：a.如果公司只有你乙個tester，就沒必要寫測試用例了，寫測試點（xmind），提取關鍵要素；
b.如果需求老是頻繁變化，寫測試點吧；你的測試用例的更新速度永遠跟不上需求的變化速度，每天都在改用例。太詳細的用例，無太多的意義和價值；
c.如果你們的節奏控制的非常緊湊，完全沒時間嚴格按照測試用例執行，寫測試點吧，提取關鍵要素；
d.如果團隊的整體tester技能均衡，測試點已經能夠充分覆蓋了，寫測試點吧，測試用例的意義不大；
e.如果這塊的邏輯非常複雜，你未曾接觸，盡量寫詳細點的測試用例，通過用例的梳理過程，是乙個很好的梳理理解需求和產品的過程；
f.如何用更少的測試點，盡可能的充分考慮各種可能性呢?跟什麼因素有關呢？與用例設計方法、經驗、需求理解等等有關。我們要綜合運用等價類、邊界值、錯誤推測、場景法、因果圖等測試用例的設計方法；
g.不要總找刁鑽的用例，要把客戶常用的流程弄好。產品上線之前無論經過多少輪測試，一定要把主體業務流程進行回歸測試。
18.測試點怎麼寫？
答：a.重點關注業務邏輯、業務場景、異常測試等，至於具體ui細節，簡單帶過即可（因為ui層面的問題，視覺就可直觀的看出來，不需要大篇幅的測試用例，浪費時間，產出並不高）
b.總結來看，就是寫更大顆粒度的測試點來代替測試用例。由此減少需求變更帶來的用例維護成本，又可測試前置，還可以保證核心流程、功能、場景化、異常情況充分覆蓋。
c.補充乙個話題，需求頻繁變更，本身就是不合理的，特別是版本發布臨界點，是不建議臨時插播需求的。源頭沒控制，最後出問題屬於正常現象。
19.對於開發不自測的，測試該如何做？
答：a.建議加入提測環節，測試給出提測標準，沒達到就打回。或者先給產品進行功能主流程驗收（設計對ui進行驗收），產品說通過驗收了再給測試提測。要開發自測，可自上而下進行推動，加入某個環節也需要技術總監的支援。
b.開發自測可以使測試人員輕鬆點，有更多的時間去測複雜的邏輯問題，而不是只測需求功能問題。同時，給研發一點壓力，開發的功能模組質量也會有所提高。多次提測不通過也可以作為研發考核的乙個標準。
20.測試的價值是什麼？
答：不是發現多少bug，而是產品上線之後，有多少漏測問題。作為測試從業者，必須明白自己的核心價值在何處，把它作為目標，才能正確指引我們平時的測試工作中的具體內容及細節落實。
軟體測試 用例
三 什麼是測試用例的有效性 四 測試用例的粒度和評價 軟體測試 用例 本節重點 1.測試用例的基本要素 2.測試用例的設計方法 3.測試用例的有效性 4.測試用例的粒度和評價 測試用例就是向被測試系統發起的一組集合，包含測試資料，測試環境，操作步驟，預期結果 要素 測試前期 測試版本 功能模組 重要...
軟體測試與軟體測試用例
程式設計要寫 測試要寫用例。做了這麼多年的軟體測試工作，經歷了對測試用例認識的不同階段。第一階段，入門。編號，測試點，測試環境，測試資料，測試步驟，預期結果，設計人，設計時間，執行結果，執行時間，備註。所有的一切都要寫的清清楚楚，詳詳細細。設計 評審 修改，迴圈往復。這個階段提到的有關測試用例設計最...
toft 測試用例rat 軟體測試用例型別
rat rat release acceptance test 發布驗收測試 rat又稱為構建驗證測試或者煙霧測試，rat會在每個開發版本發布之後進行。以確定系統處於穩定狀態 所有的主要功能都具備並且能夠在 正常 條件下執行的測試用例。rat用來評斷這個build能否進行後續的測試，如果rat測試失...