基于需求變更測(cè)試模型的研究

謝 春，鄭顯舉

(成都電子機(jī)械高等?？茖W(xué)校 計(jì)算機(jī)工程系，成都 610071)

軟件測(cè)試是保證軟件質(zhì)量的重要環(huán)節(jié)，而穩(wěn)定的需求則是軟件測(cè)試的關(guān)鍵［1-2］。一個(gè)良好穩(wěn)定的需求有利于開(kāi)發(fā)人員和測(cè)試人員對(duì)系統(tǒng)進(jìn)行準(zhǔn)確的驗(yàn)證和評(píng)定，確認(rèn)軟件系統(tǒng)是否滿足用戶的需要［3］。然而實(shí)際開(kāi)發(fā)過(guò)程中需求卻是經(jīng)常發(fā)生變化的，EBERT［4］發(fā)現(xiàn)，一個(gè)為期2年的項(xiàng)目，會(huì)有大于30%的需求發(fā)生變更。另一方面，由于新的開(kāi)發(fā)方式［5］的出現(xiàn)，使得需求不僅受到開(kāi)發(fā)團(tuán)隊(duì)和客戶的影響，組件服務(wù)提供商同樣也會(huì)導(dǎo)致需求的變更。顯然，處理這些頻繁而又復(fù)雜的需求變更僅靠配置管理是不夠的。因此，采用合理的開(kāi)發(fā)或測(cè)試模型，并在適當(dāng)?shù)臅r(shí)機(jī)借助工具的支持，才能有效控制需求變更的風(fēng)險(xiǎn)。

一般常用的開(kāi)發(fā)或測(cè)試模型大都只關(guān)注怎樣將測(cè)試活動(dòng)融入開(kāi)發(fā)的各個(gè)環(huán)節(jié)，對(duì)于需求經(jīng)常變更的問(wèn)題都沒(méi)有很好的解決方案。例如在XP的開(kāi)發(fā)方法［6］中，當(dāng)需求發(fā)生變化時(shí)，團(tuán)隊(duì)開(kāi)發(fā)人員要和客戶代表一起分析并撰寫(xiě)新的需求并對(duì)全部需求進(jìn)行優(yōu)先級(jí)排序，這就會(huì)對(duì)當(dāng)前迭代造成影響，會(huì)有部分需求挪至下一迭代階段實(shí)現(xiàn)，仍然無(wú)法從根本上解決需求變更的問(wèn)題。在Scrum方法［7］中，開(kāi)發(fā)過(guò)程被分成數(shù)個(gè)小周期的沖刺階段，在每個(gè)沖刺階段中需求變化是被忽視的，期間出現(xiàn)的任何需求變化，將作為下次沖刺的需求部分，不對(duì)當(dāng)前狀態(tài)產(chǎn)生影響。前置測(cè)試模型［8］是將測(cè)試執(zhí)行和開(kāi)發(fā)結(jié)合在一起，一段程序編寫(xiě)完成就立即進(jìn)行測(cè)試，這樣就能在較早時(shí)間發(fā)現(xiàn)錯(cuò)誤并將其改正，從而降低測(cè)試成本。然而，該模型仍舊是以確定需求為前提，測(cè)試的設(shè)計(jì)和執(zhí)行都是以固定的需求為綱，一旦需求發(fā)生變化，則需要改動(dòng)以此為基礎(chǔ)的許多工作。本研究針對(duì)以往模型的不足，在原有測(cè)試模型的基礎(chǔ)上提出一個(gè)應(yīng)對(duì)需求變更的新測(cè)試模型，以幫助開(kāi)發(fā)人員更好地應(yīng)對(duì)不斷變化的需求。

1 需求變更對(duì)模塊組裝方式的影響

需求是軟件開(kāi)發(fā)和測(cè)試的綱領(lǐng)，其變更主要來(lái)自客戶要求的變化，具體來(lái)說(shuō)可以分為3種:

1)需求減少。此類需求變更相對(duì)來(lái)說(shuō)較少發(fā)生，如客戶由于經(jīng)費(fèi)的原因縮減項(xiàng)目規(guī)模，減少軟件系統(tǒng)中的功能需求等。這種需求變更處理起來(lái)也很方便，只要屏蔽相關(guān)模塊即可。

2)需求增加。此類的需求變更有時(shí)會(huì)發(fā)生，主要是由于客戶想增加某一功能而導(dǎo)致需要編寫(xiě)新的功能模塊。這種需求變更對(duì)整個(gè)系統(tǒng)而言就是增加新的功能模塊，對(duì)其它模塊來(lái)說(shuō)就是重新編寫(xiě)集成測(cè)試中所需要的樁模塊和驅(qū)動(dòng)模塊。

3)需求改變。此類的需求變更最多，如客戶的業(yè)務(wù)流程改變會(huì)導(dǎo)致軟件項(xiàng)目中的某個(gè)邏輯序列或信息傳遞途徑的改變。對(duì)于這種需求變更而言，由于目前通常采用面向?qū)ο蟮拈_(kāi)發(fā)方法，系統(tǒng)中對(duì)象相對(duì)穩(wěn)定，所以改變的只是對(duì)象中的方法和對(duì)象之間的關(guān)系。因此，只要提高基線用例庫(kù)的可信度并選擇恰當(dāng)?shù)幕貧w測(cè)試包就可提高測(cè)試效率。

軟件測(cè)試包括4個(gè)階段，即單元測(cè)試、集成測(cè)試、確認(rèn)測(cè)試和系統(tǒng)測(cè)試。相對(duì)于軟件開(kāi)發(fā)過(guò)程的自頂向下而言，測(cè)試過(guò)程正好相反，是自底向上逐步集成。集成方式有一次性組裝和逐步增殖組裝［9］。對(duì)于一次性組裝方式來(lái)說(shuō)，需求變更發(fā)生后，對(duì)象會(huì)有新的方法、新數(shù)據(jù)結(jié)構(gòu)以及新的對(duì)象間關(guān)系，所以系統(tǒng)復(fù)雜性增加，從而導(dǎo)致錯(cuò)誤(bug)查找難度成倍地提高。對(duì)于增殖組裝方式而言，自頂向下增殖的方式和自底向上增殖的方式對(duì)應(yīng)于需求變更各有缺點(diǎn)。具體來(lái)說(shuō)，自頂向下增殖方式需要建立樁模塊，而樁模塊要能夠較好地模擬實(shí)際子模塊的功能是比較困難的，因?yàn)闃赌K在接收了所測(cè)模塊發(fā)送的信息后需要按照它所代替的實(shí)際子模塊功能返回應(yīng)該回送的信息，這中間涉及復(fù)雜算法和底層輸入輸出模塊，難度較大而且也最容易出問(wèn)題。此外，到組裝和測(cè)試的后期，因需求變更所增加新模塊一旦出現(xiàn)問(wèn)題，就會(huì)成倍地增加回歸測(cè)試的工作量。而自底向上增殖方式的缺點(diǎn)是被測(cè)試系統(tǒng)一直未能作為一個(gè)實(shí)體存在，直到最后一個(gè)模塊加上去后才形成一個(gè)實(shí)體。也就是說(shuō)，在自底向上組裝和測(cè)試的過(guò)程中，對(duì)主要的控制模塊直到最后才接觸到，因此由于需求變更所產(chǎn)生或修改的模塊是否滿足需求，直到最后一步之前是未知的。這2種增殖方式的組裝方向都是單向的，難以滿足軟件開(kāi)發(fā)過(guò)程中需求變更的要求。

當(dāng)使用自頂向下組裝方式時(shí)，遇到的問(wèn)題是對(duì)應(yīng)于需求變更的模塊過(guò)晚的測(cè)試，違背了最可能出現(xiàn)問(wèn)題的部分最先測(cè)試的原則［10］。當(dāng)使用自底向上組裝方式時(shí)，遇到的問(wèn)題類似，前者是模塊失效，導(dǎo)致系統(tǒng)的反復(fù)回歸測(cè)試，后者則對(duì)于測(cè)試處于失控狀態(tài)，盡管測(cè)試順利，但不能說(shuō)明整個(gè)系統(tǒng)的具體狀況。

綜上所述，可以采取以下方法加以改進(jìn):1)衍變的自頂向下的增殖方式。強(qiáng)化對(duì)需求變更模塊的測(cè)試，自底向上組裝成為功能比較完整且相對(duì)獨(dú)立的子系統(tǒng)，然后由系統(tǒng)主模塊開(kāi)始自頂向下進(jìn)行增殖測(cè)試。這種方法既避免了自頂向下增殖組裝時(shí)測(cè)試的失敗導(dǎo)致的反復(fù)回歸測(cè)試，又避免失去對(duì)測(cè)試過(guò)程的控制。采用這種改進(jìn)后的策略，在遇到需求變更的情況時(shí)，系統(tǒng)的模塊會(huì)對(duì)應(yīng)地變化，新變化的模塊出問(wèn)題的概率相對(duì)較大(即質(zhì)量風(fēng)險(xiǎn)高)，因此先加強(qiáng)它的測(cè)試就可以有效規(guī)避質(zhì)量風(fēng)險(xiǎn)，然后再利用自頂向下組裝的優(yōu)勢(shì)組裝成一個(gè)稍大的子系統(tǒng)，從而改進(jìn)測(cè)試過(guò)程。2)基于服務(wù)的增殖方式。首先對(duì)含服務(wù)請(qǐng)求操作的新模塊進(jìn)行自底向上直至根結(jié)點(diǎn)的組裝和測(cè)試，然后對(duì)含提供服務(wù)操作的新模塊做自頂向下的組裝與測(cè)試。這種方法符合面向?qū)ο笙l(fā)送的原則，更重要的是能夠簡(jiǎn)化樁模塊的編寫(xiě)工作。采用這種組裝策略，在遇到需求變更的情況時(shí)，最大的變化是對(duì)象的方法和對(duì)象間關(guān)系的改變，組裝時(shí)重點(diǎn)考慮對(duì)象間關(guān)系的變化，即考慮服務(wù)提供者和服務(wù)請(qǐng)求者之間的關(guān)系，簡(jiǎn)化樁模塊的編寫(xiě)，同時(shí)分別利用自頂向下和自底向上的優(yōu)點(diǎn)，從而改進(jìn)測(cè)試過(guò)程。

2 對(duì)于傳統(tǒng)模型的改進(jìn)與工具的選擇

2.1 模型的改進(jìn)

筆者采用了如圖1所示的改進(jìn)的測(cè)試模型。該模型以系統(tǒng)需求為起點(diǎn)進(jìn)行系統(tǒng)分析與設(shè)計(jì)，同時(shí)制定測(cè)試計(jì)劃;以需求變更為切入點(diǎn)修正測(cè)試計(jì)劃，即對(duì)需求變更進(jìn)行控制，并以此來(lái)跟蹤需求變更對(duì)系統(tǒng)中原有的對(duì)象的影響。此外，為了突出對(duì)于需求變更的處理，這里簡(jiǎn)化了系統(tǒng)分析設(shè)計(jì)的描述，但并不是不重視系統(tǒng)的分析與設(shè)計(jì)，相反，良好的系統(tǒng)分析與設(shè)計(jì)是這個(gè)測(cè)試模型能順利實(shí)施的最基本的前提條件［11］。該模型主要有如下3個(gè)特點(diǎn):

圖1 基于需求變更的測(cè)試模型

1)在設(shè)計(jì)階段進(jìn)行計(jì)劃和測(cè)試設(shè)計(jì)。設(shè)計(jì)階段建立測(cè)試計(jì)劃和進(jìn)行測(cè)試設(shè)計(jì)至關(guān)重要。沒(méi)有測(cè)試計(jì)劃和設(shè)計(jì)的測(cè)試過(guò)程只是驗(yàn)證了程序的正確性，無(wú)法驗(yàn)證整個(gè)系統(tǒng)本該實(shí)現(xiàn)的東西。V模型中驗(yàn)收測(cè)試最早被定義好，并在最后執(zhí)行，以驗(yàn)證所交付的系統(tǒng)是否真正符合用戶業(yè)務(wù)的需求。相對(duì)于V模型，本測(cè)試模型還包含了對(duì)需求進(jìn)行的測(cè)試，這樣可以保障對(duì)需求變更的控制。

2)測(cè)試和開(kāi)發(fā)結(jié)合在一起。本模型中，測(cè)試執(zhí)行和開(kāi)發(fā)結(jié)合在一起形成一個(gè)迭代的過(guò)程。在普通情況下，先進(jìn)行的測(cè)試是單元測(cè)試，因?yàn)檫@是測(cè)試人員通過(guò)測(cè)試來(lái)發(fā)現(xiàn)錯(cuò)誤最經(jīng)濟(jì)的方式。需求變更后，則可以結(jié)合需求變更采用不同的集成測(cè)試方式，并且可以跨越各個(gè)不同的測(cè)試階段靈活地進(jìn)行測(cè)試。在技術(shù)測(cè)試計(jì)劃中定義好單元測(cè)試與集成測(cè)試的組裝類型，就可有效地改善軟件測(cè)試質(zhì)量，提高測(cè)試效率。

3)驗(yàn)收測(cè)試和技術(shù)測(cè)試保持相互獨(dú)立。驗(yàn)收測(cè)試獨(dú)立于其他的技術(shù)測(cè)試階段，這樣可以提供雙重驗(yàn)證，保證設(shè)計(jì)及程序編碼能夠最終符合用戶的需求。

2.2 工具的選擇

從功能角度看，為了滿足以上模型的需求，需求管理工具需要提供以下基本功能:1)支持需求的記錄以及分解和對(duì)需求按照優(yōu)先級(jí)或者其他方式進(jìn)行排序。2)需求之間依賴關(guān)系的標(biāo)識(shí)，隱藏需求依賴關(guān)系的識(shí)別和定義，對(duì)變化的需求影響范圍進(jìn)行分析等。3)支持版本記錄和基線記錄，并支持不同版本之間的比較，根據(jù)需要恢復(fù)到歷史版本等功能。4)需求到設(shè)計(jì)、代碼、測(cè)試等工作產(chǎn)品之間的鏈接，并且在需求變化的時(shí)候，提示相關(guān)聯(lián)工作產(chǎn)品的功能。5)支持各種狀態(tài)下的提醒以及提供交流的功能，方便異步或者遠(yuǎn)程交流等。6)對(duì)流程的定制功能，以便適應(yīng)不同的流程控制方法，不同的機(jī)構(gòu)也可以對(duì)各種主流的變更管理在流程上針對(duì)自己的情況做定制。

如果有需求管理工具能覆蓋上面這些功能，那就可以對(duì)本研究提出的需求變更測(cè)試模型進(jìn)行支持。目前比較常用的需求管理工具有 Borland的 CaliberRM，IBM Rational的 RequisitePro與 ClearQuest。其中CaliberRM功能相對(duì)較全，對(duì)需求變更管理的大部分功能都有支持，但在工作產(chǎn)品鏈接上以及交流方面的支持相對(duì)較弱。而RequisitePro和ClearQuest相對(duì)于前兩者則功能較弱，這是因?yàn)檫@2個(gè)都是IBM Rational的產(chǎn)品，RequisitePro是一個(gè)需求管理工具，而ClearQuest是一個(gè)變更管理工具，要提供需求變更管理，需要把兩者結(jié)合使用。但是ClearQuest雖然對(duì)變更管理支持得很好，卻不是專門(mén)為需求變更所開(kāi)發(fā)的，即使與RequisitePro搭配也很難針對(duì)需求的特點(diǎn)定制使用?？傮w來(lái)說(shuō)，這些主流的需求管理工具都提供了對(duì)需求變更管理能力的支持，但是并沒(méi)有做到很完美，例如對(duì)于交流的支持、工作產(chǎn)品的鏈接查看等有待改進(jìn)。

3 測(cè)試改進(jìn)實(shí)例

EHR人力資源管理系統(tǒng)是陜西驊冠信息技術(shù)有限公司針對(duì)特定企業(yè)進(jìn)行定制開(kāi)發(fā)的人力資源管理系統(tǒng)。它由公司組織結(jié)構(gòu)、員工基本信息管理、招聘管理、考勤管理、薪資管理、績(jī)效考評(píng)等模塊組成。在該系統(tǒng)測(cè)試的具體實(shí)施過(guò)程中，采用本文提出的基于需求變更的測(cè)試模型與CaliberRM輔助需求管理軟件。首先以需求分析為基礎(chǔ)編寫(xiě)需求文檔，然后進(jìn)行需求評(píng)審，制定測(cè)試計(jì)劃，在開(kāi)發(fā)過(guò)程中，針對(duì)需求變更做出適當(dāng)記錄，為以后的測(cè)試改進(jìn)打下基礎(chǔ)(過(guò)程如圖2所示)。

仔細(xì)閱讀規(guī)格說(shuō)明、設(shè)計(jì)文檔、使用說(shuō)明書(shū)及測(cè)試大綱、測(cè)試內(nèi)容及測(cè)試的通過(guò)準(zhǔn)則，全面熟悉系統(tǒng)，編寫(xiě)測(cè)試計(jì)劃，設(shè)計(jì)測(cè)試用例，作好測(cè)試前的準(zhǔn)備工作。為了保證測(cè)試的質(zhì)量，將測(cè)試過(guò)程分成代碼審查、單元測(cè)試、集成測(cè)試和驗(yàn)收測(cè)試等幾個(gè)階段。代碼會(huì)審由一組人通過(guò)閱讀、討論和爭(zhēng)議對(duì)程序進(jìn)行靜態(tài)分析。會(huì)審小組在充分閱讀待審程序文本、控制流程圖及有關(guān)要求、規(guī)范等文件基礎(chǔ)上，召開(kāi)代碼會(huì)審會(huì)，由編碼者講解程序的邏輯。實(shí)踐表明，編碼者在講解過(guò)程中能發(fā)現(xiàn)許多原來(lái)沒(méi)有發(fā)現(xiàn)的錯(cuò)誤，并通過(guò)討論發(fā)現(xiàn)更多問(wèn)題。例如，對(duì)某個(gè)局部性小問(wèn)題修改方法的討論，可能發(fā)現(xiàn)涉及到模塊的功能、模塊間接口和系統(tǒng)結(jié)構(gòu)的大問(wèn)題，導(dǎo)致對(duì)需求定義的重定義、重設(shè)計(jì)驗(yàn)證。單元測(cè)試集中在檢查軟件設(shè)計(jì)的最小單位模塊上，通過(guò)測(cè)試發(fā)現(xiàn)實(shí)現(xiàn)該模塊的實(shí)際功能與定義該模塊的功能說(shuō)明不符合的情況，甚至編碼的錯(cuò)誤。由于單一模塊規(guī)模小、功能和邏輯簡(jiǎn)單，測(cè)試者可清楚地了解該模塊的邏輯結(jié)構(gòu)，采用結(jié)構(gòu)測(cè)試方法徹底測(cè)試，然后輔以功能測(cè)試，覆蓋輸入域(如圖3所示)。

單元測(cè)試完成后展開(kāi)集成測(cè)試，模塊按照設(shè)計(jì)要求組裝起來(lái)同時(shí)進(jìn)行測(cè)試，目的是發(fā)現(xiàn)與接口有關(guān)的問(wèn)題。如數(shù)據(jù)通過(guò)接口時(shí)丟失;一個(gè)模塊與另一個(gè)模塊由于疏忽造成互相有害的影響;子功能模塊組合起來(lái)不產(chǎn)生預(yù)期的主功能;個(gè)別看起來(lái)可以接受的誤差積累到不能接受的程度;全程數(shù)據(jù)結(jié)構(gòu)可能有錯(cuò)誤等。在集成測(cè)試階段，針對(duì)需求變更的不同類型，采取合適的測(cè)試方案，在EHR人力資源管理系統(tǒng)中，用戶由于對(duì)績(jī)效考評(píng)方法的變更導(dǎo)致需求發(fā)生了變化，但是由于系統(tǒng)中的對(duì)象沒(méi)有發(fā)生本質(zhì)的變化，所以可以采取基于服務(wù)請(qǐng)求方向的集成組裝測(cè)試策略。

集成測(cè)試完成后展開(kāi)系統(tǒng)測(cè)試，從產(chǎn)品的角度檢驗(yàn)軟件。經(jīng)過(guò)這樣的測(cè)試過(guò)程后，軟件基本滿足質(zhì)量要求，測(cè)試宣告結(jié)束，經(jīng)驗(yàn)收后將軟件提交用戶。

縱觀HER人力資源管理系統(tǒng)的測(cè)試，從初始階段跟蹤需求變更，將需求變更分類，在集成測(cè)試階段依據(jù)需求變更的不同類型采取恰當(dāng)?shù)募蓽y(cè)試策略，其間優(yōu)化維護(hù)測(cè)試用例庫(kù)，并以此展開(kāi)回歸測(cè)試，降低了測(cè)試工作量，改善了測(cè)試的效率，減低了測(cè)試成本，提高了軟件產(chǎn)品的質(zhì)量。

4 結(jié)語(yǔ)

本文從需求變更的原因入手，通過(guò)分析軟件測(cè)試過(guò)程，詳細(xì)說(shuō)明了測(cè)試系統(tǒng)的組織以及工程設(shè)計(jì)的原則，著重探討了集成測(cè)試中模塊組裝的策略，分析了一次性組裝和增殖組裝方式各自的優(yōu)缺點(diǎn)，在基于需求變更控制的基礎(chǔ)上改進(jìn)了軟件測(cè)試方法。對(duì)傳統(tǒng)測(cè)試模型進(jìn)行了改進(jìn)，形成了基于需求變更的新模型。該模型以系統(tǒng)需求為起點(diǎn)進(jìn)行系統(tǒng)分析與設(shè)計(jì)，同時(shí)制定測(cè)試計(jì)劃;以需求變更為切入點(diǎn)修正測(cè)試計(jì)劃，為軟件測(cè)試活動(dòng)作出具體的指導(dǎo)。

［1］KENNER C，F(xiàn)ALK J.計(jì)算機(jī)軟件測(cè)試［M］.北京:機(jī)械工業(yè)出版社，2004.

［2］PERRY W E.軟件測(cè)試的有效方法［M］.北京:機(jī)械工業(yè)出版社，2004.

［3］LEFFINGWELL D，WIDRIG D.軟件需求管理:用例方法［M］.北京:中國(guó)電力出版社，2004.

［4］EBERT C.Understanding the product life cycle:FOUR key requirements engineering techniques［J］.Software，IEEE，2006，23(3):19-25.

［5］KOHL R J.Requirements engineering changes for COST-intensive systems［J］.IEEE Software，2005，22(4):63-64.

［6］BECK K，ANDRES C.解析極限編程:擁抱變化［M］.北京:電子工業(yè)出版社，2006.

［7］SCHWABER K，BEEDLE M.Agile software development with scrum［M］.［S.1.］:［s.n.］，2002.

［8］BINDER R V.Design for testability in Object-Oriented system［J］.Communications of the ACM，2004，37(9):87-101.

［9］GAUSS D C，WEINBERG G M.探索需求:設(shè)計(jì)前的質(zhì)量［M］.北京:清華大學(xué)出版社，2004.

［10］GUPTA N，MATHUR P A，SOFFA M L.Automated test data generation using an iterative relaxation method［J］.Software Engineering Notes，1998，23(6):231-244.

［11］DOONG R K，F(xiàn)RANKL P G.The approach to testing Object-oriented programs［J］.ACM Transactions on Software Engineering and Methodology，2004(3):101-177.