02 facebook腳本×32(web前端需要掌握的哪些知識)

163;⼰來完成了，⽆疑進⼀步加⼤了開發⼈員的⼯作量，⽽且開發⼈員往往對跨模塊，跨系統的測試數據準備缺乏系統性的理解，往往為了⽣成⼀條⾮⾃⼰業務領域的數據⽽花費⼤量的學習成本。舉個例⼦，假設現在“買家模塊”的開發⼈員需要測試“商品買⼊”的操作，那么就需要事先準備好“可以被賣的商品”，這就意味著“買家模塊”的開發⼈員需要明確知道“賣家模

塊”和“商品模塊”的細節，才能⽣成“可以被賣的商品”。這類問題在⽬前主流的微服務架構⾯前會更嚴重，原因是為了產⽣⼀條測試數據，可能會需要依次調⽤很多個服務。

測試執⾏與 CI/CD 集成問題

對于不同的業務開發團隊，各個階段采⽤的⾃動化測試框架可能都不同，⽐如有些會使⽤基于Java 的Selenium，也有些會使⽤基于JavaScript 的 Nightwatch 等，有專職測試的時候，各種不同的測試框架與 CI/CD 的集成，都是由各個業務團隊的測試⼈員和 CI/CD 的⼈員⼀起完成的，現在沒有了專職測試，這部分⼯作就需要開發⼈員⾃⼰和 CI/CD ⼈員⼀起完成，這就要求開發⼈員不僅需要⾮常熟悉⾃動化測試框架的細節（很多時候為了更好地和 CI/CD 集成，會對開源測試框架或者是⾃研測試框架做⼆次開發，⽐如改進 retry 機制，增加覆蓋率統計等等），還必須了解 CI/CD 的流⽔線設計以及腳本設計，然后再將需要⽀持的⾃動化測試框架的運⾏命令⾏和需要暴露的參數（測試⽤例 Git 路徑、測試執⾏環境、測試報告路徑等等）寫進 CI/CD 的腳本。這些⼯作在很⼤程度上分散了開發的精⼒，對于提⾼開發⾃⾝效率是⾮常不利的。

失敗測試⽤例歸屬問題

有專職測試的時候，開發⼈員往往只關注⾃⼰修改部分相關的測試⽤例，模塊或者服務的全回歸測試中如果有失敗的測試⽤例，通常是由測試⼈員跟進去分析具體原因，并協調解決然后才能發布上線。但是現在開發⼈員負責所有測試，他就必須關注全局的測試。舉個實際的例⼦來看，⽐如“⽤戶登錄”服務的開發⼯程師修復了⼀個缺陷，然后本地⾃測通過后遞交了代碼，然后很不幸，在CI/CD 的流⽔線上全回歸測試卻發現有部分⽤例失敗了，雖然這些失敗的⽤例和這次的代碼修改沒有任何關系，但是為了保證⾃⼰的修改能夠順利上線（CI/CD 的流⽔線要求只有全回歸測試 100% 通過才可以上線），他必須挨個去分析失敗的測試⽤例然后⾃⼰去找到對應的⼈去協調解決，這顯然是⾮常不合理和不敏捷的做法。

歸根結底，這些問題的本質都會直接影響開發⼈員本質⼯作的進度和效率，那么我們應該如何解決或者在⼀定程度上緩解這些問題呢？這就是接下來要討論的問題，⼯程效能團隊如何賦能開發⼈員，幫助開發⼈員⾼效地完成⾼質量的測試。

2⼯程效能團隊賦能開發⼈員進⾏⾼效率⾼質量的測試

賦能的基本思路是能夠讓開發⼈員更專注于測試本⾝，⽽從那些輔助測試的⼯作（⽐如搭建測試執⾏環境、CI/CD 集成等）上解放出來，這些輔助測試的⼯作由“⼯程效能”服務或者相關⽀持⼯具鏈來統⼀解決。這個思想和和⽬前⾮常流⾏的Service Mesh 的設計思想不謀⽽合，Service Mesh 也是可以讓服務的開發⼈員可以把所有的精⼒集中在業務功能的實現上，⽽不需要去關⼼服務間通信的基礎設施，像類似于服務的注冊與發現，熔斷機制等都會統⼀由 Service Mesh 以對業務應⽤透明的⽅式來實現。這些“⼯程效能”服務或者相關⽀持⼯具鏈通常都會由原本從測試開發轉型過來的⼯程效能團隊來設計和開發。那么我們接下來看⼀下可以提供哪些“⼯程效能”服務或者相關⽀持⼯具鏈，并且能以什么樣的⽅式來解決或緩解上⾯提到的開發⾃⼰測試帶來的問題。

測試執⾏服務（Test Execution Service）

CI/CD 各個階段所有的測試執⾏發起都通過測試執⾏服務（TES，Test Execution Service），TES 通過統⼀的 Web Service 接⼝與 CI/CD 以解耦的⽅式進⾏集成。⽆論是 CI/CD 流⽔線，還是開發⼈員執⾏測試，都通過 TES 來發起，唯⼀的區別是開發⼈員⼀般使⽤ TES 的 UI 界⾯發起測試，⽽ CI/CD 是直接在流⽔線腳本⾥⾯調⽤ TES 的 Restful API 發起測試。測試執⾏服務的輸⼊參數也很簡單直觀，通常只包括測試框架名字、測試⽤例集版本號、測試⽤例路徑、測試報告獲取⽅式、同步/ 異步執⾏開關等。⼀旦調⽤TES 發起測試，后續如何調⽤Jenkins job、如何打包下載test jar、如何找到適合的測試執⾏環境、如何發起測試以及如何收集測試報告等都對使⽤者完全透明。可以想象，現在，開發⼈員在和 CI/CD 集成以及執⾏測試的時候，已經可以完全不需要去關⼼執⾏測試的命令⾏、發起測試的 Jenkins job 以及配置、測試的具體執⾏環境、測試報告獲取等信息。這將⼤⼤提⾼開發⼈員⾃⼰執⾏測試的效率和便利程度。

測試數據服務（Test Data Service）

前⾯提到過，跨模塊，跨系統的測試數據準備對于開發⾃⼰做測試是個挑戰，尤其是現在⼤量采⽤微服務架構，這個問題就會更突出。測試數據服務（TDS，Test Data Service）將會以Web Service 接⼝的形式為所有類型的測試提供⼀致的測試數據準備⼊⼝。⽆論開發是要做API 測試，還是 GUI 測試，或者是性能測試，都可以通過調⽤ TDS 的 Web Service 或者 UI 來準備各種組合類型和量級的測試數據。TDS 本⾝還是個開發平臺，任何開發⼈員都可以通過腳⼿架代碼來貢獻新的數據類型⽀持，并且 TDS 平臺本⾝借助⾃⼰的 Core Service 和內建數據庫具有元數據管理能⼒，能夠提供諸如測試數據數量以及質量的管理。下圖展⽰了典型的 TDS 架構設計簡圖供參考。

測試執⾏環境服務（Test Bed Service）

正如前⾯提到的，測試執⾏環境對于⼤型企業來說是很龐⼤復雜的，為了⽅便開發⼈員使⽤測試執⾏環境，或者說為了使測試執⾏環境對于開發⼈員透明，就需要引⼊測試執⾏環境服務（TBS，Test Bed Service）。TBS 的主要職責是負責管理、創建，擴容/ 收縮測試執⾏集群。⼀個常見的測試執⾏環境架構如下圖所⽰，TBS 會根據等待執⾏的測試⽤例的排隊情況，動態決策測試執⾏集群的節點數量和類型，通常會使⽤ Docker 和 Kuber買粉絲es 來實現 TBS 的 Gird 管理。

構建⼯程效率⼯具鏈倉庫（Engineering Proctivity Tools Store）

類似于App Store 的概念，可以把各種測試⼩⼯具以及提⾼效率的⼯具集統⼀在Engineering Proctivity Tools Store ⾥⾯集中版本化管理。⽐如⽂章開頭我們提到過開發⾃⼰做測試的時候存在思維盲區，對于像String 這樣的參數可能遺漏Null 值得⽤例，我們就可以開發⼀個⼩⼯具對被測函數的輸⼊參數類型基于邊界值⾃動⽣成邊界測試⽤例，⽐如String 類型的參數⼀定會⽣成Null，SQL 注⼊攻擊字符串，⾮英⽂字符，超長的字符串等，這樣就可以系統性地避免開發的盲區。諸如此類的⼯具還有很多，以后有機會再和⼤家⼀⼀分享。

3測試即服務（TaaS，Test as a Service）的全局架構

除了以上的內容，其實還有諸如測試

很赞哦!（6）