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

那么，如果我們能夠獲取開發(fā)代碼，我們?cè)趺磸拇a入手，進(jìn)行具體的局部探索性測(cè)試呢？

簡(jiǎn)單回顧

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

一張圖說明一切。

圖1局部探索性測(cè)試測(cè)試要點(diǎn)總結(jié)

具體案例講解

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

比對(duì)代碼改動(dòng)，尋找測(cè)試要點(diǎn)！

隨著功能的改進(jìn)或者故障的修復(fù)，總會(huì)伴隨代碼的改動(dòng)。因此，我們可以從代碼改動(dòng)點(diǎn)出發(fā)尋找測(cè)試要點(diǎn)。

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

圖2 elasticsearch開源代碼提交記錄：修改遠(yuǎn)程集群設(shè)置的authorization為credentials

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

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

我們?cè)賮砜匆粋€(gè)樣例。如下圖所示，為elasticsearch的PreviewTransformAction.java某次代碼變動(dòng)。

從提交記錄說明可以看到變動(dòng)原因：目前我們按順序序列化轉(zhuǎn)換預(yù)覽文檔。

然而，當(dāng)我們?cè)诹硪欢俗x取它們時(shí)，我們將其反序列化為散列映射，失去順序。因此，排序時(shí)序列化毫無意義。但是在集成測(cè)試時(shí)，writeMapWithConsistentOrder的使用總使得集成測(cè)試失敗，因此將其改為無功能影響的writeGenericMap。

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

所以，對(duì)此次變更，我們應(yīng)首要進(jìn)行功能回歸測(cè)試，確保已有功能正常。那還有沒有其它測(cè)試要點(diǎn)呢？試試writeGenericMap是否真的是無順序轉(zhuǎn)換？

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

注意覆蓋代碼中的分支！

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

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

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

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

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

如圖5所示，switch…case分支，想想：測(cè)試場(chǎng)景中覆蓋完了所有case分支嗎？如果沒有，如何構(gòu)造場(chǎng)景走到這些分支，尤其是default分支？

3)異常都捕獲到?jīng)]？

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

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

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

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

如題所述，試試不同的返回值對(duì)調(diào)用者的影響。看看是否調(diào)用方都能夠正確處理或響應(yīng)。如下圖7所示，試試不同case分支下的返回值，尤其是不常見用的返回值，如PARTIAL、INCOMPATIBLE等。

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

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

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

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

如上圖8所示，定義返回類型為L(zhǎng)ist，如果返回值的類型不是list或者列表中的值不是String呢？想想。

6)正則表達(dá)式呢？

正則表達(dá)式是很多測(cè)試人員頭疼的一點(diǎn)，因?yàn)槿斯そ馕霾惶槙?。在此可以給大家推薦一個(gè)很好的解析器網(wǎng)址https://regexper.com/#%5Ba-zA-Z_0-9%5D%7B3%2C%7D。如下圖所示，將正則表達(dá)式輸入，就可以解析。

圖9 regexper。com正則表達(dá)式解析網(wǎng)站

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

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

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

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

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

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

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

3.總結(jié)

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

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

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