基于需求的測試:確保需求與軟件的統(tǒng)一

軟件質(zhì)量保證是軟件開發(fā)過程的重要一環(huán)。所謂軟件質(zhì)量保證就是使軟件綜合品質(zhì)符合用戶需求，軟件質(zhì)量保證的理論、技術(shù)、措施很多，測試是其中最重要的手段之一。實(shí)踐證明，雖然軟件的質(zhì)量并不完全依賴于測試，但科學(xué)、合理、有效的測試方案卻可以極大地提高軟件質(zhì)量。其中，基于需求的測試（RBT）就是軟件質(zhì)量保證的重要工具途徑之一。相關(guān)權(quán)威研究表明，已發(fā)現(xiàn)的軟件缺陷中超過50%的缺陷源于錯(cuò)誤或者不恰當(dāng)?shù)能浖枨蟆?/p>

保證需求與軟件的統(tǒng)一

Richard Bender是基于需求的軟件測試方法創(chuàng)始人。他認(rèn)為：改進(jìn)軟件系統(tǒng)測試方法的最佳途徑在于改進(jìn)軟件需求定義開發(fā)過程和功能測試設(shè)計(jì)過程，基于需求的測試是一種最根本的軟件測試。

軟件需求分析解決的主要問題是“軟件產(chǎn)品必須或應(yīng)該做什么”，軟件需求分析的最重要成果就是需求說明書，需求說明書是軟件產(chǎn)品的雛形，軟件產(chǎn)品是需求說明書的最終展現(xiàn)成果。由于需求和軟件之間是相互對應(yīng)的，編碼和測試用例之間也是相互對應(yīng)的，所以需求和測試用例之間是互相對應(yīng)的，在本質(zhì)上也是互相關(guān)聯(lián)、密不可分的，可以實(shí)現(xiàn)需求和測試用例之間的雙向跟蹤追溯。

值得一提的是，在軟件開發(fā)過程中，編程和測試是緊密相關(guān)、相輔相成的活動(dòng)，兩者同等重要、缺一不可。測試的目的是為了發(fā)現(xiàn)盡可能多的缺陷，并期望通過修改完善缺陷以提高軟件的質(zhì)量。成功的測試在于發(fā)現(xiàn)了迄今尚未發(fā)現(xiàn)的缺陷，測試人員的職責(zé)是設(shè)計(jì)這樣的測試用例，它能有效地揭示潛伏在軟件里的缺陷。

然而，在企業(yè)應(yīng)用軟件項(xiàng)目的實(shí)施過程中，普遍存在重編碼輕測試、缺乏高素質(zhì)軟件測試人員的現(xiàn)象。事實(shí)上，設(shè)計(jì)與測試應(yīng)該完全分離，好的開發(fā)者構(gòu)建事務(wù)，好的測試者破壞事務(wù)，一個(gè)好的軟件測試工程師應(yīng)該要比開發(fā)工程師對整個(gè)系統(tǒng)的理解更加透徹。目前很多軟件測試工程師處在軟件項(xiàng)目組的最低職級，缺乏高層的重視和支持，自身對于整個(gè)應(yīng)用系統(tǒng)“該做什么、要做什么、必須做什么”并不清楚，如果再加上與設(shè)計(jì)人員的溝通交流協(xié)作過程中不講究原則性、策略性，其工作成效可想而知。

基于需求的軟件測試方法

要實(shí)施基于需求的軟件測試，其正確的工作步驟如下：

1．全面清晰地掌握用戶需求

全面、清晰、準(zhǔn)確地認(rèn)識(shí)理解用戶需求、軟件平臺(tái)架構(gòu)是軟件測試工程師開展一切測試工作的前提和基礎(chǔ)。軟件測試工程師應(yīng)認(rèn)真閱讀、研究、分析《用戶需求說明書》、《軟件產(chǎn)品設(shè)計(jì)說明書》（分為概要設(shè)計(jì)和詳細(xì)設(shè)計(jì)）等關(guān)鍵文檔，清晰掌握平臺(tái)架構(gòu)設(shè)計(jì)、數(shù)據(jù)庫結(jié)構(gòu)設(shè)計(jì)、模塊功能設(shè)計(jì)、核心算法、界面展現(xiàn)、人員權(quán)限角色分配、輸入輸出數(shù)據(jù)等要素，將業(yè)務(wù)操作流程和以上要素分別逐一對應(yīng)關(guān)聯(lián)。

2．明確測試的目標(biāo)和任務(wù)

軟件測試的任務(wù)就是驗(yàn)證軟件是否準(zhǔn)確地實(shí)現(xiàn)了用戶需求，檢驗(yàn)需求和軟件之間是否一致。好的測試用例能發(fā)現(xiàn)軟件中潛在的新缺陷，糟糕的測試用例在目標(biāo)及任務(wù)尚不明確的情況下盲目進(jìn)行評測，不僅效率低下，而且毫無效果。

3．分階段制訂測試計(jì)劃方案

測試計(jì)劃方案不是從頭到尾一成不變的，應(yīng)根據(jù)企業(yè)應(yīng)用軟件項(xiàng)目所處的不同階段制訂，不同的項(xiàng)目階段所需的測試方法是不一致的?？梢越梃bRBT理論關(guān)于基于需求的測試方法的最佳實(shí)踐（參見鏈接）。

4．設(shè)計(jì)基于需求的復(fù)合測試用例

在很多情況下，單一的測試方法很難實(shí)現(xiàn)軟件缺陷或錯(cuò)誤的全面檢查，在軟件工程中使用最多的往往是組合多種測試方法的復(fù)合測試用例。例如黑盒測試和白盒測試兩者的功能作用就可以互相彌補(bǔ)，實(shí)踐中可以將兩種測試方法組合起來設(shè)計(jì)復(fù)合測試用例。

5．妥善處理測試和設(shè)計(jì)之間的關(guān)系

測試是“破壞性”的，而開發(fā)卻是“建設(shè)性”的。從行為學(xué)角度看，開發(fā)與測試是對立的。如果測試人員對開發(fā)人員的錯(cuò)誤批評指責(zé)過多，容易導(dǎo)致雙方的關(guān)系對立隔閡；如果測試人員對開發(fā)人員的錯(cuò)誤疏忽怠慢，容易導(dǎo)致軟件質(zhì)量的隱形下降，實(shí)踐中需要找到一個(gè)平衡點(diǎn)。

6．建立測試報(bào)告審批通報(bào)制度

建立測試報(bào)告審批通報(bào)制度對于提升軟件質(zhì)量具有明顯作用。作為一名優(yōu)秀的測試工程師，要養(yǎng)成書面起草測試工作報(bào)告的好習(xí)慣。將已經(jīng)定位發(fā)現(xiàn)的缺陷或錯(cuò)誤進(jìn)行分析匯總，用統(tǒng)計(jì)數(shù)字、圖表等方式說明缺陷或錯(cuò)誤的根源，及時(shí)將測試工作報(bào)告提交上級主管領(lǐng)導(dǎo)審議，并通知研發(fā)設(shè)計(jì)人員，使設(shè)計(jì)人員做到對缺陷心中有數(shù)、控制有道，以防患于未然。

鏈接

基于需求的測試?yán)碚摰奈屙?xiàng)最佳實(shí)踐

1．轉(zhuǎn)變“編碼后進(jìn)行測試”的傳統(tǒng)觀念。在軟件編碼開始之前的設(shè)計(jì)階段就根據(jù)需求文檔和設(shè)計(jì)文檔開發(fā)出90%以上的測試用例，盡早發(fā)現(xiàn)和排除絕大部分的缺陷。

2．根據(jù)各項(xiàng)應(yīng)用功能的優(yōu)先級、重要性制訂不同等級的測試方案、測試用例。重要的模塊投入較多的測試資源（人力、時(shí)間、物資），次要的模塊投入較少的測試資源。

3．盡早測試，頻繁測試。測試進(jìn)行得越早，缺陷發(fā)現(xiàn)越早，修復(fù)缺陷的代價(jià)越??；測試進(jìn)行得越晚，缺陷發(fā)現(xiàn)越遲，修復(fù)缺陷的代價(jià)越大。

4．摒棄“經(jīng)驗(yàn)至上”的想法。設(shè)計(jì)系統(tǒng)、嚴(yán)謹(jǐn)、合理的測試用例才能使測試達(dá)到實(shí)效。

5．加強(qiáng)對測試過程的監(jiān)控跟蹤。當(dāng)用戶需求發(fā)生變更時(shí)，軟件需求文檔和設(shè)計(jì)文檔都隨之發(fā)生變更，相應(yīng)測試用例也應(yīng)發(fā)生變更。要隨時(shí)監(jiān)控需求的變化，保證測試用例和用戶需求的雙向追溯統(tǒng)一。