相信很多人跟我有過一樣的困惑，那就是在需求階段我們測試人員到底應該如何對需求進行測試？大家應該都經(jīng)歷過因為需求的緣故而導致大量的返工，造成進度上的delay以及線上BUG的遺漏，要想得到好的result當然離不開一個好的process支持。那么我們在項目的前期，應該如何對需求進行把關呢？個人建議可以從需求的完整性、正確性、二義性這三個方面來著手，隨著測試經(jīng)驗的積累，逐漸培養(yǎng)自己挖掘隱藏需求的能力，充分發(fā)現(xiàn)需求中不完善，不嚴密的地方。那么我們具體應該怎么做呢？
第一步,先收集一切與需求有關的資料，如果可能的話，最好能拿到PD與運營方會議的討論細節(jié)，里面一般會包含一些用戶使用場景的討論，這對我們的測試工作應該是很有幫助的。我們可以按模塊去確定所包含的功能點，分析該功能所對應的actor，明確actor之間的關系。針對單獨的usecase去分析其對應的輸入、處理、和輸出,將自己的分析有條理的寫出來：不同條件下執(zhí)行某操作后得到不同的結果。?
第二步，分析業(yè)務流程，明確需求分析中不同的usecase所組成的業(yè)務，形成一系列的業(yè)務場景活動圖：拆點: 對應的每一個功能點將其對應的輸入,處理和輸出進行提取; 連線 :將每一功能所對應的輸入,處理和輸出形成業(yè)務活動圖;
第三步，了解系統(tǒng)所涉及到的數(shù)據(jù)流，分析功能入口和角色權限。確定系統(tǒng)的數(shù)據(jù)流動，包括系統(tǒng)的內(nèi)部模塊間數(shù)據(jù)流和系統(tǒng)間的數(shù)據(jù)流接口，在這些地方一般都比較容易出問題。確定系統(tǒng)擁有多少角色（業(yè)務），他們負責什么樣的工作，在系統(tǒng)中體現(xiàn)在那些模塊中。然后畫出這些角色的用例，或者他們涉及的業(yè)務。我們可以先把每一個角色所做的每一個功能點列出來，然后再將它們放到一個完整的業(yè)務流中去；或者先畫出整個的業(yè)務流，然后再分配給角色。最后得到一個完整的圖，它包含整個系統(tǒng)所有業(yè)務流程，并且有哪些 角色在某個節(jié)點上能夠做哪些操作（擁有哪些權限），這些其實就是我們測試的重點。
第四步，確定公共部分需要測試的需求。系統(tǒng)中有一些部分是很多角色所共同擁有的，并且不涉及具體的業(yè)務流程。將這部分內(nèi)容整理出來，一般來說這些內(nèi)容只會涉及到界面和普通功能的測試，如定義系統(tǒng)界面風格。?
針對需求完整性的驗證方法：
1.項目范圍是否清晰？應該能清楚的標明哪些功能要實現(xiàn)，哪些功能本期不實現(xiàn)，這樣我們才能確定測試范圍。
2.是否說明了對每個輸入的驗證措施，并描述了每個輸入的屬性，如：邊界值、時序要求等以及對于出錯時的處理
3.是否清楚描述了系統(tǒng)中與其它子系統(tǒng)、模塊間的關系，包括頁面的跳轉，傳遞的參數(shù)，對于業(yè)務邏輯的控制是否需要兩邊都進行控制還是只需要調(diào)用方進行控制即可？這個主要是用于項目中涉及到系統(tǒng)之間的調(diào)用的情況
4.對于是改造型的項目，是否已經(jīng)說明了對歷史數(shù)據(jù)的處理？如果對于新老系統(tǒng)共存的情況下，要說明兩個系統(tǒng)之間數(shù)據(jù)的處理關系，以及數(shù)據(jù)遷移時需要關注的內(nèi)容
5.頁面展現(xiàn)的處理：對于不允許進行操作的控制，是直接進行屏蔽還是展示后進行相關控件的disable處理
6.借助數(shù)據(jù)流圖以及狀態(tài)轉化圖對需求進行測試，檢查每個路徑的步驟是否都清晰明了，主干過程、分支過程、異常處理的每個步驟是否都已經(jīng)描述清楚了參與者要干什么？系統(tǒng)要響應什么？是否還存在開環(huán)的情況？
7.是否有對用戶類型的描述？需求組合是否充分地考慮了所有異常的情況?是否已經(jīng)考慮到了所有人的需求？是否充分地提出了邊界情況？所有到其它需求的交叉引用是否都正確?
針對需求正確性，二義性的檢查：
主要是考慮文檔中是否存在描述模糊的地方，對于模棱兩可的問題，一定要明確具體的輸出是什么，可以