余久久, 張佑生

(安徽三聯(lián)學(xué)院 計算機(jī)科學(xué)與技術(shù)系,安徽 合肥 230601)

0 引 言

軟件探索性測試[1]是一種測試思想或測試策略，要求測試人員在測試過程中同時展開測試學(xué)習(xí)、測試設(shè)計、測試執(zhí)行和測試結(jié)果評估等活動，達(dá)到持續(xù)優(yōu)化測試工作的目的。探索性測試不是、也不隸屬于某一種具體的軟件測試技術(shù)(白盒測試、黑盒測試、灰盒測試)，在實際測試應(yīng)用中不會受到測試軟件的某一特性或方面(如功能測試、性能測試、易用性測試、界面測試等)所約束，在軟件開發(fā)過程中的任一測試階段(如單元測試、集成測試、系統(tǒng)測試、驗收測試等)均可應(yīng)用，亦可運用于不同的測試實施組織(如用戶測試、第三方測試等)或與相應(yīng)的測試技術(shù)結(jié)合起來。

探索性測試需要測試人員在測試過程中反復(fù)了解與學(xué)習(xí)被測軟件，結(jié)合自身測試經(jīng)驗把不斷整理與綜合分析得出的測試信息快速反饋至下一次測試活動中，從而激發(fā)出更多的測試思想或測試策略。探索性測試也是當(dāng)前軟件測試領(lǐng)域中較前沿的思想理論，并不完全依賴于事先所設(shè)計的一塵不變的測試場景或測試腳本。以測試目標(biāo)為向?qū)В瑴y試人員充分利用任何與測試目標(biāo)有關(guān)聯(lián)的信息，例如需求文檔、用戶手冊、甚至是被測軟件或類似產(chǎn)品的缺陷歷史信息等，在無明確的測試指導(dǎo)環(huán)境下通過主動的“探索”來發(fā)現(xiàn)軟件缺陷。

1 探索性測試

1.1 探索性測試的引入

探索性測試是近年來針對腳本化測試過程中因嚴(yán)格遵循“先測試設(shè)計，后測試執(zhí)行”策略所暴露出的若干問題[2-5]所提出。例如，測試初期因測試需求不明確而無法確定測試場景；測試執(zhí)行對需求變更的應(yīng)對能力較弱，測試環(huán)境與組合的不斷變化使腳本化測試難以及時跟蹤；使用事先設(shè)計好的測試用例去指導(dǎo)測試實施過程會降低測試者的主觀能動性；耗費在測試設(shè)計階段的時間已遠(yuǎn)遠(yuǎn)超過測試執(zhí)行時間而增加測試成本等。鑒于現(xiàn)代企業(yè)在實際測試項目的運作過程中均存在開發(fā)初期文檔資料缺乏、短時間內(nèi)開發(fā)版本演化過于頻繁或產(chǎn)品不穩(wěn)定、測試人員缺乏相應(yīng)專業(yè)技能而沒有充裕時間編寫測試計劃和測試腳本的現(xiàn)狀，測試人員在測試實踐中均有意或無意的不同程度采用“探索或摸索的思想”執(zhí)行測試過程來彌補腳本化測試的不足，從而引入了對軟件“探索測試”的思維方式。

1.2 探索性測試的組織與實施過程

探索性測試中，平行展開且相互支持而形成循環(huán)反饋的學(xué)習(xí)、設(shè)計、執(zhí)行與結(jié)果分析四個測試活動構(gòu)成了測試實施過程。學(xué)習(xí)階段中，學(xué)習(xí)的內(nèi)容不僅包括測試軟件的用途和系統(tǒng)需求、顯示用途及特性，也包括對相關(guān)軟件的風(fēng)險與失效信息(如同類軟件或被測對象以前版本的失效信息)、被測對象的隱形規(guī)格說明(如開發(fā)人員、專家和用戶等軟件不同利益相關(guān)者提出的設(shè)計規(guī)格要求)等。設(shè)計階段中，如何由學(xué)習(xí)階段所獲得一切與軟件有關(guān)的信息而設(shè)計出高效的測試用例(集)來定位軟件潛在的缺陷風(fēng)險是該階段重要的挑戰(zhàn)。文獻(xiàn)[6]把開發(fā)針對測試對象的測試數(shù)據(jù)與判斷準(zhǔn)則作為探索性測試設(shè)計的輸出，但不必形成規(guī)范的腳本文檔。文獻(xiàn)[7]認(rèn)為設(shè)計內(nèi)容來源于軟件的失效列表和簡單的被測功能信息清單。文獻(xiàn)[8]認(rèn)為把如何從應(yīng)用于某具體測試技術(shù)中所獲得的以及同類軟件的缺陷或風(fēng)險列表中生成測試用例(集)是探索性測試設(shè)計的關(guān)鍵。文獻(xiàn)[9]提出了構(gòu)建分別由測試功能點描述信息與測試人員組合資源分配以行與列所組成的二維測試圖作為測試設(shè)計對象，通過把不同的測試功能點組合分配給不同測試人員測試所生成的各種排列組合來指導(dǎo)探索性測試的執(zhí)行。執(zhí)行階段可以采用手工測試或自動化測試方式，通常采用不拘泥于測試計劃實現(xiàn)，而易于激發(fā)測試人員測試主觀創(chuàng)造性的結(jié)對測試方式[10](兩位測試人員同時參與測試過程，其中一人執(zhí)行測試活動，另一人記錄測試結(jié)果并且提供測試建議或提出問題)進(jìn)行。其優(yōu)點在于把兩個不同背景的測試人員的測試信息洞察力同時運用于測試用例的設(shè)計或分析問題，有利于測試思想的激發(fā)與延伸。結(jié)果分析主要是判斷測試用例是否執(zhí)行，測試過程中是否產(chǎn)生新發(fā)現(xiàn)或存在測試遺漏等問題。測試用例執(zhí)行通過的評判標(biāo)準(zhǔn)是該階段的關(guān)鍵。作者傾向于文獻(xiàn)[11]中提出的準(zhǔn)則。

實施探索性測試的難點在于測試執(zhí)行環(huán)節(jié)，需要具有豐富測試設(shè)計經(jīng)驗的測試者在項目開發(fā)周期中不完全依賴事先編寫好的測試用例或測試腳本，充分發(fā)揮自由想象空間去探索被測對象。當(dāng)前國內(nèi)外不少專家學(xué)者都一致提出“腳本化測試為主、探索性測試為輔”的二者相互融合的方案，在不同的項目中采取不同的結(jié)合方式可以取得良好的測試效果。比較典型的有：軟件測試之初以正式腳本為指導(dǎo)，然后在腳本中隨機(jī)加入各種變化進(jìn)行探索性測試并觀察[12]；或是先有計劃地修改事先所制定測試腳本中定義的某些步驟再進(jìn)行測試；以及先脫離測試腳本的描述，而使用探索性測試思想進(jìn)行自由發(fā)揮，再馬上回到腳本中[13]等。盡管以上研究已取得一定進(jìn)展，但是當(dāng)前針對有關(guān)在探索性測試執(zhí)行環(huán)節(jié)中如何取代腳本化測試中事先設(shè)計測試用例的活動，而采用另一種途徑計劃、建構(gòu)、引導(dǎo)及追蹤測試過程的探究仍屬空白，這將成為未來關(guān)注的熱點方向。

1.3 探索性測試的特點

近年來很多文獻(xiàn)[14-16]只是把探索性測試歸結(jié)為是一種可有可無的隨機(jī)測試方法，旨在發(fā)現(xiàn)更多的缺陷。和隨機(jī)測試不同，探索性測試注重對測試結(jié)果的分析與判斷，把對被測對象的學(xué)習(xí)、測試設(shè)計、測試執(zhí)行與分析結(jié)果作為并行與相互支持的測試活動來形成一個快速迭代，達(dá)到持續(xù)優(yōu)化測試價值的目的。測試者可以缺乏測試經(jīng)驗，但是需要具備一定的天賦、測試直覺及想象力，高水平智商與外向型性格將直接決定探索性測試的效率[17]。探索性測試運用于敏捷開發(fā)項目會呈現(xiàn)出較高測試效率。敏捷開發(fā)模式下，測試者設(shè)計和執(zhí)行的內(nèi)容來源于頻繁演化的測試用例。不斷設(shè)計與執(zhí)行被測對象中功能及數(shù)據(jù)的不同輸入組合將導(dǎo)致測試對象中新的測試組合，從而拓寬和增加測試覆蓋率[18]。然而其所表現(xiàn)出的測試組合無窮性，在腳本化測試中卻無法預(yù)先全部定義。此外，迭代開發(fā)早期所呈現(xiàn)出軟件需求變更頻繁、測試場景不確定等因素將導(dǎo)致軟件設(shè)計及測試文檔的更新有難度，而探索性測試在實際應(yīng)用中所具備的文檔最小化特征將體現(xiàn)出很好的測試優(yōu)勢。

但是探索性測試也存在不足之處。由于當(dāng)前缺乏系統(tǒng)的理論指導(dǎo)，不了解應(yīng)用探索性測試的具體流程及缺乏事先計劃好的測試架構(gòu)，在評估測試效果與發(fā)現(xiàn)測試覆蓋率方面還存在困難。文獻(xiàn)[19]指出探索性測試在實際測試項目的應(yīng)用中沒有預(yù)防缺陷的能力。文獻(xiàn)[20]則認(rèn)為探索性測試會導(dǎo)致純自由或單一的測試過程，使得測試者在測試中沒有重點，漫無目的嘗試各種情況試圖發(fā)現(xiàn)軟件缺陷，測試效率低下。所以目前大多數(shù)測試機(jī)構(gòu)都是把探索性測試及其應(yīng)用作為對常規(guī)腳本化測試過程的有益補充。

1.4 對發(fā)現(xiàn)缺陷特征的研究

對發(fā)現(xiàn)缺陷特征方面的研究也是近幾年軟件測試研究的熱點，目前國內(nèi)研究尚未起步。但是國外一些測試機(jī)構(gòu)已開始嘗試，主要采取與腳本化測試過程的實驗數(shù)據(jù)比較來研究所發(fā)現(xiàn)缺陷的數(shù)目、特征類型及覆蓋情況，并取得一定的成果。Juha.Itkonen等人在文獻(xiàn)[21]中通過對兩組測試者就包含于事先植入錯誤的開源軟件分別進(jìn)行探索性與腳本化測試方式的實驗，實驗結(jié)果表明在發(fā)現(xiàn)缺陷的難度方面兩種測試方法無顯著區(qū)別，但就所發(fā)現(xiàn)缺陷的危害嚴(yán)重程度而言，探索性測試所發(fā)現(xiàn)的較嚴(yán)重的缺陷數(shù)目略高于腳本化測試，嚴(yán)重性低的缺陷數(shù)目卻明顯高于腳本化測試。在發(fā)現(xiàn)缺陷類型方面，探索性測試所發(fā)現(xiàn)的功能性缺陷數(shù)目略高于腳本化測試；而用戶界面接口缺陷與軟件可用性缺陷數(shù)目則要顯著高于腳本化測試。而在發(fā)現(xiàn)技術(shù)性缺陷及性能缺陷方面，探索性測試明顯低于腳本化測試。

同樣文獻(xiàn)[22]也認(rèn)為探索性測試能發(fā)現(xiàn)更多的用戶圖形界面接口缺陷，常規(guī)的腳本化測試過程中事先設(shè)計的測試用例在后續(xù)指導(dǎo)測試軟件用戶界面接口方面所起作用不大。

Prakash.V等人在文獻(xiàn)[23]中則根據(jù)迭代開發(fā)某算數(shù)計算器程序為例，分別通過腳本化與探索性兩種方法進(jìn)行測試，每次測試時間為8 h、共進(jìn)行7輪測試周期的迭代測試實驗(實驗數(shù)據(jù)如表1所示)。得出盡管腳本化測試與探索性測試都是可以發(fā)現(xiàn)大量缺陷，所發(fā)現(xiàn)的缺陷總數(shù)大體相當(dāng)(試驗中兩種測試方法所發(fā)現(xiàn)缺陷數(shù)目總數(shù)分別為51和59)。但是在基于迭代開發(fā)方式下，測試初期探索性測試在較短時間內(nèi)能發(fā)現(xiàn)較多的軟件缺陷，例如在前兩輪測試周期中腳本化測試與探索性測試所發(fā)現(xiàn)的缺陷數(shù)目分別為14與21。腳本化測試所發(fā)現(xiàn)的缺陷大都集中在有限的迭代測試階段(如第2輪、第3輪與第4輪)，而探索性測試所發(fā)現(xiàn)的缺陷相對較平均地分布在每次迭代測試階段中。

表1 迭代開發(fā)模式下兩種測試方法發(fā)現(xiàn)缺陷數(shù)目

2 探索性測試設(shè)計方法

需求分析階段為了更好地了解產(chǎn)品，更周密地測試，測試人員會將被測對象所包含的功能進(jìn)行逐一分解來制定相應(yīng)測試設(shè)計方法。探索性測試作為一種測試思想或思考風(fēng)格，需要在一些典型的測試輸入設(shè)計技術(shù)中(如黑盒測試技術(shù)中的等價類劃分，邊界值分析等)融入相應(yīng)的探索式的測試輸入組合與變化，以便測試人員快速探索與掌握并且設(shè)計出測試范圍內(nèi)的關(guān)鍵測試點。作者在結(jié)合文獻(xiàn)[24-26]的基礎(chǔ)上分別從被測對象的單個功能特性、多個功能交互特性、與基于系統(tǒng)功能交互特性三個方面從探索性測試輸入設(shè)計的角度總結(jié)出相應(yīng)的測試設(shè)計方法。

2.1 單個功能特性的測試設(shè)計方法

2.1.1聯(lián)想測試設(shè)計方法

適用于對被測對象的單一功能點進(jìn)行探索性測試的輸入設(shè)計。測試人員在無法全面了解被測對象的功能需求的環(huán)境下，探索使用的軟件產(chǎn)品，發(fā)現(xiàn)與記錄所遇到的缺陷，通過測試輸出進(jìn)一步補充與完善后續(xù)的測試設(shè)計活動。方法的核心是基于黑盒測試中的等價類劃分測試技術(shù)，歸納出的聯(lián)想測試設(shè)計方法如表2所示。

2.1.2互聯(lián)網(wǎng)測試設(shè)計方法

互聯(lián)網(wǎng)測試設(shè)計方法是基于互聯(lián)網(wǎng)環(huán)境下針對以網(wǎng)頁頁面形式所呈現(xiàn)的單個功能點，以用戶操作視角主要從互聯(lián)網(wǎng)頁面的可用性與安全性兩個方面啟發(fā)測試設(shè)計思路，進(jìn)行探索性的測試設(shè)計，學(xué)習(xí)與理解易遺漏的測試情景與異常流程。

表2 聯(lián)想測試設(shè)計方法

(注：① 無特定格式或含義，開發(fā)人員計劃中的或真實用戶使用的輸入值；② 測試輸入界面所提供的默認(rèn)值，如某一正常值、0值、空值、NULL等；③ 某些特殊情況下，或由某機(jī)緣巧合產(chǎn)生的輸入值：如字符A通過Shift+a輸入，變成了兩個輸入字符，可能與測試需求不符而發(fā)生測試異常；④ 測試輸入界面提供列表框或下拉列表框環(huán)境下，測試合法的輸入選項以及是否可以選定非法輸入選項；⑤ 用類似選擇-判斷結(jié)構(gòu)實現(xiàn)的語句體，用來判斷接受輸入值合法；⑥ 位于程序結(jié)尾處或某單獨文件中，檢測與處理整個程序所發(fā)生的任何一個錯誤的代碼段。)

2.1.3單個特性漫游測試設(shè)計方法

漫游探索性測試方法最早由James A. Whittaker提出，其最主要優(yōu)點是啟發(fā)與探索范圍更廣泛的測試設(shè)計思路，帶來更多的測試變化。作者在結(jié)合文獻(xiàn)[24,27]的基礎(chǔ)上從測試設(shè)計描述與實際測試意義(價值)兩個方面對單個被測特性歸納出多種漫游探索性測試設(shè)計方法，為新入職的測試人員與具備一定測試經(jīng)驗的測試人員啟發(fā)探索性測試思路，歸納后如表5所示。

2.2 基于多個功能交互特性測試設(shè)計方法

2.2.1場景探索測試設(shè)計方法

場景即從軟件需求分析中提煉出描述被測軟件功能及特性去實現(xiàn)用戶實際操作行為的問題，從而由各種行為的不同組合來生成相應(yīng)的測試用例及其集合[28]。由于場景一般包含多個測試用例來描述用戶完成某一任務(wù)的條件、步驟與結(jié)果，用戶為完成某一場景中的任務(wù)需要進(jìn)行幾個單一功能的交互操作，所以場景探索測試設(shè)計方法適合對被測對象的交互特性的測試設(shè)計，測試人員嘗試對場景的前提條件或?qū)崿F(xiàn)步驟做添增、刪除、重復(fù)、修改等相應(yīng)變化來探索發(fā)現(xiàn)更多缺陷。

基于交互特性的場景測試設(shè)計方法思想,是根據(jù)用戶在實際中往往很少按照開發(fā)人員事先設(shè)計好的場景中所描述的步驟或方法使用軟件，通過為已知或基本場景注入相應(yīng)變化進(jìn)行的探索測試手段。作者從探索場景變化方案、測試設(shè)計變化內(nèi)容、測試設(shè)計描述與測試意義(價值)四個方面較詳細(xì)歸納出具體的基于場景的探索性測試方法，歸納后如表3所示。

表3 基于交互特性的場景測試設(shè)計方法

2.2.2交互特性的漫游測試設(shè)計方法

基于交互特性的漫游探索測試設(shè)計方法的思路是在基礎(chǔ)測試場景的基礎(chǔ)上，探索被測任務(wù)可能產(chǎn)生的邏輯分支的步驟，先測試各個分支路徑(方向)，然后再回到場景描述的路徑(方向)測試。該測試設(shè)計思路適合指導(dǎo)在軟件需求細(xì)節(jié)未明確的情況下有效開展探索性測試過程，彌補前期在需求測試與需求評審的不足，在一定程度上快速保證了測試質(zhì)量與覆蓋率。作者同樣在文獻(xiàn)[24-25]的基礎(chǔ)上就從測試設(shè)計描述與實際測試意義(價值)兩個方面對被測對象交互特性列出了以下漫游探索性測試設(shè)計方法。

2.3 基于系統(tǒng)功能交互特性的測試設(shè)計方法

2.3.1通用功能性與穩(wěn)定性的測試設(shè)計方法

通用功能性與穩(wěn)定性的測試設(shè)計方法主要圍繞被測對象的使用目的、核心功能與潛在的不穩(wěn)定區(qū)域進(jìn)行的探索性測試設(shè)計方法。其專注于軟件核心任務(wù)的功能性和穩(wěn)定性。

該方法認(rèn)為產(chǎn)品的某些隱藏性功能在僅僅考慮測試與用戶交互情景,而忽視與系統(tǒng)服務(wù)、其它程序、文件系統(tǒng)的交互過程是無法被識別出的，測試人員在產(chǎn)品界面上也不能直接觀察出某些隱藏性功能的作用?；诖?，首先，把被測產(chǎn)品的功能在此測試設(shè)計方法中分為主要功能與貢獻(xiàn)性功能兩大類別。主要功能即從普通用戶的角度來看是否達(dá)到使用產(chǎn)品的主要目的；貢獻(xiàn)性功能即為使產(chǎn)品在使用上所具有相關(guān)實用性或易用性，提高用戶使用興趣的一些輔助性功能、增值服務(wù)類等隱藏性功能[24]。測試人員需要與軟件開發(fā)人員及產(chǎn)品經(jīng)理密切合作，重視與挖掘被測產(chǎn)品中的貢獻(xiàn)性功能。其次，測試人員還需要關(guān)注威脅產(chǎn)品穩(wěn)定性運行的若干潛在的不穩(wěn)定因素：例如被測產(chǎn)品與操作系統(tǒng)交互緊密的功能；涉及到多線程操作的功能；與其它產(chǎn)品進(jìn)行交互的功能等。具有資深測試經(jīng)驗的工程師可以就不穩(wěn)定因素參考與借鑒文獻(xiàn)[24]中表4所示的一些具有挑戰(zhàn)性的測試內(nèi)容及測試想法。

測試人員在了解產(chǎn)品目的，確定產(chǎn)品功能與識別產(chǎn)品運行不穩(wěn)定因素區(qū)域后，探索性設(shè)計每個被測功能點的測試用例，實施測試并記錄所發(fā)現(xiàn)問題。

2.3.2漫游地圖測試設(shè)計方法

漫游地圖測試設(shè)計思想[29,30]是在被測系統(tǒng)主要功能測試完畢之后，采用“漫游”方法探索測試某些易忽視功能與特性。其趣味性體現(xiàn)在將被測軟件比喻成一個城市，把一些易于忽視的功能需求劃分成“觀光特點”不同的“旅游區(qū)域”。測試人員需要從整體上分析與把握被測系統(tǒng)的需求與目的，詳細(xì)了解其需求說明文檔及架構(gòu)設(shè)計文檔，把被測系統(tǒng)功能需求劃分為“商業(yè)區(qū)”、“娛樂區(qū)”、“旅館區(qū)”、“破舊區(qū)”、“歷史區(qū)”、“旅游區(qū)”共六個測試著眼點不同的邏輯區(qū)域，在每一個區(qū)域內(nèi)確定出需要測試的單個特性或交互特性，運用前文所介紹的單個特性與交互特性的探索性測試設(shè)計方法進(jìn)行測試設(shè)計與執(zhí)行。與指導(dǎo)旅游者游玩城市不同區(qū)域所借助的城市旅行指南類似，漫游地圖對被測系統(tǒng)區(qū)域的劃分從邏輯上劃分了產(chǎn)品的“非主要”特性，可以有效幫助測試人員探索出某些容易被忽視的測試范圍，制定出相應(yīng)的測試設(shè)計方法。同樣作者在文獻(xiàn)[24-30]的基礎(chǔ)上歸納出如表5所示的漫游地圖測試設(shè)計方法。

表4 不穩(wěn)定因素中挑戰(zhàn)性的測試內(nèi)容與測試想法

3 探索性測試應(yīng)用現(xiàn)狀

探索性測試擁有其獨特的測試思考風(fēng)格及測試設(shè)計方法，但重要的是如何把該方法應(yīng)用到實際測試過程或測試技術(shù)中。本節(jié)就當(dāng)前國內(nèi)外有關(guān)探索性測試在實際測試活動中的應(yīng)用現(xiàn)狀作介紹。

3.1 引入探索性測試流程模型

3.1.1X模型

傳統(tǒng)的X模型的亮點是引入了探索性測試流程，旨在無需通過制定復(fù)雜的測試計劃和設(shè)計大量測試用例來發(fā)現(xiàn)更多的缺陷。由于X模型關(guān)注的是程序的低級別測試行為，同樣對于引入的探索性測試流程缺乏指明其所需要進(jìn)行相應(yīng)的測試設(shè)計活動及測試內(nèi)容的描述，也無明確的需求角色活動。

3.1.2X改進(jìn)模型

汕頭大學(xué)熊智等人在文獻(xiàn)[31]中對X模型進(jìn)行改進(jìn)，在遵循原模型框架基礎(chǔ)上，對左右兩半部分內(nèi)部的測試活動的執(zhí)行次序進(jìn)行相應(yīng)調(diào)整，增加了迭代測試與回歸測試。并且在X改進(jìn)模型的左半部分(模塊單元測試活動)與右半部分(模塊間的不斷交接，逐步進(jìn)行集成測試)中的回歸測試階段之前都增添了探索性測試活動，并指定由測試經(jīng)驗豐富的測試組長擔(dān)當(dāng)。圖1所示。

表5 漫游地圖測試設(shè)計方法

圖1 X改進(jìn)模型

可是該應(yīng)用只是把探索性測試安插在系統(tǒng)模塊的單元測試與集成測試過程中，隨機(jī)進(jìn)行測試，成為回歸測試的一附帶補充測試。作為引入到模型中的一條簡單籠統(tǒng)的測試流程，同樣缺少對采用探索性測試設(shè)計和測試輸入設(shè)計過程，對具體測試內(nèi)容缺少細(xì)致分析，未形成完整的測試過程體系。

3.2 純自由的探索性測試

純自由的探索性測試即在常規(guī)測試中選取任意測試輸入數(shù)據(jù)以任意方式組合來測試應(yīng)用程序的功能[32]。與隨機(jī)測試一樣，不遵循任何測試技術(shù)及相應(yīng)的測試計劃。測試前測試人員無需學(xué)習(xí)測試對象，也無需具備測試經(jīng)驗或技能來完成“探索”測試過程。鑒于自由探索性測試中的“過分自由”測試特點，在實際情況下更多采取與腳本化測試方法相結(jié)合共同完成測試活動。

文獻(xiàn)[24]認(rèn)為純自由的探索性測試方法應(yīng)該在常規(guī)測試中的第二輪測試結(jié)束后介入迭代測試環(huán)節(jié)較為合適。因為被測模塊中大部分危害程度較高的缺陷可能第一輪常規(guī)測試后被修復(fù)，第二輪測試將完成對修復(fù)后的缺陷的驗證，且被測對象的測試免疫性大幅度提高。測試人員通過前兩輪測試對測試需求已較為熟悉，從第三輪測試起通過對前面測試中所發(fā)現(xiàn)問題制定探索性測試計劃，通過盡可能多的改變各種隨機(jī)測試手段側(cè)重探索隱藏的錯誤或異常流程可能觸發(fā)的問題。此種介入自由探索性測試有助于提高測試差異性，解決測試疲勞現(xiàn)象，發(fā)現(xiàn)較多的用戶界面錯誤或軟件頁面元素顯示錯誤方面危害程度不是太高的隱藏缺陷。

3.3 探索性與腳本化相結(jié)合的測試

該測試方式采用以腳本化測試作為項目測試過程的主導(dǎo)，從測試過程整體層面來看需要設(shè)計詳細(xì)的測試用例并依據(jù)測試用例文檔執(zhí)行測試，從執(zhí)行文檔化測試用例的局部層面上，開展探索性測試，由被測產(chǎn)品的輸出,設(shè)計與執(zhí)行更多的測試用例。盡管該測試方式的核心仍然是以腳本化測試為主、探索性測試為輔，但是充分利用了腳本化測試與探索性測試的部分特點。既保證了測試用例的詳實性與傳承性，也提高了測試的多樣性，有效保證產(chǎn)品質(zhì)量的可控性。

當(dāng)然，探索性測試在軟件生命周期中處于什么樣的地位，何時介入腳本化測試進(jìn)程中等問題，在不同的測試團(tuán)隊以及不同的測試項目中存在不同的定位。文獻(xiàn)[18,24]認(rèn)為詳細(xì)測試用例的執(zhí)行在腳本化測試初期與中期階段可以發(fā)現(xiàn)并修復(fù)驗證產(chǎn)品重要功能及主要流程上所存在的絕大多數(shù)缺陷，在測試后期(如用戶驗收測試、β測試)階段由于被測產(chǎn)品的免疫性會逐步提高，致使事先編寫好的固定的測試用例集無法適應(yīng)產(chǎn)品的變化，存在測試盲點，所遺漏的缺陷會大都出現(xiàn)在用戶使用方面比較特殊的場景中。所以要求測試人員借助已有測試用例的標(biāo)題擴(kuò)展測試思路，或利用前文所介紹的單個特性與交互特性的探索性測試設(shè)計方法啟發(fā)新的測試思路，通過交叉測試策略[33](例如，測試前、中期，測試人員A與B分別測試與驗證C模塊與D模塊；測試后期，測試人員A與B互換測試各自先前的測試模塊)開展探索性測試活動。同時文獻(xiàn)[24]給出了一個以腳本化測試為主、探索性測試為輔的流程圖，如圖2所示。

圖2 腳本化測試為主、探索性測試為輔的測試流程圖

探索性測試計劃1用來確定實施探索性測試的功能模塊，為確定與細(xì)化測試任務(wù)做準(zhǔn)備。測試任務(wù)并非詳細(xì)的測試計劃，而是建議即將測試的內(nèi)容以及測試的思路、策略，可以是對已有測試用例標(biāo)題的一段簡單描述[34]。文獻(xiàn)[35]給出了一個基于模塊功能領(lǐng)域用到的探索性測試任務(wù)模板，如表6所示。探索性測試計劃2中主要依據(jù)被測模塊的特點制定出相應(yīng)的探索性測試設(shè)計方法，并對每個測試任務(wù)分配測試時間、人員等相關(guān)測試資源。實驗數(shù)據(jù)表明了盡管測試后期實施探索性測試時間較短，但是可以發(fā)現(xiàn)較多的危害程度不是太高的軟件易用性方面的缺陷。缺陷發(fā)現(xiàn)率盡管小于腳本化測試前期階段，但卻高于測試中期缺陷率30%以上。

表6 探索性測試任務(wù)模板

3.4 基于探索性測試思想的測試用例生成系統(tǒng)的設(shè)計

北京交通大學(xué)練榮政在文獻(xiàn)[36]中運用探索性測試思想結(jié)合軟件測試中問題模板(Q-Patterns，將一組相關(guān)問題歸納到一起而形成的測試問題組，提供作為用戶或軟件某類方面的問題的統(tǒng)一測試方法，或?qū)ν粏栴}提供多種測試方法[36-37]。由模板名、內(nèi)容簡介、測試問題摘要、適用測試?yán)优c特別說明幾部分組成)技術(shù)與測試發(fā)現(xiàn)缺陷歷史記錄信息，設(shè)計并實現(xiàn)了一基于探索性軟件測試思想的測試用例生成系統(tǒng)，達(dá)到高效及精確的定位出被測軟件中的缺陷信息的目的。該系統(tǒng)功能實現(xiàn)模型如圖3所示。

圖3 問題模板結(jié)合缺陷歷史統(tǒng)計信息的探索性測試模型

模型主要由執(zhí)行測試，測試設(shè)計與測試計劃三部分組成，從對開發(fā)人員和被測軟件兩個方面同時進(jìn)行測試任務(wù)的探索。前者體現(xiàn)在模型中的補充與參考“開發(fā)人員缺陷歷史記錄”方面，通過細(xì)致分析開發(fā)人員在軟件設(shè)計中的其思維定勢、編程風(fēng)格等主觀因素而導(dǎo)致可能存在的軟件設(shè)計方面的缺陷，探索其編寫軟件模塊中所隱藏的錯誤。后者即通過對問題模板的問題域?qū)W習(xí)和對每次探索性測試執(zhí)行結(jié)果的分析，探索對象是對被測軟件的設(shè)計及相關(guān)文檔、軟件代碼。此外，問題模板中的問題域與相應(yīng)的測試用例緊密關(guān)聯(lián)。最后該文獻(xiàn)提供了兩個測試組在為期15天的三個測試周期內(nèi)分別用傳統(tǒng)的腳本化測試方法與問題模板結(jié)合缺陷歷史統(tǒng)計信息的探索性測試方法相比較的測試實驗數(shù)據(jù)。如表7和表8所示。

表7 兩種測試方法人均發(fā)現(xiàn)缺陷數(shù)目比較

表8 兩種測試方法對測試用例發(fā)現(xiàn)缺陷效率比較 %

3.5 基于規(guī)則的圖形用戶界面的探索性測試流程

軟件圖形用戶界面(GUI)的測試是近年來軟件測試的熱門研究方向。軟件中60%的缺陷來源于被測軟件系統(tǒng)的圖形用戶界面，其中65%的有關(guān)圖形用戶界面方面的缺陷將直接導(dǎo)致軟件功能失效[38-39]。但是被測軟件的圖形用戶界面以手工測試方式在限定的時間內(nèi)僅僅滿足測試出少部分功能。即使引入探索性測試策略，但是圖形用戶界面的構(gòu)成元素(如按鈕、下拉框、下拉菜單等)較為復(fù)雜加之探索性測試具有一定的隨機(jī)性，導(dǎo)致引導(dǎo)測試方向上存在困難。自動化測試在發(fā)現(xiàn)與重現(xiàn)軟件低層次的代碼層缺陷方面富有成效，可是測試人員通過專門的測試工具往往更多地關(guān)注對軟件內(nèi)部功能的測試而忽視了軟件較高應(yīng)用層次的圖形用戶界面。由于交互界面構(gòu)成要素復(fù)雜且相互影響因素錯綜繁瑣，以致設(shè)計其測試用例及維護(hù)過程困難[40-41]。基于此，Theodore D. Hellmann等人在文獻(xiàn)[41]中結(jié)合了自動化測試與手工探索性測試方法，設(shè)計出一種基于規(guī)則的圖形用戶界面的探索性測試流程結(jié)構(gòu)，如圖4所示。測試者憑借自身測試經(jīng)驗自定義相應(yīng)的探索性測試規(guī)則來執(zhí)行利用腳本捕獲/回放工具所創(chuàng)造的腳本測試活動，從而較好的解決圖形用戶界面測試所發(fā)現(xiàn)的異常問題。

圖4 基于規(guī)則的用戶界面探索性測試流程結(jié)構(gòu)圖

3.6 探索性測試思想在遺傳算法中的應(yīng)用

謝經(jīng)緯等人把探索性測試思想與遺傳算法[42]相結(jié)合并進(jìn)行了實際運用。在面向軟件故障測試的框架下對測試過程進(jìn)行量化處理，提取出一系列指標(biāo)與效應(yīng)函數(shù)作為采用的用于遺傳算法中的迭代條件，尋找出有限測試成本下最佳檢查點組合[43]。

文獻(xiàn)中采用PC-link代碼檢測工具針對約2萬行代碼的程序進(jìn)行普通測試與采用有限測試成本下最佳檢查點組合方法的兩組測試實驗，驗證針對非法測試故障在基于探索性測試方法下減少測試成本的有效性。把遺傳算法與探索性測試思想相結(jié)合在實際中通過測試工具對軟件故障測試過程進(jìn)行改進(jìn)與優(yōu)化，實現(xiàn)以測試低代價找出高覆蓋的測試組合，減少測試成本。

4 總結(jié)與展望

4.1 探索性測試應(yīng)用總結(jié)

前文對當(dāng)前探索性測試的進(jìn)展及運用現(xiàn)狀進(jìn)行了綜述。探討了其定義、特點、實施過程、測試設(shè)計方法的分類及所發(fā)現(xiàn)缺陷的特征狀況等。此外，還簡要介紹了探索性測試在實際項目中的應(yīng)用現(xiàn)狀、實驗數(shù)據(jù)比較及尚存的不足之處。

探索性測試在當(dāng)前實際運用中，主要還是僅以一種探索的測試設(shè)計思想或策略被引用到具體的測試項目中，其自身缺乏形成一套完整的探索性測試過程體系以及與探索性測試思想相匹配的相關(guān)測試工具的開發(fā)。在文獻(xiàn)[24,31]中只是把探索性測試作為一條測試流程引入測試改進(jìn)模型里或腳本化測試后期階段的迭代過程中，還是以腳本化測試為主導(dǎo),測試人員憑借經(jīng)驗去探索測試認(rèn)為有疑惑的地方，均未能設(shè)計出以探索性測試為主導(dǎo)的完整的過程模型或體系結(jié)構(gòu)。探索性測試往往會受到被測對象功能特性、測試任務(wù)、測試時間、測試經(jīng)驗等諸多因素的影響，測試結(jié)果不能追蹤，測試經(jīng)驗無法傳承，這需要進(jìn)一步探索。文獻(xiàn)[36,41,43]分別也只是在軟件用戶圖形界面測試中提出了創(chuàng)建探索性思想的測試規(guī)則流程來指導(dǎo)測試，利用探索性測試思想設(shè)計測試用例生成系統(tǒng)，以及把探索性測試思想簡單的運用到遺傳算法中去。以上應(yīng)用即缺少對探索性測試過程的具體構(gòu)成內(nèi)容作明確定義，也無有效的與開發(fā)過程交互而形成完整的測試過程模型來指導(dǎo)具體測試項目?？傊?，目前國內(nèi)、外對有關(guān)探索性測試以及在實際項目中的應(yīng)用研究還只是停留在理論層面上，已有的研究成果也僅局限于在常規(guī)腳本化測試中通過引入探索性測試設(shè)計(思想)的方法或技巧，來提供新的測試思路。并未闡明探索性測試從測試計劃、分析(探索性測試準(zhǔn)備)到設(shè)計、執(zhí)行的一套完整測試過程，以及如何進(jìn)行探索性測試管理、如何有效控制探索性測試所帶來的潛在風(fēng)險等問題。

4.2 未來的展望

雖然國內(nèi)外專家學(xué)者在探索性測試研究方面已取得一定進(jìn)展，但是仍有一些潛在的亟待研究解決的問題，下面分別予以闡述。

4.2.1構(gòu)建以探索性測試為主的測試過程

探索性測試為主、腳本化測試為輔的測試方法的思想核心即測試人員借助簡約的腳本用例或通過加入包含腳本化測試特點的測試思路列表來取代編寫詳細(xì)測試用例的環(huán)節(jié)來指導(dǎo)測試全過程，按照探索性測試思路與方法執(zhí)行測試，發(fā)揮更多自由空間探索被測軟件。該測試方法旨在盡量減少文檔編寫時間，而增加測試執(zhí)行時學(xué)習(xí)產(chǎn)品的時間，拓展測試思路。

該方法中盡管不會要求設(shè)計與編寫詳細(xì)的測試用例過程，但是借助簡約的測試腳本通過對測試對象的測試思維架構(gòu)圖[44](思維導(dǎo)圖)的逐層分析而產(chǎn)生探索性測試列表的設(shè)計過程是該方法中探索性測試設(shè)計的關(guān)鍵。文獻(xiàn)[24]中也給出一個由對測試對象的測試思維導(dǎo)圖所產(chǎn)生的測試列表的探索性測試設(shè)計流程圖，圖5所示。

圖5 探索性測試設(shè)計流程圖

測試人員由測試任務(wù)對每一個測試功能點或特性進(jìn)行細(xì)致分析，由最初需求規(guī)格評審階段所得出的最重要的用例場景與主要功能的用例場景作為第一層思維導(dǎo)圖(思維導(dǎo)圖一)，在用例評審階段所衍生的次要功能及功能細(xì)節(jié)用例場景以及在系統(tǒng)設(shè)計評審階段補充可能遺漏的異常場景及詳細(xì)校驗點作為第二層思維導(dǎo)圖(思維導(dǎo)圖二)。測試執(zhí)行中因需求變更或測試靈感的迸發(fā)對其完善與優(yōu)化，形成思維導(dǎo)圖三。測試思路由思維導(dǎo)圖形成，內(nèi)容可以包括各種探索性測試設(shè)計方法。

測試設(shè)計階段測試者還需要將被測對象的隱性需求(如同類軟件特點或在被測軟件以前版本中所發(fā)現(xiàn)的缺陷反饋信息，不同用戶可能使用到的風(fēng)格及用戶接口標(biāo)準(zhǔn)等)不斷完善到測試思路列表中并保持優(yōu)化。測試執(zhí)行階段根據(jù)測試思路列表探索性的測試同時，記錄下被測對象行為的可疑之處為下一步的探索提供測試思路。但是如何在測試設(shè)計過程中明確定義測試思路列表中的構(gòu)成元素而形成規(guī)范的模版體系，如何把被測對象的思維導(dǎo)圖結(jié)合隱性需求轉(zhuǎn)化為具體測試思路列表的詳細(xì)過程及所使用到方法、工具等問題需要未來繼續(xù)探索與實驗。

4.2.2可復(fù)用探索性測試用例的設(shè)計方法

迭代設(shè)計與復(fù)用執(zhí)行測試用例，并把已執(zhí)行的測試用例不同程度的多次應(yīng)用于該軟件新的測試或同類軟件的測試過程中去可以縮短測試周期，減輕測試工作量，提高測試效率[45,46]。憑借測試經(jīng)驗如何對已知測試場景有系統(tǒng)的進(jìn)行輸入選擇、數(shù)據(jù)使用及環(huán)境條件的變化而設(shè)計出具有探索性思想的測試用例來完成測試復(fù)用過程也將成為探索性測試在實際運用中的關(guān)鍵之處。

目前大量文獻(xiàn)資料都已進(jìn)行詳細(xì)的定義與描述，并通過實際項目建立起一系列有效的測試用例復(fù)用模型[47,48]。但是如何把相應(yīng)的探索性測試設(shè)計方法中的各種探索測試變化策略描述加入到可復(fù)用測試用例設(shè)計的組成要素中，同時形成規(guī)范的標(biāo)準(zhǔn)化文檔模版并實施有效測試用例復(fù)用管理過程也是一個潛在的值得研究的方向。

4.2.3探索性測試中的文檔標(biāo)準(zhǔn)化管理過程

軟件文檔作為軟件產(chǎn)品的伴生物，記錄著軟件產(chǎn)品從誕生之前到開發(fā)完全過程的相關(guān)信息，可具有固定不變的形式[49,50]。從測試文檔的角度來看，測試過程是一測試相關(guān)文檔編寫與執(zhí)行的過程。測試過程中的每項工作(如編寫測試規(guī)格說明書、測試計劃、測試場景與測試用例、缺陷統(tǒng)計報告、測試評審等)均需要形成相應(yīng)的測試文檔，包括測試相關(guān)的資源及其使用情況。作為測試過程的一部分，測試文檔的編寫和管理在測試中占有突出地位和相當(dāng)大的工作量。高質(zhì)量的編制、變更、修正、管理和維護(hù)文檔，對于提高測試質(zhì)量和客戶滿意度有著重要的現(xiàn)實意義[50]。

5 結(jié) 語

探索性測試作為一種不依賴于具體測試技術(shù)的測試思想或測試思考風(fēng)格，是對常規(guī)腳本化測試的有益補充，但是不能完全取而代之。測試人員需要具備良好的測試素養(yǎng)與主觀測試能動性，結(jié)合實際測試項目與測試環(huán)境合理應(yīng)用探索性測試方法。作為一種前沿測試?yán)碚?，探索性測試還需要作進(jìn)一步的研究與探索，這對軟件測試的發(fā)展具有深遠(yuǎn)意義。

[1] Cem Kaner, James Bach. The Nature of Exploratory Testing[DB/OL]. 2009. http://www.testingeducation.org.

[2] Juha Itkonen, Kristian Rautiainen. Exploratory Testing A Multiple Case Study[C]//Proceedings of International Symposium on Empirical Software Engineering,2005 Helsinki:IEEE, 2005：84-85.

[3] IEEE, Guide to the Software Engineering Body of Knowledge[S]. IEEE.Tech.Rep. IEEE-2008 Version, 2008.

[4] 余久久.張佑生.軟件測試改進(jìn)模型研究進(jìn)展[J].計算機(jī)應(yīng)用與軟件, 2012,29(11):201-204.

YU Jiu-jiu, ZHANG You-sheng.Research Process of Improved Software Testing Model[J].Journal of Computer Applications and Software, 2012,29(11):201-204.

[5] 林 煒.兩種軟件測試方法的比較和改進(jìn)[J].信息網(wǎng)絡(luò)安全，2012(7):58-60,73.

LIN Wei. The Research and Improvement of Software Testing Methods[J].Journal of Netinfo Security,2012(7):58-60,73.

[6] 蔣方純. 軟件測試設(shè)計與實施[M].北京：北京大學(xué)出版社，2010.

[7] Torens C, Ebrecht L, Lemmer K. Starting Model-Based Testing Based on Existing Test Cases Used for Model Creation: Computer and Information Technology,2011[C]//Cyprus: IEEE, 2011:320-327.

[8] 劉 海，郝克剛.軟件缺陷原因分析方法[J].計算機(jī)科學(xué)，2009，36(1):242-243.

LIU Hai,HAO Ke-gang.Cause Analysis Method of Software Defect[J].Journal of Computer Science,2009，36(1):242-243.

[9] Claudia Dencker. Test Case Maps In Support of Exploratory Testing: Annual Pacific Northwest Software Quality Conference, 2006[C]//Portland: PNSQC, 2006:357-366.

[10] Taobao QA Team.測試手段之探索性測試[DB/OL].2010. http://www.51testing.com.

[11] Sundmark, D.,Petersen, K.,Larsson, S. An exploratory case study of testing in an automotive electrical system release process:Industrial Embedded Systems (SIES), 2011[C]//Vasteras: 6th IEEE International Symposium,2011:166-170.

[12] Juha Itkonen，Mika V. Mantyla，Casper Lassenius .How Do Testers Do It? An Exploratory Study on Manual Testing Practices: Empirical Software Engineering and Measurement, 2009[C]//Lake Buena Vista: 3rd International Symposium on, 2009：494-496．

[13] Cem Kaner. A Tutorial in Exploratory Testing[DB/OL]. 2010. http://www.sast.se/q-moten.

[14] Lozina Shoaib, Aamer Nadeem,Aisha Akbar. An Empirical Evaluation of the Influence of Human Personality on Exploratory Software Testing: Multitopic Conference, 2009[C]//Islamabad: IEEE, 2009:235-237.

[15] 李軍鋒，欒 靜.探索性軟件測試解析[J].計算機(jī)與數(shù)字工程，2011, 39(8):39-42.

LI Jun-feng, LUAN Jing.Research and Analysis of Exploratory Software Testing[J].Journal of Computer and Digital Engineering,2011, 39(8):39-42.

[16] 聶長海.關(guān)于軟件測試的幾點思考[J].計算機(jī)科學(xué), 2011,38(2):1-2.

NIE Chang-hai.Thoughts on Software Testing[J].Journal of Computer Science, 2011,38(2):1-2.

[17] L.Copeland. A Practitioner’s Guide to Software Test Design[M]. Boston:ArtechHouse Publishers, 2007.

[18] 馬均飛，鄭文強(qiáng).軟件測試設(shè)計[M].北京：電子工業(yè)出版社，2011.

[19] Alistair Cockburn. Agile Software Development[M]. Addison-Wesley Professional, 2007.

[20] 朱昭俊，蘇 賽.探索性測試方法分析[J].計算機(jī)光盤軟件與應(yīng)用，2012(19):66-67.

ZHU Zhao-jun, SU Sai.The Analysis of Exploratory testing method[J].Journal of Computer CD Software and Applications, 2012(19):66-67.

[21] Juha Itkonen, Mika V.Mantyla, Casper Lassenius. Defect Detection Efficiency Test Case Based vs. Exploratory Testing: Empirical Software Engineering and Measurement, 2007[C]//Madrid: First International Symposium on, 2007:61-70.

[22] Atif M. Memon. Automatically Repairing Event Sequence-Based GUI Test Suites for Regression Testing[J]. ACM Transactions on Software Engineering and Methodology, 2008,18(2): 19-36.

[23] Prakash V, Gopalakrishnan S.Testing efficiency exploited Scripted versus Exploratory testing: Electronics Computer Technology (ICECT),2011[C]//Kanyakumari: 3rd International Conference on, 2011:168-172.

[24] 史 亮，高 翔. 探索式軟件測試實踐之路[M].北京：電子工業(yè)出版社，2012.

[25] James A.Whittaker. 探索式軟件測試[M]. 方 毅，張 勝，鐘頌東 等譯.北京：清華大學(xué)出版社，2010.

[26] James A. Whittaker. Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design[M]. Addison-Wesley Professional, 2009.

[27] James A. Whittaker. Bugs, Patterns, Automation: Thoughts on More Effective Testing[DB/OL]. 2011.http://www.51testing.com.

[28] 陸永忠，宋駿禮，谷希謙. 基于行為的軟件測試過程模型及其應(yīng)用研究[J].計算機(jī)應(yīng)用.2007，27(5):1238-1239.

LU Yong-zhong, SONG Jun-li, GU Xi-qian. Behavior-based software testing process model and its application[J].Journal of Computer Applications, 2007,27(5):1238-1239.

[29] Jon Bach，James Bach. Dynamics of Exploratory Testing: Annual Pacific Northwest Software Quality Conference, 2006[C]//Portland: PNSQC, 2006:459-462.

[30] Sven Sambaer. Exploratory Testing: Evolution or Revolution[DB/OL]. 2009. http://www.51testing.com.

[31] 熊 智，劉 莉，雷鈺鋒，等. X測試模型的改進(jìn)與應(yīng)用[J].計算機(jī)工程與設(shè)計，2011,32(8):2748-2751.

XIONG Zhi, LIU Li, LEI Yu-feng,etal.Improvement and application of X test model[J].Journal of Computer Engineering and Design, 2011,32(8):2748-2751.

[32] Sam.探索式軟件測試的四個類型[DB/OL].2012. http://www.Smart Testing.com.

[33] 朱少民.軟件測試[M].北京：人民郵電出版社，2009.

[34] Paul Carvalho. SBTM is not ET[DB/OL].2010. http://www.swtester.biogspot.com.

[35] Anders Classon. How to perform Exploratory Testing by using Test Charters[DB/OL]. 2009. http://www.sast.se/q-moten.

[36] 練榮政.一個基于探索性軟件測試?yán)碚摰臏y試用例生成系統(tǒng)的研究與實現(xiàn)[D].北京:北京交通大學(xué)，2008.

[37] Vipul Kocher. Insight into reusable test cases using Questioning Patterns[DB/OL]. 2009. http://www.whatistesting.com.

[38] B.Robinson,P. Brooks. An Initial Study of Customer-Reported GUI Defects: IEEE International Conference on Software Testing, 2009[C]//Verification and Validation Workshops, 2009: 267-274.

[39] Emelie Engstrom, Per Runeson, Andreas Ljung. Improving Regression Testing Transparency and Efficiency with History-Based Prioritization-an Industrial Case Study: The Fourth IEEE International Conference on Software Testing, Verification and Validation, 2011[C]//Berlin:IEEE,2011：367-370．

[40] Micah Garrison，Morris Cox，Brad Clarkson. Reinventing Deepwater Exploratory Testing: Offshore Technology Conference,2011[C].Houston: IEEE,2011:2-6．

[41] Theodore D. Hellmann, Frank Maurer. Rule-Based Exploratory Testing of Graphical User Interfaces: Agile Conference,2011[C]//Salt Lake City: IEEE,2011：107-111．

[42] 顧澤元，劉文強(qiáng). 數(shù)據(jù)結(jié)構(gòu)[M].北京：北京航空航天大學(xué)出版社，2011.

[43] 謝經(jīng)緯，吳 昊. 探索性方法在面向故障軟件測試中的應(yīng)用[J].微計算機(jī)信息，2010，26(9-1):145-146.

XIE Jing-wei,WU Hao. The application of exploratory method in fault oriented software testing[J].Journal of Control & Automation, 2010，26(9-1):145-146.

[44] 陳 欣，藍(lán)國興，段 楓, 等. 基于思維導(dǎo)圖的仿真實驗方法研究[J]. 兵工學(xué)報，2013(3):346-352.

CHEN Xin, LANG Guo-xing, DUAN Feng etc.Design of Simulation Experiment Based on the Mind Map[J].Journal of Acta Armamentarii,2013(3):346-352.

[45] 樓 芳，李 亮，何志強(qiáng). 基于本體的滲透測試用例復(fù)用模型[J].計算機(jī)工程與科學(xué)，2011, 33(2):23-26.

LOU Fang, LI Liang, HE Zhi-qiang. An Ontology Based Testing Case Reuse Model for Penetration Testing[J].Journal of Computer Engineering and Science,2011, 33(2):23-26.

[46] 卜國峰，孫志剛，丁小良. 軟件測試用例的復(fù)用研究[J].四川兵工學(xué)報，2009, 30(5):124-126.

PU Guo-feng, SUN Zhi-gang, DING Xiao-liang. The reuse of software test case study[J].Journal of Acta Armamentarii of Sichuan, 2009, 30(5):124-126.

[47] 張玉彬，謝康林. 測試用例的設(shè)計和復(fù)用[J].計算機(jī)應(yīng)用與軟件，2008，25(1):23-24.

ZHANG Yu-bin, XIE Kang-lin. Test Case Design and Reuse Technology[J].Journal of Computer Applications and Software, 2008，25(1):23-24.

[48] 尹 平.可復(fù)用測試用例研究[J].計算機(jī)應(yīng)用，2010, 30(5):1309-1311.

YIN Ping. Study on reusable test case[J].Journal of Computer Applications, 2010, 30(5):1309-1311.

[49] 季超英，宋曉秋.軟件文檔質(zhì)量的度量方法研究[J]. 計算機(jī)工程與設(shè)計，2007，28(17)：4068-4071.

JI Chao-ying, SONG Xiao-qiu. Research on measurement of method of software documents quality[J].Journal of Computer Engineering and Design, 2007，28(17)：4068-4071.

[50] 馬 平，黃冬梅.軟件文檔寫作教程[M].北京：電子工業(yè)出版社, 2010.