1、軟件測試的組織與管理軟件世界 2000/6 丁順利 袁靜波作為軟件開發的重要環節 ,軟件測試越來越受到人們的重視。隨著軟件開發規模的增大、復雜程度的增加 ,以尋找 軟件中的錯誤為目的的測試工作就顯得更加困難。 然而 , 為了盡可能多地找出程序中的錯誤 , 生產出高質量的軟件 產品 ,加強對測試工作的組織和管理就顯得尤為重要。從軟件的生存周期看 , 測試往往指對程序的測試 , 這樣做的優點是被測對象明確 , 測試的可操作性相對較強。 但是 , 由于測試的依據是規格說明書、設計文檔和使用說明書 ,如果設計有錯誤 ,測試的質量就難以保證。即使測試后發現是設計的錯誤 ,這時 ,修改的代價是相當昂貴的。

2、因此 ,較理想的做法應該是對軟件的開發過程 ,按軟件工程各 階段形成的結果 ,分別進行嚴格的審查。軟件的生命周期可用圖 1 的流程表示。為了確保軟件的質量 ,對圖 1 的過程應進行嚴格的管理。雖然測試是在實現且經驗證后進行的 ,實際上 ,測試的準 備工作在分析和設計階段就開始了。1.測試的過程及組織當設計工作完成以后 , 就應該著手測試的準備工作了 , 一般來講 , 由一位對整個系統設計熟悉的設計人員編寫測試 大綱 ,明確測試的內容和測試通過的準則 ,設計完整合理的測試用例 ,以便系統實現后進行全面測試。在實現組將所開發的程序經驗證后 ,提交測試組 ,由測試負責人組織測試 ,測試一般可按下列方

3、式組織 :(1 首先 ,測試人員要仔細閱讀有關資料 ,包括規格說明、設計文檔、使用說明書及在設計過程中形成的測試大綱、 測試內容及測試的通過準則 ,全面熟悉系統 ,編寫測試計劃 ,設計測試用例 ,作好測試前的準備工作。(2 為了保證測試的質量 ,將測試過程分成幾個階段,即:代碼審查、單元測試、集成測試和驗收測試。(3 代碼會審 :代碼會審是由一組人通過閱讀、討論和爭議對程序進行靜態分析的過程。會審小組由組長 , 23 名程序設計和測 試人員及程序員組成。會審小組在充分閱讀待審程序文本、控制流程圖及有關要求、規范等文件基礎上,召開代碼 會審會 ,程序員逐句講解程序的邏輯 ,并展開熱烈的討論甚至爭

4、議,以揭示錯誤的關鍵所在。實踐表明,程序員在 講解過程中能發現許多自己原來沒有發現的錯誤, 而討論和爭議則進一步促使了問題的暴露。例如 , 對某個局部性 小問題修改方法的討論 ,可能發現與之有牽連的甚至能涉及到模塊的功說明、模塊間接口和系統總結構的大問題 , 導致對需求定義的重定義、重設計驗證 ,大大改善了軟件的質量。(4 單元測試 :單元測試集中在檢查軟件設計的最小單位 模塊上 , 通過測試發現實現該模塊的實際功能與定義該模塊的功能說明 不符合的情況 ,以及編碼的錯誤。由于模塊規模小、功能單一、邏輯簡單 ,測試人員有可能通過模塊說明書和源程 序,清楚地了解該模塊的 I/O 條件和模塊的邏輯結

5、構 ,采用結構測試 (白盒法的用例 ,盡可能達到徹底測試 ,然 后輔之以功能測試 (黑盒法的用例 ,使之對任何合理和不合理的輸入都能鑒別和響應。高可靠性的模塊是組成可 靠系統的堅實基礎。(5 集成測試 :集成測試是將模塊按照設計要求組裝起來同時進行測試 , 主要目標是發現與接口有關的問題。 如數據穿過接口時可 能丟失 ; 一個模塊與另一個模塊可能有由于疏忽的問題而造成有害影響 ; 把子功能組合起來可能不產生預期的主功 能;個別看起來是可以接受的誤差可能積累到不能接受的程度 ;全程數據結構可能有錯誤等。(6 驗收測試 :驗收測試的目的是向未來的用戶表明系統能夠像預定要求那樣工作。 經集成測試后

6、, 已經按照設計把所有的模塊組 裝成一個完整的軟件系統 , 接口錯誤也已經基本排除了 , 接著就應該進一步驗證軟件的有效性 , 這就是驗收測試的任務 ,即軟件的功能和性能如同用戶所合理期待的那樣。經過上述的測試過程對軟件進行測試后,軟件基本滿足開發的要求,測試宣告結束 ,經驗收后 ,將軟件提交用戶。 2.測試方法的應用集成測試及其后的測試階段 ,一般采用黑盒方法。其策略包括 :(1 用邊值分析法和 (或等價分類法提出基本的測試用例;(2 用猜測法補充新的測試用例;(3 如果在程序的功能說明中含有輸入條件的組合 ,宜在一開始就用因果圖法 ,然后再按以上 (1、(2 兩步進 行。單元測試的設計策略

7、稍有不同。 因為在為模塊設計程序用例時 , 可以直接參考模塊的源程序。 所以單元測試的策略 , 總是把白盒法和黑盒法結合運用。具體做法有兩種 :a 、先仿照上述步驟用黑盒法提出一組基本的測試用例 ,然后用白盒法作驗證。如果發現用黑盒法產生的測試用例 未能滿足所需的覆蓋標準 ,就用白盒法增補新的測試用例來滿足它們。覆蓋的標準應該根據模塊的具體情況確定。 對可靠性要求較高的模塊 ,通常要滿足條件組合覆蓋或路徑覆蓋標準。b 、先用白盒法分析模塊的邏輯結構,提出一批測試用例 ,然后根據模塊的功能用黑盒法進行補充。3.測試的人員組織為了保證軟件的開發質量,軟件測試應貫穿于軟件定義與開發的整個過程。因此

8、,對分析、設計和實現等各階段所 得到的結果 ,包括需求規格說明、設計規格說明及源程序都應進行軟件測試。基于此 ,測試人員的組織也應是分階 段的。(1 軟件的設計和實現都是基于需求分析規格說明進行的。需求分析規格說明是否完整、正確、清晰是軟件開發成敗的關鍵。為了保證需求定義的質量 ,應對其進行嚴格的審 查。審查小組由下列人員組成 :組長:1人成員 :包括系統分析員 ,軟件開發管理者 ,軟件設計、開發和測試人員和用戶(2 設計評審 :軟件設計是將軟件需求轉換成軟件表示的過程。 主要描繪出系統結構、 詳細的處理過程和數據庫模式。 按照需求的 規格說明對系統結構的合理性、 處理過程的正確性進行評價 ,

9、 同時利用關系數據庫的規范化理論對數據庫模式進行 審查。評審小組由下列人員組成 :組長:1人成員 :包括系統分析員、軟件設計人員、測試負責人員各一人。(3 程序的測試 :軟件測試。 是整個軟件開發過程中交付用戶使用前的最后階段 , 是軟件質量保證的關鍵。 軟件測試在軟件生存周期 中橫跨兩個階段 :通常在編寫出每一個模塊之后 ,就對它進行必要的測試 (稱為單元測試。編碼與單元測試屬于 軟件生存周期中的同一階段。 該階段的測試工作 , 由編程組內部人員進行交叉測試 (避免編程人員測試自己的程序 。 這一階段結束后 ,進入軟件生存周期的測試階段 ,對軟件系統進行各種綜合測試。測試工作由專門的測試組完

10、成 , 測試組設組長一名 ,負責整個測試的計劃、組織工作。測試組的其他成員由具有一定的分析、設計和編程經驗的專業人員組成 ,人數根據具體情況可多可少,一般 35人為宜。4.軟件測試文件軟件測試文件描述要執行的軟件測試及測試的結果。 由于軟件測試是一個很復雜的過程 , 同時也是設計軟件開發其 它一些階段的工作 , 對于保證軟件的質量和它的運行有著重要意義 , 必須把對它們的要求、 過程及測試結果以正式 的文件形式寫出。測試文件的編寫是測試工作規范化的一個組成部分。測試文件不只在測試階段才考慮 , 它在軟件開發的需求分析階段就開始著手 , 因為測試文件與用戶有著密切的關系。 在設計階段的一些設計方

11、案也應在測試文件中得到反映 , 以利于設計的檢驗。 測試文件對于測試階段工作的指導與 評價作用更是非常明顯的。 需要特別指出的是 , 在已開發的軟件投入運行的維護階段 , 常常還要進行再測試或回歸 測試 ,這時仍須用到測試文件。(1 測試文件的類型 :根據測試文件所起的作用不同 , 通常把測試文件分成兩類 , 即測試計劃和測試分析報告。 測試計劃詳細規定測試的 要求 ,包括測試的目的和內容、方法和步驟 ,以及測試的準則等。由于要測試的內容可能涉及到軟件的需求和軟件 的設計 ,因此必須及早開始測試計劃的編寫工作。不應在著手測試時 ,才開始考慮測試計劃。通常 ,測試計劃的編 寫從需求分析階段開始

12、,到軟件設計階段結束時完成。測試報告用來對測試結果的分析說明 ,經過測試后 ,證實了 軟件具有的能力 ,以及它的缺陷和限制 ,并給出評價的結論性意見 ,這些意見即是對軟件質量的評價 ,又是決定該 軟件能否交付用戶使用的依據。由于要反映測試工作的情況 ,自然要在測試階段內編寫。(2 測試文件的使用 :測試文件的重要性表現在以下幾個方面:a 、驗證需求的正確性 :測試文件中規定了用以驗證軟件需求的測試條件,研究這些測試條件對弄清用戶需求的意圖是十分有益的 ,b 、檢驗測試資源 :測試計劃不僅要用文件的形式把測試過程規定下來 ,還應說明測試工作必不可少的資源 ,進而 檢驗這些資源是否可以得到 ,即它

13、的可用性如何。如果某個測試計劃已經編寫出來 ,但所需資源仍未落實 ,那就必 須及早解決。c 、明確任務的風險 :有了測試計劃 ,就可以弄清楚測試可以做什么 ,不能做什么。了解測試任務的風險有助于對 潛伏的可能出現的問題事先作好思想上和物質上的準備。d 、生成測試用例 :測試用例的好壞決定著測試工作的效率 ,選擇合適的測試用例是作好測試工作的關鍵。在測試 文件編制過程中 ,按規定的要求精心設計測試用例有重要的意義。e 、評價測試結果 :測試文件包括測試用例 ,即若干測試數據及對應的預期測試結果。完成測試后 ,將測試結果與 預期的結果進行比較 ,便可對已進行的測試提出評價意見。f 、再測試 :測試文件規定的和說明的內容對維護階段由于各種原因的需求進行再測試時