測試驅動開發在星載軟件開發中的應用

【文章摘要】

本文介紹了一種測試驅動開發的軟件開發方法，在設計測試用例的基礎上完成軟件設計實現的過程，繼而通過重構代碼來優化軟件，分析了這種方法的優缺點，結合星載軟件開發的工程要求，在傳統瀑布模型中加入測試驅動方法，用結對編程和完善測試環節的方法彌補測試驅動開發的缺點，在工程實踐中取得了提高程序編寫質量和減少開發時間的效果。

【關鍵詞】

測試驅動開發；結對編程；星載軟件

1 概述

自20世紀60年代以來，人們發現了“軟件危機”帶來的巨大危害，于是在軟件工程領域做了大量研究工作，逐漸形成了一整套軟件生命周期的開發理論，隨著軟件規模越來越大，項目周期縮短，而用戶的需求快速變換，傳統的開發方法已不能適應軟件開發的需要，而測試驅動開發（簡稱TDD），是一種不同于傳統軟件開發流程的新型的開發方法。它要求在編寫某個功能的代碼之前先編寫測試代碼，然后只編寫使測試通過的功能代碼，通過測試來推動整個開發的進行。這有助于編寫簡潔可用和高質量的代碼，并加速開發過程。

2 測試驅動方法的優缺點分析

2.1 測試驅動的優點

測試驅動開發相對于傳統的軟件開發方式，具有以下特點：

1）測試驅動開發根據客戶需求編寫測試用例，對功能的過程和接口都進行了設計，而且這種從使用者角度對代碼進行的設計通常更符合后期開發的需求。因為關注用戶反饋，可以及時響應需求變更，同時因為從使用者角度出發的簡單設計，也可以更快地適應變化；

2）出于易測試和測試獨立性的要求，測試驅動開發促使開發者實現松耦合的設計，并更多地依賴于接口而非具體的類，提高系統的可擴展性和抗變性，從而明顯地縮短了設計決策的反饋循環；

3）測試驅動開發將測試工作提到編碼之前，并頻繁地運行所有測試，可以盡量地避免和盡早地發現錯誤，降低了后續測試及修復的成本，提高了代碼的質量。在測試的保護下，不斷重構代碼，以消除重復設計，優化設計結構，提高了代碼的重用性，從而提高了軟件產品的質量；

4）測試驅動開發提供了持續的回歸測試，便于開發者對代碼進行重構，因為代碼的改動導致系統其他部分產生任何異常，測試都會立刻通知我們。完整的測試會幫助我們持續地跟蹤整個系統的狀態，因此可以避免一些軟件潛通路問題；

5）系統可以與詳細的測試集一起發布，從而對程序將來版本的更改和擴展提供方便；

6）由于編寫測試用例和代碼過程上統一，降低了測試人員理解代碼所花費的成本。

2.2 測試驅動存在的問題

根據已采用測試驅動開發的人員評價，測試驅動方法也存在以下問題：

1）開發者可能只完成滿足了測試的代碼，而忽略了對實際需求的實現；

2）會放慢開發實際代碼的速度，特別對于要求開發速度的原型開發造成不利；

3）對于圖形化用戶界面（GUI）、資料庫和Web應用而言。構造單元測試比較困難，如果強行構造單元測試，反而給維護帶來額外的工作量；

4）使得開發更為關注測試用例，而不是設計本身；

5）單純的測試驅動開發會導致單元測試的覆蓋度不夠，比如可能缺乏邊界測試。

3 某星載管理軟件開發過程

3.1 測試驅動思想的引入和改進

針對測試驅動開發方法的優缺點，根據航天嵌入式軟件開發的行業要求，在充分繼承航天軟件原有V型瀑布模型開發模式的基礎上，不改變原來開發模式的主體結構，在軟件需求分析階段引入測試驅動開發的思想，提前到需求階段就同步開展測試用例和測試計劃的編制工作，由面向用戶的系統分析員直接設計測試用例。由于星載嵌入式軟件對于軟件可靠性要求較高，因此在開發測試過程中，在代碼完成后還是需要補充單元測試和組裝測試，以保證測試的覆蓋性，單元測試用例要覆蓋詳細設計中描述的每個子程序，語句覆蓋率、分支覆蓋率均要達到100%，加強對邊界點的測試以及邊界外的測試。

軟件開發組采用雙人雙崗制，用結對編程的方式彌補測試驅動開發可能忽略實際需求的不足之處，在兩人結對編程中，一個人負責輸入代碼，稱為“駕駛員”，另一個人負責審查代碼，稱為“觀察員”，在同一個軟件開發過程中，兩者的角色可以經常互換，觀察員主要考慮工作的戰略性方向，提出改進的意見，或將來可能出現的問題以便處理，而駕駛員專注于當前任務的“戰術層面”，兩人的協調工作則帶來紀律和時間管理的提升。

在操作層面上，觀察者編寫可能導致當前程序出錯的測試用例，駕駛者修改代碼以通過該用例，觀察者編寫新的測試用例，以此類推。這個循環持續到觀察者不能寫出失敗的測試用例。顯然，結對編程要花較多的時間，但航天軟件研制周期相對較長，可靠性要求較高，因而采用這種方式進行補充是合理的。

3.2 項目策劃和需求分析

在某試驗衛星中，需要搭載一臺國產SM1750計算機驗證國產元器件及軟件的工作情況，這類軟件屬于嵌入式實時軟件，規模估計在4000行左右的小型軟件，開發團隊共4人，設置項目經理1人，開發人員2人（結對編程，互相測試），質量過程管理人員1人。

3.3 測試用例設計

項目經理在需求分析的同時，也針對性地設計出各個需求項對應的測試用例，用自然語言來描述。

如CAN數據接收的功能，項目經理無需考慮軟件如何實現，參考用戶給出的協議，編制若干組數據，這些數據一部分是符合協議的，也包括一些雜亂無意義的數據。對應前述各功能項，項目經理設計測試用例，選取典型的測試用例，見表3：

顯然，項目經理是站在用戶的角度設計出上述測試的，如果測試能夠通過，也就能滿足用戶將來驗收時的要求，至于三個性能需求，是用戶提出的強制性的約束條件，但都是可以通過儀器或代碼走查驗證的，項目經理如果發現生成的目標代碼有任何一條性能指標不滿足要求，即要求開發人員通過優化設計來重構代碼。

4 采用測試驅動開發的效果

以往航天型號軟件的研制流程是基于體系結構驅動，先做設計，再做測試。設計是根據需求導出，有時會偏離用戶需求，在實際工程中，用戶也會經常改變已有需求，會新增需求，也會廢棄已有的需求，每次更改代碼都帶來巨大的工作量和風險。而在這個項目中采用了測試驅動開發方式后，對照以前未采用測試驅動開發的同等軟件，在縮短軟件開發周期和減少軟件潛在缺陷方面取得了一定進展

【參考文獻】

[1]劉赟.測試驅動開發探討[J].電腦開發與應用，2006年，第19卷第8期：P12-16

【作者簡介】

朱琦，1978年生，男，漢族，浙江紹興，上海航天技術研究院工作，工程師，主要研究為嵌入式軟件開發。