可靠性軟件測試介紹

    [摘要] 隨著軟件系統(tǒng)規(guī)模和復雜度日益升高，越來越多的軟件項目明確提出軟件的可靠性要求。而涉及高可靠性軟件開發(fā)的軟件企業(yè)也越來越意識到，軟件測試在這些項目開發(fā)過程中絕不是一種輔助性工作，而是從軟件質(zhì)量控制角度保證軟件工程過程質(zhì)量的Z有效方法。有鑒于此，本文以CraftGS航天項目模型為例，系統(tǒng)地介紹了一套行之有效的軟件測試方案，該方案對同類高可靠性軟件項目測試工作的開展具有一定的參考意義和指導作用。 

[關鍵詞] 高可靠性 軟件測試 軟件驗證技術 軟件確認技術 軟件測試管理 

1 引言

　　高可靠性軟件泛指一類軟件：該類軟件運行過程中若出現(xiàn)故障會引發(fā)重大災難性事故或經(jīng)濟損失。通常航天型號軟件、銀行系統(tǒng)軟件、醫(yī)療行業(yè)軟件、通訊行業(yè)軟件等均屬此范疇。目前，越來越多的軟件企業(yè)涉及高可靠性軟件項目，如何保證軟件質(zhì)量成為眾多企業(yè)面臨的一個很重要的課題。這篇文章結合某航天項目地面應用系統(tǒng)模型（本文命名為 CraftGS ），重點討論如何從軟件測試的角度保證此類產(chǎn)品的軟件質(zhì)量。 

2 CraftGS 項目簡介

　　CraftGS 是一個很經(jīng)典的衛(wèi)星地面應用系統(tǒng)模擬項目。它分為 5 個子系統(tǒng)：數(shù)據(jù)接收子系統(tǒng) (DAS) 、數(shù)據(jù)預處理子系統(tǒng) (DPS) 、運行管理子系統(tǒng) (OMS) 、數(shù)據(jù)管理子系統(tǒng) (DMS) 以及數(shù)據(jù)產(chǎn)品實現(xiàn) (DPRS) 子系統(tǒng)。 CraftGS 的總體可靠度要求是 0.95 。各分系統(tǒng)分配到的可靠度指標是如下：

　　 CraftGS 的業(yè)務邏輯是 Data Package 從衛(wèi)星傳入 DAS ， DAS 負責解包，將解包后數(shù)據(jù)傳入 OMS 及 DPS ， OMS 通過 DAS 傳來的數(shù)據(jù)檢測衛(wèi)星是否正常運行并負責衛(wèi)星飛行姿態(tài)調(diào)整； DPS 負責調(diào)制 DAS 傳來的數(shù)據(jù)，轉換成有意義的邏輯數(shù)據(jù)。 DPS 處理后的邏輯數(shù)據(jù)傳入 DMS 以及 DPRS 。其中 DMS 負責數(shù)據(jù)備份、數(shù)據(jù)查詢及數(shù)據(jù)鏈路維護等操作； DPRS 負責將 DPS 處理過的邏輯數(shù)據(jù)分門別類地轉換成數(shù)據(jù)產(chǎn)品，并封裝發(fā)布。

　　考慮到項目固有的可靠性安全性要求， CraftGS 系統(tǒng)采用 Java+Unix 技術架構實現(xiàn)。該架構從編程語言級和系統(tǒng)級對軟件產(chǎn)品質(zhì)量做了保證。為了控制軟件產(chǎn)品開發(fā)過程中的質(zhì)量，筆者推薦采用如下軟件測試方案。

　　3 測試方案：軟件驗證技術 + 軟件確認技術 + 軟件測試管理

　　CraftGS 系統(tǒng)的軟件測試方案由三個部分組成，即軟件驗證技術、軟件確認技術和軟件測試管理技術。它們內(nèi)涵及相互之間的關系如下圖所示：

　　其中，軟件驗證技術著眼于排除軟件開發(fā)文檔中的錯誤。驗證活動涉及的文檔按開發(fā)流程主要涉及需求規(guī)格說明、設計規(guī)格說明（包括概要設計規(guī)格說明、詳細設計規(guī)格說明、數(shù)據(jù)庫設計規(guī)格說明）、編碼規(guī)格說明、產(chǎn)品交付文檔等一系列書面材料。目前驗證技術的實施在很大程度上是依靠測試人員手工完成的。驗證活動視實際需要有時還會涉及到開發(fā)人員和目標客戶，需要得到他們必要的理解和支持。驗證測試采用的主要測試手段有：面對面質(zhì)詢、文檔抽查、非正式會議、同行評審等等。 
相對于軟件驗證技術，軟件確認技術則主要著眼于排除程序代碼中的錯誤。活動涉及的對象主要是程序部件的代碼或軟件成品。在實施過程中，常常按被測代碼的規(guī)模和測試所處的層次將軟件確認測試分為四個階段，即：單元測試（也叫類測試）、集成測試（也叫組裝測試）、系統(tǒng)測試和交付測試。確認測試基本上由軟件測試人員對照相關開發(fā)文檔運行程序獨立完成的。必要時，也可讓設計人員帶領測試人員閱讀程序代碼共同發(fā)現(xiàn)其中的錯誤，（即所謂代碼評審會）。有意見認為，在單元測試 ( 或類測試 ) 階段，應該有軟件編碼人員參與，這樣能減輕測試人員閱讀代碼障礙。原則上，測試理論不提倡程序作者負責把關自己編寫的程序的質(zhì)量。在實際實施過程中，可視實際情況靈活處理。（如成對編程可能會較好的處理單元測試這個難題，上面提到的代碼評審會也是為應對這個難題而想出的一個好辦法。），軟件確認技術目前已經(jīng)部分地實現(xiàn)了測試工具的自動化，市面上已有不少自動化工具能在測試人員的輔助下完成相應的測試工作（例如用于 Java 代碼單元測試的 Junit 工具，又如用于 GUI 測試的 Rational Visual Test 工具，等等）。 

　　軟件驗證技術和軟件確認技術均屬于測試技術層面的東西。然而對于工程質(zhì)量的保證而言，光靠軟件測試技術還遠遠不夠，還需要技術管理層面上的東西。軟件測試管理技術的誕生正是為彌補這個不足。按照管理的對象不同，測試管理技術大致涵蓋軟件測試團隊組織管理、軟件測試計劃管理、軟件缺陷（錯誤）跟蹤管理以及軟件測試件管理四大部分。下面，筆者將結合 CraftGS 項目對該測試方案做一個詳細的詮釋。

4 在 CraftGS 項目中具體應用上述測試方案

　　CraftGS 五個分系統(tǒng)的開發(fā)過程均在 CraftGS 測試團隊的質(zhì)量控制下有序進行，嚴格地實施了上述測試方案。經(jīng)專家評定，各分系統(tǒng)及Z后集成后的系統(tǒng)總體均達到了任務書中所分配的可靠性指標。

　　4.1 在 CraftGS 項目中應用軟件驗證技術

　　CraftGS 項目中應用的軟件驗證技術主要包括需求規(guī)格說明驗證、設計規(guī)格說明驗證、代碼驗證以及交付驗證。以下逐一說明。

　　需求規(guī)格說明驗證的主要任務是保證用戶的功能需求、業(yè)務需求、以及其他的一些需求（如非功能性需求、約束性需求等等）都已經(jīng)被分配到軟件需求規(guī)格說明的各需求項中。

　　設計規(guī)格說明驗證相對需求規(guī)格說明驗證而言，稍微復雜些，它包括 3 個部分的內(nèi)容：即概要設計規(guī)格說明驗證、詳細設計規(guī)格說明驗證以及數(shù)據(jù)庫設計規(guī)格說明驗證。其中概要設計規(guī)格說明驗證的主要任務是確保軟件需求規(guī)格說明中的需求項全部已經(jīng)分配到了概要設計規(guī)格說明的各軟件模塊之中并且無多余物，詳細設計規(guī)格說明驗證的主要任務是確保概要設計規(guī)格說明中的模塊已經(jīng)全部分配到詳細設計規(guī)格說明的各軟件單元之中并且無多余物，數(shù)據(jù)庫設計規(guī)格說明雖然從范疇上講應該屬于詳細設計規(guī)格說明范疇，但筆者認為因改把它獨立出來實施驗證活動。（數(shù)據(jù)庫設計和軟件設計畢竟有很多不同之處。）數(shù)據(jù)庫設計規(guī)格說明驗證的重點任務是驗證數(shù)據(jù)庫與外部應用程序的接口是否正確、數(shù)據(jù)操作實現(xiàn)界面是否清晰、數(shù)據(jù)庫整體設計是否合理、數(shù)據(jù)表設計是否符合 3NF 要求（如違反范式要說明詳細理由）以及數(shù)據(jù)表中的字段（鍵）和索引的設計是否合理等等。完成設計規(guī)格說明以后，下一步要做代碼驗證。

　　代碼驗證的內(nèi)容包括：代碼編寫規(guī)范審查、代碼審查和代碼靜態(tài)分析三個部分。代碼編寫規(guī)范審查主要是審核代碼排版的格式以及注解的格式是否符合開發(fā)團隊的相應規(guī)范；代碼審查的任務主要是驗證詳細設計中的軟件單元是否都已被代碼覆蓋并正確實現(xiàn)，并且代碼中不含冗余物；代碼靜態(tài)分析技術主要任務是檢查變量或標號的定義與使用、表達式運算以及程序的流程設計上是否存在缺陷或錯誤。

　　做完代碼驗證以后，軟件系統(tǒng)需要依次做單元測試、集成測試和系統(tǒng)測試，這部分內(nèi)容屬軟件確認技術范疇，下面有專門的論述。軟件系統(tǒng)在做完系統(tǒng)測試后，就面臨著交付使用的問題，在系統(tǒng)正式移交給用戶之前，還需要做交付驗證和交付測試。交付測試技術下文有專門的論述，不贅述，這里主要談交付驗證技術。交付驗證包括安裝驗證和使用驗證兩部分內(nèi)容。其中，安裝驗證的主要任務是保證程序能按照用戶手冊的提示正確安裝到目標機器上，使用驗證的主要任務是確保程序能按照用戶手冊的提示的操作正確完成某項功能或事務處理。這兩部分工作通常是由測試人員完成的，用以核實相關安裝和使用手冊是否正確無誤。

　　4.2 在 CraftGS 項目中應用軟件確認技術

　　CraftGS 中應用的軟件確認技術包括單元測試技術、集成測試技術、系統(tǒng)測試技術和交付測試技術。

　　其中單元測試的主要任務是驗證詳細設計規(guī)格說明中所劃分出來的軟件單元是否被程序編制人員用代碼形式正確地實現(xiàn)了。這里軟件單元可能是某個函數(shù)（或稱方法）也可能是某個抽象數(shù)據(jù)類型（如類、數(shù)據(jù)結構或者模板）。單元測試在實際測試當中也常常被稱為類測試（在面向對象的設計中）或白盒測試（白盒的意思是面向代碼）。單元測試的工作原理是建構樁模塊和驅動模塊以驅動被測單元運行，然后，測試人員輸入設計好的測試用例，測試被測單元能否按照設計要求處理這些測試用例，對出現(xiàn)異常的測試用例，測試人員應做記載并反饋給軟件開發(fā)團隊。

　　做完單元測試以后，下一步的工作是對照軟件概要設計規(guī)格說明，驗證各軟件單元組裝后形成模塊能否達到概要設計規(guī)格說明中模塊的設計目標；在模塊級集成工作完成之后，測試人員還應測試各模塊組裝后形成的用戶系統(tǒng)內(nèi)部存在沖突，各模塊能否正常工作。這里，模塊可能是指某個軟件部件，也可能是指某個或某幾個分系統(tǒng)。通常在做集成測試時先是從分系統(tǒng)內(nèi)部的集成測試開始做起，做完以后再測試各分系統(tǒng)是否能集成為Z終要實現(xiàn)的大系統(tǒng)。也有其他做法（如自頂向下集成測試方法、核心系統(tǒng)先做集成測試或每日集成測試等等）。總之，萬變不離其宗。集成測試要保證模塊的內(nèi)部正確性以及保證模塊能Z終集成為大系統(tǒng)。集成測試有時也被稱為組裝測試（在型號軟件中）或灰盒測試（有人認為集成測試介于白盒與黑盒之間）。 
    做完集成測試以后，下一步工作就是做系統(tǒng)測試。系統(tǒng)測試的主要任務是驗證經(jīng)集成測試后形成的軟件系統(tǒng)是否滿足軟件需求規(guī)格說明中的各需求項。這些需求項包括：業(yè)務需求、功能需求、非功能性需求（如：性能、可靠性、安全性、系統(tǒng)維護等方面的要求）以及一些約束性需求（如開發(fā)標準、編程語言、通訊協(xié)議）等等。由于需求項涉及的領域很廣泛，這就導致了系統(tǒng)測試中對應的測試門類相當龐雜。如：功能測試、執(zhí)行路徑測試、可靠性測試、壓力測試、可恢復性測試、可移植性測試等等。這些測試Z顯著的特征是在一定環(huán)境條件下（如：模擬現(xiàn)場或條件），設計各種測試用例，輸入并運行完整的軟件系統(tǒng)，根據(jù)軟件系統(tǒng)運行過程中的實際表現(xiàn)，評估軟件系統(tǒng)是否符合軟件需求項的各類要求。由于這類測試一般不涉及內(nèi)部代碼，因此，也有人把系統(tǒng)測試稱做是黑盒測試。

　　在做完系統(tǒng)測試以后，軟件產(chǎn)品就到了交付用戶使用這個階段了。交付過程中的重要一環(huán)就是交付測試，交付測試的目標是保證用戶對所交付的系統(tǒng)的滿意。與前面所討論的測試不同，交付測試主要的參與者應該是目標客戶。客戶參與越多越好。交付測試的內(nèi)容一般包括安裝測試、可用性測試、 alpha 測試、 beta 測試等。其中安裝測試的主要任務是測試軟件系統(tǒng)能否在模擬環(huán)境下或實際現(xiàn)場由目標用戶順利完成在目標機器上的安裝；可用性測試的主要任務是測試軟件系統(tǒng)在完成安裝以后能否完成用戶的模擬任務或現(xiàn)場任務； alpha 測試采用的形式一般是由一個用戶在開發(fā)環(huán)境下對軟件系統(tǒng)進行類似于黑盒的測試，測試的目的是從用戶的角度評價軟件產(chǎn)品的功能、可使用性、可靠性、性能和支持，尤其注重產(chǎn)品的界面和特色； beta 測試采用的形式一般是先由軟件的多個用戶在實際使用環(huán)境下使用 beta 版軟件系統(tǒng)一段時間，然后把使用中出現(xiàn)的各類故障或缺陷反饋給 beta 測試負責人員，再由測試負責人員移交給軟件，由開發(fā)人員負責修正并完善軟件系統(tǒng)。 Beta 測試的目的是確保軟件產(chǎn)品交付給全體用戶之前能部分或全面地修正其在實際應用中可能出現(xiàn)的各類 BUG 或不足。 
　　4.3 在 CraftGS 項目中應用軟件測試管理技術 

　　一如前文所述，測試技術解決了測試采用的方法和技術問題，然而，對于一個工程而言，還需要相應的測試管理才能保證各項測試活動的有序開展。因此，在 CraftGS 項目中，軟件測試管理技術要解決的問題是如何確保軟件測試技術（包括軟件驗證技術和軟件確認技術）能在軟件項目在軟件生命內(nèi)得到順利實施，并產(chǎn)生預期的效果。 

　　按照軟件測試管理面對的管理對象的差異，軟件測試管理技術大致分為軟件測試團隊組織管理、軟件測試計劃管理、軟件缺陷（錯誤）跟蹤管理以及軟件測試件管理四大部分。以下一一詮釋： 

　　軟件測試團隊組織管理通俗地講就是測試團隊應該如何組建。在實際項目開發(fā)中，我們常常看到有些單位忽視測試團隊存在的意義，當要實施測試時，往往臨時找?guī)讉€程序員充當測試人員；也有些單位盡管認識到了組建測試團隊的重要性，但在具體落實的時候往往安排一些毫無開發(fā)經(jīng)驗的行業(yè)新手去做測試工作，這常常導致測試效率的低下，測試人員對測試工作索然無味。 CraftGS 項目的測試團隊首先聘有一名的測試領域專家，他具有極為豐富的航天項目軟件測試經(jīng)驗，對軟件開發(fā)過程中常見的缺陷或錯誤了然于胸，此外，他還具有較好的親和力和人格魅力。其次， CraftGS 項目測試團隊還具有很多具備一技之長的成員，如對某些自動化測試工具運用嫻熟或能輕而易舉地編寫自動化測試腳本。另外，測試團隊還聘有兼職成員。如驗證測試實施過程中，同行評審是Z常使用的一種形式，這些同行專家就屬于兼職測試團隊成員的范疇。至于測試團隊里里的測試新手，這部分人可以安排去從事交付驗證或黑盒測試之類的工作。 

　　軟件測試計劃管理通俗地講就是安排好測試流程。這部分內(nèi)容具體涵蓋軟件測試策劃、軟件測試技術剪裁、測試進度管理、成本管理等幾個部分。其中測試策劃工作主要是指具體測試活動實施之前做好策劃工作，如起草測試大綱以及測試計劃；軟件測試技術剪裁工作主要是指測試團隊應根據(jù)軟件項目的具體實際剪裁出所要實施的測試技術；測試進度管理工作主要是指排出各項測試的時間進度及人員安排，如有變動時應做相應調(diào)整；測試成本管理工作的內(nèi)容即開列出測試活動中會涉及到的資源需求。 CraftGS 項目測試團隊較好地按照上述要求，完成了軟件測試計劃管理。 

　　軟件缺陷（錯誤）跟蹤管理通俗地講就是確保發(fā)現(xiàn)的缺陷（錯誤）已經(jīng)被開發(fā)團隊糾正或處理過并且沒有引入新的缺陷（錯誤）。具體來講，當測試團隊通過各種途徑發(fā)現(xiàn)了文檔或代碼中的缺陷或錯誤以后，并不是交一份測試報告就草草了事，而是在遞交報告以后繼續(xù)督促開發(fā)團隊及時關閉已知缺陷或錯誤（當然，如有必要應對這些缺陷、錯誤做嚴重程度排序，以便開發(fā)團隊能視輕重緩急安排處理順序）。當開發(fā)團隊關閉了測試報告中的缺陷（錯誤）以后，測試團隊還需驗證開發(fā)團隊在關閉過程中有沒有引入新的錯誤。通常，這個過程稱為回歸測試。回歸測試如發(fā)現(xiàn)問題，繼續(xù)報開發(fā)團組，按上述流程循環(huán)，直至回歸測試Z終通過。這部分工作在 CraftGS 項目中是使用自動化的測試管理工具完成的，（市面上可選擇的工具有 華創(chuàng)缺陷管理系統(tǒng) (BMS) 和 Rational ClearQuest 等等 ），這么做非常有效率。 

　　軟件測試件管理通俗地講就是指努力建設好測試團隊的財富庫并對測試團隊成員進行技能培訓以幫助他們能使用好這個財富庫。這里，財富庫是指軟件測試件。測試件（ Testware ，指測試工作形成的產(chǎn)品）是一個不常見到的詞匯，它包括是測試團隊在長期實踐過程中逐步積累起來的經(jīng)驗教訓、測試技巧、測試工具、規(guī)格文檔以及一些經(jīng)過少量修改能推廣至通用的測試腳本程序。測試件管理工作做得越好，測試團隊在實際測試過程中就能越少走彎路，測試團隊內(nèi)部的知識交流和傳遞就越充分，測試腳本或規(guī)格文檔的重復開發(fā)工作也就能被有效地避免。軟件測試件管理工作包括兩部分，一是建設，另一個是培訓。建設工作大抵是收集各類測試外文檔、測試工具、測試腳本，也包括收集整理測試人員的會議發(fā)言、總結報告、技術心得等等。培訓工作大抵是通過技術講座、正式或非正式團隊會議、印發(fā)學習資料等形式進行。 CraftGS 項目組考慮到測試團隊的長久發(fā)展，較好地完成了測試件管理，測試團隊成員的技能水平在較短的時間內(nèi)都有了非常迅速的進步。 

5 結語：高可靠性軟件測試技術需要更多關注