軟件測試2-測試模型與過程

1、本節(jié)內(nèi)容本節(jié)內(nèi)容軟件開發(fā)模式軟件測試模型軟件測試流程軟件開發(fā)模型是軟件從最初構思到發(fā)布軟件產(chǎn)品的全部過程，明確規(guī)定要完成的主要活動和任務，是軟件項目開發(fā)的基礎正確、適宜的軟件開發(fā)方法對開發(fā)進程很重要。不同類型的軟件的需求及規(guī)模不盡相同。不同軟件過程采用不同開發(fā)流程主流軟件開發(fā)過程瀑布模型螺旋模型RUP模型敏捷開發(fā)模型瀑布模型瀑布模型瀑布模型的核心思想是按工序將問題化簡，將功能的實現(xiàn)與設計分開，采用機構化的分析與設計方法將邏輯實現(xiàn)與物理實現(xiàn)分開。軟件生命周期劃分為制定計劃、需求分析、軟件設計、程序編寫、軟件測試、運行維護。規(guī)定活動自上而下、相互銜接的固定次序，逐級下落。優(yōu)點：易于理解；為項目提供

2、了按階段劃分的檢查點。強調早期計劃及需求調查；確定何時能夠交付產(chǎn)品及何時進行評審與測試。缺點：需求調查分析只進行一次，不能適應需求變化；順序的開發(fā)流程，使得在項目各個階段之間極少有反饋。沒有包含任何類型的風險評估；開發(fā)中出現(xiàn)的問題直到開發(fā)后期才能夠顯露，因此失去及早糾正的機會。通過過多的強制完成日期和里程碑來跟蹤各個項目階段。傳統(tǒng)的瀑布模型，軟件測試的地位和價值并沒有體現(xiàn)出來，測試只能作為一個事后補救工作。早期的錯誤可能要等到開發(fā)后期的測試階段才能發(fā)現(xiàn)，進而帶來嚴重的后果。各個階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，極大地增加了工作量。由于開發(fā)模型是線性的，用戶只有等到整個過程的末期才能見

3、到開發(fā)成果，從而增加 了開發(fā)的風險。螺旋模式是瀑布模式與邊寫邊改演化模式相結合，并加入風險評估所建立的軟件開發(fā)模式。 主要思想是在開始時不必詳細定義所有細節(jié)，而是從小開始，定義重要功能，盡量實現(xiàn)，接受客戶反饋，進入下一階段，并重復上述過程，直到獲得最終產(chǎn)品。 每一螺旋（開發(fā)階段）包括5個步驟：確定目標，選擇方案和限制條件。 對方案風險進行評估，并能解決風險。 進行本階段的開發(fā)和測試。 計劃下一階段。 確定進入下階段的方法。優(yōu)點：嚴格的全過程風險管理，測試介入早，發(fā)現(xiàn)問題早；強調各開發(fā)階段的質量；提供機會評估項目是否有價值繼續(xù)下去。缺點：螺旋開發(fā)需要巨大的回歸測試周期，以確定添加的內(nèi)容是否會對整

4、個系統(tǒng)的運行產(chǎn)生影響螺旋開發(fā)模式詳細設計風險分析評估方案累計成本提交線制定計劃原型1原型2原型3可運行原型風險分析風險分析需求計劃開發(fā)計劃集成與測試軟件需求軟件產(chǎn)品設計需求確定設計確定實現(xiàn)編碼單元測試集成測試驗收測試IBM開發(fā)的面向對象且基于網(wǎng)絡的程序開發(fā)方法論：可以遠距離網(wǎng)絡協(xié)同完成開發(fā)工作面向對象軟件工程的通用業(yè)務流程，微型版螺旋開發(fā)具有統(tǒng)一的軟件流程構架，提供規(guī)范的開發(fā)任務分配和職責明確分配，其目標是確保可預期和預算內(nèi)開發(fā)滿足用戶高質量產(chǎn)品RUP認為,所有的階段(需求及其它)都可以細分為迭代。每一次的迭代都會產(chǎn)生一個可以發(fā)布的產(chǎn)品,這個產(chǎn)品是最終產(chǎn)品的一個子集。RUP把一個項目分為四個不

5、同的階段：初始階段 ：包括用戶溝通和計劃活動兩個方面，強調定義和細化用例，并將其作為主要模型。細化階段 ：包括用戶溝通和建模活動，重點是創(chuàng)建分析和設計模型，強調類的定義和體系結構的表示構建階段 ：將設計轉化為實現(xiàn)，并進行集成和測試發(fā)布階段 ：將產(chǎn)品發(fā)布給用戶進行測試評價，并收集用戶的意見，之后再次進行迭代修改產(chǎn)品使之完善。敏捷開發(fā)以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發(fā)。在敏捷開發(fā)中，軟件項目在構建初期被切分成多個子項目，各個子項目的成果都經(jīng)過測試（24小時內(nèi)），具備可視、可集成和可運行使用的特征。敏捷原則：個體和交互勝于過程與工具；可運行的軟件勝于面面俱到的文檔，客戶合作

6、勝于合同談判；響應變化勝于教條遵循計劃需求變更，日常工作，共享狀態(tài)，發(fā)現(xiàn)潛在問題軟件測試生命周期包含在軟件生命周期中測試生命周期主要橫跨兩歷程：軟件開發(fā)階段的測試歷程軟件運行維護階段的測試活動軟件測試與軟件開發(fā)過程的關系測試在開發(fā)階段的作用：項目規(guī)劃階段：負責從單元測試到系統(tǒng)測試的整個測試階段的監(jiān)控。需求分析階段：確定測試需求分析、系統(tǒng)測試計劃的制定，評審后成為管理項目。詳細設計和概要設計階段：確保集成測試計劃和單元測試計劃完成。編碼階段：由開發(fā)人員進行自己負責部分的測試代碼。在項目較大時，由專人進行編碼階段的測試任務。測試階段（單元、集成、系統(tǒng)測試）：依據(jù)測試代碼進行測試，并提交相應的測試狀

7、態(tài)報告和測試結束報告。V模型W模型H模型X 模型測試前置模型(測試驅動模型)V模型是最廣為人知的測試模型，由Paul Rook在世紀年代后期提出的，旨在改進軟件開發(fā)的效率和效果。V模型與瀑布模型有共同特性，開發(fā)與測試實現(xiàn)層級對應其重要之處在于從左到右，描述了基本的開發(fā)過程和測試行為，非常明確地標明了測試過程中存在的不同級別，描述了這些測試階段和開發(fā)過程期間各階段的對應關系需求分析需求分析概要設計概要設計詳細設計詳細設計編碼編碼單元測試單元測試集成測試集成測試系統(tǒng)測試系統(tǒng)測試驗收測試驗收測試單元和集成測試應檢測程序的執(zhí)行是否滿足軟件設計的要求；系統(tǒng)測試應檢測系統(tǒng)功能、性能的質量特性是否達到系統(tǒng)要

8、求的指標；驗收測試確定軟件的實現(xiàn)是否滿足用戶需要或合同的要求。V模型中的過程從左到右，描述了基本的開發(fā)過程和測試行為。V模型的價值在于它非常明確地標注了測試過程中存在的不同類型的測試。V模型的缺陷存在局限性，僅僅把測試過程作為在需求分析、系統(tǒng)設計及編碼之后的一個階段，只針對程序進行的尋找錯誤的活動，忽視了測試活動對需求分析,系統(tǒng)設計等活動的驗證和確認的功能，直到后期的驗收測試才被發(fā)現(xiàn)，違背了測試盡早介入的原則。W模型由Evolutif公司提出。W模型從V模型演化過來，實際上開發(fā)是V，測試也是與此并行的V。相對于V模型，W模型增加了軟件各開發(fā)階段中應同步進行的驗證和確認活動。測試伴隨整個軟件開發(fā)

9、周期，而且測試的對象不僅僅是程序，需求、設計等同樣要測試，測試與開發(fā)是同步進行的。W模型有利于盡早地全面的發(fā)現(xiàn)問題。優(yōu)點需求分析完成后，就參與到對需求的驗證和確認活動中，以盡早地找出缺陷所在。同時，對需求的測試也有利于及時了解項目難度和測試風險，及早制定應對措施，這將顯著減少總體測試時間，加快項目進度。非常明確地標注了生產(chǎn)周期中開發(fā)與測試之間的對應關系。缺點W模型也存在局限性。在W模型中，需求、設計、編碼等活動被視為串行的，同時，測試和開發(fā)活動也保持著一種線性的前后關系，上一階段完全結束，才可正式開始下一個階段工作工作。這樣就無法支持迭代，自發(fā)性以及變更調整的開發(fā)模型。對于當前軟件開發(fā)復雜多變

10、的情況，W模型并不能解除測試管理面臨著困惑。測試準備測試準備測試執(zhí)行測試執(zhí)行測試流程測試流程其他流程（設計、其他流程（設計、編碼等流程）編碼等流程）測試就緒點測試就緒點測試的“微循環(huán)”與前兩種模型相比，H模型充分地體現(xiàn)了測試過程。H模型說明:1、軟件測試不僅僅指測試的執(zhí)行, 還包括很多其他的活動。2、軟件測試是一個獨立的流程, 貫穿產(chǎn)品的整個開發(fā)周期, 與其它流程并發(fā)進行。3、軟件測試要盡早準備, 盡早執(zhí)行。軟件測試可以根據(jù)被測物的不同而分層次進行。不同的測試活動可以是按照某個次序先后進行的，但也可能是反復的,只要某個測試達到準備就緒點,測試執(zhí)行活動就可以開展。很好地處理測試與開發(fā)的交接過程（

11、交接的過程是一個時間段，而不是一個點）左邊描述的是針對多個單獨程序片段所進行的相互分離的編碼和測試，通過集成最終合成為可執(zhí)行的程序，然后再對這些可執(zhí)行程序進行測試。己通過集成測試的成品可以進行封版并提交給用戶，也可以作為更大規(guī)模和范圍內(nèi)集成的一部分。多根并行的曲線表示變更可以在各個部分發(fā)生。X模型還定位了探索性測試，這是不進行事先計劃的特殊類型的測試，給有經(jīng)驗的測試人員在測試計劃之外發(fā)現(xiàn)更多的軟件缺陷。但可能對測試造成人力、物力和財力的浪費，對測試員的熟練程度要求比較高。V模型與W模型與開發(fā)模型相對應，非常正規(guī)，但實踐性較弱；H模型代表了迭代，由于沒有和開發(fā)相對應，有時候難于確認測試就緒點，對

12、于缺乏經(jīng)驗的測試員更是如此；X模型強調了單元測試、集成測試以及探索性測試，實用性較強，但并沒有涵蓋整個開發(fā)周期，比如軟件設計階段，形成不完整的模型。軟件開發(fā)是一個自頂向下，逐步細化的過程；軟件測試則是以相反順序的自底向上，逐步集成的過程。軟件測試工作必須要通過制定測試計劃、測試設計、測試開發(fā)、測試執(zhí)行、測試評估幾個階段來完成。測試以下程序： void static main(int argc, char * argv) printf(“Hello world!”);測試用例編號測試用例編號說明說明操作過程操作過程輸入值輸入值期望結果期望結果1測試程序功能運行軟件無在控制臺打印出“Hello w

13、orld！”將程序編譯、連接形成可執(zhí)行程序Hello.exe，然后運行它，由于測試不要求輸入值，因此運行軟件即是執(zhí)行測試。程序在控制臺打印出“Hello world！”字樣測試的實際結果與期望的結果一致，程序的打印功能是正確的。軟件測試生命周期 回歸測試回歸測試制定測試計劃制定測試計劃 測試設計測試設計 測試開發(fā)測試開發(fā) 執(zhí)行測試執(zhí)行測試評估測試評估測試缺陷缺陷測試策略是制定測試計劃的重要參考依據(jù)目的：如何以最少的人力、物力和時間等資源投入來達到最佳測試效果的綜合方法，原因在于完全的測試是不可能的，對任何程序的測試必定是不完全的。那么，最顯然的測試策略就是努力使測試盡可能完全。影響因素： 測試

14、完成的標準成本、人力、時間等資源狀況針對需求定義測試類型、方法及工具等由于時間和成本的約束，軟件測試的最關鍵問題是： 所有可能的測試用例中，哪個子集所有可能的測試用例中，哪個子集最有可能發(fā)現(xiàn)最多的錯誤？最有可能發(fā)現(xiàn)最多的錯誤？代表性、典型性正確和錯誤的或者異常的輸入多考慮用戶實際使用場景避免含糊的測試用例（三種狀態(tài)）盡量將具有相類似功能的測試用例抽象并歸類盡量避免冗長和復雜的測試用例軟件測試的主要評測方法包括：覆蓋評測測試覆蓋是對測試完全程度的評測，它建立在測試覆蓋基礎上。覆蓋指標提供了“測試的完全程度如何？”這一問題的答案。最常用的覆蓋評測是基于測試需求和測試用例基于測試需求和測試用例的測試

15、覆蓋和基于已執(zhí)行代碼基于已執(zhí)行代碼的測試覆蓋。質量評測質量是對測試對象的可靠性、穩(wěn)定性以及性能的評測。評估測試對象的性能時，側重于獲取與行為相關的數(shù)據(jù)，如響應時間、事務處理數(shù)、內(nèi)存占用率、操作可靠性等。立項會議需求評審測試工作啟動測試設計階段設計內(nèi)容評審測試交接測試交接測試實施測試實施階段階段回歸測試回歸測試同行評審同行評審測試總結報告測試驗收測試歸檔工作總結由工程技術委員會召開立項會議，會議主要對項目的可行性進行分析，并且確定項目經(jīng)理及項目測試組長。過程要點過程要點詳細說明詳細說明輸入條件立項會議工作內(nèi)容 項目（產(chǎn)品）可行性分析。 項目經(jīng)理的確定. 根據(jù)項目信息，測試經(jīng)理確定測試組長。退出標

16、準測試組長確定責任人測試經(jīng)理（確定測試組長）注： 1需求定義基本完成，此時應在評審會議召開之前發(fā)給測試團隊，預留時間給測試相關人員熟悉、理解。 2測試部參與人員由測試部經(jīng)理指定，主要由測試組長、測試設計等人員組成（還應包括配置管理人員、質量保證人員）。過程要點過程要點詳細說明詳細說明輸入條件需求定義完成工作內(nèi)容測試團隊成員對需求中不清楚、不完整、太概括或存在疑義的地方提出問題，相關人員解答并確認。退出標準所有人員對需求無異議參與人員需求調研人員，工程技術委員會，開發(fā)組，測試部責任人工程技術委員會過程要點過程要點詳細說明詳細說明輸入條件項目（產(chǎn)品）開發(fā)計劃完成工作內(nèi)容1項目/產(chǎn)品經(jīng)理郵件通知測試

17、組長正式測試交接時間，測試規(guī)模預估等，同時提交相關最新項目資料：項目需求及軟件規(guī)格定義文檔、項目開發(fā)計劃、開發(fā)設計過程中提供概要設計、詳細設計文檔等其他相關資料2組建測試小組，確定小組成員。并指定測試設計工程師及測試實施工程師。3召開測試啟動會議，開發(fā)團隊提供需求規(guī)格說明書和開發(fā)計劃，確認開發(fā)組與測試組對需要交接的測試內(nèi)容、測試目標達成一致，統(tǒng)一項目組的目標和測試的工作重點。 退出標準測試小組成立，雙方對測試目標及內(nèi)容達成一致。責任人產(chǎn)品（項目）經(jīng)理，測試組長在正式測試任務下達前，開發(fā)團隊應在項目（產(chǎn)品）開發(fā)計劃完成后及時向測試團隊下達預通知，告之較為確切的測試日期，提供當前最新的相關資料。部

18、門經(jīng)理和測試組長組建測試小組，并視具體情況決定是否需要調整人力、時間安排、測試環(huán)境等其它資源。測試小組成員可預先熟悉必要的項目（產(chǎn)品）資料。過程要點過程要點詳細說明詳細說明輸入條件項目需求文檔建立，項目開發(fā)計劃完成工作內(nèi)容根據(jù)項目的需求文檔、設計文檔，按照測試計劃文檔模板編寫測試計劃。測試計劃中應該至少包括以下關鍵內(nèi)容：依據(jù)項目背景及要求，確定測試環(huán)境。測試需求需要測試的范圍，估算出測試所花費的人力資源和各個測試需求的測試優(yōu)先級測試策略確定項目的測試計劃內(nèi)容，整體測試的測試方法和每個測試需求的測試方法，同時做好測試進度安排及人員調整。測試資源本次測試所需要用到的人力、硬件、軟件、技術的資源測試

19、組角色明確測試組內(nèi)各個成員的角色和相關責任可交付工件在測試組的工作中必須向項目組提交的產(chǎn)物，包括測試計劃、測試報告等等風險管理列舉出測試工作所可能出現(xiàn)的風險測試計劃編寫完畢后，必須提交給項目組全體成員，并由項目組組中各個角色組聯(lián)合評審。退出標準測試計劃由項目組評審并通過.在項目開發(fā)過程中，要適時的對測試計劃進行跟蹤，以及評估此計劃的完整性、可行性，在項目結束時還要最后評估一下測試計劃的質量責任人測試設計工程師 過程要點過程要點詳細說明詳細說明輸入條件測試需求明確，測試計劃明確工作內(nèi)容根據(jù)測試計劃設計測試用例，設計參考原則：等價類劃分邊界值分析錯誤推測等業(yè)務知識及相關流程退出標準 測試用例需要覆

20、蓋所有的測試需求 測試用例集需進行評審并通過 項目進行過程中，適時的根據(jù)需求變更來對測試用例進行維護責任人測試組成員在需求分析文檔確立基線以后，測試組需要針對項目的測試需求編寫測試用例，在實際的測試中，測試用例將是唯一實施標準。過程要點過程要點詳細說明詳細說明輸入條件測試計劃、測試用例集完成工作內(nèi)容評審測試計劃內(nèi)容的正確性及合理性：測試環(huán)境、測試資源；測試需求范圍，各個測試需求的優(yōu)先級；測試策略及風險管理等；評審測試用例集：測試用例優(yōu)先級測試用例集基于需求的覆蓋程度退出標準測試計劃及測試用例集評審通過責任人同行測試組，項目經(jīng)理，測試計劃及測試用例的設計工作完成后，需通知項目組相關成員召開評審會

21、議。在這之前需要將待評審的內(nèi)容發(fā)給相關人員熟悉和理解。過程要點過程要點詳細說明詳細說明輸入條件測試設計內(nèi)容評審完畢，開發(fā)團隊編碼工作完成，并已完成內(nèi)部測試；工作內(nèi)容1. 開發(fā)組根據(jù)測試啟動會上所規(guī)定的內(nèi)容，填寫送測單，向測試組提交測試內(nèi)容。2. 測試小組檢查提交部件的完整性和可測性： 檢查接收的測試內(nèi)容（按照測試啟動會上所規(guī)定的交接內(nèi)容）； 檢查程序是否有病毒； 能否正確安裝/卸載； 檢查送測的軟件是否完整，能否進行測試；退出標準提交部件經(jīng)測試組檢驗通過責任人產(chǎn)品（項目）經(jīng)理，測試組長過程要點過程要點詳細描述詳細描述輸入條件測試組長于前一工作日定出當日的測試計劃，確定可用的測試用例。工作內(nèi)容

22、測試實施工程師根據(jù)測試計劃中分配給自己的測試任務和提供的測試用例，實施相應的測試用例。 記錄實施用例的結果，提交當日測試紀錄。 提交缺陷。退出標準測試用例中的所有任務被執(zhí)行，結果被記錄。責任人測試組成員實施測試用例將花費測試組大部分時間，這些工作都是建立在前期很多計劃工作的基礎上。過程要點詳細描述輸入條件測試組完成了預定周期的測試任務工作內(nèi)容測試組長根據(jù)此輪測試的結果，編寫階段性測試報告，主要應包含以下內(nèi)容：測試報告的版本、測試的人員和時間測試所覆蓋的缺陷測試組在這輪測試中所有處理的缺陷，報告測試組長處理的缺陷和實施工程師驗證的缺陷。不僅要寫出覆蓋缺陷的總數(shù)，還要寫明這些缺陷的去向測試新發(fā)現(xiàn)的

23、缺陷數(shù)量、上一版本活動缺陷的數(shù)量經(jīng)過此輪測試，所有活動缺陷的數(shù)量及其狀態(tài)分類測試評估寫明在這一版本中，哪些功能被實現(xiàn)了，哪些還沒有實現(xiàn)，只需寫明和上一版本不同之處即可急待解決的問題寫明當前項目組中面臨的最優(yōu)先的問題，可以重復提出退出標準在每輪測試結束之后應盡快將符合標準的測試報告發(fā)給全項目組責任人測試組長在約定的測試周期完成之后，測試組長需要總結此次測試的結果，編寫階段性測試報告。過程要點過程要點詳細描述詳細描述輸入條件在每輪測試中，按照現(xiàn)有的測試用例沒有新的缺陷被發(fā)現(xiàn)，測試報告中全部的活動缺陷都被解決。工作內(nèi)容 測試組將按照測試計劃中對于回歸測試的策略對產(chǎn)品進行回歸測試，回歸測試的用例屬于測

24、試用例的一部分或者是全部測試用例，但不能超出原先預定的測試用例的范圍。 記錄用例實施結果，提交回歸測試記錄。退出標準 回歸測試所運行的用例全部通過 缺陷經(jīng)過驗證 所有缺陷都被指明處理方式責任人測試實施工程師 在每輪測試結束之后，由測試組重新拷貝修改后的最新版本，進行回歸測試。過程要點過程要點詳細描述詳細描述輸入條件回歸測試結束，所有缺陷都被關閉。工作內(nèi)容1.進行對測試組所測試項目或產(chǎn)品的測試審查工作.基本原則:不依據(jù)所設計測試用例,進行自由測試.測試時間保持在3個正常工作日以內(nèi).如發(fā)現(xiàn)嚴重缺陷,則一輪測試結束后,更新版本,執(zhí)行回歸測試.2.提交當日測試紀錄.3.編寫同行審查總結報告(報告以簡單

25、為好).退出標準同行審查沒有新的缺陷或沒有嚴重缺陷產(chǎn)生.責任人同行測試組過程要點過程要點詳細描述詳細描述輸入條件測試組完成了所有的測試實施工作,同行審查結束.工作內(nèi)容測試組長根據(jù)測試的結果，按照測試總結報告的文檔模板編寫測試總結報告，測試報告必須包含以下重要內(nèi)容：測試資源概述多少人、多長時間。測試結果摘要分別描述各個測試需求的測試結果，產(chǎn)品實現(xiàn)了哪些功能點，哪些還沒有實現(xiàn)缺陷分析按照缺陷的屬性分類進行分析測試需求覆蓋率原先列舉的測試需求的測試覆蓋率，可能一部分測試需求因為資源和優(yōu)先級的因素沒有進行測試，那么在這里要進行說明測試評估從總體對項目質量進行評估測試組建議從測試組的角度為項目組提出工作

26、建議退出標準測試組長完成了符合標準的測試報告，發(fā)送給全項目組。責任人測試組長在回歸測試結束之后，測試組長將要編寫測試總結報告，對測試進行總結，并且提交給全體項目組，為產(chǎn)品的后續(xù)工作提供重要的信息支持。過程要點過程要點詳細描述詳細描述輸入條件測試組完成了所有的測試實施工作，測試組長完成符合標準的測試總結文檔工作內(nèi)容由測啟會上約定的驗收組成員，對本次測試收進行驗收，驗收內(nèi)容包括：測試效果驗收測試是否達到預期目的測試文檔驗收測試過程文檔是否齊全，可信，符合標準測試評估從總體對測試的質量進行評估測試建議對本次測試工作指出不足，需要在以后工作中改進的地方宣布測試結束測試驗收組成員簽字宣布本次測試結束退出

27、標準測試驗收通過，測試驗收會議記錄整理完畢參與人員驗收組人員，測試經(jīng)理，測試組長，產(chǎn)品（項目）經(jīng)理測試驗收工作是在以上工作全部結束后，對測試的過程，效果進行驗收，宣布測試結束。過程要點過程要點詳細描述詳細描述輸入條件測試驗收通過工作內(nèi)容歸類、存檔測試過程涉及到的文檔，主要包括以下文檔（必須）測試任務書測試計劃書測試用例書階段性測試報告測試總結報告測試驗收會議記錄退出標準全部文檔歸類完畢，版本號封存責任人測試組長測試歸檔是在測試驗收結束宣布測試有效，結束測試后，對測試過程中涉及到各種標準文檔進行歸類，存檔。過程要點過程要點 詳細描述詳細描述輸入條件項目驗收工作完成。工作內(nèi)容由質控部經(jīng)理，測試組長

28、召開項目測試工作總結會議，會議內(nèi)容主要為：測試組長對項目期間的整個測試組的工作情況進行總結，指出測試工作中存在的問題，同時也對工作中表現(xiàn)好的地方給與肯定。（具體包括整個測試情況、流程實施、人員安排、測試方法等）參與本次項目測試工作的所有成員個人體會和建議。討論測試工作中出現(xiàn)的問題，尋求更好的解決辦法。宣布解散測試小組。退出標準所提問題尋求到較好解決方式，測試小組解散參與人員測試部所有成員測試歸檔是在測試驗收結束宣布測試有效，結束測試后，對測試過程中涉及到各種標準文檔進行歸類，存檔。軟件測試的周期性是“測試-改錯-再測試-再改錯”這樣一個循環(huán)過程，如下圖所示。測試周期測試周期開發(fā)開發(fā)/ 改錯改錯改錯改錯測試周期測試周期改錯改錯串行方式串行方式開發(fā)者開發(fā)者： .開發(fā)者：開發(fā)者：并行方式并行方式測試者：測試者：開發(fā)開發(fā)/ 改錯改錯開發(fā)開發(fā)/ 改錯改錯最終回歸測試最終回歸測試回歸測試回歸測試1測試周期測試周期1功能凍結功能凍結代碼凍