高可靠性軟體測試方案探讨

高可靠性軟體測試方案探讨

作者：戴金龍    文章來源：codesky

[摘要] 随着軟體系統規模和複雜度日益升高，越來越多的軟體項目明确提出軟體的可靠性要求。而涉及高可靠性軟體開發的軟體企業也越來越意識到，軟體測試在這些項目開發過程中絕不是一種輔助性工作，而是從軟體品質控制角度保證軟體工程過程品質的最有效方法。有鑒于此，本文以CraftGS航天項目模型為例，系統地介紹了一套行之有效的軟體測試方案，該方案對同類高可靠性軟體項目測試工作的開展具有一定的參考意義和指導作用。 　　[關鍵詞] 高可靠性 軟體測試 軟體驗證技術 軟體确認技術 軟體測試管理 　　1 引言 　　高可靠性軟體泛指一類軟體：該類軟體運作過程中若出現故障會引發重大災難性事故或經濟損失。通常航天型号軟體、銀行系統軟體、醫療行業軟體、通訊行業軟體等均屬此範疇。目前，越來越多的軟體企業涉及高可靠性軟體項目，如何保證軟體品質成為衆多企業面臨的一個很重要的課題。這篇文章結合某航天項目地面應用系統模型（本文命名為 CraftGS ），重點讨論如何從軟體測試的角度保證此類産品的軟體品質。 　　2 CraftGS 項目簡介 　　CraftGS 是一個很經典的衛星地面應用系統模拟項目。它分為 5 個子系統：資料接收子系統 (DAS) 、資料預處理子系統 (DPS) 、運作管理子系統 (OMS) 、資料管理子系統 (DMS) 以及資料産品實作 (DPRS) 子系統。 CraftGS 的總體可靠度要求是 0.95 。各分系統配置設定到的可靠度名額是如下： 分系統名 可靠度名額 DAS 0.99994 DPS 0.99865 OMS 0.99910 DMS 0.99950 DPRS 0.99502 　　CraftGS 的業務邏輯是 Data Package 從衛星傳入 DAS ， DAS 負責解包，将解包後資料傳入 OMS 及 DPS ， OMS 通過 DAS 傳來的資料檢測衛星是否正常運作并負責衛星飛行姿态調整； DPS 負責調制 DAS 傳來的資料，轉換成有意義的邏輯資料。 DPS 處理後的邏輯資料傳入 DMS 以及 DPRS 。其中 DMS 負責資料備份、資料查詢及資料鍊路維護等操作； DPRS 負責将 DPS 處理過的邏輯資料分門别類地轉換成資料産品，并封裝釋出。 　　考慮到項目固有的可靠性安全性要求， CraftGS 系統采用 Java+Unix 技術架構實作。該架構從程式設計語言級和系統級對軟體産品品質做了保證。為了控制軟體産品開發過程中的品質，筆者推薦采用如下軟體測試方案。 　　3 測試方案：軟體驗證技術 + 軟體确認技術 + 軟體測試管理 　　CraftGS 系統的軟體測試方案由三個部分組成，即軟體驗證技術、軟體确認技術和軟體測試管理技術。它們内涵及互相之間的關系如下圖所示： CraftGS 測試方案 測試技術層面 測試管理層面 軟體驗證技術 需求規格說明驗證 軟體測試團隊組織管理 設計規格說明驗證 代碼驗證 軟體測試計劃管理 傳遞驗證 軟體确認技術 單元測試 軟體缺陷（錯誤）跟蹤管理 內建測試 系統測試 軟體測試件管理 傳遞測試 　　其中，軟體驗證技術着眼于排除軟體開發文檔中的錯誤。驗證活動涉及的文檔按開發流程主要涉及需求規格說明、設計規格說明（包括概要設計規格說明、詳細設計規格說明、資料庫設計規格說明）、編碼規格說明、産品傳遞文檔等一系列書面材料。目前驗證技術的實施在很大程度上是依靠測試人員手工完成的。驗證活動視實際需要有時還會涉及到開發人員和目标客戶，需要得到他們必要的了解和支援。驗證測試采用的主要測試手段有：面對面質詢、文檔抽查、非正式會議、同行評審等等。 　　相對于軟體驗證技術，軟體确認技術則主要着眼于排除程式代碼中的錯誤。活動涉及的對象主要是程式部件的代碼或軟體成品。在實施過程中，常常按被測代碼的規模和測試所處的層次将軟體确認測試分為四個階段，即：單元測試（也叫類測試）、內建測試（也叫組裝測試）、系統測試和傳遞測試。确認測試基本上由軟體測試人員對照相關開發文檔運作程式獨立完成的。必要時，也可讓設計人員帶領測試人員閱讀程式代碼共同發現其中的錯誤，（即所謂代碼評審會）。有意見認為，在單元測試 ( 或類測試 ) 階段，應該有軟體編碼人員參與，這樣能減輕測試人員閱讀代碼障礙。原則上，測試理論不提倡程式作者負責把關自己編寫的程式的品質。在實際實施過程中，可視實際情況靈活處理。（如成對程式設計可能會較好的處理單元測試這個難題，上面提到的代碼評審會也是為應對這個難題而想出的一個好辦法。），軟體确認技術目前已經部分地實作了測試工具的自動化，市面上已有不少自動化工具能在測試人員的輔助下完成相應的測試工作（例如用于 Java 代碼單元測試的 Junit 工具，又如用于 GUI 測試的 Rational Visual Test 工具，等等）。 　　軟體驗證技術和軟體确認技術均屬于測試技術層面的東西。然而對于工程品質的保證而言，光靠軟體測試技術還遠遠不夠，還需要技術管理層面上的東西。軟體測試管理技術的誕生正是為彌補這個不足。按照管理的對象不同，測試管理技術大緻涵蓋軟體測試團隊組織管理、軟體測試計劃管理、軟體缺陷（錯誤）跟蹤管理以及軟體測試件管理四大部分。下面，筆者将結合 CraftGS 項目對該測試方案做一個詳細的诠釋。 　　4 在 CraftGS 項目中具體應用上述測試方案 　　CraftGS 五個分系統的開發過程均在 CraftGS 測試團隊的品質控制下有序進行，嚴格地實施了上述測試方案。經專家評定，各分系統及最後內建後的系統總體均達到了任務書中所配置設定的可靠性名額。 　　4.1 在 CraftGS 項目中應用軟體驗證技術 　　CraftGS 項目中應用的軟體驗證技術主要包括需求規格說明驗證、設計規格說明驗證、代碼驗證以及傳遞驗證。以下逐一說明。 　　需求規格說明驗證的主要任務是保證使用者的功能需求、業務需求、以及其他的一些需求（如非功能性需求、限制性需求等等）都已經被配置設定到軟體需求規格說明的各需求項中。 　　設計規格說明驗證相對需求規格說明驗證而言，稍微複雜些，它包括 3 個部分的内容：即概要設計規格說明驗證、詳細設計規格說明驗證以及資料庫設計規格說明驗證。其中概要設計規格說明驗證的主要任務是確定軟體需求規格說明中的需求項全部已經配置設定到了概要設計規格說明的各軟體子產品之中并且無多餘物，詳細設計規格說明驗證的主要任務是確定概要設計規格說明中的子產品已經全部配置設定到詳細設計規格說明的各軟體單元之中并且無多餘物，資料庫設計規格說明雖然從範疇上講應該屬于詳細設計規格說明範疇，但筆者認為因改把它獨立出來實施驗證活動。（資料庫設計和軟體設計畢竟有很多不同之處。）資料庫設計規格說明驗證的重點任務是驗證資料庫與外部應用程式的接口是否正确、資料操作實作界面是否清晰、資料庫整體設計是否合理、資料表設計是否符合 3NF 要求（如違反範式要說明詳細理由）以及資料表中的字段（鍵）和索引的設計是否高效合理等等。完成設計規格說明以後，下一步要做代碼驗證。 　　代碼驗證的内容包括：代碼編寫規範審查、代碼審查和代碼靜态分析三個部分。代碼編寫規範審查主要是稽核代碼排版的格式以及注解的格式是否符合開發團隊的相應規範；代碼審查的任務主要是驗證詳細設計中的軟體單元是否都已被代碼覆寫并正确實作，并且代碼中不含備援物；代碼靜态分析技術主要任務是檢查變量或标号的定義與使用、表達式運算以及程式的流程設計上是否存在缺陷或錯誤。 　　做完代碼驗證以後，軟體系統需要依次做單元測試、內建測試和系統測試，這部分内容屬軟體确認技術範疇，下面有專門的論述。軟體系統在做完系統測試後，就面臨着傳遞使用的問題，在系統正式移交給使用者之前，還需要做傳遞驗證和傳遞測試。傳遞測試技術下文有專門的論述，不贅述，這裡主要談傳遞驗證技術。傳遞驗證包括安裝驗證和使用驗證兩部分内容。其中，安裝驗證的主要任務是保證程式能按照使用者手冊的提示正确安裝到目标機器上，使用驗證的主要任務是確定程式能按照使用者手冊的提示的操作正确完成某項功能或事務處理。這兩部分工作通常是由測試人員完成的，用以核實相關安裝和使用手冊是否正确無誤。 　　4.2 在 CraftGS 項目中應用軟體确認技術 　　CraftGS 中應用的軟體确認技術包括單元測試技術、內建測試技術、系統測試技術和傳遞測試技術。 　　其中單元測試的主要任務是驗證詳細設計規格說明中所劃分出來的軟體單元是否被程式編制人員用代碼形式正确地實作了。這裡軟體單元可能是某個函數（或稱方法）也可能是某個抽象資料類型（如類、資料結構或者模闆）。單元測試在實際測試當中也常常被稱為類測試（在面向對象的設計中）或白盒測試（白盒的意思是面向代碼）。單元測試的工作原理是建構樁子產品和驅動子產品以驅動被測單元運作，然後，測試人員輸入設計好的測試用例，測試被測單元能否按照設計要求處理這些測試用例，對出現異常的測試用例，測試人員應做記載并回報給軟體開發團隊。 　　做完單元測試以後，下一步的工作是對照軟體概要設計規格說明，驗證各軟體單元組裝後形成子產品能否達到概要設計規格說明中子產品的設計目标；在子產品級內建工作完成之後，測試人員還應測試各子產品組裝後形成的使用者系統内部存在沖突，各子產品能否正常工作。這裡，子產品可能是指某個軟體部件，也可能是指某個或某幾個分系統。通常在做內建測試時先是從分系統内部的內建測試開始做起，做完以後再測試各分系統是否能內建為最終要實作的大系統。也有其他做法（如自頂向下內建測試方法、核心系統先做內建測試或每日內建測試等等）。總之，萬變不離其宗。內建測試要保證子產品的内部正确性以及保證子產品能最終內建為大系統。內建測試有時也被稱為組裝測試（在型号軟體中）或灰盒測試（有人認為內建測試介于白盒與黑盒之間）。 　　做完內建測試以後，下一步工作就是做系統測試。系統測試的主要任務是驗證經內建測試後形成的軟體系統是否滿足軟體需求規格說明中的各需求項。這些需求項包括：業務需求、功能需求、非功能性需求（如：性能、可靠性、安全性、系統維護等方面的要求）以及一些限制性需求（如開發标準、程式設計語言、通訊協定）等等。由于需求項涉及的領域很廣泛，這就導緻了系統測試中對應的測試門類相當龐雜。如：功能測試、執行路徑測試、可靠性測試、壓力測試、可恢複性測試、可移植性測試等等。這些測試最顯著的特征是在一定環境條件下（如：模拟現場或極端條件），設計各種測試用例，輸入并運作完整的軟體系統，根據軟體系統運作過程中的實際表現，評估軟體系統是否符合軟體需求項的各類要求。由于這類測試一般不涉及内部代碼，是以，也有人把系統測試稱做是黑盒測試。 　　在做完系統測試以後，軟體産品就到了傳遞使用者使用這個階段了。傳遞過程中的重要一環就是傳遞測試，傳遞測試的目标是保證使用者對所傳遞的系統的滿意。與前面所讨論的測試不同，傳遞測試主要的參與者應該是目标客戶。客戶參與越多越好。傳遞測試的内容一般包括安裝測試、可用性測試、 alpha 測試、 beta 測試等。其中安裝測試的主要任務是測試軟體系統能否在模拟環境下或實際現場由目标使用者順利完成在目标機器上的安裝；可用性測試的主要任務是測試軟體系統在完成安裝以後能否完成使用者的模拟任務或現場任務； alpha 測試采用的形式一般是由一個使用者在開發環境下對軟體系統進行類似于黑盒的測試，測試的目的是從使用者的角度評價軟體産品的功能、可使用性、可靠性、性能和支援，尤其注重産品的界面和特色； beta 測試采用的形式一般是先由軟體的多個使用者在實際使用環境下使用 beta 版軟體系統一段時間，然後把使用中出現的各類故障或缺陷回報給 beta 測試負責人員，再由測試負責人員移交給軟體開發者，由開發人員負責修正并完善軟體系統。 Beta 測試的目的是確定軟體産品傳遞給全體使用者之前能部分或全面地修正其在實際應用中可能出現的各類 BUG 或不足。 　　4.3 在 CraftGS 項目中應用軟體測試管理技術 　　一如前文所述，測試技術解決了測試采用的方法和技術問題，然而，對于一個工程而言，還需要相應的測試管理才能保證各項測試活動的有序開展。是以，在 CraftGS 項目中，軟體測試管理技術要解決的問題是如何確定軟體測試技術（包括軟體驗證技術和軟體确認技術）能在軟體項目在軟體生命内得到順利實施，并産生預期的效果。 　　按照軟體測試管理面對的管理對象的差異，軟體測試管理技術大緻分為軟體測試團隊組織管理、軟體測試計劃管理、軟體缺陷（錯誤）跟蹤管理以及軟體測試件管理四大部分。以下一一诠釋： 　　軟體測試團隊組織管理通俗地講就是測試團隊應該如何組建。在實際項目開發中，我們常常看到有些機關忽視測試團隊存在的意義，當要實施測試時，往往臨時找幾個程式員充當測試人員；也有些機關盡管認識到了組建測試團隊的重要性，但在具體落實的時候往往安排一些毫無開發經驗的行業新手去做測試工作，這常常導緻測試效率的低下，測試人員對測試工作索然無味。 CraftGS 項目的測試團隊首先聘有一名資深的測試領域專家，他具有極為豐富的航天項目軟體測試經驗，對軟體開發過程中常見的缺陷或錯誤了然于胸，此外，他還具有較好的親和力和人格魅力。其次， CraftGS 項目測試團隊還具有很多具備一技之長的成員，如對某些自動化測試工具運用娴熟或能輕而易舉地編寫自動化測試腳本。另外，測試團隊還聘有兼職成員。如驗證測試實施過程中，同行評審是最常使用的一種形式，這些同行專家就屬于兼職測試團隊成員的範疇。至于測試團隊裡裡的測試新手，這部分人可以安排去從事傳遞驗證或黑盒測試之類的工作。 　　軟體測試計劃管理通俗地講就是安排好測試流程。這部分内容具體涵蓋軟體測試策劃、軟體測試技術剪裁、測試進度管理、成本管理等幾個部分。其中測試策劃工作主要是指具體測試活動實施之前做好策劃工作，如起草測試大綱以及測試計劃；軟體測試技術剪裁工作主要是指測試團隊應根據軟體項目的具體實際剪裁出所要實施的測試技術；測試進度管理工作主要是指排出各項測試的時間進度及人員安排，如有變動時應做相應調整；測試成本管理工作的内容即開列出測試活動中會涉及到的資源需求。 CraftGS 項目測試團隊較好地按照上述要求，完成了軟體測試計劃管理。 　　軟體缺陷（錯誤）跟蹤管理通俗地講就是確定發現的缺陷（錯誤）已經被開發團隊糾正或處理過并且沒有引入新的缺陷（錯誤）。具體來講，當測試團隊通過各種途徑發現了文檔或代碼中的缺陷或錯誤以後，并不是交一份測試報告就草草了事，而是在遞交報告以後繼續督促開發團隊及時關閉已知缺陷或錯誤（當然，如有必要應對這些缺陷、錯誤做嚴重程度排序，以便開發團隊能視輕重緩急安排處理順序）。當開發團隊關閉了測試報告中的缺陷（錯誤）以後，測試團隊還需驗證開發團隊在關閉過程中有沒有引入新的錯誤。通常，這個過程稱為回歸測試。回歸測試如發現問題，繼續報開發團組，按上述流程循環，直至回歸測試最終通過。這部分工作在 CraftGS 項目中是使用自動化的測試管理工具完成的，（市面上可選擇的工具有 華創缺陷管理系統 (BMS) 和 Rational ClearQuest 等等 ），這麼做非常有效率。 　　軟體測試件管理通俗地講就是指努力建設好測試團隊的财富庫并對測試團隊成員進行技能教育訓練以幫助他們能使用好這個财富庫。這裡，财富庫是指軟體測試件。測試件（ Testware ，指測試工作形成的産品）是一個不常見到的詞彙，它包括是測試團隊在長期實踐過程中逐漸積累起來的經驗教訓、測試技巧、測試工具、規格文檔以及一些經過少量修改能推廣至通用的測試腳本程式。測試件管理工作做得越好，測試團隊在實際測試過程中就能越少走彎路，測試團隊内部的知識交流和傳遞就越充分，測試腳本或規格文檔的重複開發工作也就能被有效地避免。軟體測試件管理工作包括兩部分，一是建設，另一個是教育訓練。建設工作大抵是收集各類測試外文檔、測試工具、測試腳本，也包括收集整理測試人員的會議發言、總結報告、技術心得等等。教育訓練工作大抵是通過技術講座、正式或非正式團隊會議、印發學習資料等形式進行。 CraftGS 項目組考慮到測試團隊的長久發展，較好地完成了測試件管理，測試團隊成員的技能水準在較短的時間内都有了非常迅速的進步。 　　5 結語：高可靠性軟體測試技術需要更多關注 　　以上筆者結合 CraftGS 項目對從測試技術和測試管理的角度對高可靠性軟體測試方案一個略粗淺的探讨。筆者希望此文的發表能對相關軟體企業和軟體項目實施軟體測試技術起一定的參考和指導作用。需要說明的是目前對高可靠性軟體如何實施軟體測試技術仍是一個頗不成熟的領域，缺少一種體系化的方法。各個企業可能都有一定的經驗積累，不妨整理出來，互相借鑒。這裡，筆者所做的探讨雖然已經竭盡所能，但卻不能保證一定能照搬照抄到所有的高可靠性軟體項目的測試之中。希望該領域的學者和技術專家共同努力、不斷摸索，逐漸完善這一課題。 　　參考文獻： 　　[1] Glenford J.Myers.The Art of Software Testing.NewYork:John wiley Press,1979.127-170. 　　[2] Bill Hetzel.The complete Guide to Software Testing.2,NewYork:John Wilely Press,1988.137-190. 　　[3] Edward Kit. Software Testing in the Real World. London:Pearson Education,1995.45-88. 　　[4] Daniel J.Mosely,Bruce A.posey.Just Enough Software Test Automation..NewYork:Pearson Education,2002.87-91. 　　[5] Paul C.Jorgensen. Software Testing -A Craftsman's Approach. 2,Florida:CRC Press,2002.260-296. 　　[6] 許勝，支定镛等 . 航天軟體工程實施技術指南及範例 . 北京 : 航天 5 院， 2003.