軟件測試主要工作內(nèi)容是驗證（verification）和確認(rèn)（validation），下面分別給出其概念：
驗證(verification)是保證軟件正確地實現(xiàn)了一些特定功能的一系列活動， 即保證軟件以正確的方式來做了這個事件(Do it right)
1.確定軟件生存周期中的一個給定階段的產(chǎn)品是否達到前階段確立的需求的過程。
2.程序正確性的形式證明，即采用形式理論證明程序符合設(shè)計規(guī)約規(guī)定的過程。
3.評審、審查、測試、檢查、審計等各類活動，或?qū)δ承╉椞幚怼⒎?wù)或文件等是否和規(guī)定的需求相一致進行判斷和提出報告。
確認(rèn)（validation）是一系列的活動和過程，目的是想證實在一個給定的外部環(huán)境中軟件的邏輯正確性。即保證軟件做了你所期望的事情。（Do the right thing）
1.靜態(tài)確認(rèn)，不在計算機上實際執(zhí)行程序，通過人工或程序分析來證明軟件的正確性。
2.動態(tài)確認(rèn)，通過執(zhí)行程序做分析，測試程序的動態(tài)行為，以證實軟件是否存在問題。
軟件測試的對象不僅僅是程序測試，軟件測試應(yīng)該包括整個軟件開發(fā)期間各個階段所產(chǎn)生的文檔，如需求規(guī)格說明、概要設(shè)計文檔、詳細(xì)設(shè)計文檔，當(dāng)然軟件測試的主要對象還是源程序。
測試方法
等價類
1.定義
是把所有可能的輸入數(shù)據(jù)，即程序的輸入域劃分成若干部分（子集），然后從每一個子集中選取少數(shù)具有代表性的數(shù)據(jù)作為測試用例。該方法是一種重要的，常用的黑盒測試用例設(shè)計方法。
2.劃分等價類
等價類是指某個輸入域的子集合。在該子集合中，各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的，并合理地假定：測試某等價類的代表值就等于對這一類其它值的測試，因此，可以把全部輸入數(shù)據(jù)合理劃分為若干等價類，在每一個等價類中取一個數(shù)據(jù)作為測試的輸入條件就可以用少量代表性的測試數(shù)據(jù)取得較好的測試結(jié)果。等價類劃分可有兩種不同的情況：有效等價類和無效等價類。
1)有效等價類
是指對于程序的規(guī)格說明來說是合理的、有意義的輸入數(shù)據(jù)構(gòu)成的集合。利用有效等價類可檢驗程序是否實現(xiàn)了規(guī)格說明中所規(guī)定的功能和性能。
2)無效等價類
與有效等價類的定義恰巧相反。無效等價類指對程序的規(guī)格說明是不合理的或無意義的輸入數(shù)據(jù)所構(gòu)成的集合。對于具體的問題，無效等價類至少應(yīng)有一個，也可能有多個。
設(shè)計測試用例時，要同時考慮這兩種等價類。因為軟件不僅要能接收合理的數(shù)據(jù)，也要能經(jīng)受意外的考驗，這樣的測試才能確保軟件具有更高的可靠性。
3.劃分等價類的標(biāo)準(zhǔn)
1)完備測試、避免冗余；
2)劃分等價類重要的是：集合的劃分，劃分為互不相交的一組子集，而子集的并是整個集合；
3)并是整個集合：完備性；
4)子集互不相交：保證一種形式的無冗余性；
5)同一類中標(biāo)識（選擇）一個測試用例，同一等價類中，往往處理相同，相同處理映射到"相同的執(zhí)行路徑"。
4.劃分等價類的方法
1)在輸入條件規(guī)定了取值范圍或值的個數(shù)的情況下，則可以確立一個有效等價類和兩個無效等價類。
如：輸入值是學(xué)生成績，范圍是0～100。
2)在輸入條件規(guī)定了輸入值的集合或者規(guī)定了"必須如何"的條件的情況下，可確立一個有效等價類和一個無效等價類。
邊界值
1. 定義：邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界。
2. 與等價劃分的區(qū)別
1) 邊界值分析不是從某等價類中隨便挑一個作為代表，而是使這個等價類的每個邊界都要作為測試條件。
2) 邊界值分析不僅考慮輸入條件，還要考慮輸出空間產(chǎn)生的測試情況。
3. 邊界值分析方法的考慮：
長期的測試工作經(jīng)驗告訴我們，大量的錯誤是發(fā)生在輸入或輸出范圍的邊界上，而不是發(fā)生在輸入輸出范圍的內(nèi)部。因此針對各種邊界情況設(shè)計測試用例，可以查出更多的錯誤。
使用邊界值分析方法設(shè)計測試用例，首先應(yīng)確定邊界情況。通常輸入和輸出等價類的邊界，就是應(yīng)著重測試的邊界情況。應(yīng)當(dāng)選取正好等于，剛剛大于或剛剛小于邊界的值作為測試數(shù)據(jù)，而不是選取等價類中的典型值或任意值作為測試數(shù)據(jù)。
4. 常見的邊界值
1) 對16-bit 的整數(shù)而言 32767 和 -32768 是邊界
2) 屏幕上光標(biāo)在最左上、最右下位置
3) 報表的第一行和最后一行
4) 數(shù)組元素的第一個和最后一個
5) 循環(huán)的第 0 次、第 1 次和倒數(shù)第 2 次、最后一次
5. 邊界值分析
1) 邊界值分析使用與等價類劃分法相同的劃分，只是邊界值分析假定錯誤更多地存在于劃分的邊界上，因此在等價類的邊界上以及兩側(cè)的情況設(shè)計測試用例。
例：測試計算平方根的函數(shù)
--輸入：實數(shù)
--輸出：實數(shù)
--規(guī)格說明：當(dāng)輸入一個0或比0大的數(shù)的時候，返回其正平方根；當(dāng)輸入一個小于0的數(shù)時，顯示錯誤信息"平方根非法-輸入值小于0"并返回0；庫函數(shù)Print-Line可以用來輸出錯誤信息。[3]
詳細(xì)分類
角度細(xì)分
從是否關(guān)心軟件內(nèi)部結(jié)構(gòu)和具體實現(xiàn)的角度劃分（按測試分類）
A.白盒測試
B.黑盒測試
C.灰盒測試
從是否執(zhí)行程序的角度
A.靜態(tài)測試
B.動態(tài)測試。
階段細(xì)分
從軟件開發(fā)的過程按階段劃分有
A.單元測試
B.集成測試
C.確認(rèn)測試
D.系統(tǒng)測試
E.驗收測試
F.回歸測試
G.Alpha測試
H.Beta測試
* 測試過程按4個步驟進行，即單元測試、集成測試、確認(rèn)測試和系統(tǒng)測試及發(fā)布測試。
* 開始是單元測試，集中對用源代碼實現(xiàn)的每一個程序單元進行測試，檢查各個程序模塊是否正確地實現(xiàn)了規(guī)定的功能。
*集成測試把已測試過的模塊組裝起來，主要對與設(shè)計相關(guān)的軟件體系結(jié)構(gòu)的構(gòu)造進行測試。
* 確認(rèn)測試則是要檢查已實現(xiàn)的軟件是否滿足了需求規(guī)格說明中確定了的各種需求，以及軟件配置是否完全、正確。
* 系統(tǒng)測試把已經(jīng)經(jīng)過確認(rèn)的軟件納入實際運行環(huán)境中，與其它系統(tǒng)成份組合在一起進行測試。
單元測試 (Unit Testing)
* 單元測試又稱模塊測試，是針對軟件設(shè)計的最小單位 ─ 程序模塊，進行正確性檢驗的測試工作。其目的在于發(fā)現(xiàn)各模塊內(nèi)部可能存在的各種差錯。
* 單元測試需要從程序的內(nèi)部結(jié)構(gòu)出發(fā)設(shè)計測試用例。多個模塊可以平行地獨立進行單元測試。
1. 單元測試的內(nèi)容
* 在單元測試時，測試者需要依據(jù)詳細(xì)設(shè)計說明書和源程序清單，了解該模塊的I/O條件和模塊的邏輯結(jié)構(gòu)，主要采用白盒測試的測試用例，輔之以黑盒測試的測試用例，使之對任何合理的輸入和不合理的輸入，都能鑒別和響應(yīng)。
(1) 模塊接口測試
* 在單元測試的開始，應(yīng)對通過被測模塊的數(shù)據(jù)流進行測試。測試項目包括：
--調(diào)用本模塊的輸入?yún)?shù)是否正確；
--本模塊調(diào)用子模塊時輸入給子模塊的參數(shù)是否正確；
--全局量的定義在各模塊中是否一致
* 在做內(nèi)外存交換時要考慮：
--文件屬性是否正確；
--OPEN與CLOSE語句是否正確；
--緩沖區(qū)容量與記錄長度是否匹配；
--在進行讀寫操作之前是否打開了文件；
--在結(jié)束文件處理時是否關(guān)閉了文件；
--正文書寫/輸入錯誤，
--I/O錯誤是否檢查并做了處理。
(2) 局部數(shù)據(jù)結(jié)構(gòu)測試
* 不正確或不一致的數(shù)據(jù)類型說明
* 使用尚未賦值或尚未初始化的變量
* 錯誤的初始值或錯誤的缺省值
* 變量名拼寫錯或書寫錯
* 不一致的數(shù)據(jù)類型
* 全局?jǐn)?shù)據(jù)對模塊的影響
(3) 路徑測試
* 選擇適當(dāng)?shù)臏y試用例，對模塊中重要的執(zhí)行路徑進行測試。
* 應(yīng)當(dāng)設(shè)計測試用例查找由于錯誤的計算、不正確的比較或不正常的控制流而導(dǎo)致的錯誤。
* 對基本執(zhí)行路徑和循環(huán)進行測試可以發(fā)現(xiàn)大量的路徑錯誤。
(4) 錯誤處理測試
* 出錯的描述是否難以理解
* 出錯的描述是否能夠?qū)﹀e誤定位
* 顯示的錯誤與實際的錯誤是否相符
* 對錯誤條件的處理正確與否
* 在對錯誤進行處理之前，錯誤條件是否已經(jīng)引起系統(tǒng)的干預(yù)等
(5) 邊界測試
* 注意數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值時出錯的可能性。對這些地方要仔細(xì)地選擇測試用例，認(rèn)真加以測試。
* 如果對模塊運行時間有要求的話，還要專門進行關(guān)鍵路徑測試，以確定最壞情況下和平均意義下影響模塊運行時間的因素。
2. 單元測試的步驟
* 模塊并不是一個獨立的程序，在考慮測試模塊時，同時要考慮它和外界的聯(lián)系，用一些輔助模塊去模擬與被測模塊相聯(lián)系的其它模塊。
--驅(qū)動模塊 (driver)
--樁模塊 (stub) ── 存根模塊
* 如果一個模塊要完成多種功能，可以將這個模塊看成由幾個小程序組成。必須對其中的每個小程序先進行單元測試要做的工作，對關(guān)鍵模塊還要做性能測試。
* 對支持某些標(biāo)準(zhǔn)規(guī)程的程序，更要著手進行互聯(lián)測試。有人把這種情況特別稱為模塊測試，以區(qū)別單元測試。
集成測試（Integrated Testing）
* 集成測試 (組裝測試、聯(lián)合測試）
* 通常，在單元測試的基礎(chǔ)上，需要將所有模塊按照設(shè)計要求組裝成為系統(tǒng)。這時需要考慮的問題是：
--在把各個模塊連接起來的時候，穿越模塊接口的數(shù)據(jù)是否會丟失；
--一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響
--各個子功能組合起來，能否達到預(yù)期要求的父功能；
--全局?jǐn)?shù)據(jù)結(jié)構(gòu)是否有問題；
--單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。
在單元測試的同時可進行集成測試，
發(fā)現(xiàn)并排除在模塊連接中可能出現(xiàn)
的問題，最終構(gòu)成要求的軟件系統(tǒng)。
* 子系統(tǒng)的集成測試特別稱為部件測試，它所做的工作是要找出集成后的子系統(tǒng)與系統(tǒng)需求規(guī)格說明之間的不一致。
* 通常，把模塊集成成為系統(tǒng)的方式有兩種
--一次性集成方式
--增殖式集成方式
1. 一次性集成方式(big bang)
* 它是一種非增殖式組裝方式。也叫做整體拼裝。
* 使用這種方式，首先對每個模塊分別進行模塊測試，然后再把所有模塊組裝在一起進行測試，最終得到要求的軟件系統(tǒng)。
2. 增殖式集成方式
* 這種集成方式又稱漸增式集成
* 首先對一個個模塊進行模塊測試，然后將這些模塊逐步組裝成較大的系統(tǒng)
* 在集成的過程中邊連接邊測試，以發(fā)現(xiàn)連接過程中產(chǎn)生的問題
* 通過增殖逐步組裝成為要求的軟件系統(tǒng)。
(1) 自頂向下的增殖方式
* 這種集成方式將模塊按系統(tǒng)程序結(jié)構(gòu)，沿控制層次自頂向下進行組裝。
* 自頂向下的增殖方式在測試過程中較早地驗證了主要的控制和判斷點。
* 選用按深度方向組裝的方式，可以首先實現(xiàn)和驗證一個完整的軟件功能。
(2) 自底向上的增殖方式
* 這種集成的方式是從程序模塊結(jié)構(gòu)的最底層的模塊開始集成和測試。
* 因為模塊是自底向上進行組裝，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）已經(jīng)組裝并測試完成，所以不再需要樁模塊。在模塊的測試過程中需要從子模塊得到的信息可以直接運行子模塊得到。
* 自頂向下增殖的方式和自底向上增殖的方式各有優(yōu)缺點。
* 一般來講，一種方式的優(yōu)點是另一種方式的缺點。
(3) 混合增殖式測試
* 衍變的自頂向下的增殖測試
--首先對輸入/輸出模塊和引入新算法模塊進行測試；
--再自底向上組裝成為功能相當(dāng)完整且相對獨立的子系統(tǒng)；
--然后由主模塊開始自頂向下進行增殖測試。
* 自底向上-自頂向下的增殖測試
--首先對含讀操作的子系統(tǒng)自底向上直至根結(jié)點模塊進行組裝和測試；
--然后對含寫操作的子系統(tǒng)做自頂向下的組裝與測試。
* 回歸測試
--這種方式采取自頂向下的方式測試被修改的模塊及其子模塊；
--然后將這一部分視為子系統(tǒng)，再自底向上測試。
關(guān)鍵模塊問題
* 在組裝測試時，應(yīng)當(dāng)確定關(guān)鍵模塊，對這些關(guān)鍵模塊及早進行測試。
* 關(guān)鍵模塊的特征：
① 滿足某些軟件需求
② 在程序的模塊結(jié)構(gòu)中位于較高的層次（高層控制模塊）
③ 較復(fù)雜、較易發(fā)生錯誤
④ 有明確定義的性能要求。
確認(rèn)測試（Validation Testing）
* 確認(rèn)測試又稱有效性測試。任務(wù)是驗證軟件的功能和性能及其它特性是否與用戶的要求一致。
* 對軟件的功能和性能要求在軟件需求規(guī)格說明書中已經(jīng)明確規(guī)定。它包含的信息就是軟件確認(rèn)測試的基礎(chǔ)。
1. 進行有效性測試（黑盒測試）
* 有效性測試是在模擬的環(huán)境 (可能就是開發(fā)的環(huán)境) 下，運用黑盒測試的方法，驗證被測軟件是否滿足需求規(guī)格說明書列出的需求。
* 首先制定測試計劃，規(guī)定要做測試的種類。還需要制定一組測試步驟，描述具體的測試用例。
* 通過實施預(yù)定的測試計劃和測試步驟，確定
--軟件的特性是否與需求相符；
--所有的文檔都是正確且便于使用；
--同時，對其它軟件需求，例如可移植性、兼容性、出錯自動恢復(fù)、可維護性等，也都要進行測試
* 在全部軟件測試的測試用例運行完后，所有的測試結(jié)果可以分為兩類：
--測試結(jié)果與預(yù)期的結(jié)果相符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明書相符合，從而這部分程序被接受。
--測試結(jié)果與預(yù)期的結(jié)果不符。這說明軟件的這部分功能或性能特征與需求規(guī)格說明不一致，因此要為它提交一份問題報告。
2. 軟件配置復(fù)查
n 軟件配置復(fù)查的目的是保證
u 軟件配置的所有成分都齊全；
u 各方面的質(zhì)量都符合要求；
u 具有維護階段所必需的細(xì)節(jié)；
u 而且已經(jīng)編排好分類的目錄。
n 應(yīng)當(dāng)嚴(yán)格遵守用戶手冊和操作手冊中規(guī)定的使用步驟，以便檢查這些文檔資料的完整性和正確性。
系統(tǒng)測試（System Testing）
* 系統(tǒng)測試，是將通過確認(rèn)測試的軟件，作為整個基于計算機系統(tǒng)的一個元素，與計算機硬件、外設(shè)、某些支持軟件、數(shù)據(jù)和人員等其它系統(tǒng)元素結(jié)合在一起，在實際運行環(huán)境下，對計算機系統(tǒng)進行一系列的組裝測試和確認(rèn)測試。
* 系統(tǒng)測試的目的在于通過與系統(tǒng)的需求定義作比較， 發(fā)現(xiàn)軟件與系統(tǒng)的定義不符合或與之矛盾的地方。
驗收測試（Acceptance Testing）
* 在通過了系統(tǒng)的有效性測試及軟件配置審查之后，就應(yīng)開始系統(tǒng)的驗收測試。
* 驗收測試是以用戶為主的測試。軟件開發(fā)人員和QA（質(zhì)量保證）人員也應(yīng)參加。
* 由用戶參加設(shè)計測試用例，使用生產(chǎn)中的實際數(shù)據(jù)進行測試。
* 在測試過程中，除了考慮軟件的功能和性能外，還應(yīng)對軟件的可移植性、兼容性、可維護性、錯誤的恢復(fù)功能等進行確認(rèn)。
*確認(rèn)測試應(yīng)交付的文檔有：
--確認(rèn)測試分析報告
--最終的用戶手冊和操作手冊
--項目開發(fā)總結(jié)報告。
測試流程
1、制定測試計劃[4]
2、編輯測試用例
3、執(zhí)行測試用例
4、發(fā)現(xiàn)并提交BUG
5、開發(fā)組修正BUG
6、對已修正BUG進行返測
7、修正完成的BUG將狀態(tài)置為已關(guān)閉，未正確修正的BUG重新激活
測試階段
單元測試
單元測試是對軟件組成單元進行測試，其目的是檢驗軟件基本組成單位的正確性，測試的對象是軟件設(shè)計的最小單位：模塊。
集成測試
集成測試也稱聯(lián)合測試，將程序模塊采用適當(dāng)?shù)募刹呗越M裝起來，對系統(tǒng)的接口及集成后的功能進行正確性檢測的測試工作。其主要目的是檢查軟件單位之間的接口是否正確，集成測試的對象是已經(jīng)經(jīng)過單元測試的模塊。
系統(tǒng)測試
系統(tǒng)測試[5]  主要包括功能測試、界面測試、可靠性測試、易用性測試、性能測試。 功能測試主要針對包括功能可用性、功能實現(xiàn)程度（功能流程&業(yè)務(wù)流程、數(shù)據(jù)處理&業(yè)務(wù)數(shù)據(jù)處理）方面測試。
回歸測試
回歸測試指在軟件維護階段，為了檢測代碼修改而引入的錯誤所進行的測試活動。回歸測試是軟件維護階段的重要工作，有研究表明，回歸測試帶來的耗費占軟件生命周期的1/3總費用以上。
與普通的測試不同，在回歸測試過程開始的時候，測試者有一個完整的測試用例集可供使用，因此，如何根據(jù)代碼的修改情況對已有測試用例集進行有效的復(fù)用是回歸測試研究的重要方向，此外，回歸測試的研究方向還涉及自動化工具，面向?qū)ο蠡貧w測試，測試用例優(yōu)先級，回歸測試用例補充生成等。
測試模型
V模型
測試階段:
單元測試
集成測試
系統(tǒng)測試
實現(xiàn)意義
V模型是軟件開發(fā)瀑布模型的變種，它反映了測試活動與分析和設(shè)計的關(guān)系 。
從左到右，描述了基本的開發(fā)過程和測試行為，非常明確地標(biāo)明了測試過程中存在的不同級別，并且清楚地描述了這些測試階段和開發(fā)過程期間各階段的對應(yīng)關(guān)系 。
左邊依次下降的是開發(fā)過程各階段，與此相對應(yīng)的是右邊依次上升的部分，即各測試過程的各個階段。
用戶需求 驗收測試
需求分析和系統(tǒng)設(shè)計 確認(rèn)測試和系統(tǒng)測試
概要設(shè)計 集成測試
詳細(xì)設(shè)計 單元測試
編碼
V模型問題
1.測試是開發(fā)之后的一個階段。
2.測試的對象就是程序本身。
3.實際應(yīng)用中容易導(dǎo)致需求階段的錯誤一直到最后系統(tǒng)測試階段才被發(fā)現(xiàn)。
4.整個軟件產(chǎn)品的過程質(zhì)量保證完全依賴于開發(fā)人員的能力和對工作的責(zé)任心，而且上一步的結(jié)果必須是充分和正確的，如果任何一個環(huán)節(jié)出了問題，則必將嚴(yán)重的影響整個工程的質(zhì)量和預(yù)期進度
W模型
W模型由Evolutif公司公司提出，相對于V模型，W模型增加了軟件各開發(fā)階段中應(yīng)同步進行的驗證和確認(rèn)活動。W模型由兩個V字型模型組成，分別代表測試與開發(fā)過程，圖中明確表示出了測試與開發(fā)的并行關(guān)系。 W模型強調(diào)：測試伴隨著整個軟件開發(fā)周期，而且測試的對象不僅僅是程序，需求、設(shè)計等同樣要測試，也就是說，測試與開發(fā)是同步進行的。W模型有利于盡早地全面的發(fā)現(xiàn)問題。例如，需求分析完成后，測試人員就應(yīng)該參與到對需求的驗證和確認(rèn)活動中，以盡早地找出缺陷所在。同時，對需求的測試也有利于及時了解項目難度和測試風(fēng)險，及早制定應(yīng)對措施，這將顯著減少總體測試時間，加快項目進度。 但W模型也存在局限性。在W模型中，需求、設(shè)計、編碼等活動被視為串行的，同時，測試和開發(fā)活動也保持著一種線性的前后關(guān)系，上一階段完全結(jié)束，才可正式開始下一個階段工作。這樣就無法支持迭代的開發(fā)模型。對于當(dāng)前軟件開發(fā)復(fù)雜多變的情況，W模型并不能解除測試管理面臨著困惑。
H模型
H模型中， 軟件測試過程活動完全獨立，貫穿于整個產(chǎn)品的周期，與其他流程并發(fā)地進行，某個測試點準(zhǔn)備就緒時，就可以從測試準(zhǔn)備階段進行到測試執(zhí)行階段。軟件測試可以盡早的進行，并且可以根據(jù)被測物的不同而分層次進行。
這個示意圖演示了在整個生產(chǎn)周期中某個層次上的一次測試"微循環(huán)"。圖中標(biāo)注的其它流程可以是任意的開發(fā)流程，例如設(shè)計流程或者編碼流程。也就是說， 只要測試條件成熟了，測試準(zhǔn)備活動完成了，測試執(zhí)行活動就可以進行了。
H模型揭示了一個原理：軟件測試是一個獨立的流程，貫穿產(chǎn)品整個生命周期，與其他流程并發(fā)地進行。H模型指出軟件測試要盡早準(zhǔn)備， 盡早執(zhí)行。不同的測試活動可以是按照某個次序先后進行的，但也可能是反復(fù)的，只要某個測試達到準(zhǔn)備就緒點，測試執(zhí)行活動就可以開展。
X模型
X模型也是對V模型的改進，X模型提出針對單獨的程序片段進行相互分離的編碼和測試，此后通過頻繁的交接，通過集成最終合成為可執(zhí)行的程序。X模型的左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此后將進行頻繁的交接，通過集成最終成為可執(zhí)行的程序，然后再對這些可執(zhí)行程序進行測試。己通過集成測試的成品可以進行封裝并提交給用戶，也可以作為更大規(guī)模和范圍內(nèi)集成的一部分。多根并行的曲線表示變更可以在各個部分發(fā)生。由圖中可見，X模型還定位了探索性測試，這是不進行事先計劃的特殊類型的測試，這一方式往往能幫助有經(jīng)驗的測試人員在測試計劃之外發(fā)現(xiàn)更多的軟件錯誤。但這樣可能對測試造成人力、物力和財力的浪費，對測試員的熟練程度要求比較高。