現(xiàn)在包括 Google、Facebook 和 eBay 等一線互聯(lián)網(wǎng)巨頭公司都在逐漸推行“沒(méi)有專職測(cè)試,測(cè)試工作由開(kāi)發(fā)人員完成”的全新模式,原本專職的業(yè)務(wù)功能測(cè)試團(tuán)隊(duì)的規(guī)模逐漸縮小,有些甚至已經(jīng)完全沒(méi)有了,而原本的測(cè)試開(kāi)發(fā)團(tuán)隊(duì)逐漸在向工程效能(Engineering Productivity)團(tuán)隊(duì)轉(zhuǎn)型。這些互聯(lián)網(wǎng)巨頭之所以能夠很好地落地這種全新的模式,是因?yàn)樗麄兌驾^好地解決了這個(gè)模式的兩個(gè)最大的難題:
開(kāi)發(fā)人員如何能夠勝任測(cè)試?
工程效能團(tuán)隊(duì)如何賦能開(kāi)發(fā)人員,幫助開(kāi)發(fā)人員高效地完成高質(zhì)量測(cè)試?
本文會(huì)圍繞這兩個(gè)問(wèn)題來(lái)展開(kāi)討論。首先讓我們一起看一下開(kāi)發(fā)人員自己做測(cè)試都會(huì)遇到哪些問(wèn)題和阻礙。
1開(kāi)發(fā)人員自己做測(cè)試會(huì)遇到哪些問(wèn)題人性角度引發(fā)的問(wèn)題
首先從人性的角度來(lái)看,開(kāi)發(fā)人員通常是屬于“創(chuàng)造性思維”,自己開(kāi)發(fā)的代碼就像是親兒子一樣,怎么看都覺(jué)得實(shí)現(xiàn)很棒;而測(cè)試人員則屬于“破壞性思維”,測(cè)試人員的職責(zé)就是要盡可能多的找到潛在的缺陷,而且專職的測(cè)試人員通常已經(jīng)在以往的測(cè)試實(shí)踐中積累了大量典型的容易出錯(cuò)的模式,所以測(cè)試人員比起開(kāi)發(fā)人員,往往更能客觀且全面做好充分的測(cè)試。
思維慣性的問(wèn)題
剛才是從人性角度上來(lái)講的,如果從技術(shù)層面來(lái)看,由開(kāi)發(fā)人員自己測(cè)試,會(huì)存在嚴(yán)重的“思維慣性”,通常開(kāi)發(fā)人員在設(shè)計(jì)和開(kāi)發(fā)過(guò)程中沒(méi)有考慮到的分支和處理邏輯,在自己做測(cè)試的時(shí)候同樣不會(huì)考慮到。比如對(duì)于一個(gè)函數(shù),其中有一個(gè) String 類型的輸入參數(shù),如果開(kāi)發(fā)人員在做功能實(shí)現(xiàn)的時(shí)候壓根沒(méi)有考慮到 String 存在 Null 值得可能性,那么代碼的實(shí)現(xiàn)里面也不會(huì)對(duì) Null 值做處理,連帶結(jié)果就是測(cè)試的時(shí)候就更不會(huì)設(shè)計(jì) Null 值得測(cè)試數(shù)據(jù),這樣的“一條龍”缺失就會(huì)給代碼的質(zhì)量留下了缺陷隱患。更糟糕的是,對(duì)于這種情況,即便啟用了代碼覆蓋率指標(biāo)去衡量測(cè)試完整程度,也不能有效暴露這類問(wèn)題,因?yàn)樘幚?Null 值得代碼壓根沒(méi)有寫(xiě),又何來(lái)代碼覆蓋率一說(shuō)吶。
被測(cè)試環(huán)境和測(cè)試執(zhí)行環(huán)境的復(fù)雜性問(wèn)題
有專職測(cè)試的時(shí)候,測(cè)試工作是專職測(cè)試人員完成的,專職測(cè)試人員通常會(huì)負(fù)責(zé)搭建被測(cè)試環(huán)境以及管理測(cè)試執(zhí)行環(huán)境。被測(cè)試環(huán)境好理解,就是 System Under Test(SUT)。而測(cè)試執(zhí)行環(huán)境是指用于執(zhí)行測(cè)試用例的機(jī)器,比如對(duì)于 Web 的 GUI 測(cè)試,最簡(jiǎn)單的測(cè)試執(zhí)行環(huán)境就是你本地機(jī)器上的瀏覽器。但是對(duì)于大型互聯(lián)網(wǎng)企業(yè),測(cè)試執(zhí)行環(huán)境遠(yuǎn)遠(yuǎn)要比你想象的更復(fù)雜。通常都是一些大型的測(cè)試執(zhí)行集群,甚至是內(nèi)部的測(cè)試執(zhí)行私有云,比如用 Selenium Grid 搭建的 GUI 測(cè)試執(zhí)行環(huán)境,往往這樣的集群都會(huì)有成百上千臺(tái)機(jī)器,再比如用 Appium+Selenium Grid 搭建的移動(dòng)設(shè)備測(cè)試集群,也往往會(huì)有上千臺(tái)設(shè)備?,F(xiàn)在沒(méi)有了專職的測(cè)試人員,那就需要開(kāi)發(fā)人員自己去管理、維護(hù)和搭建這些測(cè)試基礎(chǔ)架構(gòu),這樣做其實(shí)是得不償失的,工作量本身并沒(méi)有減少,只是換了一批人來(lái)做同樣的事情,而且開(kāi)發(fā)的精力往往更應(yīng)該花在構(gòu)建新的業(yè)務(wù)功能上,而不是用在維護(hù)測(cè)試基礎(chǔ)設(shè)施。
測(cè)試數(shù)據(jù)準(zhǔn)備的問(wèn)題
測(cè)試數(shù)據(jù)準(zhǔn)備是測(cè)試過(guò)程中必不可少的關(guān)鍵步驟,有專職測(cè)試的時(shí)候,是由測(cè)試人員來(lái)準(zhǔn)備測(cè)試數(shù)據(jù)的,一方面測(cè)試人員往往比開(kāi)發(fā)人員在全局層面上更了解被測(cè)系統(tǒng),所以對(duì)于測(cè)試數(shù)據(jù)的設(shè)計(jì)與生成也會(huì)更高效,另一方面測(cè)試人員在以往的測(cè)試過(guò)程中已經(jīng)積累了很多測(cè)試數(shù)據(jù)生成的方法和小工具。現(xiàn)在這些都需要開(kāi)發(fā)人員自己來(lái)完成了,無(wú)疑進(jìn)一步加大了開(kāi)發(fā)人員的工作量,而且開(kāi)發(fā)人員往往對(duì)跨模塊,跨系統(tǒng)的測(cè)試數(shù)據(jù)準(zhǔn)備缺乏系統(tǒng)性的理解,往往為了生成一條非自己業(yè)務(wù)領(lǐng)域的數(shù)據(jù)而花費(fèi)大量的學(xué)習(xí)成本。舉個(gè)例子,假設(shè)現(xiàn)在“買家模塊”的開(kāi)發(fā)人員需要測(cè)試“商品買入”的操作,那么就需要事先準(zhǔn)備好“可以被賣的商品”,這就意味著“買家模塊”的開(kāi)發(fā)人員需要明確知道“賣家模塊”和“商品模塊”的細(xì)節(jié),才能生成“可以被賣的商品”。這類問(wèn)題在目前主流的微服務(wù)架構(gòu)面前會(huì)更嚴(yán)重,原因是為了產(chǎn)生一條測(cè)試數(shù)據(jù),可能會(huì)需要依次調(diào)用很多個(gè)服務(wù)。
測(cè)試執(zhí)行與 CI/CD 集成問(wèn)題
對(duì)于不同的業(yè)務(wù)開(kāi)發(fā)團(tuán)隊(duì),各個(gè)階段采用的自動(dòng)化測(cè)試框架可能都不同,比如有些會(huì)使用基于 Java 的 Selenium,也有些會(huì)使用基于 JavaScript 的 Nightwatch 等,有專職測(cè)試的時(shí)候,各種不同的測(cè)試框架與 CI/CD 的集成,都是由各個(gè)業(yè)務(wù)團(tuán)隊(duì)的測(cè)試人員和 CI/CD 的人員一起完成的,現(xiàn)在沒(méi)有了專職測(cè)試,這部分工作就需要開(kāi)發(fā)人員自己和 CI/CD 人員一起完成,這就要求開(kāi)發(fā)人員不僅需要非常熟悉自動(dòng)化測(cè)試框架的細(xì)節(jié)(很多時(shí)候?yàn)榱烁玫睾?CI/CD 集成,會(huì)對(duì)開(kāi)源測(cè)試框架或者是自研測(cè)試框架做二次開(kāi)發(fā),比如改進(jìn) retry 機(jī)制,增加覆蓋率統(tǒng)計(jì)等等),還必須了解 CI/CD 的流水線設(shè)計(jì)以及腳本設(shè)計(jì),然后再將需要支持的自動(dòng)化測(cè)試框架的運(yùn)行命令行和需要暴露的參數(shù)(測(cè)試用例 Git 路徑、測(cè)試執(zhí)行環(huán)境、測(cè)試報(bào)告路徑等等)寫(xiě)進(jìn) CI/CD 的腳本。這些工作在很大程度上分散了開(kāi)發(fā)的精力,對(duì)于提高開(kāi)發(fā)自身效率是非常不利的。
失敗測(cè)試用例歸屬問(wèn)題
有專職測(cè)試的時(shí)候,開(kāi)發(fā)人員往往只關(guān)注自己修改部分相關(guān)的測(cè)試用例,模塊或者服務(wù)的全回歸測(cè)試中如果有失敗的測(cè)試用例,通常是由測(cè)試人員跟進(jìn)去分析具體原因,并協(xié)調(diào)解決然后才能發(fā)布上線。但是現(xiàn)在開(kāi)發(fā)人員負(fù)責(zé)所有測(cè)試,他就必須關(guān)注全局的測(cè)試。舉個(gè)實(shí)際的例子來(lái)看,比如“用戶登錄”服務(wù)的開(kāi)發(fā)工程師修復(fù)了一個(gè)缺陷,然后本地自測(cè)通過(guò)后遞交了代碼,然后很不幸,在 CI/CD 的流水線上全回歸測(cè)試卻發(fā)現(xiàn)有部分用例失敗了,雖然這些失敗的用例和這次的代碼修改沒(méi)有任何關(guān)系,但是為了保證自己的修改能夠順利上線(CI/CD 的流水線要求只有全回歸測(cè)試 100% 通過(guò)才可以上線),他必須挨個(gè)去分析失敗的測(cè)試用例然后自己去找到對(duì)應(yīng)的人去協(xié)調(diào)解決,這顯然是非常不合理和不敏捷的做法。
歸根結(jié)底,這些問(wèn)題的本質(zhì)都會(huì)直接影響開(kāi)發(fā)人員本質(zhì)工作的進(jìn)度和效率,那么我們應(yīng)該如何解決或者在一定程度上緩解這些問(wèn)題呢?這就是接下來(lái)要討論的問(wèn)題,工程效能團(tuán)隊(duì)如何賦能開(kāi)發(fā)人員,幫助開(kāi)發(fā)人員高效地完成高質(zhì)量的測(cè)試。
2工程效能團(tuán)隊(duì)賦能開(kāi)發(fā)人員進(jìn)行高效率高質(zhì)量的測(cè)試
賦能的基本思路是能夠讓開(kāi)發(fā)人員更專注于測(cè)試本身,而從那些輔助測(cè)試的工作(比如搭建測(cè)試執(zhí)行環(huán)境、CI/CD 集成等)上解放出來(lái),這些輔助測(cè)試的工作由“工程效能”服務(wù)或者相關(guān)支持工具鏈來(lái)統(tǒng)一解決。這個(gè)思想和和目前非常流行的 Service Mesh 的設(shè)計(jì)思想不謀而合,Service Mesh 也是可以讓服務(wù)的開(kāi)發(fā)人員可以把所有的精力集中在業(yè)務(wù)功能的實(shí)現(xiàn)上,而不需要去關(guān)心服務(wù)間通信的基礎(chǔ)設(shè)施,像類似于服務(wù)的注冊(cè)與發(fā)現(xiàn),熔斷機(jī)制等都會(huì)統(tǒng)一由 Service Mesh 以對(duì)業(yè)務(wù)應(yīng)用透明的方式來(lái)實(shí)現(xiàn)。這些“工程效能”服務(wù)或者相關(guān)支持工具鏈通常都會(huì)由原本從測(cè)試開(kāi)發(fā)轉(zhuǎn)型過(guò)來(lái)的工程效能團(tuán)隊(duì)來(lái)設(shè)計(jì)和開(kāi)發(fā)。那么我們接下來(lái)看一下可以提供哪些“工程效能”服務(wù)或者相關(guān)支持工具鏈,并且能以什么樣的方式來(lái)解決或緩解上面提到的開(kāi)發(fā)自己測(cè)試帶來(lái)的問(wèn)題。
測(cè)試執(zhí)行服務(wù)(Test Execution Service)
CI/CD 各個(gè)階段所有的測(cè)試執(zhí)行發(fā)起都通過(guò)測(cè)試執(zhí)行服務(wù)(TES,Test Execution Service),TES 通過(guò)統(tǒng)一的 Web Service 接口與 CI/CD 以解耦的方式進(jìn)行集成。無(wú)論是 CI/CD 流水線,還是開(kāi)發(fā)人員執(zhí)行測(cè)試,都通過(guò) TES 來(lái)發(fā)起,唯一的區(qū)別是開(kāi)發(fā)人員一般使用 TES 的 UI 界面發(fā)起測(cè)試,而 CI/CD 是直接在流水線腳本里面調(diào)用 TES 的 Restful API 發(fā)起測(cè)試。測(cè)試執(zhí)行服務(wù)的輸入?yún)?shù)也很簡(jiǎn)單直觀,通常只包括測(cè)試框架名字、測(cè)試用例集版本號(hào)、測(cè)試用例路徑、 測(cè)試報(bào)告獲取方式、同步 / 異步執(zhí)行開(kāi)關(guān)等。一旦調(diào)用 TES 發(fā)起測(cè)試,后續(xù)如何調(diào)用 Jenkins job、如何打包下載 test jar、如何找到適合的測(cè)試執(zhí)行環(huán)境、如何發(fā)起測(cè)試以及如何收集測(cè)試報(bào)告等都對(duì)使用者完全透明??梢韵胂?,現(xiàn)在,開(kāi)發(fā)人員在和 CI/CD 集成以及執(zhí)行測(cè)試的時(shí)候,已經(jīng)可以完全不需要去關(guān)心執(zhí)行測(cè)試的命令行、發(fā)起測(cè)試的 Jenkins job 以及配置、測(cè)試的具體執(zhí)行環(huán)境、測(cè)試報(bào)告獲取等信息。這將大大提高開(kāi)發(fā)人員自己執(zhí)行測(cè)試的效率和便利程度。
測(cè)試數(shù)據(jù)服務(wù)(Test Data Service)
前面提到過(guò),跨模塊,跨系統(tǒng)的測(cè)試數(shù)據(jù)準(zhǔn)備對(duì)于開(kāi)發(fā)自己做測(cè)試是個(gè)挑戰(zhàn),尤其是現(xiàn)在大量采用微服務(wù)架構(gòu),這個(gè)問(wèn)題就會(huì)更突出。測(cè)試數(shù)據(jù)服務(wù)(TDS,Test Data Service)將會(huì)以 Web Service 接口的形式為所有類型的測(cè)試提供一致的測(cè)試數(shù)據(jù)準(zhǔn)備入口。無(wú)論開(kāi)發(fā)是要做 API 測(cè)試,還是 GUI 測(cè)試,或者是性能測(cè)試,都可以通過(guò)調(diào)用 TDS 的 Web Service 或者 UI 來(lái)準(zhǔn)備各種組合類型和量級(jí)的測(cè)試數(shù)據(jù)。TDS 本身還是個(gè)開(kāi)發(fā)平臺(tái),任何開(kāi)發(fā)人員都可以通過(guò)腳手架代碼來(lái)貢獻(xiàn)新的數(shù)據(jù)類型支持,并且 TDS 平臺(tái)本身借助自己的 Core Service 和內(nèi)建數(shù)據(jù)庫(kù)具有元數(shù)據(jù)管理能力,能夠提供諸如測(cè)試數(shù)據(jù)數(shù)量以及質(zhì)量的管理。下圖展示了典型的 TDS 架構(gòu)設(shè)計(jì)簡(jiǎn)圖供參考。
測(cè)試執(zhí)行環(huán)境服務(wù)(Test Bed Service)
正如前面提到的,測(cè)試執(zhí)行環(huán)境對(duì)于大型企業(yè)來(lái)說(shuō)是很龐大復(fù)雜的,為了方便開(kāi)發(fā)人員使用測(cè)試執(zhí)行環(huán)境,或者說(shuō)為了使測(cè)試執(zhí)行環(huán)境對(duì)于開(kāi)發(fā)人員透明,就需要引入測(cè)試執(zhí)行環(huán)境服務(wù)(TBS,Test Bed Service)。TBS 的主要職責(zé)是負(fù)責(zé)管理、創(chuàng)建,擴(kuò)容 / 收縮測(cè)試執(zhí)行集群。一個(gè)常見(jiàn)的測(cè)試執(zhí)行環(huán)境架構(gòu)如下圖所示,TBS 會(huì)根據(jù)等待執(zhí)行的測(cè)試用例的排隊(duì)情況,動(dòng)態(tài)決策測(cè)試執(zhí)行集群的節(jié)點(diǎn)數(shù)量和類型,通常會(huì)使用 Docker 和 Kubernetes 來(lái)實(shí)現(xiàn) TBS 的 Gird 管理。
構(gòu)建工程效率工具鏈倉(cāng)庫(kù)(Engineering Productivity Tools Store)
類似于 App Store 的概念,可以把各種測(cè)試小工具以及提高效率的工具集統(tǒng)一在 Engineering Productivity Tools Store 里面集中版本化管理。比如文章開(kāi)頭我們提到過(guò)開(kāi)發(fā)自己做測(cè)試的時(shí)候存在思維盲區(qū),對(duì)于像 String 這樣的參數(shù)可能遺漏 Null 值得用例,我們就可以開(kāi)發(fā)一個(gè)小工具對(duì)被測(cè)函數(shù)的輸入?yún)?shù)類型基于邊界值自動(dòng)生成邊界測(cè)試用例,比如 String 類型的參數(shù)一定會(huì)生成 Null,SQL 注入攻擊字符串,非英文字符,超長(zhǎng)的字符串等,這樣就可以系統(tǒng)性地避免開(kāi)發(fā)的盲區(qū)。諸如此類的工具還有很多,以后有機(jī)會(huì)再和大家一一分享。
3測(cè)試即服務(wù)(TaaS,Test as a Service)的全局架構(gòu)
除了以上的內(nèi)容,其實(shí)還有諸如測(cè)試報(bào)告服務(wù)(TRS,Test Report Service)、全局測(cè)試配置服務(wù)(GRS,Global Registry Service)和用于 API 測(cè)試解耦的 Mock 服務(wù)(Unified Mock Service),由于篇幅無(wú)法一一展開(kāi)。需要強(qiáng)調(diào)是的是,這里談到的很多服務(wù)已經(jīng)在某些企業(yè)內(nèi)部有了落地實(shí)踐,并取得了很好地效果。最后,以 Test as a Service 的全局架構(gòu)圖來(lái)結(jié)束本文。
-
互聯(lián)網(wǎng)
+關(guān)注
關(guān)注
54文章
11046瀏覽量
102484 -
GUI
+關(guān)注
關(guān)注
3文章
633瀏覽量
39454 -
測(cè)試數(shù)據(jù)
+關(guān)注
關(guān)注
0文章
26瀏覽量
9035
原文標(biāo)題:開(kāi)發(fā)要不要自己做測(cè)試?怎么做?
文章出處:【微信號(hào):mcuworld,微信公眾號(hào):嵌入式資訊精選】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論