軟件測試的組織與管理

　　作為軟件開(kāi)發(fā)的重要環(huán)節，軟件測試越來(lái)越受到人們的重視。隨著(zhù)軟件開(kāi)發(fā)規模的增大、復雜程度的增加，以尋找軟件中的錯誤為目的的測試工作就顯得更加困難。然而，為了盡可能多地找出程序中的錯誤，生產(chǎn)出高質(zhì)量的軟件產(chǎn)品，加強對測試工作的組織和管理就顯得尤為重要。

　　從軟件的生存周期看，測試往往指對程序的測試，這樣做的優(yōu)點(diǎn)是被測對象明確，測試的可操作性相對較強。但是，由于測試的依據是規格說(shuō)明書(shū)、設計文檔和使用說(shuō)明書(shū)，如果設計有錯誤，測試的質(zhì)量就難以保證。即使測試后發(fā)現是設計的錯誤，這時(shí)，修改的代價(jià)是相當昂貴的。因此，較理想的做法應該是對軟件的開(kāi)發(fā)過(guò)程，按軟件工程各階段形成的結果，分別進(jìn)行嚴格的審查。軟件的生命周期可用圖1的流程表示。

　　為了確保軟件的質(zhì)量，對圖1的過(guò)程應進(jìn)行嚴格的管理。雖然測試是在實(shí)現且經(jīng)驗證后進(jìn)行的，實(shí)際上，測試的準備工作在分析和設計階段就開(kāi)始了。

　　1.測試的過(guò)程及組織

　　當設計工作完成以后，就應該著(zhù)手測試的準備工作了，一般來(lái)講，由一位對整個(gè)系統設計熟悉的設計人員編寫(xiě)測試大綱，明確測試的內容和測試通過(guò)的準則，設計完整合理的測試用例，以便系統實(shí)現后進(jìn)行全面測試。

　　在實(shí)現組將所開(kāi)發(fā)的程序經(jīng)驗證后，提交測試組，由測試負責人組織測試，測試一般可按下列方式組織：

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

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

　　(3)代碼會(huì )審：

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

　　(4)單元測試：

　　單元測試集中在檢查軟件設計的最小單位—模塊上，通過(guò)測試發(fā)現實(shí)現該模塊的實(shí)際功能與定義該模塊的功能說(shuō)明不符合的情況，以及編碼的錯誤。由于模塊規模小、功能單一、邏輯簡(jiǎn)單，測試人員有可能通過(guò)模塊說(shuō)明書(shū)和源程序，清楚地了解該模塊的I/O條件和模塊的邏輯結構，采用結構測試(白盒法)的用例，盡可能達到徹底測試，然后輔之以功能測試(黑盒法)的用例，使之對任何合理和不合理的輸入都能鑒別和響應。高可靠性的模塊是組成可靠系統的堅實(shí)基礎。

　　(5)集成測試：

　　集成測試是將模塊按照設計要求組裝起來(lái)同時(shí)進(jìn)行測試，主要目標是發(fā)現與接口有關(guān)的問(wèn)題。如數據穿過(guò)接口時(shí)可能丟失;一個(gè)模塊與另一個(gè)模塊可能有由于疏忽的問(wèn)題而造成有害影響;把子功能組合起來(lái)可能不產(chǎn)生預期的主功能;個(gè)別看起來(lái)是可以接受的誤差可能積累到不能接受的程度;全程數據結構可能有錯誤等。

　　(6)驗收測試：

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

　　經(jīng)過(guò)上述的測試過(guò)程對軟件進(jìn)行測試后，軟件基本滿(mǎn)足開(kāi)發(fā)的要求，測試宣告結束，經(jīng)驗收后，將軟件提交用戶(hù)。

　　2.測試方法的應用

　　集成測試及其后的測試階段，一般采用黑盒方法。其策略包括?/p>

　　(1)用邊值分析法和(或)等價(jià)分類(lèi)法提出基本的測試用例;

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

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

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

　　a、先仿照上述步驟用黑盒法提出一組基本的測試用例，然后用白盒法作驗證。如果發(fā)現用黑盒法產(chǎn)生的測試用例未能滿(mǎn)足所需的覆蓋標準，就用白盒法增補新的測試用例來(lái)滿(mǎn)足它們。覆蓋的標準應該根據模塊的具體情況確定。對可靠性要求較高的模塊，通常要滿(mǎn)足條件組合覆蓋或路徑覆蓋標準。

　　b、先用白盒法分析模塊的邏輯結構，提出一批測試用例，然后根據模塊的功能用黑盒法進(jìn)行補充。

　　3.測試的人員組織

　　為了保證軟件的開(kāi)發(fā)質(zhì)量，軟件測試應貫穿于軟件定義與開(kāi)發(fā)的整個(gè)過(guò)程。因此，對分析、設計和實(shí)現等各階段所得到的結果，包括需求規格說(shuō)明、設計規格說(shuō)明及源程序都應進(jìn)行軟件測試?；诖?，測試人員的組織也應是分階段的。

　　(1)軟件的設計和實(shí)現都是基于需求分析規格說(shuō)明進(jìn)行的。

　　需求分析規格說(shuō)明是否完整、正確、清晰是軟件開(kāi)發(fā)成敗的關(guān)鍵。為了保證需求定義的質(zhì)量，應對其進(jìn)行嚴格的審查。審查小組由下列人員組成：

　　組長(cháng)：1人

　　成員：包括系統分析員，軟件開(kāi)發(fā)管理者，軟件設計、開(kāi)發(fā)和測試人員和用戶(hù)

　　(2)設計評審：

　　軟件設計是將軟件需求轉換成軟件表示的過(guò)程。主要描繪出系統結構、詳細的處理過(guò)程和數據庫模式。按照需求的規格說(shuō)明對系統結構的合理性、處理過(guò)程的正確性進(jìn)行評價(jià)，同時(shí)利用關(guān)系數據庫的規范化理論對數據庫模式進(jìn)行審查。評審小組由下列人員組成：

　　組長(cháng)：1人

　　成員：包括系統分析員、軟件設計人員、測試負責人員各一人。

　　(3)程序的測試：

　　軟件測試。是整個(gè)軟件開(kāi)發(fā)過(guò)程中交付用戶(hù)使用前的最后階段，是軟件質(zhì)量保證的關(guān)鍵。軟件測試在軟件生存周期中橫跨兩個(gè)階段：通常在編寫(xiě)出每一個(gè)模塊之后，就對它進(jìn)行必要的測試(稱(chēng)為單元測試)。編碼與單元測試屬于軟件生存周期中的同一階段。該階段的測試工作，由編程組內部人員進(jìn)行交叉測試(避免編程人員測試自己的程序)。這一階段結束后，進(jìn)入軟件生存周期的測試階段，對軟件系統進(jìn)行各種綜合測試。測試工作由專(zhuān)門(mén)的測試組完成，測試組設組長(cháng)一名，負責整個(gè)測試的計劃、組織工作。測試組的其他成員由具有一定的分析、設計和編程經(jīng)驗的專(zhuān)業(yè)人員組成，人數根據具體情況可多可少，一般3～5人為宜。

原文轉自：http://kjueaiud.com