軟 件 探 索 性 測 試 研 究 進 展

余久久, 張佑生

(安徽三聯學院 計算機科學與技術系,安徽 合肥 230601)

0 引 言

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

探索性測試需要測試人員在測試過程中反復了解與學習被測軟件，結合自身測試經驗把不斷整理與綜合分析得出的測試信息快速反饋至下一次測試活動中，從而激發出更多的測試思想或測試策略。探索性測試也是當前軟件測試領域中較前沿的思想理論，并不完全依賴于事先所設計的一塵不變的測試場景或測試腳本。以測試目標為向導，測試人員充分利用任何與測試目標有關聯的信息，例如需求文檔、用戶手冊、甚至是被測軟件或類似產品的缺陷歷史信息等，在無明確的測試指導環境下通過主動的“探索”來發現軟件缺陷。

1 探索性測試

1.1 探索性測試的引入

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

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

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

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

1.3 探索性測試的特點

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

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

1.4 對發現缺陷特征的研究

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

同樣文獻[22]也認為探索性測試能發現更多的用戶圖形界面接口缺陷，常規的腳本化測試過程中事先設計的測試用例在后續指導測試軟件用戶界面接口方面所起作用不大。

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

表1 迭代開發模式下兩種測試方法發現缺陷數目

2 探索性測試設計方法

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

2.1 單個功能特性的測試設計方法

2.1.1聯想測試設計方法

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

2.1.2互聯網測試設計方法

互聯網測試設計方法是基于互聯網環境下針對以網頁頁面形式所呈現的單個功能點，以用戶操作視角主要從互聯網頁面的可用性與安全性兩個方面啟發測試設計思路，進行探索性的測試設計，學習與理解易遺漏的測試情景與異常流程。

表2 聯想測試設計方法

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

2.1.3單個特性漫游測試設計方法

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

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

2.2.1場景探索測試設計方法

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

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

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

2.2.2交互特性的漫游測試設計方法

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

2.3 基于系統功能交互特性的測試設計方法

2.3.1通用功能性與穩定性的測試設計方法

通用功能性與穩定性的測試設計方法主要圍繞被測對象的使用目的、核心功能與潛在的不穩定區域進行的探索性測試設計方法。其專注于軟件核心任務的功能性和穩定性。

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

測試人員在了解產品目的，確定產品功能與識別產品運行不穩定因素區域后，探索性設計每個被測功能點的測試用例，實施測試并記錄所發現問題。

2.3.2漫游地圖測試設計方法

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

表4 不穩定因素中挑戰性的測試內容與測試想法

3 探索性測試應用現狀

探索性測試擁有其獨特的測試思考風格及測試設計方法，但重要的是如何把該方法應用到實際測試過程或測試技術中。本節就當前國內外有關探索性測試在實際測試活動中的應用現狀作介紹。

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

3.1.1X模型

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

3.1.2X改進模型

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

表5 漫游地圖測試設計方法

圖1 X改進模型

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

3.2 純自由的探索性測試

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

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

3.3 探索性與腳本化相結合的測試

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

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

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

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

表6 探索性測試任務模板

3.4 基于探索性測試思想的測試用例生成系統的設計

北京交通大學練榮政在文獻[36]中運用探索性測試思想結合軟件測試中問題模板(Q-Patterns，將一組相關問題歸納到一起而形成的測試問題組，提供作為用戶或軟件某類方面的問題的統一測試方法，或對同一問題提供多種測試方法[36-37]。由模板名、內容簡介、測試問題摘要、適用測試例子與特別說明幾部分組成)技術與測試發現缺陷歷史記錄信息，設計并實現了一基于探索性軟件測試思想的測試用例生成系統，達到高效及精確的定位出被測軟件中的缺陷信息的目的。該系統功能實現模型如圖3所示。

圖3 問題模板結合缺陷歷史統計信息的探索性測試模型

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

表7 兩種測試方法人均發現缺陷數目比較

表8 兩種測試方法對測試用例發現缺陷效率比較 %

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

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

圖4 基于規則的用戶界面探索性測試流程結構圖

3.6 探索性測試思想在遺傳算法中的應用

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

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

4 總結與展望

4.1 探索性測試應用總結

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

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

4.2 未來的展望

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

4.2.1構建以探索性測試為主的測試過程

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

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

圖5 探索性測試設計流程圖

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

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

4.2.2可復用探索性測試用例的設計方法

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

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

4.2.3探索性測試中的文檔標準化管理過程

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

5 結 語

探索性測試作為一種不依賴于具體測試技術的測試思想或測試思考風格，是對常規腳本化測試的有益補充，但是不能完全取而代之。測試人員需要具備良好的測試素養與主觀測試能動性，結合實際測試項目與測試環境合理應用探索性測試方法。作為一種前沿測試理論，探索性測試還需要作進一步的研究與探索，這對軟件測試的發展具有深遠意義。

[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].計算機應用與軟件, 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].信息網絡安全，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] 蔣方純. 軟件測試設計與實施[M].北京：北京大學出版社，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].計算機科學，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].計算機與數字工程，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] 聶長海.關于軟件測試的幾點思考[J].計算機科學, 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] 馬均飛，鄭文強.軟件測試設計[M].北京：電子工業出版社，2011.

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

[20] 朱昭俊，蘇 賽.探索性測試方法分析[J].計算機光盤軟件與應用，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].北京：電子工業出版社，2012.

[25] James A.Whittaker. 探索式軟件測試[M]. 方 毅，張 勝，鐘頌東 等譯.北京：清華大學出版社，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] 陸永忠，宋駿禮，谷希謙. 基于行為的軟件測試過程模型及其應用研究[J].計算機應用.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].計算機工程與設計，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] 練榮政.一個基于探索性軟件測試理論的測試用例生成系統的研究與實現[D].北京:北京交通大學，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] 顧澤元，劉文強. 數據結構[M].北京：北京航空航天大學出版社，2011.

[43] 謝經緯，吳 昊. 探索性方法在面向故障軟件測試中的應用[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] 陳 欣，藍國興，段 楓, 等. 基于思維導圖的仿真實驗方法研究[J]. 兵工學報，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] 樓 芳，李 亮，何志強. 基于本體的滲透測試用例復用模型[J].計算機工程與科學，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] 卜國峰，孫志剛，丁小良. 軟件測試用例的復用研究[J].四川兵工學報，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] 張玉彬，謝康林. 測試用例的設計和復用[J].計算機應用與軟件，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] 尹 平.可復用測試用例研究[J].計算機應用，2010, 30(5):1309-1311.

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

[49] 季超英，宋曉秋.軟件文檔質量的度量方法研究[J]. 計算機工程與設計，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].北京：電子工業出版社, 2010.