現(xiàn)在包括 Google、Facebook 和 eBay 等一線互聯(lián)網(wǎng)巨頭公司都在逐漸推行“沒有專職測試，測試工作由開發(fā)人員完成”的全新模式，原本專職的業(yè)務(wù)功能測試團(tuán)隊的規(guī)模逐漸縮小，有些甚至已經(jīng)完全沒有了，而原本的測試開發(fā)團(tuán)隊逐漸在向工程效能（Engineering Productivity）團(tuán)隊轉(zhuǎn)型。這些互聯(lián)網(wǎng)巨頭之所以能夠很好地落地這種全新的模式，是因為他們都較好地解決了這個模式的兩個最大的難題：

開發(fā)人員如何能夠勝任測試？

工程效能團(tuán)隊如何賦能開發(fā)人員，幫助開發(fā)人員高效地完成高質(zhì)量測試？

本文會圍繞這兩個問題來展開討論。首先讓我們一起看一下開發(fā)人員自己做測試都會遇到哪些問題和阻礙。

1開發(fā)人員自己做測試會遇到哪些問題人性角度引發(fā)的問題

首先從人性的角度來看，開發(fā)人員通常是屬于“創(chuàng)造性思維”，自己開發(fā)的代碼就像是親兒子一樣，怎么看都覺得實現(xiàn)很棒；而測試人員則屬于“破壞性思維”，測試人員的職責(zé)就是要盡可能多的找到潛在的缺陷，而且專職的測試人員通常已經(jīng)在以往的測試實踐中積累了大量典型的容易出錯的模式，所以測試人員比起開發(fā)人員，往往更能客觀且全面做好充分的測試。

思維慣性的問題

剛才是從人性角度上來講的，如果從技術(shù)層面來看，由開發(fā)人員自己測試，會存在嚴(yán)重的“思維慣性”，通常開發(fā)人員在設(shè)計和開發(fā)過程中沒有考慮到的分支和處理邏輯，在自己做測試的時候同樣不會考慮到。比如對于一個函數(shù)，其中有一個 String 類型的輸入?yún)?shù)，如果開發(fā)人員在做功能實現(xiàn)的時候壓根沒有考慮到 String 存在 Null 值得可能性，那么代碼的實現(xiàn)里面也不會對 Null 值做處理，連帶結(jié)果就是測試的時候就更不會設(shè)計 Null 值得測試數(shù)據(jù)，這樣的“一條龍”缺失就會給代碼的質(zhì)量留下了缺陷隱患。更糟糕的是，對于這種情況，即便啟用了代碼覆蓋率指標(biāo)去衡量測試完整程度，也不能有效暴露這類問題，因為處理 Null 值得代碼壓根沒有寫，又何來代碼覆蓋率一說吶。

被測試環(huán)境和測試執(zhí)行環(huán)境的復(fù)雜性問題

有專職測試的時候，測試工作是專職測試人員完成的，專職測試人員通常會負(fù)責(zé)搭建被測試環(huán)境以及管理測試執(zhí)行環(huán)境。被測試環(huán)境好理解，就是 System Under Test（SUT）。而測試執(zhí)行環(huán)境是指用于執(zhí)行測試用例的機(jī)器，比如對于 Web 的 GUI 測試，最簡單的測試執(zhí)行環(huán)境就是你本地機(jī)器上的瀏覽器。但是對于大型互聯(lián)網(wǎng)企業(yè)，測試執(zhí)行環(huán)境遠(yuǎn)遠(yuǎn)要比你想象的更復(fù)雜。通常都是一些大型的測試執(zhí)行集群，甚至是內(nèi)部的測試執(zhí)行私有云，比如用 Selenium Grid 搭建的 GUI 測試執(zhí)行環(huán)境，往往這樣的集群都會有成百上千臺機(jī)器，再比如用 Appium+Selenium Grid 搭建的移動設(shè)備測試集群，也往往會有上千臺設(shè)備。現(xiàn)在沒有了專職的測試人員，那就需要開發(fā)人員自己去管理、維護(hù)和搭建這些測試基礎(chǔ)架構(gòu)，這樣做其實是得不償失的，工作量本身并沒有減少，只是換了一批人來做同樣的事情，而且開發(fā)的精力往往更應(yīng)該花在構(gòu)建新的業(yè)務(wù)功能上，而不是用在維護(hù)測試基礎(chǔ)設(shè)施。

測試數(shù)據(jù)準(zhǔn)備的問題

測試數(shù)據(jù)準(zhǔn)備是測試過程中必不可少的關(guān)鍵步驟，有專職測試的時候，是由測試人員來準(zhǔn)備測試數(shù)據(jù)的，一方面測試人員往往比開發(fā)人員在全局層面上更了解被測系統(tǒng)，所以對于測試數(shù)據(jù)的設(shè)計與生成也會更高效，另一方面測試人員在以往的測試過程中已經(jīng)積累了很多測試數(shù)據(jù)生成的方法和小工具。現(xiàn)在這些都需要開發(fā)人員自己來完成了，無疑進(jìn)一步加大了開發(fā)人員的工作量，而且開發(fā)人員往往對跨模塊，跨系統(tǒng)的測試數(shù)據(jù)準(zhǔn)備缺乏系統(tǒng)性的理解，往往為了生成一條非自己業(yè)務(wù)領(lǐng)域的數(shù)據(jù)而花費大量的學(xué)習(xí)成本。舉個例子，假設(shè)現(xiàn)在“買家模塊”的開發(fā)人員需要測試“商品買入”的操作，那么就需要事先準(zhǔn)備好“可以被賣的商品”，這就意味著“買家模塊”的開發(fā)人員需要明確知道“賣家模塊”和“商品模塊”的細(xì)節(jié)，才能生成“可以被賣的商品”。這類問題在目前主流的微服務(wù)架構(gòu)面前會更嚴(yán)重，原因是為了產(chǎn)生一條測試數(shù)據(jù)，可能會需要依次調(diào)用很多個服務(wù)。

測試執(zhí)行與 CI/CD 集成問題

對于不同的業(yè)務(wù)開發(fā)團(tuán)隊，各個階段采用的自動化測試框架可能都不同，比如有些會使用基于 Java 的 Selenium，也有些會使用基于 JavaScript 的 Nightwatch 等，有專職測試的時候，各種不同的測試框架與 CI/CD 的集成，都是由各個業(yè)務(wù)團(tuán)隊的測試人員和 CI/CD 的人員一起完成的，現(xiàn)在沒有了專職測試，這部分工作就需要開發(fā)人員自己和 CI/CD 人員一起完成，這就要求開發(fā)人員不僅需要非常熟悉自動化測試框架的細(xì)節(jié)（很多時候為了更好地和 CI/CD 集成，會對開源測試框架或者是自研測試框架做二次開發(fā)，比如改進(jìn) retry 機(jī)制，增加覆蓋率統(tǒng)計等等），還必須了解 CI/CD 的流水線設(shè)計以及腳本設(shè)計，然后再將需要支持的自動化測試框架的運行命令行和需要暴露的參數(shù)（測試用例 Git 路徑、測試執(zhí)行環(huán)境、測試報告路徑等等）寫進(jìn) CI/CD 的腳本。這些工作在很大程度上分散了開發(fā)的精力，對于提高開發(fā)自身效率是非常不利的。

失敗測試用例歸屬問題

有專職測試的時候，開發(fā)人員往往只關(guān)注自己修改部分相關(guān)的測試用例，模塊或者服務(wù)的全回歸測試中如果有失敗的測試用例，通常是由測試人員跟進(jìn)去分析具體原因，并協(xié)調(diào)解決然后才能發(fā)布上線。但是現(xiàn)在開發(fā)人員負(fù)責(zé)所有測試，他就必須關(guān)注全局的測試。舉個實際的例子來看，比如“用戶登錄”服務(wù)的開發(fā)工程師修復(fù)了一個缺陷，然后本地自測通過后遞交了代碼，然后很不幸，在 CI/CD 的流水線上全回歸測試卻發(fā)現(xiàn)有部分用例失敗了，雖然這些失敗的用例和這次的代碼修改沒有任何關(guān)系，但是為了保證自己的修改能夠順利上線（CI/CD 的流水線要求只有全回歸測試 100% 通過才可以上線），他必須挨個去分析失敗的測試用例然后自己去找到對應(yīng)的人去協(xié)調(diào)解決，這顯然是非常不合理和不敏捷的做法。

歸根結(jié)底，這些問題的本質(zhì)都會直接影響開發(fā)人員本質(zhì)工作的進(jìn)度和效率，那么我們應(yīng)該如何解決或者在一定程度上緩解這些問題呢？這就是接下來要討論的問題，工程效能團(tuán)隊如何賦能開發(fā)人員，幫助開發(fā)人員高效地完成高質(zhì)量的測試。

2工程效能團(tuán)隊賦能開發(fā)人員進(jìn)行高效率高質(zhì)量的測試

賦能的基本思路是能夠讓開發(fā)人員更專注于測試本身，而從那些輔助測試的工作（比如搭建測試執(zhí)行環(huán)境、CI/CD 集成等）上解放出來，這些輔助測試的工作由“工程效能”服務(wù)或者相關(guān)支持工具鏈來統(tǒng)一解決。這個思想和和目前非常流行的 Service Mesh 的設(shè)計思想不謀而合，Service Mesh 也是可以讓服務(wù)的開發(fā)人員可以把所有的精力集中在業(yè)務(wù)功能的實現(xiàn)上，而不需要去關(guān)心服務(wù)間通信的基礎(chǔ)設(shè)施，像類似于服務(wù)的注冊與發(fā)現(xiàn)，熔斷機(jī)制等都會統(tǒng)一由 Service Mesh 以對業(yè)務(wù)應(yīng)用透明的方式來實現(xiàn)。這些“工程效能”服務(wù)或者相關(guān)支持工具鏈通常都會由原本從測試開發(fā)轉(zhuǎn)型過來的工程效能團(tuán)隊來設(shè)計和開發(fā)。那么我們接下來看一下可以提供哪些“工程效能”服務(wù)或者相關(guān)支持工具鏈，并且能以什么樣的方式來解決或緩解上面提到的開發(fā)自己測試帶來的問題。

測試執(zhí)行服務(wù)（Test Execution Service）

CI/CD 各個階段所有的測試執(zhí)行發(fā)起都通過測試執(zhí)行服務(wù)（TES，Test Execution Service），TES 通過統(tǒng)一的 Web Service 接口與 CI/CD 以解耦的方式進(jìn)行集成。無論是 CI/CD 流水線，還是開發(fā)人員執(zhí)行測試，都通過 TES 來發(fā)起，唯一的區(qū)別是開發(fā)人員一般使用 TES 的 UI 界面發(fā)起測試，而 CI/CD 是直接在流水線腳本里面調(diào)用 TES 的 Restful API 發(fā)起測試。測試執(zhí)行服務(wù)的輸入?yún)?shù)也很簡單直觀，通常只包括測試框架名字、測試用例集版本號、測試用例路徑、 測試報告獲取方式、同步 / 異步執(zhí)行開關(guān)等。一旦調(diào)用 TES 發(fā)起測試，后續(xù)如何調(diào)用 Jenkins job、如何打包下載 test jar、如何找到適合的測試執(zhí)行環(huán)境、如何發(fā)起測試以及如何收集測試報告等都對使用者完全透明?？梢韵胂?，現(xiàn)在，開發(fā)人員在和 CI/CD 集成以及執(zhí)行測試的時候，已經(jīng)可以完全不需要去關(guān)心執(zhí)行測試的命令行、發(fā)起測試的 Jenkins job 以及配置、測試的具體執(zhí)行環(huán)境、測試報告獲取等信息。這將大大提高開發(fā)人員自己執(zhí)行測試的效率和便利程度。

測試數(shù)據(jù)服務(wù)（Test Data Service）

前面提到過，跨模塊，跨系統(tǒng)的測試數(shù)據(jù)準(zhǔn)備對于開發(fā)自己做測試是個挑戰(zhàn)，尤其是現(xiàn)在大量采用微服務(wù)架構(gòu)，這個問題就會更突出。測試數(shù)據(jù)服務(wù)（TDS，Test Data Service）將會以 Web Service 接口的形式為所有類型的測試提供一致的測試數(shù)據(jù)準(zhǔn)備入口。無論開發(fā)是要做 API 測試，還是 GUI 測試，或者是性能測試，都可以通過調(diào)用 TDS 的 Web Service 或者 UI 來準(zhǔn)備各種組合類型和量級的測試數(shù)據(jù)。TDS 本身還是個開發(fā)平臺，任何開發(fā)人員都可以通過腳手架代碼來貢獻(xiàn)新的數(shù)據(jù)類型支持，并且 TDS 平臺本身借助自己的 Core Service 和內(nèi)建數(shù)據(jù)庫具有元數(shù)據(jù)管理能力，能夠提供諸如測試數(shù)據(jù)數(shù)量以及質(zhì)量的管理。下圖展示了典型的 TDS 架構(gòu)設(shè)計簡圖供參考。

測試執(zhí)行環(huán)境服務(wù)（Test Bed Service）

正如前面提到的，測試執(zhí)行環(huán)境對于大型企業(yè)來說是很龐大復(fù)雜的，為了方便開發(fā)人員使用測試執(zhí)行環(huán)境，或者說為了使測試執(zhí)行環(huán)境對于開發(fā)人員透明，就需要引入測試執(zhí)行環(huán)境服務(wù)（TBS，Test Bed Service）。TBS 的主要職責(zé)是負(fù)責(zé)管理、創(chuàng)建，擴(kuò)容 / 收縮測試執(zhí)行集群。一個常見的測試執(zhí)行環(huán)境架構(gòu)如下圖所示，TBS 會根據(jù)等待執(zhí)行的測試用例的排隊情況，動態(tài)決策測試執(zhí)行集群的節(jié)點數(shù)量和類型，通常會使用 Docker 和 Kubernetes 來實現(xiàn) TBS 的 Gird 管理。

構(gòu)建工程效率工具鏈倉庫（Engineering Productivity Tools Store）

類似于 App Store 的概念，可以把各種測試小工具以及提高效率的工具集統(tǒng)一在 Engineering Productivity Tools Store 里面集中版本化管理。比如文章開頭我們提到過開發(fā)自己做測試的時候存在思維盲區(qū)，對于像 String 這樣的參數(shù)可能遺漏 Null 值得用例，我們就可以開發(fā)一個小工具對被測函數(shù)的輸入?yún)?shù)類型基于邊界值自動生成邊界測試用例，比如 String 類型的參數(shù)一定會生成 Null，SQL 注入攻擊字符串，非英文字符，超長的字符串等，這樣就可以系統(tǒng)性地避免開發(fā)的盲區(qū)。諸如此類的工具還有很多，以后有機(jī)會再和大家一一分享。

3測試即服務(wù)（TaaS，Test as a Service）的全局架構(gòu)

除了以上的內(nèi)容，其實還有諸如測試報告服務(wù)（TRS，Test Report Service）、全局測試配置服務(wù)（GRS，Global Registry Service）和用于 API 測試解耦的 Mock 服務(wù)（Unified Mock Service），由于篇幅無法一一展開。需要強(qiáng)調(diào)是的是，這里談到的很多服務(wù)已經(jīng)在某些企業(yè)內(nèi)部有了落地實踐，并取得了很好地效果。最后，以 Test as a Service 的全局架構(gòu)圖來結(jié)束本文。