就像軟件的需求一樣，測試需求根據(jù)不同的公司環(huán)境，不同的專業(yè)水平，不同的要求，詳細(xì)程度也是不同的。但是，對于一個全新的項(xiàng)目或者產(chǎn)品，測試需求力求詳細(xì)明確，以避免測試遺漏與誤解。
2、為什么要做測試需求分析
如果要成功的做一個測試項(xiàng)目，首先必須了解測試規(guī)模、復(fù)雜程度與可能存在的風(fēng)險(xiǎn)，這些都需要通過詳細(xì)的測試需求來了解。所謂知己知彼，百戰(zhàn)不殆。測試需求不明確，只會造成獲取的信息不正確，無法對所測軟件有一個清晰全面的認(rèn)識，測試計(jì)劃就毫無根據(jù)可言?；钤谧约菏澜缋锏娜耸强杀模粦{感覺不做詳細(xì)了解就下定論的項(xiàng)目是失敗的。
測試需求越詳細(xì)精準(zhǔn)，表明對所測軟件的了解越深，對所要進(jìn)行的任務(wù)內(nèi)容就越清晰，就更有把握保證測試的質(zhì)量與進(jìn)度。
如果把測試活動比作軟件生命周期，測試需求就相當(dāng)于軟件的需求規(guī)格，測試策略相當(dāng)于軟件的架構(gòu)設(shè)計(jì)，測試用例相當(dāng)于軟件的詳細(xì)設(shè)計(jì)，測試執(zhí)行相當(dāng)于軟件的編碼過程。只是在測試過程中，我們把”軟件”兩個字全部替換成了”測試”。這樣，我們就明白了整個測試活動的依據(jù)來源于測試需求。
3、測試需求的依據(jù)與收集
測試需求通常是以待測對象的軟件需求為原型進(jìn)行分析而轉(zhuǎn)變過來的。但測試需求并不等同于軟件需求，它是以測試的觀點(diǎn)根據(jù)軟件需求整理出一個checklist，作為測試該軟件的主要工作內(nèi)容。
測試需求主要通過以下途徑來收集：
1） 與待測軟件相關(guān)的各種文檔資料。如軟件需求規(guī)格、Usecase、界面設(shè)計(jì)、項(xiàng)目會議或與客戶溝通時(shí)有關(guān)于需求信息的會議記錄、其他技術(shù)文檔等。
2） 與客戶或系統(tǒng)分析員的溝通。
3） 業(yè)務(wù)背景資料。如待測軟件業(yè)務(wù)領(lǐng)域的知識等。
4） 正式與非正式的培訓(xùn)。
5）其他。如果以舊系統(tǒng)為原型，以全新的架構(gòu)方式來設(shè)計(jì)或完善軟件，那么舊系統(tǒng)的原有功能跟特性就成為了最有效的測試需求收集途徑。
在整個信息收集過程中，務(wù)必確保軟件的功能與特性被正確理解。因此，測試需求分析人員必須具備優(yōu)秀的溝通能力與表達(dá)能力。
4、測試需求的分析
目前不少的書籍與網(wǎng)站資料開始重視測試需求的分析，同時(shí)也提出了一些測試需求分析的方法。這里也提出一些自己的看法。
測試需求需要考慮幾個層面的因素：
第一層：測試階段。系統(tǒng)測試階段，需求分析更注重于技術(shù)層面，即軟件是否實(shí)現(xiàn)了具備的功能。如果某一種流程或者某一角色能夠執(zhí)行一項(xiàng)功能，那么我們相信具備相同特征的業(yè)務(wù)或角色都能夠執(zhí)行該功能。為了避免測試執(zhí)行的冗余，可不再重復(fù)測試。而在驗(yàn)收測試階段，更注重于不同角色在同一功能上能否走通要求的業(yè)務(wù)流程。因此需要根據(jù)不同的業(yè)務(wù)需要而測試相同的功能，以確保系統(tǒng)上線后不會有意外發(fā)生。但是否有必要進(jìn)行這種大量的重復(fù)性質(zhì)的測試，不過也是見仁見智的做法，要看測試管理者對測試策略與風(fēng)險(xiǎn)的平衡能力了。
目前，大多數(shù)的測試都會在系統(tǒng)測試中完成，驗(yàn)收測試只是對于系統(tǒng)測試的回歸。此種情況也是合理的，關(guān)鍵看測試周期與資源是否允許，以及各測試階段的任務(wù)劃分。
第二層：待測軟件的特性。不同的軟件業(yè)務(wù)背景不同，所要求的特性也不相同，測試的側(cè)重點(diǎn)自然也不相同。除了需要確保要求實(shí)現(xiàn)的功能正確，銀行/財(cái)務(wù)軟件更強(qiáng)調(diào)數(shù)據(jù)的精確性，網(wǎng)站強(qiáng)調(diào)服務(wù)器所能承受的壓力，ERP強(qiáng)調(diào)業(yè)務(wù)流程，驅(qū)動程序強(qiáng)調(diào)軟硬件的兼容性。在做測試分析時(shí)需要根據(jù)軟件的特性來選取測試類型，并將其列入測試需求當(dāng)中。
第三層：測試的焦點(diǎn)。測試的焦點(diǎn)是指根據(jù)所測的功能點(diǎn)進(jìn)行分析、分解，從而得出的著重于某一方面的測試，如界面、業(yè)務(wù)流、模塊化、數(shù)據(jù)、輸入域等。目前關(guān)于各個焦點(diǎn)的測試也有不少的指南，那些已經(jīng)是很好的測試需求參考了，在此僅列出業(yè)務(wù)流的測試分析方法。
任何一套軟件都會有一定的業(yè)務(wù)流，也就是用戶用該軟件來實(shí)現(xiàn)自己實(shí)際業(yè)務(wù)的一個流程。簡單的來說，在做測試需求分析時(shí)需要列出以下類別：
1） 常用的或規(guī)定的業(yè)務(wù)流程
2） 各業(yè)務(wù)流程分支的遍歷
3） 明確規(guī)定不可使用的業(yè)務(wù)流程
4） 沒有明確規(guī)定但是應(yīng)該不可以執(zhí)行的業(yè)務(wù)流程
5） 其他異?；虿环弦?guī)定的操作
然后根據(jù)軟件需求理出業(yè)務(wù)的常規(guī)邏輯，按照以上類別提出的思路，一項(xiàng)一項(xiàng)列出各種可能的測試場景，同時(shí)借助于軟件的需求以及其他信息，來確定該場景應(yīng)該導(dǎo)致的結(jié)果，便形成了軟件業(yè)務(wù)流的基本測試需求。
在做完以上步驟之后，將業(yè)務(wù)流中涉及的各種結(jié)果以及中間流程分支回顧一遍，確定是否還有其他場景可能導(dǎo)致這些結(jié)果，以及各中間流程之間的交互可能產(chǎn)生的新的流程，從而進(jìn)一步補(bǔ)充與完善測試需求。
5、測試需求的優(yōu)先級
優(yōu)先級別的確定，利于測試工作有的放矢的展開，使測試人員清晰了解核心的功能、特性與流程有哪些，客戶最為關(guān)注的是什么，由此可確定測試的工作重點(diǎn)在何處，更方便處理測試進(jìn)度發(fā)生問題時(shí)，實(shí)現(xiàn)不同優(yōu)先級別的功能、模塊、系統(tǒng)等迭代遞交或取舍，從而緩和測試風(fēng)險(xiǎn)。
通常，需求管理規(guī)范的客戶，會規(guī)定用戶需求/軟件需求的優(yōu)先級別，測試需求的優(yōu)先級可根據(jù)其直接定義。如果沒有規(guī)定項(xiàng)目需求的優(yōu)先級，則可與客戶溝通，確定哪些功能或特性是需要尤其關(guān)注的，從而確定測試需求的優(yōu)先級。
6、測試需求的覆蓋率與覆蓋程度
測試需求的覆蓋率通常是由與軟件需求所建立的對應(yīng)關(guān)系來確定的。如果一個軟件的需求已經(jīng)跟測試需求存在了一對一或一對多的對應(yīng)關(guān)系，可以說測試需求已經(jīng)覆蓋了該功能點(diǎn)，以此類推，如果確定了所有的軟件需求都建立了對應(yīng)的測試需求，那么測試需求的覆蓋率便是測試需求覆蓋點(diǎn)/軟件需求功能點(diǎn)=100%，但并不意味著測試需求的覆蓋程度高。因?yàn)闇y試需求的覆蓋率只計(jì)算了顯性的（即被明確規(guī)定的功能與特性）因素，而隱性的（即沒有被明確規(guī)定但是有可能或不應(yīng)該擁有的功能與特性）因素并未計(jì)算在內(nèi)。因此根據(jù)不斷的完善或?qū)嶋H測試中發(fā)生的缺陷，可以對測試需求進(jìn)行補(bǔ)充或優(yōu)化，并更新進(jìn)測試用例中，以此來提高測試需求的覆蓋程度。
