楊 燕 劉 釗 蔡久濤
1(江西航天鄱湖云科技有限公司 江西 南昌 330096)
2(航天恒星科技有限公司 北京 100086)
3(金蝶軟件(中國)有限公司南昌分公司 江西 南昌 330096)
腳本化測試是先設計、再執行,設計時就指定輸入值和預期結果,執行時嚴格按照測試設計進行。一方面隨著軟件應用的發展,軟件出現了推出快、變化頻繁、接口雜、重體驗、開放性等特點,另一方面隨著測試的積累測試人員發現缺陷的類型增長緩慢。為了適用這種變化,也為了解決現存問題,需要引入新的測試技術。探索性測試作為一種前沿的測試思維,在項目周期短、需求不明確或者需求變更頻繁的項目中發現缺陷的效果顯著,也能發現一些腳本化測試發現不了的缺陷,因此受到越來越多軟件測試人員的青睞。
目前對探索性測試的研究主要集中在測試思想和方法上[1-3],近年來也有研究探索性測試在個別領域上的應用。文獻[4]將探索性測試應用到航空聲納軟件中能夠有效發掘軟件中隱藏的缺陷。文獻[5]研究表明,將探索性測試思維引入到軍用軟件中與傳統的軟件測試相結合,能有效提高軟件測試效率和測試覆蓋率。但是在實際工作中對實施探索性測試發現的缺陷特征及在不同測試階段的實施的研究甚少。本文通過對“同時進行設計、測試和學習”的探索性測試進行研究,總結出幾種可采用探索性測試的情況,并將探索性測試融入到傳統的測試流程體系中,再選取三個不同類型的項目進行實踐來研究如何采用探索性測試方法開展軟件測試工作。
探索性測試最先由Cem Kaner在1983年提出,它是一種軟件測試風格,也是一種測試思維[6]。這種測試思維不同于傳統軟件測試過程中嚴格的“先設計,后執行”,它將學習、測試設計和測試執行整合在一起,測試人員通過不斷的學習,并把學習到的關于軟件系統的更多信息通過綜合的整理和分析,創造出更多的關于測試的想法。它強調測試執行、學習、測試設計的同時性,注重思考和學習,通過思考和學習改善測試設計與測試執行,不斷地發現新的缺陷。
探索性測試在軟件生命周期的任一階段均可使用,如:集成測試、系統測試、驗收測試等;也適用于各種類型的測試,如:功能測試、可靠性測試、兼容性測試、易用性測試、性能測試、安全性測試等[7]。
不同于隨機測試,探索性測試是帶著“反思”的測試,通過對測試結果的分析和判斷,驅動下一步的測試設計和測試執行,達到持續優化測試價值的目的。隨機測試通常利用錯誤猜測、典型風險來驗證軟件,可以在短時間內發現許多軟件錯誤,但是它不強調測試的系統性和完整性,漏測風險很高。而探索性測試會拓展測試的深度和廣度,能夠發現一些隱藏較深的缺陷[6]。
探索性測試的指導方法有局部探索性測試和全局探索性測試兩種[6]。
局部探索性測試關注局部小范圍,測試時需要考慮5個部分:輸入、狀態、代碼路徑、用戶數據和執行環境[6]。這5個部分的測試可按照傳統的腳本化測試用例設計方法進行設計測試,如:輸入,可采用等價類劃分法、邊界值法、錯誤推測法等方法進行測試[3]。
全局探索性測試也叫漫游測試,把全局探索性測試和旅游進行類比,測試人員就是游客,被測軟件就是旅游地。旅游地按照功能區域劃分可劃分為:商業區、歷史區、旅游區、娛樂區、旅館區和破舊區[6]。各功能區域說明及測試要點如表1所示。
針對不同區域選取不同的測試方法進行測試:商業區側重于測試用戶關注的核心業務和功能,可采用指南測試法、賣點測試法、地標測試法、極限測試法、快遞測試法、深夜測試法、遍歷測試法;針對歷史區舊的功能和缺陷修復代碼可采用惡鄰測試法、博物館測試法、上一版測試法;娛樂區測試對應到軟件上就是輔助功能,可采用配角測試法、深巷測試法、通宵測試法進行測試;類比旅游區的可快速訪問功能的測試可采用收藏家測試法、長路徑測試法、超模測試、測一送一測試法;旅館區可采用取消測試法、懶漢測試法;破舊區測試可采用破壞測試法、反叛測試法、強迫癥測試法。
在實際測試工作中針對功能點的測試可以采用局部探索性測試,針對涉及到業務的場景及整體層面的可以采用全局探索性測試。
文獻[9]指出了采用探索性測試的情況,如:文檔資料缺乏;產品不穩定、軟件版本較多;測試人員專業技能不足;沒有時間編寫測試計劃和測試腳本。根據對探索性測試的研究,結合項目測試管理經驗,在以下情況下也可考慮采用探索性測試:
(1) 項目組人員調整后,新成員為了能夠在短時間內快速了解系統,可以執行一次探索性測試。
(2) 在缺陷驗證時,為了確認修復缺陷時是否引入新缺陷,可以加入適當圍繞該被測功能點的探索性測試,及時發現可能由修復帶來的新缺陷。
(3) 在完成常規測試且時間充沛的情況下進行探索性測試可以檢查測試的完整性,拓展當前測試的覆蓋度和深度。
(4) 出于對現存測試設計和結果存疑的情況下,可以執行探索性測試來驗證。
由于探索性測試不同于傳統的先設計、再執行,它強調設計和測試的同時性,如果不講究方法、沒有重點地盲目進行測試,就會出現重復測試和漏測的情況。在實際工作中,實施探索性測試也要保證測試覆蓋率。
文獻[10]提出將探索性測試和腳本測試的優勢結合到混合測試過程中的方法。文獻[11]研究表明,將探索式軟件測試融入傳統測試模型,在每個階段測試執行完成后進行探索式測試可以提高測試覆蓋率。目前許多國內外專家學者也認可這種“腳本化為主、探索性測試為輔”的二者融合方案[7]。即執行腳本化測試用例,又邊測試邊記錄新的測試點,過程中不斷分析、不斷學習,發現更多的腳本化測試發現不了的缺陷。
傳統的軟件測試一般嚴格按照測試需求分析、編寫測試計劃、測試計劃評審、編寫測試用例、測試用例評審、搭建測試環境、執行測試、提交缺陷、修復缺陷、驗證缺陷、回歸測試等流程執行,測試流程如圖1所示。

圖1 傳統測試流程
隨著軟件應用的發展,軟件出現了推出快、變化頻繁、接口雜、重體驗、開放性等特點[12],測試也需要適當進行調整以適應這種變化。文獻[13]表明,不論如何測試也不能保證軟件中不存在任何錯誤,但是通過測試策略可以努力使測試盡可能完全。
通過在傳統測試流程中加入探索性測試,分別分析在系統測試階段后和系統測試階段加入探索性測試發現的缺陷的有效性、在總缺陷數中的占比及發現的缺陷類型,查看實施探索性測試對腳本化測試的助力到底如何。
在測試需求分析、設計測試用例及測試用例評審階段融入探索性測試思維,融入探索性測試后測試流程如圖2所示。

圖2 融入探索性測試后測試流程
在測試需求分析階段加入探索性測試,通過換位思考站在包括業務領域專家、用戶、項目經理、開發人員、公司管理者角度分析他們對需求規格的要求,也可以參考同類軟件或以前項目經驗等對其進行探索性測試,從而發現更多隱形需求,進而避免由于需求原因而埋下缺陷。
在設計測試用例階段加入探索性測試,將通過思考學習獲得的一切與軟件系統相關的信息設計成測試用例,意在通過執行測試用例發現更多的需求規格說明中沒有明確說明的隱形或深層業務方面的缺陷。在測試用例評審階段加入探索性測試,通過借助眾人的智慧和經驗,豐富用例設計內容,減少漏測率。在執行測試階段加入探索性測試,意在將測試人員的測試經驗和測試思想轉化為盡早發現的缺陷,降低后期缺陷修復成本。在驗證缺陷階段加入探索性測試意在驗證修復缺陷時是否影響到了其他模塊功能使用,是否引入新的缺陷。在回歸測試階段加入探索性測試意在確認最終效果是否滿足用戶需要。
實施探索性測試的難點在于測試執行環節,執行時面對持續變化的情況,由于測試人員的認知不同,應對方式也會不同。為了指導測試,探索性測試也需要進行測試設計,此工作可以在執行前進行,也可在執行測試時進行。探索性測試設計不局限于傳統的腳本化測試用例的設計,需要包含:唯一標識、摘要、描述、設計方法、測試階段、測試類型、預期結果、測試步驟等。探索性測試設計可以是思維導圖等,意在記錄測試點及系統業務等,便于后期系統維護及回歸測試。
結合項目實際情況基于1.3節中場景(3)和場景(4)的考慮,選擇某區實驗室管理系統、某任務管理軟件和某信息化平臺這三個項目為實踐對象來研究如何采用探索性測試開展軟件測試工作,并對測試結果進行分析,選取的項目基本信息如表2所示。

表2 實踐項目信息
這三個項目的測試過程都是按照CMMI3級標準進行管理的,對其分析的結果具有一定的可參考性,對于后期軟件管理過程改進也有一定的幫助。
某區實驗室管理系統是一個專屬于該區環境保護檢測站實驗室內部工作管理的管理系統。主要用于實驗室基礎信息管理、樣品報告流轉、報告數據統計和樣品數據統計。
按照已有的測試流程完成測試后,得出該系統的千行代碼缺陷率為2.56,而根據2016年-2018年項目測試累計數據得到的平均千行代碼缺陷率分別為4.5、5.0和4.3,故在此系統中引入探索性測試,通過探索性測試確認該系統是否測試充分,是否存在漏測的情況。
某區實驗室管理系統采用“腳本化為主、探索性測試為輔”的測試方案進行測試,在系統測試完成后引入探索性測試,軟件測試總體流程見圖3。

圖3 軟件測試總體流程圖
探索性測試的測試過程如下:
(1) 測試負責人收集測試相關文檔,包括:需求規格說明書、需求變更申請單、測試說明等,并結合已完成系統獲取需要測試的內容,然后制定測試計劃、分配測試人員和測試內容。
(2) 探索性測試人員與項目組測試人員進行溝通,了解更多業務信息及缺陷分布情況等,確定高風險功能點。
(3) 開始執行探索性測試,在這個過程中同時進行測試執行、思考學習、測試設計,并根據實際情況隨時更改測試策略,同時記錄軟件邏輯和發現的缺陷。
(4) 項目組開發人員對缺陷進行修復,測試人員再對其進行驗證,待所有缺陷閉環后,進行測試結果分析、總結。
文獻[12]指出,不同的人實施探索性測試會有不同的效果,在制定探索性測試計劃時需要做到:給新人分配的是基本信息的增刪改查,除了希望發現更多缺陷外,也希望通過此次測試能夠加深對測試的理解;經驗豐富的人,用于執行核心的業務流程,希望通過他確認重要的影響因素在設計中已經都考慮到了;有開發經驗的,期望他能夠發現框架等更深層次的缺陷。
通過對腳本化測試發現的缺陷,及執行完腳本化測試后加入探索性測試后探索性測試發現的缺陷進行統計分析,得到加入探索性測試后發現的缺陷數和測試耗時情況如表3所示。

表3 加入探索性測試后測試結果
由表3可知,實施探索性測試后又發現了92個缺陷,說明實施探索性測試是有必要的,能夠提高產品的質量。分析投入與產出效能可知,實施探索性測試雖然耗時增加了37.5%,但是發現的缺陷增量也高達35.11%,實施探索性測試后該系統的千行代碼缺陷率也達到了4.6,參考以往測試結果說明此次探索性測試是較充分的。針對92個缺陷進行分析后可知,有90%的缺陷是有效缺陷,也是被項目組的開發人員所認可的缺陷,探索性測試發現的缺陷分類如圖4所示。

圖4 探索性測試缺陷分類
探索性測試發現的有效缺陷的類別如圖5所示。

圖5 有效缺陷類別
由圖5可知,探索性測試發現的缺陷主要集中在功能性和易用性這兩個方面,同時也能發現安全性、維護性、兼容性和可靠性方面的缺陷。
參考文獻[14-15]后,將探索性測試思維應用到傳統軟件測試中,應用后測試流程如圖6所示。

圖6 加入探索性測試后測試流程
將探索性測試應用于某任務管理軟件和某信息化平臺的執行測試、缺陷驗證和回歸測試階段中,對測試數據進行整理分析后得到表4和表5所示測試結果。

表4 某任務管理軟件實施了探索性測試后測試結果

表5 某信息化平臺實施了探索性測試后測試結果
將實施探索性測試后發現的缺陷進行整理后,得到實施探索性測試發現的缺陷分布情況如圖7所示。

圖7 探索性測試發現缺陷分布
從測試結果可以看出,探索性測試發現的缺陷分布主要集中在功能性和易用性兩個方面。
將探索性測試應用到三個不同類型的項目中,發現均能夠助力腳本化測試使發現缺陷的總量增長至少25%以上。由此可知,探索性測試對于腳本測試是一種非常有益有效的補充。
探索性測試作為一種新的測試理論,除了將探索性測試思維融入到軟件測試的各個階段外,后期還可從以下兩個方面繼續進行研究:(1) 目前已有腳本化測試的公共測試用例庫,隨著開展探索性測試的項目越來越多,通過探索性測試方法分析出一些測試點,抽取可以復用的探索性測試的測試用例也是一種需要;(2) 針對已經出了原型需要進行測試的項目,及采購類產品和設備構建以探索性測試為主的測試過程也是一種可嘗試的方向。