測試過程中的評審工作及關注事項

　　公司的軟體開發EPG過程規範中對測試領域的工作及其規範做了細緻的說明，雖然是CMMI3+，不過還是有些地方只是官樣文章，是形而上的東西，在實 際工作中不具備任何的指導作用。所以我們領導覺得這個可以自己重新定義一些在測試思維上較為技術性的東西納入到測試領域的規範當中，而我負責關於使用者需求 評審和系統測試用例評審的檢查點整理工作。由於使用者需求評審能夠有助於測試人員工 作的開展，所以下面就使用者與需求評審所需要準備的工作、使用者需求評審時所要思考的問題、系統測試用例評審過程中所需要考慮的一些檢查點進行簡單的列舉。這 些內容都是個人經驗總結，並不能應用於所有型別的系統，所以請不要拿來硬套，因為不同行業、不同型別的系統特徵是不同的，我所關注的只是我所負責的保險系 列業務系統。

　　使用者需求評審準備工作
》向使用者或者BA/SA索取原始需求文件；
》仔細閱讀需求文件，大致估算系統改動；
》向開發人員瞭解預計的開發工作量，並且相互印證系統改動的估算；
》瞭解需求排期，預估測試所需人力，估算時需要考慮關聯影響測試；
》瞭解相同和接近的版本週期內的其他需求和版本，預估測試環境和人力是否足夠，如果有可能資源不足則及時升級並且邀請測試經理參與需求評審會議。

　　使用者問題清單
》本需求提出的背景：現有功能有什麼樣的問題、由什麼市場、行業的變化所導致？
》本需求所要實現的目標：操作流程簡化、業務成本降低或者客戶滿意度提高等等？
》本需求是否有前置和後續需求排期？其優先順序是否合理，實現情況分別是怎樣的？
》本需求的內容是否會與現有業務邏輯或者系統邏輯的衝突？如果有，該如何解決？
》本需求所包含內容是否有冗餘：與現有某些系統功能或流程重複，造成重複開發？
》本需求是否有足夠的資源去實現，包括測試人力、開發人力或者測試環境等資源？
》本需求完成之後的效益是否足夠抵消其在IT版本的成本投入？是否可能會出現在這個需求上“得不償失”或者說“入不敷出”的情況？
》本需求使用者驗收測試有什麼樣的案例？對應的資料型別和資料量的需求是怎樣的？
》本需求的UAT所需要的時間應該有多少？使用者是否有足夠的測試人力投入？IT應該保證的最短UAT時間需要多少天？
》UAT人員是否有就此需求測試的其他特殊要求或疑問？如果有，這些要求是否合理、是否有必要、是否需要IT同事支援或者是否有變通解決方法？

　　用例評審關注點
》用例描述、操作步驟、預期結果和資料使用等資訊是否準確、完整、無歧義；
》用例是否包含了足夠多的業務型別分支或資料場景分支；
》用例中是否設計了操作源表包含百、萬、百萬甚至億級資料，結果集輸出包含十、百、千等不同級別的資料場景，對其效能是否可接受是否有可行的驗證方法；
》用例是否考慮了使用者使用的頻率，若使用非常頻繁，那麼是否需要做併發測試；
》被測功能是否為無操作介面的系統自動任務，若無操作介面，那麼用例中是否考慮了使用者測試的方法；若有介面，是否有介面規範性性檢查測試用例（CQ中有介面變更項為是的需求）；

本文轉自：