軟件需求的測試應該如何做？

　　相信很多人跟我有過一樣的困惑，那就是在需求階段我們測試人員到底應該如何對需求進行測試?大家應該都經歷過因為需求的緣故而導致大量的返工，造成進度上的delay以及線上BUG的遺漏，要想得到好的result當然離不開一個好的process支持。那么我們在項目的前期，應該如何對需求進行把關呢?個人建議可以從需求的完整性、正確性、二義性這三個方面來著手，隨著測試經驗的積累，逐漸培養自己挖掘隱藏需求的能力，充分發現需求中不完善，不嚴密的地方。那么我們具體應該怎么做呢?

　　第一步,先收集一切與需求有關的資料，如果可能的話，最好能拿到PD與運營方會議的討論細節，里面一般會包含一些用戶使用場景的討論，這對我們的測試工作應該是很有幫助的。我們可以按模塊去確定所包含的功能點，分析該功能所對應的actor，明確actor之間的關系。針對單獨的usecase去分析其對應的輸入、處理、和輸出,將自己的分析有條理的寫出來：不同條件下執行某操作后得到不同的結果。?

　　第二步，分析業務流程，明確需求分析中不同的usecase所組成的業務，形成一系列的業務場景活動圖：拆點: 對應的每一個功能點將其對應的輸入,處理和輸出進行提取; 連線 :將每一功能所對應的輸入,處理和輸出形成業務活動圖;

　　第三步，了解系統所涉及到的數據流，分析功能入口和角色權限。確定系統的數據流動，包括系統的內部模塊間數據流和系統間的數據流接口，在這些地方一般都比較容易出問題。確定系統擁有多少角色(業務)，他們負責什么樣的工作，在系統中體現在那些模塊中。然后畫出這些角色的用例，或者他們涉及的業務。我們可以先把每一個角色所做的每一個功能點列出來，然后再將它們放到一個完整的業務流中去;或者先畫出整個的業務流，然后再分配給角色。最后得到一個完整的圖，它包含整個系統所有業務流程，并且有哪些 角色在某個節點上能夠做哪些操作(擁有哪些權限)，這些其實就是我們測試的重點。

　　第四步，確定公共部分需要測試的需求。系統中有一些部分是很多角色所共同擁有的，并且不涉及具體的業務流程。將這部分內容整理出來，一般來說這些內容只會涉及到界面和普通功能的測試，如定義系統界面風格。?

　　針對需求完整性的驗證方法：

　　1.項目范圍是否清晰?應該能清楚的標明哪些功能要實現，哪些功能本期不實現，這樣我們才能確定測試范圍。

　　2.是否說明了對每個輸入的驗證措施，并描述了每個輸入的屬性，如：邊界值、時序要求等以及對于出錯時的處理

　　3.是否清楚描述了系統中與其它子系統、模塊間的關系，包括頁面的跳轉，傳遞的參數，對于業務邏輯的控制是否需要兩邊都進行控制還是只需要調用方進行控制即可?這個主要是用于項目中涉及到系統之間的調用的情況

　　4.對于是改造型的項目，是否已經說明了對歷史數據的處理?如果對于新老系統共存的情況下，要說明兩個系統之間數據的處理關系，以及數據遷移時需要關注的內容

　　5.頁面展現的處理：對于不允許進行操作的控制，是直接進行屏蔽還是展示后進行相關控件的disable處理

　　6.借助數據流圖以及狀態轉化圖對需求進行測試，檢查每個路徑的步驟是否都清晰明了，主干過程、分支過程、異常處理的每個步驟是否都已經描述清楚了參與者要干什么?系統要響應什么?是否還存在開環的情況?

　　7.是否有對用戶類型的描述?需求組合是否充分地考慮了所有異常的情況?是否已經考慮到了所有人的需求?是否充分地提出了邊界情況?所有到其它需求的交叉引用是否都正確?

　　針對需求正確性，二義性的檢查：

　　主要是考慮文檔中是否存在描述模糊的地方，對于模棱兩可的問題，一定要明確具體的輸出是什么，可以

　　通過與PD進行討論實際所想表達的內容，對于文字描述不清楚的地方，建議用圖片的方式進行頁面的交互。由于自然語言極易導致二義性，如果有條件的話，建議還是用基于原型的方式進行開發，這樣可以在早期杜絕掉交互上出現的問題。來看一個功能需求的例子：“銷售出貨要考慮到信用額度”。這里存在的問題就是出貨與信用額度之間的依賴關系沒有描述清楚,我們把它修改成：

　　1.銷售出貨的前提是該客戶擁有超過出貨價值的信用額度XXX, 否則,系統提示‘該客戶信用額度不足,不予出貨!’

　　2.正式出貨后系統將扣減其信用額度很顯然,修改后的需求把出貨和信用額度的來由去向和系統的具體反應都說明清楚了。如果你接手的項目也存在這樣類似的問題，則一定要在需求階段明確要求PD 對需求做出調整。

　　要善于挖掘隱含需求，看一下下面的需求：“本月沒有參加過競價的會員顯示0;本月參加過競價的會員顯示出價次數”這個需求看上去已經描述的很清楚了，但實際去測試的時候，我們必須覆蓋以下的業務邏輯：從來沒有出價記錄的會員顯示為0;上月有出價、本月沒有出價的會員顯示為0;本月有出價的會員顯示出價次數。挖掘需求背后的測試要點，需要我們平時一點一滴的積累，不要被表象所迷惑。

　　我們一定要以測試目標為中心，去查找不充分的不完整的需求，通過以上的過程，我們可以把不直觀的需求轉變為直觀的需求, 把不明確的需求轉變為明確的需求，直到所有的問題都得到了解決并經過再測試OK，需求階段的測試才可以結束

　　。

原文轉自：http://www.kjueaiud.com