測試開發(fā)人員如何進(jìn)行局部探索性測試？一張圖告訴你

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

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

簡單回顧

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

一張圖說明一切。

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

具體案例講解

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

比對代碼改動，尋找測試要點(diǎn)！

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

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

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

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

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

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

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

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

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

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

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

注意覆蓋代碼中的分支！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.總結(jié)

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

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

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