目前，大多數的測試都會在系統測試中完成，驗收測試只是對于系統測試的回歸。此種情況也是合理的，關鍵看測試周期與資源是否允許，以及各測試階段的任務劃分。
第二層：待測軟件的特性。不同的軟件業務背景不同，所要求的特性也不相同，測試的側重點自然也不相同。除了需要確保要求實現的功能正確，銀行/財務軟件更強調數據的精確性，網站強調服務器所能承受的壓力，ERP強調業務流程，驅動程序強調軟硬件的兼容性。在做測試分析時需要根據軟件的特性來選取測試類型，并將其列入測試需求當中。
第三層：測試的焦點。測試的焦點是指根據所測的功能點進行分析、分解，從而得出 的著重于某一方面的測試，如界面、業務流、模塊化、數據、輸入域等。目前關于各個焦點的測試也有不少的指南，那些已經是很好的測試需求參考了，在此僅列出業務流的測試分析方法。
任何一套軟件都會有一定的業務流，也就是用戶用該軟件來實現自己實際業務的一個流程。簡單的來說，在做測試需求分析時需要列出以下類別：
1) 常用的或規定的業務流程
2) 各業務流程分支的遍歷
3) 明確規定不可使用的業務流程
4) 沒有明確規定但是應該不可以執行的業務流程
5) 其他異�；虿环弦幎ǖ牟僮�
然后根據軟件需求理出業務的常規邏輯，按照以上類別提出的思路，一項一項列出各種可能的測試場景，同時借助于軟件的需求以及其他信息，來確定該場景應該導致的結果，便形成了軟件業務流的基本測試需求。
在做完以上步驟之后，將業務流中涉及的各種結果以及中間流程分支回顧一遍，確定是否還有其他場景可能導致這些結果，以及各中間流
程之間的交互可能產生的新的流程，從而進一步補充與完善測試需求。
5. 測試需求的優先級
優先級別的確定，利于測試工作有的放矢的展開，使測試人員清晰了解核心的功能、特性與流程有哪些，客戶最為關注的是什么，由此可確定測試的工作重點在何處，更方便處理測試進度發生問題時，實現不同優先級別的功能、模塊、系統等迭代遞交或取舍，從而緩和測試風險。
通常，需求管理規范的客戶，會規定用戶需求/軟件需求的優先級別，測試需求的優先級可根據其直接定義。如果沒有規定項目需求的優先級，則可與客戶溝通，確定哪些功能或特性是需要尤其關注的，從而確定測試需求的優先級。
6. 測試需求的覆蓋率與覆蓋程度
測試需求的覆蓋率通常是由與軟件需求所建立的對應關系來確定的。如果一個軟件的需求已經跟測試需求存在了一對一或一對多的對應關系，可以說測試需求已經覆蓋了該功能點，以此類推，如果確定了所有的軟件需求都建立了對應的測試需求，那么測試需求的覆蓋率便是測試需求覆蓋點/軟件需求功能點=100%，但并不意味著測試需求的覆蓋程度高。因為測試需求的覆蓋率只計算了顯性的(即被明確規定的功能與特性)因素，而隱性的(即沒有被明確規定但是有可能或不應該擁有的功能與特性)因素并未計算在內。因此根據不斷的完善或實際測試中發生的缺陷，可以對測試需求進行補充或優化，并更新進測試用例中，以此來提高測試需求的覆蓋程度。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
