軟件管理項目中的測試管理

作爲軟件開發的重要環節，軟件測試越來越受到人們的重視。隨着軟件開發規模的增大、複雜程度的增加，以尋找軟件中的錯誤爲目的的測試工作就顯得更加困難。然而，爲了儘可能多地找出程序中的錯誤，生產出高質量的軟件產品，加強對測試工作的組織和管理就顯得尤爲重要。

 

從軟件的生存週期看，測試往往指對程序的測試，這樣做的優點是被測對象明確，測試的可操作性相對較強。但是，由於測試的依據是規格說明書、設計文檔和使用說明書，如果設計有錯誤，測試的質量就難以保證。即使測試後發現是設計的錯誤，這時，修改的代價是相當昂貴的。因此，較理想的做法應該是對軟件的開發過程，按軟件工程各階段形成的結果，分別進行嚴格的審查。

 

    爲了確保軟件的質量，對圖1的過程應進行嚴格的管理。雖然測試是在實現且經驗證後進行的，實際上，測試的準備工作在分析和設計階段就開始了。

 

1．測試的過程及組織

    當設計工作完成以後，就應該着手測試的準備工作了，一般來講，由一位對整個系統設計熟悉的設計人員編寫測試大綱，明確測試的內容和測試通過的準則，設計完整合理的測試用例，以便系統實現後進行全面測試。

 

在實現組將所開發的程序經驗證後，提交測試組，由測試負責人組織測試，測試一般可按下列方式組織：

(1)首先，測試人員要仔細閱讀有關資料，包括規格說明、設計文檔、使用說明書及在設計過程中形成的測試大綱、測試內容及測試的通過準則，全面熟悉系統，編寫測試計劃，設計測試用例，作好測試前的準備工作。

(2)爲了保證測試的質量，將測試過程分成幾個階段，即：代碼審查、單元測試、集成測試和驗收測試。

(3)代碼會審：代碼會審是由一組人通過閱讀、討論和爭議對程序進行靜態分析的過程。會審小組由組長，2～3名程序設計和測試人員及程序員組成。會審小組在充分閱讀待審程序文本、控制流程圖及有關要求、規範等文件基礎上，召開代碼會審會，程序員逐句講解程序的邏輯，並展開熱烈的討論甚至爭議，以揭示錯誤的關鍵所在。實踐表明，程序員在講解過程中能發現許多自己原來沒有發現的錯誤，而討論和爭議則進一步促使了問題的暴露。例如，對某個局部性小問題修改方法的討論，可能發現與之有牽連的甚至能涉及到模塊的功說明、模塊間接口和系統總結構的大問題，導致對需求定義的重定義、重設計驗證，大大改善了軟件的質量。

(4)單元測試：單元測試集中在檢查軟件設計的最小單位—模塊上，通過測試發現實現該模塊的實際功能與定義該模塊的功能說明不符合的情況，以及編碼的錯誤。由於模塊規模小、功能單一、邏輯簡單，測試人員有可能通過模塊說明書和源程序，清楚地瞭解該模塊的I/O條件和模塊的邏輯結構，採用結構測試（白盒法）的用例，儘可能達到徹底測試，然後輔之以功能測試（黑盒法）的用例，使之對任何合理和不合理的輸入都能鑑別和響應。高可靠性的模塊是組成可靠系統的堅實基礎。

(5)集成測試：集成測試是將模塊按照設計要求組裝起來同時進行測試，主要目標是發現與接口有關的問題。如數據穿過接口時可能丟失；一個模塊與另一個模塊可能有由於疏忽的問題而造成有害影響；把子功能組合起來可能不產生預期的主功能；個別看起來是可以接受的誤差可能積累到不能接受的程度；全程數據結構可能有錯誤等。

(6)驗收測試：驗收測試的目的是向未來的用戶表明系統能夠像預定要求那樣工作。經集成測試後，已經按照設計把所有的模塊組裝成一個完整的軟件系統，接口錯誤也已經基本排除了，接着就應該進一步驗證軟件的有效性，這就是驗收測試的任務，即軟件的功能和性能如同用戶所合理期待的那樣。

    經過上述的測試過程對軟件進行測試後，軟件基本滿足開發的要求，測試宣告結束，經驗收後，將軟件提交用戶。

 

2．測試方法的應用

集成測試及其後的測試階段，一般採用黑盒方法。其策略包括：

(1)用邊值分析法和（或）等價分類法提出基本的測試用例；

(2)用猜測法補充新的測試用例；

(3)如果在程序的功能說明中含有輸入條件的組合，宜在一開始就用因果圖法，然後再按以上1、2兩步進行。

    單元測試的設計策略稍有不同。因爲在爲模塊設計程序用例時，可以直接參考模塊的源程序。所以單元測試的策略，總是把白盒法和黑盒法結合運用。具體做法有兩種：

a、先仿照上述步驟用黑盒法提出一組基本的測試用例，然後用白盒法作驗證。如果發現用黑盒法產生的測試用例未能滿足所需的覆蓋標準，就用白盒法增補新的測試用例來滿足它們。覆蓋的標準應該根據模塊的具體情況確定。對可靠性要求較高的模塊，通常要滿足條件組合覆蓋或路徑覆蓋標準。
b、先用白盒法分析模塊的邏輯結構，提出一批測試用例，然後根據模塊的功能用黑盒法進行補充。

 

3．測試的人員組織

    爲了保證軟件的開發質量，軟件測試應貫穿於軟件定義與開發的整個過程。因此，對分析、設計和實現等各階段所得到的結果，包括需求規格說明、設計規格說明及源程序都應進行軟件測試。基於此，測試人員的組織也應是分階段的。

(1)軟件的設計和實現都是基於需求分析規格說明進行的。需求分析規格說明是否完整、正確、清晰是軟件開發成敗的關鍵。爲了保證需求定義的質量，應對其進行嚴格的審查。審查小組由下列人員組成：
組長：1人
成員：包括系統分析員，軟件開發管理者，軟件設計、開發和測試人員和用戶

(2)設計評審：軟件設計是將軟件需求轉換成軟件表示的過程。主要描繪出系統結構、詳細的處理過程和數據庫模式。按照需求的規格說明對系統結構的合理性、處理過程的正確性進行評價，同時利用關係數據庫的規範化理論對數據庫模式進行審查。評審小組由下列人員組成：
組長：1人
成員：包括系統分析員、軟件設計人員、測試負責人員各一人。

(3)程序的測試：軟件測試。是整個軟件開發過程中交付用戶使用前的最後階段，是軟件質量保證的關鍵。軟件測試在軟件生存週期中橫跨兩個階段：通常在編寫出每一個模塊之後，就對它進行必要的測試（稱爲單元測試）。編碼與單元測試屬於軟件生存週期中的同一階段。該階段的測試工作，由編程組內部人員進行交叉測試（避免編程人員測試自己的程序）。這一階段結束後，進入軟件生存週期的測試階段，對軟件系統進行各種綜合測試。測試工作由專門的測試組完成，測試組設組長一名，負責整個測試的計劃、組織工作。測試組的其他成員由具有一定的分析、設計和編程經驗的專業人員組成，人數根據具體情況可多可少，一般3～5人爲宜。

 

4．軟件測試文件
    軟件測試文件描述要執行的軟件測試及測試的結果。由於軟件測試是一個很複雜的過程，同時也是設計軟件開發其它一些階段的工作，對於保證軟件的質量和它的運行有着重要意義，必須把對它們的要求、過程及測試結果以正式的文件形式寫出。測試文件的編寫是測試工作規範化的一個組成部分。
測試文件不只在測試階段才考慮，它在軟件開發的需求分析階段就開始着手，因爲測試文件與用戶有着密切的關係。在設計階段的一些設計方案也應在測試文件中得到反映，以利於設計的檢驗。測試文件對於測試階段工作的指導與評價作用更是非常明顯的。需要特別指出的是，在已開發的軟件投入運行的維護階段，常常還要進行再測試或迴歸測試，這時仍須用到測試文件。

(1)測試文件的類型：根據測試文件所起的作用不同，通常把測試文件分成兩類，即測試計劃和測試分析報告。測試計劃詳細規定測試的要求，包括測試的目的和內容、方法和步驟，以及測試的準則等。由於要測試的內容可能涉及到軟件的需求和軟件的設計，因此必須及早開始測試計劃的編寫工作。不應在着手測試時，纔開始考慮測試計劃。通常，測試計劃的編寫從需求分析階段開始，到軟件設計階段結束時完成。測試報告用來對測試結果的分析說明，經過測試後，證實了軟件具有的能力，以及它的缺陷和限制，並給出評價的結論性意見，這些意見即是對軟件質量的評價，又是決定該軟件能否交付用戶使用的依據。由於要反映測試工作的情況，自然要在測試階段內編寫。

(2)測試文件的使用：測試文件的重要性表現在以下幾個方面：

a、驗證需求的正確性：測試文件中規定了用以驗證軟件需求的測試條件，研究這些測試條件對弄清用戶需求的意圖是十分有益的。

b、檢驗測試資源：測試計劃不僅要用文件的形式把測試過程規定下來，還應說明測試工作必不可少的資源，進而檢驗這些資源是否可以得到，即它的可用性如何。如果某個測試計劃已經編寫出來，但所需資源仍未落實，那就必須及早解決。

c、明確任務的風險：有了測試計劃，就可以弄清楚測試可以做什麼，不能做什麼。瞭解測試任務的風險有助於對潛伏的可能出現的問題事先作好思想上和物質上的準備。

d、生成測試用例：測試用例的好壞決定着測試工作的效率，選擇合適的測試用例是作好測試工作的關鍵。在測試文件編制過程中，按規定的要求精心設計測試用例有重要的意義。

e、評價測試結果：測試文件包括測試用例，即若干測試數據及對應的預期測試結果。完成測試後，將測試結果與預期的結果進行比較，便可對已進行的測試提出評價意見。

f、再測試：測試文件規定的和說明的內容對維護階段由於各種原因的需求進行再測試時，是非常有用的。

g、決定測試的有效性：完成測試後，把測試結果寫入文件，這對分析測試的有效性，甚至整個軟件的可用性提供了依據。同時還可以證實有關方面的結論。

(3)測試文件的編制

在軟件的需求分析階段，就開始測試文件的編制工作，各種測試文件的編寫應按一定的格式進行。

 

5．結束語

    由於軟件開發的規模越來越大，因此軟件測試的重要性更加突出。本文主要對軟件測試各階段採用的方法和人員的組織進行了簡要介紹。