NEWS


持續探索與研究

您的位置: > 網站建設最新簽約客戶 > 正文



我們的本意是想通過工具幫助測試人員更好完成測試工作,但是我們不想增加額外成本,所以我們把上面部分功能進行模塊化拆分,每一步可能是一個命令,一個接口,可以嵌入到CI的過程當中,我們開始嵌入到Jenkins,后來又對接了集團的云平臺,因為我們將功能進行了服務化,可以很方便的和外部系統進行對接。

下面跟大家交流一下工具在我們測試工作當中的一些應用情況,下面是一個示例,某天下午我收到的開發的提測,他告訴我這個需求已經部署到測試環境,我可以進行測試了。

我們先來說說這個需求的背景,我們是做汽車電商的部門,基本業務形態是可以在網上買一些汽車相關的產品,比如買一個汽車的抵扣券,你花100塊錢買一個2千塊錢抵扣券,你出示券碼可以在總車款抵扣兩千塊錢,就像之前團購的餐券線上購買線下消費。
但是汽車電商略有不同,因為它還需要支付大額的尾款,比如說支付20萬尾款,這個支付過程時間有可能會比較長,比如有些顧客需要刷好幾張卡,如果其中一個卡出問題還需要解決一下,所以支付系統給我們提了一個需求,需要在他刷第一筆款時把券碼鎖住,避免打款過程中,券碼狀態發生改變。

這是他大體的需求,從技術維度來講需要我們提供一個接口,我們對接口進行測試,按照常規測試,與開發聊很多開發的設計和我們需要測試的東西,既然是要試用新工具,那我決定這次換一個方式開始這個任務,我沒有找開發直接聊,而是拉了項目覆蓋率報告,我們發現都是紅色的,這代表什么?代表著這個分支沒有被測試過,因為還沒有進行測試。

第二個現象是這個項目的覆蓋率報告只有一個類被顯示了出來,這說明開發只修改了這一個類,所以濟南網站建設公司的測試范圍就被控制在了這一個類以內,這就達到了縮小測試范圍的目的。然后我們再去分析改的這部分代碼,我們發現這就是是一個spring MVC編寫的接口的代碼,前面是各種參數校驗,后面是對券碼的操作邏輯。

我們先進行冒煙測試,就是拿開發給我們一個URL 和demo參數進行調用,我們將接口測試的數據錄入我們自研的接口測試平臺并運行,發現接口給我反饋了錯誤代碼4207(提車碼不正確)-不可凍結。按照之前的方法我們會直接扔給開發讓他們查找原因,現在我們換了一個方式,我們沒有直接扔給開發,而是拉了一次覆蓋率報告,報告中綠色代表的是被執行,黃色代表部分被執行。我們發現邏輯已經進入了這個方法,然后在第三個IF判斷時候進入了報錯邏輯,并拋回了錯誤信息,這個過程有一點像開發的Debug,我們看語句塊進入邏輯,發現是券碼狀態有問題,我推斷可能開發給我測試數據時候,可能已經用這個參數進行了自測,已經變成凍結狀態了,我再次凍結自然可能就有問題了,我分析出問題的原因,其實問題已經解決一大半了,怎么解決呢,因為我們還有解凍接口,我用同樣的參數調用了解凍接口,我發現成功了,說明我們的推斷是正確的。

我們繼續驗證,濟南網站建設公司再次調用凍結接口,我發現這次凍結成功了,發現我們的推斷是完全正確的。

我們再拉一下覆蓋率數據,我們發現已經跳出了上一次把我們扔出去的邏輯,然后進行到底部也就是主邏輯,我們發現這個方法完全被執行了,這個節點在測試中其實很重要,叫做主流程跑通。有些質量要求級別低的項目主流程跑通是可以上線的。




但是我們這時候拉取了整個項目覆蓋率情況,我們發現只有62%,我主流程跑通了,但是覆蓋率只有一半多一點,這個數據當然不是很理想,沒有關系,我們進一步去分析原因,我們需要分析的是里面的紅色部分,我們發現紅色部分都是異常情況的判斷,說第一個校驗的是參數合法性,這段邏輯無法進入是因為我們參數合法的,我要進去很簡單,我將參數改成非法就可以了,所以我把其中一個參數APPID改為不合法,然后再去調用,我發現有一些不同,給我返回了一個類似Json的信息,但是內部是空白的,這應該是有問題的,因為一個接口可以返回正確也可以返回錯誤,但是返回空白一定是不正確的,所以我就把問題反饋給開發,開發直接問我哪一個方法你知道嗎,我直接把方法貼給對方,因為我跟進覆蓋率報告,分析的就是代碼級別的東西,所以他根據你貼的代碼,就不需要調試直接就定位到問題了,然后修復了該問題。

我們再次用同樣的參數組合調用了一下凍結接口,發現反饋給了我們想要的東西,同時開發也表達了他比較激動的心情。為什么會這樣?因為你給他減少了工作量,他不需要去調試,不需要重復做你做過的事情了,所以代碼級別的一個溝通就會給他省掉很多工作量。

我們如法炮制,把所有代碼塊都進行了條件分析,對它進行進入測試。

這個校驗的是提車碼不存在的情況,我們把提車碼改成不存在的場景也進入了。這個校驗的是提車碼的有效期,我們把時間改成過期也可以進入這個邏輯。

其實操作都差不多,就是根據它的條件進入反面的邏輯就能進入到相關邏輯,這是一個信息的狀態,這是訂單類型,我們改成非法類型也可以進入,非法校驗確實很多。當我們把所有非法校驗進行了一個測試以后,我們這時候拉取覆蓋率報告,發現基本上全變成綠色了,因為所有邏輯我們都進行了覆蓋,下面僅有兩行紅色,我們發現其實是一個異常捕獲,就是當你邏輯進行不可預知異常才會進入,這是一個破壞性測試,比如中間掉一個接口報錯了,然后我們就會進入這個異常捕獲,理論上也可以進入的。

這時候我們再拉一次項目級別覆蓋率數據,我們發現自解碼已經到97%,分支已經到83%,我們認為這還是不錯的覆蓋率數據,并且紅色部分我們也進行了合理化解釋,所以我們覺得這是比較理想的測試結果。

我們復盤一下這個過程,這個工具到底幫助我們提升了什么?首先我前面故意找了一個我不是很熟悉的隔壁組項目來做的。開發只給了我一個URL和Demo參數,我發現我最后得到了一份很豐富的測試用例,我跟測試人員聊了,其實真的是按照傳統方式測的話可能其中很多的前置條件還會漏掉,一些異常情況會進入不了。

所以第一個收益是在我不了解一個業務邏輯情況下我完成了測試,并且這個測試是相對全面的。

第二個收益是我在前面測試所有參數組合都錄入到我們系統當中,當我需要回歸這個接口的時候可能只需要運行上面錄得所有接口參數組合就可以了,但是這里我想說的并不是自動化測試,當你多次迭代后,如果你自動化測試沒有進行及時的更新,那自動化測試的效果就會越來越差,這時你就會發現自動化的測試的作用會被逐漸消磨掉,我們發現覆蓋率監控可以解決這個問題,我們每次執行自動化測試都會關注它的覆蓋率。假如說這一次是98%,下次執行是濟南網站建設公司發現覆蓋率變成了60%,一定是開發加了新邏輯,而你的自動化測試沒有更新,那就需要你對自動化用例進行更新了,所以等于我們加入了一個自動化測試用例效果的監控機制。

再說第三個收益,我們在整個用例設計過程當中是有依據的,我們不會隨意的刪減有效用例,也不會做一些多余的無效覆蓋,我們把這叫做精準化測試思想,大家可以看到精準化測試思路在我們測試流程當中,對我們的幫助是多方面的。

再來說說我們的愿景,我們更深層次的復盤了我們的整個流程,發現中間這個工具只是幫助我們去分析了一些東西,但是具體分析和操作還是需要人力去完成的,我們就在想其中一些工作量是不是還可以繼續交給工具。我們既然拿到操作覆蓋率,我們反過來想我們是不是能夠建立代碼節點與用例集、用例組的關系,就是當代碼改變時候我可以映射出我需要執行的哪些用例。當我們采集到這個關系以后,我們用DIFF引擎把差異代碼分析出來,我們直接映射到的就是我們用例級別的測試方案了。

大家會覺得有一點天方夜譚,我們開始也這么想,因為等于把測試策略交給機器去做,我們對這個方案也是充滿了顧慮,所以我們加了圖中最下面這一行,我們把推薦的用例執行過程進行監控,并根據監控結果回過頭來查找推薦本身是否存在缺陷,假如說缺陷是用例不完整造成的,那我們就補充用例,如果關系有問題我們就進行關系調優,最終形成一個自我優化的閉環。





本文來源于   - 「夢之網科技」濟南網站建設公司 濟南網頁設計 www.kurbec.icu TEL:0531_8608_8957     本文網址:http://www.kurbec.icu/qianyue/1010.html



相關文章推薦:
濟南網站建設公司需要簡單說一下Jacoco的工作原理(一)

上一篇:濟南網站建設公司需要簡單說一下Jacoco的工作原理(一) 下一篇:沒有資料

秒速时时彩人为控制