我們都知道全局探索性測試的漫游測試法，也知道局部探索性測試可以從用戶輸入、狀態(tài)、代碼路徑、用戶數(shù)據和執(zhí)行環(huán)境測試著手點。

那么，如果我們能夠獲取開發(fā)代碼，我們怎么從代碼入手，進行具體的局部探索性測試呢？

簡單回顧

在進行具體的案例講解前，我們先簡單回顧下局部探索性測試的用戶輸入、狀態(tài)、代碼路徑、用戶數(shù)據和執(zhí)行環(huán)境測試方法。

一張圖說明一切。

圖1局部探索性測試測試要點總結

具體案例講解

本文從代碼層入手，分享如何進行局部探索性測試。值得注意的是，接下來的敘述沒有優(yōu)先級和重要性排序，單純是某些測試要點的啟發(fā)。

比對代碼改動，尋找測試要點！

隨著功能的改進或者故障的修復，總會伴隨代碼的改動。因此，我們可以從代碼改動點出發(fā)尋找測試要點。

在此，需要大家問自己幾個問題：開發(fā)人員為什么要這樣改？這樣改有什么意義？

圖2 elasticsearch開源代碼提交記錄：修改遠程集群設置的authorization為credentials

由上圖2所示，為elasticsearch開源代碼某次提交記錄（修改遠程集群設置的authorization為credentials）。如果我們獲取到這樣一份代碼，我們要怎么尋找測試要點呢？！

對于代碼修改的原因和意義，開發(fā)人員在代碼提交記錄中已經聲明：credentials名字更精確。而且從提交記錄中，我們還可以看到有許多地方涉及的authorization被修改。因此，我們很容易就能想到一個測試要點：authorization名字修改是否覆蓋完全？！

我們再來看一個樣例。如下圖所示，為elasticsearch的PreviewTransformAction.java某次代碼變動。

從提交記錄說明可以看到變動原因：目前我們按順序序列化轉換預覽文檔。

然而，當我們在另一端讀取它們時，我們將其反序列化為散列映射，失去順序。因此，排序時序列化毫無意義。但是在集成測試時，writeMapWithConsistentOrder的使用總使得集成測試失敗，因此將其改為無功能影響的writeGenericMap。

由此我們一眼可以得出最重要的一個信息：功能不影響。

所以，對此次變更，我們應首要進行功能回歸測試，確保已有功能正常。那還有沒有其它測試要點呢？試試writeGenericMap是否真的是無順序轉換？

圖3 elasticsearch開源代碼提交記錄：修改writeMapWithConsistentOrder方法調用為為writeGenericMap調用

注意覆蓋代碼中的分支！

開發(fā)代碼中經常會有if…else、switch…case等分支，可是當我們從外部進行場景測試或功能測試時很少能覆蓋完全代碼中的分支，從而可能忽視某些故障。因此，可以從代碼層面出發(fā)，尋找或構造能夠觸發(fā)代碼某個分支的場景。

圖4 elasticsearch的ElasticsearchException.java某部分代碼1

如上圖4所示，為ElasticsearchException.java某部分代碼。該代碼使用了if…else分支結構，面對這樣的代碼，我們是不是首先就會想：如何進入不同分支？進入不同分支后會有什么樣的效果？

如上圖所示，試試elasticsearchException不為null呢？再試試id!=127呢？更或者，試試傳入的id為null呢？

圖5 elasticsearch的ElasticsearchException.java某部分代碼2

如圖5所示，switch…case分支，想想：測試場景中覆蓋完了所有case分支嗎？如果沒有，如何構造場景走到這些分支，尤其是default分支？

3)異常都捕獲到沒？

我們在測試過程中，經常由于環(huán)境或其他原因的影響造成一些異常的產生。而針對異常的捕獲往往是代碼中預先定義好的，但如果異常不在期望中呢？是否能夠正常打印異常和捕獲異常？

圖6 elasticsearch的ExceptionsHelper。。java某部分代碼

如圖6所示，是try…catch…finally結構，但沒有catch分支。假如formatStackTrace功能異常呢？能夠捕獲異常嗎？試試。又或者ExceptionsHelper。maybeError(throwable)不存在呢？會是什么樣的效果，試試。

4)不同的return返回值嘗試過沒？

如題所述，試試不同的返回值對調用者的影響�？纯词欠裾{用方都能夠正確處理或響應。如下圖7所示，試試不同case分支下的返回值，尤其是不常見用的返回值，如PARTIAL、INCOMPATIBLE等。

圖7elasticsearch的SnapshotState。java某部分代碼

5)如果變量不在定義的集合范圍內呢？

代碼中我們難免會定義一些列表或集合，會聲明列表或集合元素的類型。那么，如果某個變量不在定義的類型范圍內呢，要使用列表或集合的功能處理這個變量，會怎么樣？

圖8 elasticsearch的SnapshotsInProgress。java某部分代碼

如上圖8所示，定義返回類型為List，如果返回值的類型不是list或者列表中的值不是String呢？想想。

6)正則表達式呢？

正則表達式是很多測試人員頭疼的一點，因為人工解析不太順暢。在此可以給大家推薦一個很好的解析器網址https://regexper.com/#%5Ba-zA-Z_0-9%5D%7B3%2C%7D。如下圖所示，將正則表達式輸入，就可以解析。

圖9 regexper。com正則表達式解析網站

假如針對[a-zA-Z_0-9]{3，}這樣的正則表達式，試試輸入變量為345呢？會有什么樣的效果？

7)代碼中有沒有寫死的變量？

比如常見的引用ip、port等，是否被固定了？比如有沒有用到sleep？被寫死的變量會導致代碼更改時容易忽略，而產生異常。而sleep 10s這樣的寫法會導致性能下降。試試有沒有這樣的問題？

8)每一條路徑走完沒有？

在這里可以給大家推薦一個好用的工具visustin（www.aivosto.com），可以解析代碼路徑，可視化輸出。支持java，jsp，python等多種語言。

圖10 visustin軟件解析代碼路徑樣例圖

如上圖所示，在visustin的幫助下，我們可以方便地看出每條路徑。試試遍歷所有路徑？

3.總結

探索性測試的核心在于啟發(fā)性思維。本文結合具體樣例，簡單講述了如何從代碼層面入手，開始局部探索性測試。并簡單介紹了兩個有用的工具regexper.com網站和visustin軟件，它們可以幫助我們解析正則表達式和可視化代碼路徑。工欲善其事必先利其器，希望這兩個軟件也能幫助到你。

探索性測試是一門值得研究和探討的課題，尤其是對于測試人員來說，對于專業(yè)能力的提升和個人職業(yè)的發(fā)展都有幫助。希望能有更多的同行加入探討和研究。

最后：在我的V：atstudy-js，可以免費領取一份10G軟件測試工程師面試寶典文檔資料。以及相對應的視頻學習教程免費分享！其中包括了有基礎知識、Linux必備、Shell、互聯(lián)網程序原理、Mysql數(shù)據庫、抓包工具專題、接口測試工具、測試進階-Python編程、Web自動化測試、APP自動化測試、接口自動化測試、測試高級持續(xù)集成、測試架構開發(fā)測試框架、性能測試、安全測試等。