一、測試需求的定義
1、測試需求主要解決‘測什么’的問題，一般來自需求規(guī)格說明書中原始需求-----項目實戰(zhàn)；
2、測試需求應(yīng)全部覆蓋已定義的業(yè)務(wù)流程，以及功能和非功能方面的需求。
二、如何進行軟件測試需求分析
測試需求分析的主要目的：依據(jù)需求文檔提取測試點，根據(jù)測試點來編寫測試用例
測試點分析的重要點：
1、通過分析需求描述中的輸入、輸出、處理、限制、約束等，給出對應(yīng)的驗證內(nèi)容；（功能測試）
2、通過分析各個功能模塊之間的專業(yè)順序，和各個功能模塊之間傳遞的信息和數(shù)據(jù)，對存在功能交互的功能項，給出對應(yīng)的驗證內(nèi)容；（功能交互測試）
3、考慮到需求的完整性，要充分覆蓋需求的各種特征，包含隱性需求的驗證，比如：界面驗證、注冊賬號的唯一性驗證（界面、易用性、兼容性、安全性、性能壓力）
三、軟件測試用例的定義
測試用例是為項目需求為編寫的一組測試輸入、執(zhí)行條件以及預(yù)期結(jié)果，以便測試某個程序是否滿足客戶需求。
可總結(jié)為：每一個測試點的數(shù)據(jù)設(shè)計和步驟設(shè)計。
四、測試用例的重要性
1、測試用例時軟件測試的核心。
解釋：軟件測試的重要性是毋庸置疑的，測試用例是測試工作的指導(dǎo)，是軟件測試質(zhì)量穩(wěn)定的根本保障。影響軟件測試的因素很多，如：軟件本身的復(fù)雜程度、開發(fā)質(zhì)量，測試方法和技術(shù)的應(yīng)用。但有些因素是客觀存在的，不可避免的，例如：IT團隊的流動、環(huán)境、情緒等。
2、評估測試結(jié)果的基準(zhǔn)。
解釋：測試用例的通過率以及錯誤率，是測試結(jié)束的一個重要依據(jù)，用來判斷該軟件測試結(jié)果是否通過，能夠達到上線的標(biāo)準(zhǔn)。
3、保證測試的時候不遺漏測試功能點。
4、在編寫測試用例的過程，可以熟悉需求，對系統(tǒng)架構(gòu)或者業(yè)務(wù)流程有一個整體的，深入地了解。
5、好的測試用例不僅方便自己和別人查看，而且能幫助設(shè)計的時候考慮的更周全，因此測試用例的寫作和設(shè)計一樣，也是非常重要的。
五、測試用例的八大要素
1、用例編號：產(chǎn)品名_測試階段（st? it? uat）_測試項_0011
2、測試項目：對應(yīng)一個功能模塊（細分功能）例如：聊天室（發(fā)紅包、轉(zhuǎn)賬、語音視頻通話）
3、測試標(biāo)題：直接對測試點進行細化得出，輸入內(nèi)容+炎癥結(jié)果，同一功能模塊標(biāo)題不能重復(fù)
4、重要級別：高/中/低
5、預(yù)置條件：需要滿足一些前提條件，否則用例無法執(zhí)行
6、測試輸入（數(shù)據(jù)）：需要加工的輸入信息，根據(jù)具體情況來設(shè)計（跟步驟結(jié)合起來一定要具有指導(dǎo)性意義）
7、操作步驟：明確給出每個步驟的描述，執(zhí)行人員可以根據(jù)該步驟完成執(zhí)行工作
8、預(yù)期結(jié)果：根據(jù)預(yù)期輸出比對實際結(jié)果，來判斷被測對象是否符合需求。（預(yù)期結(jié)果唯一，不能出現(xiàn)‘是否或者’）
9、實際結(jié)果：
六、關(guān)于寫用例的一些建議
1、功能劃分時，一個測試用例集（sheet）就只需要檢查一個功能模塊，否則，用例會混亂，降低可讀性。
2、測試用例的劃分也要單一，一個測試用例只檢查功能點的一種情況，否則會，會導(dǎo)致用例的目的不清晰，且這樣有利于需求覆蓋率的統(tǒng)計。一個功能點我們測試了那些情況，以及哪些功能點我們在重點測試，一目了然。
3、測試用例要有一個簡單的目的描述，有助于讀者對測試用例的理解。
4、測試用例要有明確的執(zhí)行前提，包括環(huán)境、數(shù)據(jù)、場景。
5、測試用例的步驟描述要簡單、清晰、一步就是一步。
6、測試用例的數(shù)據(jù)要準(zhǔn)確，特別是前提數(shù)據(jù)和要檢查的數(shù)據(jù)。
七、用例評審的重要性
1、無論是初級測試工程師，還是高級的，專家的，設(shè)計出來的測試用例都需要經(jīng)過評審。
2、測試用例一般分配給每個人來設(shè)計，設(shè)計用例的人并不知道用例在具體執(zhí)行的時候是否有問題，不能保證自己設(shè)計的用例能覆蓋完全
3、保證測試人員和開發(fā)人員對于被測試功能的理解的一致性。避免測試過程中針對bug測試人員與開發(fā)扯皮。
4、需求人員參與評審，他們能幫助你找出更多的問題，經(jīng)常在測試的時候，有些細節(jié)是無法從需求文檔上得知的，需要頻繁和需求人員溝通
5、現(xiàn)在有很多人士項目外包或人員外包，那么完成每一項工作的第一件事就是提交客戶評審，當(dāng)然在提交給客戶前自己team先評審下最好，確保提交給客戶高質(zhì)量的成功
6、按照用例數(shù)量來評書工作量。
八、用例評審的方式
以會議評審為主。
測試組內(nèi)部評審：
1、測試用例本身的描述是否清晰，是否存在二義性；
2、是否考慮到測試用例的執(zhí)行效率，往往測試用例中步驟不斷重復(fù)執(zhí)行，驗證點卻不同，而且測試設(shè)計的冗余性，都造成了效率的低下；
3、是否針對需求文檔工嗯呢該點，覆蓋了所有的軟件需求；
/4、是否完全遵守了軟件需求的規(guī)定。
項目組內(nèi)部評審：
1、收集客戶需求的人員注重你的業(yè)務(wù)邏輯是否正確；
2、分析軟件需求規(guī)格的人注重你的用例是否跟規(guī)格要求一致；
3、開發(fā)負責(zé)人會注重你的用例中對程序的要求是否合理。
九、用例評審的流程
1、評審材料準(zhǔn)備好（主要是測試用例、評審檢查清單）
2、提前2天發(fā)布評審?fù)ㄖ?，同時將評審材料發(fā)送給評審組成員，以節(jié)約溝通成本；
3、召開會議評審：針對評審用例檢查清單，評審過程中收集相關(guān)人員的反饋信息，并在此基礎(chǔ)上進行測試用例更新，直到評審?fù)ㄟ^。
4、評審結(jié)束后，修改測試用例，并將修改后發(fā)送項目組人員查看，確認沒問題，存檔。
十、用例評審檢查清單
1、測試用例是否按照公司定義的模塊進行編寫；
2、測試用例的本身描述是否清晰，是否存在二義性；
3、測試用例內(nèi)容是否正確，是否與需求目標(biāo)相一致；
4、測試用例的期望結(jié)果是否確定、唯一的；
5、操作步驟應(yīng)與描述是否相一致；
6、測試用例包含相關(guān)的配置信息，如：測試環(huán)境、數(shù)據(jù)、前置測試用例、用戶授權(quán)等；
7、測試用例是否覆蓋了所有的需求；
8、測試設(shè)計是否存在冗余性；
9、測試用例是否具有可執(zhí)行性；
10、是否從用戶層面來設(shè)計用戶使用場景和業(yè)務(wù)流程的測試用例；
11、場景測試用例是否覆蓋最復(fù)雜的業(yè)務(wù)流程；
12、用例設(shè)計是否包含了正面、反面的用例；
13、對于由系統(tǒng)自動生成的輸出項是否注明了生成規(guī)則；
14、測試用例應(yīng)包含對中間和后臺數(shù)據(jù)的檢查。
