基于需求變更測試模型的研究

謝 春，鄭顯舉

(成都電子機械高等專科學校 計算機工程系，成都 610071)

軟件測試是保證軟件質量的重要環節，而穩定的需求則是軟件測試的關鍵［1-2］。一個良好穩定的需求有利于開發人員和測試人員對系統進行準確的驗證和評定，確認軟件系統是否滿足用戶的需要［3］。然而實際開發過程中需求卻是經常發生變化的，EBERT［4］發現，一個為期2年的項目，會有大于30%的需求發生變更。另一方面，由于新的開發方式［5］的出現，使得需求不僅受到開發團隊和客戶的影響，組件服務提供商同樣也會導致需求的變更。顯然，處理這些頻繁而又復雜的需求變更僅靠配置管理是不夠的。因此，采用合理的開發或測試模型，并在適當的時機借助工具的支持，才能有效控制需求變更的風險。

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

1 需求變更對模塊組裝方式的影響

需求是軟件開發和測試的綱領，其變更主要來自客戶要求的變化，具體來說可以分為3種:

1)需求減少。此類需求變更相對來說較少發生，如客戶由于經費的原因縮減項目規模，減少軟件系統中的功能需求等。這種需求變更處理起來也很方便，只要屏蔽相關模塊即可。

2)需求增加。此類的需求變更有時會發生，主要是由于客戶想增加某一功能而導致需要編寫新的功能模塊。這種需求變更對整個系統而言就是增加新的功能模塊，對其它模塊來說就是重新編寫集成測試中所需要的樁模塊和驅動模塊。

3)需求改變。此類的需求變更最多，如客戶的業務流程改變會導致軟件項目中的某個邏輯序列或信息傳遞途徑的改變。對于這種需求變更而言，由于目前通常采用面向對象的開發方法，系統中對象相對穩定，所以改變的只是對象中的方法和對象之間的關系。因此，只要提高基線用例庫的可信度并選擇恰當的回歸測試包就可提高測試效率。

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

當使用自頂向下組裝方式時，遇到的問題是對應于需求變更的模塊過晚的測試，違背了最可能出現問題的部分最先測試的原則［10］。當使用自底向上組裝方式時，遇到的問題類似，前者是模塊失效，導致系統的反復回歸測試，后者則對于測試處于失控狀態，盡管測試順利，但不能說明整個系統的具體狀況。

綜上所述，可以采取以下方法加以改進:1)衍變的自頂向下的增殖方式。強化對需求變更模塊的測試，自底向上組裝成為功能比較完整且相對獨立的子系統，然后由系統主模塊開始自頂向下進行增殖測試。這種方法既避免了自頂向下增殖組裝時測試的失敗導致的反復回歸測試，又避免失去對測試過程的控制。采用這種改進后的策略，在遇到需求變更的情況時，系統的模塊會對應地變化，新變化的模塊出問題的概率相對較大(即質量風險高)，因此先加強它的測試就可以有效規避質量風險，然后再利用自頂向下組裝的優勢組裝成一個稍大的子系統，從而改進測試過程。2)基于服務的增殖方式。首先對含服務請求操作的新模塊進行自底向上直至根結點的組裝和測試，然后對含提供服務操作的新模塊做自頂向下的組裝與測試。這種方法符合面向對象消息發送的原則，更重要的是能夠簡化樁模塊的編寫工作。采用這種組裝策略，在遇到需求變更的情況時，最大的變化是對象的方法和對象間關系的改變，組裝時重點考慮對象間關系的變化，即考慮服務提供者和服務請求者之間的關系，簡化樁模塊的編寫，同時分別利用自頂向下和自底向上的優點，從而改進測試過程。

2 對于傳統模型的改進與工具的選擇

2.1 模型的改進

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

圖1 基于需求變更的測試模型

1)在設計階段進行計劃和測試設計。設計階段建立測試計劃和進行測試設計至關重要。沒有測試計劃和設計的測試過程只是驗證了程序的正確性，無法驗證整個系統本該實現的東西。V模型中驗收測試最早被定義好，并在最后執行，以驗證所交付的系統是否真正符合用戶業務的需求。相對于V模型，本測試模型還包含了對需求進行的測試，這樣可以保障對需求變更的控制。

2)測試和開發結合在一起。本模型中，測試執行和開發結合在一起形成一個迭代的過程。在普通情況下，先進行的測試是單元測試，因為這是測試人員通過測試來發現錯誤最經濟的方式。需求變更后，則可以結合需求變更采用不同的集成測試方式，并且可以跨越各個不同的測試階段靈活地進行測試。在技術測試計劃中定義好單元測試與集成測試的組裝類型，就可有效地改善軟件測試質量，提高測試效率。

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

2.2 工具的選擇

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

如果有需求管理工具能覆蓋上面這些功能，那就可以對本研究提出的需求變更測試模型進行支持。目前比較常用的需求管理工具有 Borland的 CaliberRM，IBM Rational的 RequisitePro與 ClearQuest。其中CaliberRM功能相對較全，對需求變更管理的大部分功能都有支持，但在工作產品鏈接上以及交流方面的支持相對較弱。而RequisitePro和ClearQuest相對于前兩者則功能較弱，這是因為這2個都是IBM Rational的產品，RequisitePro是一個需求管理工具，而ClearQuest是一個變更管理工具，要提供需求變更管理，需要把兩者結合使用。但是ClearQuest雖然對變更管理支持得很好，卻不是專門為需求變更所開發的，即使與RequisitePro搭配也很難針對需求的特點定制使用。總體來說，這些主流的需求管理工具都提供了對需求變更管理能力的支持，但是并沒有做到很完美，例如對于交流的支持、工作產品的鏈接查看等有待改進。

3 測試改進實例

EHR人力資源管理系統是陜西驊冠信息技術有限公司針對特定企業進行定制開發的人力資源管理系統。它由公司組織結構、員工基本信息管理、招聘管理、考勤管理、薪資管理、績效考評等模塊組成。在該系統測試的具體實施過程中，采用本文提出的基于需求變更的測試模型與CaliberRM輔助需求管理軟件。首先以需求分析為基礎編寫需求文檔，然后進行需求評審，制定測試計劃，在開發過程中，針對需求變更做出適當記錄，為以后的測試改進打下基礎(過程如圖2所示)。

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

單元測試完成后展開集成測試，模塊按照設計要求組裝起來同時進行測試，目的是發現與接口有關的問題。如數據通過接口時丟失;一個模塊與另一個模塊由于疏忽造成互相有害的影響;子功能模塊組合起來不產生預期的主功能;個別看起來可以接受的誤差積累到不能接受的程度;全程數據結構可能有錯誤等。在集成測試階段，針對需求變更的不同類型，采取合適的測試方案，在EHR人力資源管理系統中，用戶由于對績效考評方法的變更導致需求發生了變化，但是由于系統中的對象沒有發生本質的變化，所以可以采取基于服務請求方向的集成組裝測試策略。

集成測試完成后展開系統測試，從產品的角度檢驗軟件。經過這樣的測試過程后，軟件基本滿足質量要求，測試宣告結束，經驗收后將軟件提交用戶。

縱觀HER人力資源管理系統的測試，從初始階段跟蹤需求變更，將需求變更分類，在集成測試階段依據需求變更的不同類型采取恰當的集成測試策略，其間優化維護測試用例庫，并以此展開回歸測試，降低了測試工作量，改善了測試的效率，減低了測試成本，提高了軟件產品的質量。

4 結語

本文從需求變更的原因入手，通過分析軟件測試過程，詳細說明了測試系統的組織以及工程設計的原則，著重探討了集成測試中模塊組裝的策略，分析了一次性組裝和增殖組裝方式各自的優缺點，在基于需求變更控制的基礎上改進了軟件測試方法。對傳統測試模型進行了改進，形成了基于需求變更的新模型。該模型以系統需求為起點進行系統分析與設計，同時制定測試計劃;以需求變更為切入點修正測試計劃，為軟件測試活動作出具體的指導。

［1］KENNER C，FALK J.計算機軟件測試［M］.北京:機械工業出版社，2004.

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

［3］LEFFINGWELL D，WIDRIG D.軟件需求管理:用例方法［M］.北京:中國電力出版社，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］.北京:電子工業出版社，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.探索需求:設計前的質量［M］.北京:清華大學出版社，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，FRANKL P G.The approach to testing Object-oriented programs［J］.ACM Transactions on Software Engineering and Methodology，2004(3):101-177.