1 回顧
傳統軟件研發體系下定義的軟件測試是從用戶視角設計的。測試是試圖窮盡用戶行為的工程，從測試用例（use case）的英文定義就可見一般。測試的邏輯資產就是用自然語言去描述用戶的操作行為或路徑。
但隨著軟件工程向分布式架構和敏捷交付的變革。軟件設計變得比以前更加復雜，要驗證一個分布式部署的微服務架構應用，簡單的use case根本無法發掘應用的質量風險。一個無論是代碼上還是能力上都高度依賴其他組件/模塊的應用，都不允許測試還像對待黑盒一樣進行質量評估。測試需要有更細致，更全局，更系統的洞察力去識別潛在的質量風險。因此，“測試”這個工種在更多的團隊里被定義成概念更寬泛的QA。
2 測試自動化的語言學原理
被測對象是用編程語言構筑的，如果測試用例是自然語言編寫的，那從測試用例作用到被測對象，是需要多輪語義轉譯的。從單元測試中獲得靈感，如果我們的測試用例和被測對象用同樣的語言，這種語言上的同構會省掉語義轉譯的麻煩。讓我們的測試能夠像探針一樣，深入到代碼邏輯的縫隙，做更有針對性的觀測和假設驗證。
- 微服務應用的驗證那就基于API/SDK定義的schema驅動測試。測試斷言可以精確到每個接口返回的字段（這是自然語言用例觀測不到的）
- 應用可靠可用性的驗證就用打樁的方式改變一部分組件代碼的返回結果作為假設來觸發單點故障
- 大規模背景數據模擬或者數據遷移的驗證就直接用腳本訪問數據庫，比通過接口請求更加快捷。
因此QA的能力要求在此基礎上變得更高，除了編程基礎，還需要更系統的分析和動手等綜合能力。因此越來越多的測試工程師職位轉變為“測試開發”。
3. 自動化代碼在測試工程中的重要性
3.1 代碼即生產力
自動化框架的設計結構將測試腳本的開發變成搭積木游戲或者是數據集驅動的盲盒游戲。一個驗證動作，手動執行永遠是重復最小粒度的操作，AW的靈活組合，可以快速生產出新的業務邏輯的測試腳本來。
對于較小的改動或粒度比較小的需求，高優先級的腳本用例和文本用例可以同時編寫，一些不明確的預期結果可以立馬呈現出結果。
對于一個即將生成50-100個大特性的需求來說，直接用自動化構筑驗證任務，比寫文本用例高效得多。
3.2 代碼即資產
測試代碼被納入版本管理工具，有系統性的組織和傳遞，除了要求測試代碼符合公司的自動化規范，還要小組內部達成一致：
- 對齊頻繁調用的公共AW，查漏補缺，統一路徑，避免多個地方重復出現功能一致的AW
- 對齊腳本組織結構和特性樹，測試腳本不是業務代碼，是為了提高測試效率的測試語言，要能有助于快速執行繼承和回歸測試
- 對齊自動化實現的層級和事件節點，不同分級的用例不但表征用例的優先級，也可以作為用例自動化的優先級：優先級越高的用例，越早實現
- 對齊AW封裝程度：AW封裝程度越高，測試腳本越簡潔直觀，但是會提高定位成本和學習成本，復雜的封裝關系蒙蔽了測試邏輯本身就適得其反了。
3.3 代碼即知識
敏捷開發實踐中，不斷的迭代導致還來不及寫文檔，特性細節就又變化了。一個變化的特性，在傳統既定的測試流程中設計大量文本的調整。一些部門組織中對測試用例文本的可信度的執念構筑著產品整體的質量信心，但在版本節奏催促下，測試人員最可能的反應是直接手動驗證，一個特性驗證完，相關的測試資產沒有完整記錄跟蹤，測試資產的可信度很難在高強度下得到保證。文檔沒有比肩代碼的版本控制系統。不可避免會對成員造成誤導。
3.4 代碼即溝通語言
業務交流時團隊定期內部傳遞能力的重要部分。以定期業務培訓和團隊知識庫管理兩種方式維護。
在組織團隊培訓時，往往是主講人輸出后，聽眾雅雀無聲。雙方對領域知識都有相同的了解程度，才能讓交流更加順暢。在架構龐大，調用鏈過長的系統中，測試代碼可以精準快速定位到具體的問題。從某一行代碼、某一個斷言觸發， 可以節省很多自然語言的描述。
在管理知識庫時，我們發現文檔偏描述性語言，優勢在于承載設計思路和邏輯架構，但無法傳遞具體的測試方法。一堆命令行和截圖的拼湊的文檔不如一個好的測試腳本：靜態代碼闡述測試步驟，動態執行體現實測結果。
在系統日漸復雜的產品測試團隊中，全員熟悉每個特性和業務細節、演進進度的學習成本和溝通成本巨大，但又不能完全各自為營不聞不問，測試腳本就是很好的溝通語言，它建立在懂代碼、懂測試框架這樣的基礎公共能之上，原則上具備這類公共能力的人員即可理解。如果不能，一種可能是腳本質量差，一種可能是測試對產品知識儲備少，無論那種可能，都指向一個更好的提升方向——代碼提交者優化測試腳本，代碼閱讀者補齊相關背景知識，而文檔形式的知識，不具備這種生命力。
4 特性測試責任人即腳本責任人
傳統測試自動化策略是基于在設計好的用例中，識別可自動化的用例，由相關開發或專門編寫測試腳本的人員完成。這種實踐方式帶來兩個問題：
- 新特性場景用例開發代價高，自動化交付不及時
- 繼承特性用例無效或無法再多種場景下重用
從對特性理解和產品整體把握上，專職的腳本開發人員沒有特性測試責任人理解深入，從測試文本到測試腳本的轉化，中間會產生很多認知溝通成本。
并且，從績效結果導向上看，特性直接測試責任人如果只對交付結果質量負責，缺少自動化的驅動力就會也缺少對整體測試腳本的掌控力，在后期，整個團隊的測試資產對齊維護和測試腳本有效性上都會付出更多的成本。
當要求測試團隊每個成員都具備腳本開發，甚至是測試框架的深度理解后，測試代碼的開發會從簡單的AW組裝變成更貼近產品形態結構的簡潔高效設計。
高效的自動化能力儲備需要前期積累的自動化能力基礎，并投入更多的精力去維護和提升自動化測試的效率：
- 測試自動化是一個細水長流的過程，應該成為測試人員的習慣動作
- 要將這個習慣培養成好的習慣，制定一定的團隊公約并自覺遵守讓更多成員獲益
- 同時也要悉心呵護自動化資產，才能讓大家的好習慣不至于乏味
5 建設高可用自動化能力
CI/CD不只是代碼持續交付的優質生產力，測試執行也可以接入CI/CD流程中。用容器承載每個版本的測試代碼，規劃一部分核心用例作為轉測門禁來實現測試前移。
用監控業務的方法，監控測試結果。云平臺的運維監控平臺不光可以監控基礎設施硬件，集群業務指標。將短平快的核心用例打包發布到現網（測試后移），將撥測結果視為為測試服務的業務指標，在監控運維平臺上對接測試結果，可以進一步提升測試發現問題的效率。
測試能力的遷移和后移，讓測試工程的精力更多得投入到更有價值工程創造上去。
