我們的本意是想通過工具幫助測試人員更好完成測試工作，但是我們不想增加額外成本，所以我們把上面部分功能進(jìn)行模塊化拆分，每一步可能是一個命令，一個接口，可以嵌入到CI的過程當(dāng)中，我們開始嵌入到Jenkins，后來又對接了集團(tuán)的云平臺，因?yàn)槲覀儗⒐δ苓M(jìn)行了服務(wù)化，可以很方便的和外部系統(tǒng)進(jìn)行對接。
下面跟大家交流一下工具在我們測試工作當(dāng)中的一些應(yīng)用情況，下面是一個示例，某天下午我收到的開發(fā)的提測，他告訴我這個需求已經(jīng)部署到測試環(huán)境，我可以進(jìn)行測試了。
我們先來說說這個需求的背景，我們是做汽車電商的部門，基本業(yè)務(wù)形態(tài)是可以在網(wǎng)上買一些汽車相關(guān)的產(chǎn)品，比如買一個汽車的抵扣券，你花100塊錢買一個2千塊錢抵扣券，你出示券碼可以在總車款抵扣兩千塊錢，就像之前團(tuán)購的餐券線上購買線下消費(fèi)。
但是汽車電商略有不同，因?yàn)樗�需要支付大額的尾款，比如說支付20萬尾款，這個支付過程時間有可能會比較長，比如有些顧客需要刷好幾張卡，如果其中一個卡出問題還需要解決一下，所以支付系統(tǒng)給我們提了一個需求，需要在他刷第一筆款時把券碼鎖住，避免打款過程中，券碼狀態(tài)發(fā)生改變。
這是他大體的需求，從技術(shù)維度來講需要我們提供一個接口，我們對接口進(jìn)行測試，按照常規(guī)測試，與開發(fā)聊很多開發(fā)的設(shè)計(jì)和我們需要測試的東西，既然是要試用新工具，那我決定這次換一個方式開始這個任務(wù)，我沒有找開發(fā)直接聊，而是拉了項(xiàng)目覆蓋率報(bào)告，我們發(fā)現(xiàn)都是紅色的，這代表什么？代表著這個分支沒有被測試過，因?yàn)檫�沒有進(jìn)行測試。
第二個現(xiàn)象是這個項(xiàng)目的覆蓋率報(bào)告只有一個類被顯示了出來，這說明開發(fā)只修改了這一個類，所以
濟(jì)南網(wǎng)站建設(shè)公司的測試范圍就被控制在了這一個類以內(nèi)，這就達(dá)到了縮小測試范圍的目的。然后我們再去分析改的這部分代碼，我們發(fā)現(xiàn)這就是是一個spring MVC編寫的接口的代碼，前面是各種參數(shù)校驗(yàn)，后面是對券碼的操作邏輯。
我們先進(jìn)行冒煙測試，就是拿開發(fā)給我們一個URL 和demo參數(shù)進(jìn)行調(diào)用，我們將接口測試的數(shù)據(jù)錄入我們自研的接口測試平臺并運(yùn)行，發(fā)現(xiàn)接口給我反饋了錯誤代碼4207（提車碼不正確）-不可凍結(jié)。按照之前的方法我們會直接扔給開發(fā)讓他們查找原因，現(xiàn)在我們換了一個方式，我們沒有直接扔給開發(fā)，而是拉了一次覆蓋率報(bào)告，報(bào)告中綠色代表的是被執(zhí)行，黃色代表部分被執(zhí)行。我們發(fā)現(xiàn)邏輯已經(jīng)進(jìn)入了這個方法，然后在第三個IF判斷時候進(jìn)入了報(bào)錯邏輯，并拋回了錯誤信息，這個過程有一點(diǎn)像開發(fā)的Debug，我們看語句塊進(jìn)入邏輯，發(fā)現(xiàn)是券碼狀態(tài)有問題，我推斷可能開發(fā)給我測試數(shù)據(jù)時候，可能已經(jīng)用這個參數(shù)進(jìn)行了自測，已經(jīng)變成凍結(jié)狀態(tài)了，我再次凍結(jié)自然可能就有問題了，我分析出問題的原因，其實(shí)問題已經(jīng)解決一大半了，怎么解決呢，因?yàn)槲覀冞�有解凍接口，我用同樣的參數(shù)調(diào)用了解凍接口，我發(fā)現(xiàn)成功了，說明我們的推斷是正確的。
我們繼續(xù)驗(yàn)證，濟(jì)南網(wǎng)站建設(shè)公司再次調(diào)用凍結(jié)接口，我發(fā)現(xiàn)這次凍結(jié)成功了，發(fā)現(xiàn)我們的推斷是完全正確的。
我們再拉一下覆蓋率數(shù)據(jù)，我們發(fā)現(xiàn)已經(jīng)跳出了上一次把我們?nèi)映鋈サ倪壿嫞缓筮M(jìn)行到底部也就是主邏輯，我們發(fā)現(xiàn)這個方法完全被執(zhí)行了，這個節(jié)點(diǎn)在測試中其實(shí)很重要，叫做主流程跑通。有些質(zhì)量要求級別低的項(xiàng)目主流程跑通是可以上線的。
但是我們這時候拉取了整個項(xiàng)目覆蓋率情況，我們發(fā)現(xiàn)只有62%，我主流程跑通了，但是覆蓋率只有一半多一點(diǎn)，這個數(shù)據(jù)當(dāng)然不是很理想，沒有關(guān)系，我們進(jìn)一步去分析原因，我們需要分析的是里面的紅色部分，我們發(fā)現(xiàn)紅色部分都是異常情況的判斷，說第一個校驗(yàn)的是參數(shù)合法性，這段邏輯無法進(jìn)入是因?yàn)槲覀儏?shù)合法的，我要進(jìn)去很簡單，我將參數(shù)改成非法就可以了，所以我把其中一個參數(shù)APPID改為不合法，然后再去調(diào)用，我發(fā)現(xiàn)有一些不同，給我返回了一個類似Json的信息，但是內(nèi)部是空白的，這應(yīng)該是有問題的，因?yàn)橐粋�接口可以返回正確也可以返回錯誤，但是返回空白一定是不正確的，所以我就把問題反饋給開發(fā)，開發(fā)直接問我哪一個方法你知道嗎，我直接把方法貼給對方，因?yàn)槲腋M(jìn)覆蓋率報(bào)告，分析的就是代碼級別的東西，所以他根據(jù)你貼的代碼，就不需要調(diào)試直接就定位到問題了，然后修復(fù)了該問題。
我們再次用同樣的參數(shù)組合調(diào)用了一下凍結(jié)接口，發(fā)現(xiàn)反饋給了我們想要的東西，同時開發(fā)也表達(dá)了他比較激動的心情。為什么會這樣？因?yàn)槟憬o他減少了工作量，他不需要去調(diào)試，不需要重復(fù)做你做過的事情了，所以代碼級別的一個溝通就會給他省掉很多工作量。
我們?nèi)绶ㄅ谥疲阉写a塊都進(jìn)行了條件分析，對它進(jìn)行進(jìn)入測試。
這個校驗(yàn)的是提車碼不存在的情況，我們把提車碼改成不存在的場景也進(jìn)入了。這個校驗(yàn)的是提車碼的有效期，我們把時間改成過期也可以進(jìn)入這個邏輯。
其實(shí)操作都差不多，就是根據(jù)它的條件進(jìn)入反面的邏輯就能進(jìn)入到相關(guān)邏輯，這是一個信息的狀態(tài)，這是訂單類型，我們改成非法類型也可以進(jìn)入，非法校驗(yàn)確實(shí)很多。當(dāng)我們把所有非法校驗(yàn)進(jìn)行了一個測試以后，我們這時候拉取覆蓋率報(bào)告，發(fā)現(xiàn)基本上全變成綠色了，因?yàn)樗羞壿嬑覀兌歼M(jìn)行了覆蓋，下面僅有兩行紅色，我們發(fā)現(xiàn)其實(shí)是一個異常捕獲，就是當(dāng)你邏輯進(jìn)行不可預(yù)知異常才會進(jìn)入，這是一個破壞性測試，比如中間掉一個接口報(bào)錯了，然后我們就會進(jìn)入這個異常捕獲，理論上也可以進(jìn)入的。
這時候我們再拉一次項(xiàng)目級別覆蓋率數(shù)據(jù)，我們發(fā)現(xiàn)自解碼已經(jīng)到97%，分支已經(jīng)到83%，我們認(rèn)為這還是不錯的覆蓋率數(shù)據(jù)，并且紅色部分我們也進(jìn)行了合理化解釋，所以我們覺得這是比較理想的測試結(jié)果。
我們復(fù)盤一下這個過程，這個工具到底幫助我們提升了什么？首先我前面故意找了一個我不是很熟悉的隔壁組項(xiàng)目來做的。開發(fā)只給了我一個URL和Demo參數(shù)，我發(fā)現(xiàn)我最后得到了一份很豐富的測試用例，我跟測試人員聊了，其實(shí)真的是按照傳統(tǒng)方式測的話可能其中很多的前置條件還會漏掉，一些異常情況會進(jìn)入不了。
所以第一個收益是在我不了解一個業(yè)務(wù)邏輯情況下我完成了測試，并且這個測試是相對全面的。
第二個收益是我在前面測試所有參數(shù)組合都錄入到我們系統(tǒng)當(dāng)中，當(dāng)我需要回歸這個接口的時候可能只需要運(yùn)行上面錄得所有接口參數(shù)組合就可以了，但是這里我想說的并不是自動化測試，當(dāng)你多次迭代后，如果你自動化測試沒有進(jìn)行及時的更新，那自動化測試的效果就會越來越差，這時你就會發(fā)現(xiàn)自動化的測試的作用會被逐漸消磨掉，我們發(fā)現(xiàn)覆蓋率監(jiān)控可以解決這個問題，我們每次執(zhí)行自動化測試都會關(guān)注它的覆蓋率。假如說這一次是98%，下次執(zhí)行是濟(jì)南網(wǎng)站建設(shè)公司發(fā)現(xiàn)覆蓋率變成了60%，一定是開發(fā)加了新邏輯，而你的自動化測試沒有更新，那就需要你對自動化用例進(jìn)行更新了，所以等于我們加入了一個自動化測試用例效果的監(jiān)控機(jī)制。
再說第三個收益，我們在整個用例設(shè)計(jì)過程當(dāng)中是有依據(jù)的，我們不會隨意的刪減有效用例，也不會做一些多余的無效覆蓋，我們把這叫做精準(zhǔn)化測試思想，大家可以看到精準(zhǔn)化測試思路在我們測試流程當(dāng)中，對我們的幫助是多方面的。
再來說說我們的愿景，我們更深層次的復(fù)盤了我們的整個流程，發(fā)現(xiàn)中間這個工具只是幫助我們?nèi)シ治隽艘恍〇|西，但是具體分析和操作還是需要人力去完成的，我們就在想其中一些工作量是不是還可以繼續(xù)交給工具。我們既然拿到操作覆蓋率，我們反過來想我們是不是能夠建立代碼節(jié)點(diǎn)與用例集、用例組的關(guān)系，就是當(dāng)代碼改變時候我可以映射出我需要執(zhí)行的哪些用例。當(dāng)我們采集到這個關(guān)系以后，我們用DIFF引擎把差異代碼分析出來，我們直接映射到的就是我們用例級別的測試方案了。
大家會覺得有一點(diǎn)天方夜譚，我們開始也這么想，因?yàn)榈扔诎褱y試策略交給機(jī)器去做，我們對這個方案也是充滿了顧慮，所以我們加了圖中最下面這一行，我們把推薦的用例執(zhí)行過程進(jìn)行監(jiān)控，并根據(jù)監(jiān)控結(jié)果回過頭來查找推薦本身是否存在缺陷，假如說缺陷是用例不完整造成的，那我們就補(bǔ)充用例，如果關(guān)系有問題我們就進(jìn)行關(guān)系調(diào)優(yōu)，最終形成一個自我優(yōu)化的閉環(huán)。