單元測(cè)試 單體測(cè)試 一個(gè)概念嗎

單體測(cè)試簡單的講就是軟件開發(fā)人員把開發(fā)完了單個(gè)畫面或頁面（web開發(fā)）提交給獨(dú)立的測(cè)試人員進(jìn)行的測(cè)試的過程。由于單體測(cè)試與其單體關(guān)聯(lián)性不大甚至沒有關(guān)聯(lián)，所以會(huì)有不少人認(rèn)為單體測(cè)試分量不重，太簡單，從概念上講單體測(cè)試確實(shí)簡單，但是單體測(cè)試是以后系統(tǒng)測(cè)試的基礎(chǔ)，如果單體測(cè)試不過關(guān)沒有發(fā)現(xiàn)并曝漏出問題，那么對(duì)于整個(gè)系統(tǒng)來說將會(huì)存在很大的隱患和風(fēng)險(xiǎn)。
單元測(cè)試，是指對(duì)軟件中的最小可測(cè)試單元進(jìn)行檢查和驗(yàn)證。對(duì)于單元測(cè)試中單元的含義，一般來說，要根據(jù)實(shí)際情況去判定其具體含義，如C語言中單元指一個(gè)函數(shù)，Java里單元指一個(gè)類，圖形化的軟件中可以指一個(gè)窗口或一個(gè)菜單等。總的來說，單元就是人為規(guī)定的最小的被測(cè)功能模塊。單元測(cè)試是在軟件開發(fā)過程中要進(jìn)行的*別的測(cè)試活動(dòng)，軟件的獨(dú)立單元將在與程序的其他部分相隔離的情況下進(jìn)行測(cè)試。

北大青鳥設(shè)計(jì)培訓(xùn)：軟件測(cè)試的有效方法主要有哪些？

很多人都知道，對(duì)于很多軟件開發(fā)公司來說，無論什么軟件在進(jìn)行上市之前都需要進(jìn)行不斷的反復(fù)測(cè)試，需要在保證沒有任何問題的情況下才能投到市面上使用。
在進(jìn)行軟件測(cè)試的過程中，很多人會(huì)有一個(gè)疑問，什么測(cè)試軟件才能很好的測(cè)出開發(fā)軟件的穩(wěn)定性呢？在進(jìn)行測(cè)試的過程中，有哪些不錯(cuò)的測(cè)試軟件可以選擇呢？下面南京電腦培訓(xùn)為大家介紹有效的軟件測(cè)試方法。
金字塔模型想要構(gòu)建一個(gè)全面的測(cè)試框架，在進(jìn)行測(cè)試之前首先需要進(jìn)行了解金字塔的模型的測(cè)試方法。
在之前，很多軟件公司都會(huì)都是使用用戶界面進(jìn)行軟件測(cè)試，還需要工程師直接手動(dòng)操作界面，并且編寫自動(dòng)化宏腳本進(jìn)行界面操作。
但是這樣的方法是無法檢測(cè)出代碼存在的問題，不同的測(cè)試所能檢測(cè)的問題是不一樣的，下面南京IT培訓(xùn)介紹重要的幾個(gè)層次。
一、單元測(cè)試單元測(cè)試主要是用于驗(yàn)證服務(wù)中類方法或函數(shù)的行為。
它們?cè)诖a文件中執(zhí)行類方法或函數(shù)，提供不同的輸入，并且還能很好的驗(yàn)證與每個(gè)輸入相對(duì)應(yīng)的輸出。
二、集成測(cè)試集成測(cè)試主要是用于驗(yàn)證服務(wù)的外部行為。
能夠通過測(cè)試框架啟動(dòng)服務(wù)實(shí)例，并且調(diào)用服務(wù)的外部接口來執(zhí)行業(yè)務(wù)邏輯。
三、端到端的測(cè)試端到端測(cè)試用于驗(yàn)證多個(gè)服務(wù)之間的交互。
可以在單獨(dú)的環(huán)境中啟動(dòng)服務(wù)的多個(gè)實(shí)例，允許服務(wù)實(shí)例之間的交互完成測(cè)試。
端到端測(cè)試需要由調(diào)用的服務(wù)返回的響應(yīng)驗(yàn)證網(wǎng)絡(luò)請(qǐng)求。
四、用戶界面測(cè)試用戶界面測(cè)試是在整個(gè)測(cè)試中不可缺少的一部分，主要用于驗(yàn)證整個(gè)平臺(tái)的行為，在進(jìn)行測(cè)試的過程中，不僅需要進(jìn)行客戶端的邏輯測(cè)試，還可以對(duì)測(cè)試后系統(tǒng)的邏輯測(cè)試，南京IT培訓(xùn)認(rèn)為這樣才能很好的保證客戶端和后端的正常交互。
在進(jìn)行測(cè)試過程中，不能僅僅是為了測(cè)試而測(cè)試，最重要的是需要了解測(cè)試的目的，能夠?yàn)榭蛻魩砀玫捏w驗(yàn)，保證軟件的良好體驗(yàn)。
南京北大青鳥能夠?yàn)槟闾峁┖芎玫能浖_發(fā)平臺(tái)，通過掌握軟件開發(fā)基礎(chǔ)進(jìn)行深入了解，為想要學(xué)習(xí)軟件開發(fā)的人提供更好的平臺(tái)。

單元測(cè)試與集成測(cè)試和系統(tǒng)測(cè)試三者之間是什么關(guān)系？

單元測(cè)試就是講整體化整為零，一點(diǎn)一點(diǎn)的測(cè)試，集成測(cè)試就是把零散的全部歸結(jié)在一起去測(cè)試，系統(tǒng)測(cè)試就是使用整體應(yīng)用到真是環(huán)境下去測(cè)試。三者都是測(cè)試的關(guān)鍵環(huán)節(jié)。

方式不同

單元測(cè)試一般由開發(fā)小組采用白盒方式來測(cè)試。

集成測(cè)試一般由開發(fā)小組采用白盒加黑盒的方式來測(cè)試。

系統(tǒng)測(cè)試一般由獨(dú)立測(cè)試小組采用黑盒方式來測(cè)試。

經(jīng)常與單元測(cè)試

聯(lián)系起來的另外一些開發(fā)活動(dòng)包括代碼走讀（Code review)，靜態(tài)分析（Static analysis)和動(dòng)態(tài)分析（Dynamic analysis)。靜態(tài)分析就是對(duì)軟件的源代碼進(jìn)行研讀，查找錯(cuò)誤或收集一些度量數(shù)據(jù)，并不需要對(duì)代碼進(jìn)行編譯和執(zhí)行。動(dòng)態(tài)分析就是通過觀察軟件運(yùn)行時(shí)的動(dòng)作，來提供執(zhí)行跟蹤，時(shí)間分析，以及測(cè)試覆蓋度方面的信息。

軟件測(cè)試主要學(xué)什么，在南京有沒有？

軟件測(cè)試的分類
從是否關(guān)心軟件內(nèi)部結(jié)構(gòu)和具體實(shí)現(xiàn)的角度劃分
A.白盒測(cè)試
B.黑盒測(cè)試
C.灰盒測(cè)試

從是否執(zhí)行程序的角度
A.靜態(tài)測(cè)試
B.動(dòng)態(tài)測(cè)試。

從軟件開發(fā)的過程按階段劃分有
A.單元測(cè)試
B.集成測(cè)試
C.確認(rèn)測(cè)試
D.系統(tǒng)測(cè)試
E.驗(yàn)收測(cè)試
* 測(cè)試過程按4個(gè)步驟進(jìn)行，即單元測(cè)試、集成測(cè)試、確認(rèn)測(cè)試和系統(tǒng)測(cè)試及發(fā)版測(cè)試。
* 開始是單元測(cè)試，集中對(duì)用源代碼實(shí)現(xiàn)的每一個(gè)程序單元進(jìn)行測(cè)試，檢查各個(gè)程序模塊是否正確地實(shí)現(xiàn)了規(guī)定的功能。
* 集成測(cè)試把已測(cè)試過的模塊組裝起來，主要對(duì)與設(shè)計(jì)相關(guān)的軟件體系結(jié)構(gòu)的構(gòu)造進(jìn)行測(cè)試。
* 確認(rèn)測(cè)試則是要檢查已實(shí)現(xiàn)的軟件是否滿足了需求規(guī)格說明中確定了的各種需求，以及軟件配置是否完全、正確。
* 系統(tǒng)測(cè)試把已經(jīng)經(jīng)過確認(rèn)的軟件納入實(shí)際運(yùn)行環(huán)境中，與其它系統(tǒng)成份組合在一起進(jìn)行測(cè)試。
單元測(cè)試 (Unit Testing)
* 單元測(cè)試又稱模塊測(cè)試，是針對(duì)軟件設(shè)計(jì)的最小單位 — 程序模塊，進(jìn)行正確性檢驗(yàn)的測(cè)試工作。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯(cuò)。
* 單元測(cè)試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計(jì)測(cè)試用例。多個(gè)模塊可以平行地獨(dú)立進(jìn)行單元測(cè)試。
1. 單元測(cè)試的內(nèi)容
* 在單元測(cè)試時(shí)，測(cè)試者需要依據(jù)詳細(xì)設(shè)計(jì)說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結(jié)構(gòu)，主要采用白盒測(cè)試的測(cè)試用例，輔之以黑盒測(cè)試的測(cè)試用例，使之對(duì)任何合理的輸入和不合理的輸入，都能鑒別和響應(yīng)。
(1) 模塊接口測(cè)試
* 在單元測(cè)試的開始，應(yīng)對(duì)通過被測(cè)模塊的數(shù)據(jù)流進(jìn)行測(cè)試。測(cè)試項(xiàng)目包括：
– 調(diào)用本模塊的輸入?yún)?shù)是否正確；
– 本模塊調(diào)用子模塊時(shí)輸入給子模塊的參數(shù)是否正確；
– 全局量的定義在各模塊中是否一致；
* 在做內(nèi)外存交換時(shí)要考慮：
– 文件屬性是否正確；
– OPEN與CLOSE語句是否正確；
– 緩沖區(qū)容量與記錄長度是否匹配；
– 在進(jìn)行讀寫操作之前是否打開了文件；
– 在結(jié)束文件處理時(shí)是否關(guān)閉了文件；
– 正文書寫／輸入錯(cuò)誤，
– I／O錯(cuò)誤是否檢查并做了處理。
(2) 局部數(shù)據(jù)結(jié)構(gòu)測(cè)試
* 不正確或不一致的數(shù)據(jù)類型說明
* 使用尚未賦值或尚未初始化的變量
* 錯(cuò)誤的初始值或錯(cuò)誤的缺省值
* 變量名拼寫錯(cuò)或書寫錯(cuò)
* 不一致的數(shù)據(jù)類型
* 全局?jǐn)?shù)據(jù)對(duì)模塊的影響
(3) 路徑測(cè)試
* 選擇適當(dāng)?shù)臏y(cè)試用例，對(duì)模塊中重要的執(zhí)行路徑進(jìn)行測(cè)試。
* 應(yīng)當(dāng)設(shè)計(jì)測(cè)試用例查找由于錯(cuò)誤的計(jì)算、不正確的比較或不正常的控制流而導(dǎo)致的錯(cuò)誤。
* 對(duì)基本執(zhí)行路徑和循環(huán)進(jìn)行測(cè)試可以發(fā)現(xiàn)大量的路徑錯(cuò)誤。
(4) 錯(cuò)誤處理測(cè)試
* 出錯(cuò)的描述是否難以理解
* 出錯(cuò)的描述是否能夠?qū)﹀e(cuò)誤定位
* 顯示的錯(cuò)誤與實(shí)際的錯(cuò)誤是否相符
* 對(duì)錯(cuò)誤條件的處理正確與否
* 在對(duì)錯(cuò)誤進(jìn)行處理之前，錯(cuò)誤條件是否已經(jīng)引起系統(tǒng)的干預(yù)等
(5) 邊界測(cè)試
* 注意數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值時(shí)出錯(cuò)的可能性。對(duì)這些地方要仔細(xì)地選擇測(cè)試用例，認(rèn)真加以測(cè)試。
* 如果對(duì)模塊運(yùn)行時(shí)間有要求的話，還要專門進(jìn)行關(guān)鍵路徑測(cè)試，以確定最壞情況下和平均意義下影響模塊運(yùn)行時(shí)間的因素。
2. 單元測(cè)試的步驟
* 模塊并不是一個(gè)獨(dú)立的程序，在考慮測(cè)試模塊時(shí)，同時(shí)要考慮它和外界的聯(lián)系，用一些輔助模塊去模擬與被測(cè)模塊相聯(lián)系的其它模塊。
– 驅(qū)動(dòng)模塊 (driver)
– 樁模塊 (stub) —— 存根模塊
* 如果一個(gè)模塊要完成多種功能，可以將這個(gè)模塊看成由幾個(gè)小程序組成。必須對(duì)其中的每個(gè)小程序先進(jìn)行單元測(cè)試要做的工作，對(duì)關(guān)鍵模塊還要做性能測(cè)試。
* 對(duì)支持某些標(biāo)準(zhǔn)規(guī)程的程序，更要著手進(jìn)行互聯(lián)測(cè)試。有人把這種情況特別稱為模塊測(cè)試，以區(qū)別單元測(cè)試。
集成測(cè)試（ Testing）
* 集成測(cè)試 (集成測(cè)試、聯(lián)合測(cè)試）
* 通常，在單元測(cè)試的基礎(chǔ)上，需要將所有模塊按照設(shè)計(jì)要求組裝成為系統(tǒng)。這時(shí)需要考慮的問題是：
– 在把各個(gè)模塊連接起來的時(shí)候，穿越模塊接口的數(shù)據(jù)是否會(huì)丟失；
– 一個(gè)模塊的功能是否會(huì)對(duì)另一個(gè)模塊的功能產(chǎn)生不利的影響；
– 各個(gè)子功能組合起來，能否達(dá)到預(yù)期要求的父功能；
– 全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題；
– 單個(gè)模塊的誤差累積起來，是否會(huì)放大，從而達(dá)到不能接受的程度。
在單元測(cè)試的同時(shí)可進(jìn)行集成測(cè)試，
發(fā)現(xiàn)并排除在模塊連接中可能出現(xiàn)
的問題，最終構(gòu)成要求的軟件系統(tǒng)。
* 子系統(tǒng)的集成測(cè)試特別稱為部件測(cè)試，它所做的工作是要找出集成后的子系統(tǒng)與系統(tǒng)需求規(guī)格說明之間的不一致。
* 通常，把模塊集成成為系統(tǒng)的方式有兩種
– 一次性集成方式
– 增殖式集成方式
1. 一次性集成方式(big bang)
* 它是一種非增殖式組裝方式。也叫做整體拼裝。
* 使用這種方式，首先對(duì)每個(gè)模塊分別進(jìn)行模塊測(cè)試，然后再把所有模塊組裝在一起進(jìn)行測(cè)試，最終得到要求的軟件系統(tǒng)。
2. 增殖式集成方式
* 這種集成方式又稱漸增式集成
* 首先對(duì)一個(gè)個(gè)模塊進(jìn)行模塊測(cè)試，然后將這些模塊逐步組裝成較大的系統(tǒng)
* 在集成的過程中邊連接邊測(cè)試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題
* 通過增殖逐步組裝成為要求的軟件系統(tǒng)。
(1) 自頂向下的增殖方式
* 這種集成方式將模塊按系統(tǒng)程序結(jié)構(gòu)，沿控制層次自頂向下進(jìn)行組裝。
* 自頂向下的增殖方式在測(cè)試過程中較早地驗(yàn)證了主要的控制和判斷點(diǎn)。
* 選用按深度方向組裝的方式，可以首先實(shí)現(xiàn)和驗(yàn)證一個(gè)完整的軟件功能。
(2) 自底向上的增殖方式
* 這種集成的方式是從程序模塊結(jié)構(gòu)的*層的模塊開始集成和測(cè)試。
* 因?yàn)槟K是自底向上進(jìn)行組裝，對(duì)于一個(gè)給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)組裝并測(cè)試完成，所以不再需要樁模塊。在模塊的測(cè)試過程中需要從子模塊得到的信息可以直接運(yùn)行子模塊得到。
* 自頂向下增殖的方式和自底向上增殖的方式各有優(yōu)缺點(diǎn)。
* 一般來講，一種方式的優(yōu)點(diǎn)是另一種方式的缺點(diǎn)。
(3) 混合增殖式測(cè)試
* 衍變的自頂向下的增殖測(cè)試
– 首先對(duì)輸入／輸出模塊和引入新算法模塊進(jìn)行測(cè)試;
– 再自底向上組裝成為功能相當(dāng)完整且相對(duì)獨(dú)立的子系統(tǒng);
– 然后由主模塊開始自頂向下進(jìn)行增殖測(cè)試。
* 自底向上-自頂向下的增殖測(cè)試
– 首先對(duì)含讀操作的子系統(tǒng)自底向上直至根結(jié)點(diǎn)模塊進(jìn)行組裝和測(cè)試;
– 然后對(duì)含寫操作的子系統(tǒng)做自頂向下的組裝與測(cè)試。
* 回歸測(cè)試
– 這種方式采取自頂向下的方式測(cè)試被修改的模塊及其子模塊;
– 然后將這一部分視為子系統(tǒng)，再自底向上測(cè)試。
關(guān)鍵模塊問題
* 在組裝測(cè)試時(shí)，應(yīng)當(dāng)確定關(guān)鍵模塊，對(duì)這些關(guān)鍵模塊及早進(jìn)行測(cè)試。
* 關(guān)鍵模塊的特征：
① 滿足某些軟件需求；
② 在程序的模塊結(jié)構(gòu)中位于較高的層次（高層控制模塊）；
③ 較復(fù)雜、較易發(fā)生錯(cuò)誤；
④ 有明確定義的性能要求。
確認(rèn)測(cè)試（ Testing）
* 確認(rèn)測(cè)試又稱有效性測(cè)試。任務(wù)是驗(yàn)證軟件的功能和性能及其它特性是否與用戶的要求一致。
* 對(duì)軟件的功能和性能要求在軟件需求規(guī)格說明書中已經(jīng)明確規(guī)定。它包含的信息就是軟件確認(rèn)測(cè)試的基礎(chǔ)。
1. 進(jìn)行有效性測(cè)試（黑盒測(cè)試）
* 有效性測(cè)試是在模擬的環(huán)境 (可能就是開發(fā)的環(huán)境) 下，運(yùn)用黑盒測(cè)試的方法，驗(yàn)證被測(cè)軟件是否滿足需求規(guī)格說明書列出的需求。
* 首先制定測(cè)試計(jì)劃，規(guī)定要做測(cè)試的種類。還需要制定一組測(cè)試步驟，描述具體的測(cè)試用例。
* 通過實(shí)施預(yù)定的測(cè)試計(jì)劃和測(cè)試步驟，確定
– 軟件的特性是否與需求相符；
– 所有的文檔都是正確且便于使用；
– 同時(shí)，對(duì)其它軟件需求，例如可移植性、兼容性、出錯(cuò)自動(dòng)恢復(fù)、可維護(hù)性等，也都要進(jìn)行測(cè)試
* 在全部軟件測(cè)試的測(cè)試用例運(yùn)行完后，所有的測(cè)試結(jié)果可以分為兩類：
– 測(cè)試結(jié)果與預(yù)期的結(jié)果相符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明書相符合，從而這部分程序被接受。
– 測(cè)試結(jié)果與預(yù)期的結(jié)果不符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明不一致，因此要為它提交一份問題報(bào)告。
2. 軟件配置復(fù)查
n 軟件配置復(fù)查的目的是保證
u 軟件配置的所有成分都齊全；
u 各方面的質(zhì)量都符合要求；
u 具有維護(hù)階段所必需的細(xì)節(jié)；
u 而且已經(jīng)編排好分類的目錄。
n 應(yīng)當(dāng)嚴(yán)格遵守用戶手冊(cè)和操作手冊(cè)中規(guī)定的使用步驟，以便檢查這些文檔資料的完整性和正確性。
驗(yàn)收測(cè)試（ Testing）
* 在通過了系統(tǒng)的有效性測(cè)試及軟件配置審查之后，就應(yīng)開始系統(tǒng)的驗(yàn)收測(cè)試。
* 驗(yàn)收測(cè)試是以用戶為主的測(cè)試。軟件開發(fā)人員和QA（質(zhì)量保證）人員也應(yīng)參加。
* 由用戶參加設(shè)計(jì)測(cè)試用例，使用生產(chǎn)中的實(shí)際數(shù)據(jù)進(jìn)行測(cè)試。
* 在測(cè)試過程中，除了考慮軟件的功能和性能外，還應(yīng)對(duì)軟件的可移植性、兼容性、可維護(hù)性、錯(cuò)誤的恢復(fù)功能等進(jìn)行確認(rèn)。
* 確認(rèn)測(cè)試應(yīng)交付的文檔有：
– 確認(rèn)測(cè)試分析報(bào)告
– 最終的用戶手冊(cè)和操作手冊(cè)
– 項(xiàng)目開發(fā)總結(jié)報(bào)告。
系統(tǒng)測(cè)試（System Testing）
* 系統(tǒng)測(cè)試，是將通過確認(rèn)測(cè)試的軟件，作為整個(gè)基于計(jì)算機(jī)系統(tǒng)的一個(gè)元素，與計(jì)算機(jī)硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其它系統(tǒng)元素結(jié)合在一起，在實(shí)際運(yùn)行環(huán)境下，對(duì)計(jì)算機(jī)系統(tǒng)進(jìn)行一系列的組裝測(cè)試和確認(rèn)測(cè)試。
* 系統(tǒng)測(cè)試的目的在于通過與系統(tǒng)的需求定義作比較, 發(fā)現(xiàn)軟件與系統(tǒng)的定義不符合或與之矛盾的地方。

軟件測(cè)試流程有幾個(gè)階段

軟件測(cè)試一般分為4個(gè)階段：單元測(cè)試、集成測(cè)試、系統(tǒng)測(cè)試、驗(yàn)收測(cè)試。

軟件測(cè)試是貫穿整個(gè)軟件生命周期的，軟件測(cè)試的對(duì)象包括軟件需求、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì)、軟件運(yùn)行環(huán)境、可運(yùn)行程序和軟件源代碼等。

軟件測(cè)試包括質(zhì)量、人員、資源、技術(shù)和流程要素，以及測(cè)試覆蓋率和測(cè)試效率兩個(gè)目標(biāo)。

單元測(cè)試：單元測(cè)試是針對(duì)軟件設(shè)計(jì)的最小單位--程序模塊甚至代碼段進(jìn)行正確性檢驗(yàn)的測(cè)試工作，通常由開發(fā)人員進(jìn)行。

對(duì)于單元測(cè)試中單元的含義，一般來說，要根據(jù)實(shí)際情況去判定其具體含義，如C語言中單元指一個(gè)函數(shù)，Java里單元指一個(gè)類，圖形化的軟件中可以指一個(gè)窗口或一個(gè)菜單等。

軟件測(cè)試的基本流程（重點(diǎn)）。

1、測(cè)試需求分析階段：閱讀需求，理解需求，主要就是對(duì)業(yè)務(wù)的學(xué)習(xí)，分析需求點(diǎn)，參與需求評(píng)審會(huì)議。

2、測(cè)試計(jì)劃階段：主要任務(wù)就是編寫測(cè)試計(jì)劃，參考軟件需求規(guī)格說明書，項(xiàng)目總體計(jì)劃，內(nèi)容包括測(cè)試范圍（來自需求文檔），進(jìn)度安排，人力物力的分配，整體測(cè)試策略的制定。風(fēng)險(xiǎn)評(píng)估與規(guī)避措施有一個(gè)制定。

3、測(cè)試設(shè)計(jì)階段：主要是編寫測(cè)試用例，會(huì)參考需求文檔（原型圖），概要設(shè)計(jì)，詳細(xì)設(shè)計(jì)等文檔，用例編寫完成之后會(huì)進(jìn)行評(píng)審。

4、測(cè)試執(zhí)行階段：搭建環(huán)境，執(zhí)行冒煙測(cè)試（預(yù)測(cè)試）然后進(jìn)入正式測(cè)試，bug管理直到測(cè)試結(jié)束。

5、測(cè)試評(píng)估階段：出測(cè)試報(bào)告，確認(rèn)是否可以上線。