擁有完整而有效的自動化測試策略，是團隊達成持續(xù)集成目標的一個至關重要的前提條件。
自動化測試的定位
測試領域存在四類基本活動，即：
- 問題認知：對業(yè)務問題本身的理解和認識，來源于探索環(huán)
- 分析：測試分析和設計，通過對業(yè)務的認知，分析并設計能夠驗證是否成功解決業(yè)務問題的方式和方法，不斷優(yōu)化，在確保驗證質量的前提下降低測試成本
- 執(zhí)行：執(zhí)行測試分析得到的測試用例，得到測試結果或數據
- 決策：根據測試結果做出下一步行動判斷
自動化測試：將“執(zhí)行”階段的大量重復性的勞動力交付給機器來完成，將人從重復的手工勞動中解放出來。
敏捷測試四象限
敏捷測試四象限
- 面向業(yè)務專家：指能夠與業(yè)務專家無障礙溝通
- 面向技術人員：容易與技術人員達成共識
- 支持編程：為了幫助產品研發(fā)團隊自己檢查功能需求是否開發(fā)完成
- 評判標準：用于找出產品是否有缺陷
第二象限和第三象限的測試類型都可以被自動化，包括功能驗收測試、單元測試、組件測試和系統(tǒng)集成測試；第四象限一部分可以自動化，大部分可以半自動化；第一象限只能通過手工方式運行。
自動化測試的優(yōu)勢
- 減少失誤率，提高準確性：自動化測試每次執(zhí)行相同的步驟，并且每次都會記錄詳細的執(zhí)行結果，且不受人的因素影響；人手動測試會因個人的經驗和情緒不同而導致執(zhí)行結果不同；
- 節(jié)省時間和執(zhí)行成本：在軟件的生命周期中，測試活動需要經常重復執(zhí)行以確保質量，自動化測試用例一旦創(chuàng)建，就可以做到無人看守地運行；
- 提升測試覆蓋率：自動化測試可以增加測試的深度和范圍以提高軟件質量，從而提供手動測試所不及的覆蓋范圍；
- 做手工無法完成的測試：比如性能測試，靠人工模擬成千上萬的用戶訪問軟件，憑手工測試時無法完成的；
- 為開發(fā)人員提供質量反饋速度：開發(fā)人員可以使用共享的自動化測試快速發(fā)現問題，通過持續(xù)集成自動觸發(fā)運行，并將通知團隊成員是否失敗，這樣會節(jié)省開發(fā)人員的驗證時間，也增加他們對自己編寫軟件代碼質量的信心；
- 提供團隊士氣：將重復性的測試任務自動化，團隊可以將時間花費在更具挑戰(zhàn)性和更有價值的活動中，團隊成員個人技能和信息的提高也同時反饋給了團隊，提升了士氣。
自動化測試的成本投入
- 工具投入成本：自動化測試需要工具的支持，需要相關測試工具的研發(fā)投入，以及對團隊成員的測試框架、測試技能和工具培訓；
- 用例成本維護：功能的新增、珊瑚和修改，其所對應的自動化測試用例也需要同步的改動，帶來一定的維護成本；
- 專業(yè)技能人員成本：需要對自動化測試用例的創(chuàng)建者掌握軟件設計與代碼編寫能力進行培訓；
- 設備資源的投入：由于自動化測試無法完全代理手工測試，因此不但需要保留手工測試所需的測試環(huán)境，同時還要為自動化測試用例的執(zhí)行準備相應的測試環(huán)境。
持續(xù)集成下的自動化測試
持續(xù)集成對自動化測試的要求
持續(xù)集成實踐對自動化測試建設的四個基本衡量維度如下：
- 快速：自動化測試用例的執(zhí)行速度要快，執(zhí)行的時間代表著開發(fā)人員得到反饋的時間，最好在10分鐘之內完成，不要超過15分鐘；
- 便捷：團隊成員能夠隨時隨地很方便地執(zhí)行自動化測試用例，而不需要他們幫助，也不會影響到他人，避免出現延遲反饋的問題；
- 及時：一旦功能發(fā)生改變，就能夠通過自動化測試用例的運行，告知本次代碼變更對軟件質量的影響，包括對原有功能的影響，以及新增功能的質量情況；
- 可信：自動化測試用例運行的結果可以信賴，不存在隨機失敗的現象。持續(xù)集成要求一旦自動化測試用例失敗，必須立即修復，“隨機失敗”會大大增加工程師的“無效投入”。
《Scrum敏捷軟件開發(fā)》中指出，針對被測對象范圍較大的上層測試用例，數量應該越少，而被測對象粒度較細的下層測試用例數量應該增加，形成穩(wěn)定的正三角形。
不同類型的測試金字塔
微核架構的測試金字塔
- 組件測試：對單個組件或框架本身進行質量驗證
-
組件和插件間服務的接口自動化測試：主要是驗證兩個或兩個以上組件間的功能正確性。
微核架構下的測試金字塔
微服務應用的測試金字塔
微服務應用的測試金字塔
- 業(yè)務組件或服務測試：對單個組件或服務的測試，以驗證該組件的行為是否符合設計預期。
- 契約測試：又稱消費者驅動的契約測試，契約是指軟件系統(tǒng)中各個服務間交互的數據標準格式，其目標是測試消費者接口與服務者接口之間的正確性，驗證服務者提供的數據是否為消費者所需要的，從而將測試范圍縮小到兩個服務間的契約，以更低的成本發(fā)現問題。
- 業(yè)務工作流測試：啟動兩個或以上微服務，進行業(yè)務流程上的測試，以驗證多個被測服務之間是否可以正常工作， 完成某一業(yè)務請求，關注的是多服務組合交互、測試接口連通性和流程的可用性。
- 端到端測試：對整個軟件服務的流程進行測試，以驗證其工作流自始至終的執(zhí)行是否符合設計預期，識別系統(tǒng)以來關系，確保在各種系統(tǒng)之間傳遞正確的信息。其中一種端到端的測試時模擬用戶在可視化界面上執(zhí)行各種操作。
自動化測試的實施策略
增加自動化測試用例的著手點
除了符合測試金字塔結構，還可以從以下四個方面入手：
- 針對代碼熱區(qū)補充自動化測試用例：代碼熱區(qū)指那些改動頻率相對較高的文件或函數，以及經常出問題的功能組件；對代碼熱區(qū)寫自動化測試是投入產出比最劃算的。
- 跟隨新功能開發(fā)的進度：跟隨開發(fā)進度編寫對應的自動化測試用例。寫好的測試用例可以直接應用為開發(fā)提供及時的質量反饋。如果自動化測試用例覆蓋一直落后于功能開發(fā)，就無法起到保護網的作用。
- 從測試金字塔的中間層向上下兩端擴展：從中間層級別開始入手，投入產出比最高。
- 自動化測試用例的質量比數量重要：自動化測試具有維護成本，在達到質量目的的前提下，自動化測試的數量越少越好，數量夠用就行，不必要的測試用例只會單純增加維護成本和工作量。
良好自動化測試的特征
- 用例之間必須相互獨立：用例之間的執(zhí)行順序依賴會降低測試用例并行能力，從而導致執(zhí)行時間太長，大大降低自動化測試的反饋效率；
- 測試用例的運行結果必須穩(wěn)定：當測試腳本和被測代碼都保持不變的情況下，多次執(zhí)行的測試結果應該是穩(wěn)定的、不變的，降低無效的時間浪費；
- 測試用例的運行速度必須快：通過測試用例的拆分和“輪詢”來去除測試用例中的“等待”，減少等待時間，從而縮短整個測試用例的執(zhí)行時間；
- 測試環(huán)境應該統(tǒng)一：環(huán)境的依賴和易用性會降低自動化測試用例的收益，環(huán)境的統(tǒng)一對自動化測試的回報至關重要。
用戶驗收自動化測試的要點
處于測試金字塔頂層的用戶驗收測試的數量不應該太多，其重點在于：
- 以用戶旅程地圖的方式來驗證軟件應該活服務的核心工作流程，從用戶的角度出發(fā)，以敘述故事的方式描述用戶與軟件產品之間的交互；
- 應該驗證軟件應用或服務的端到端行為，而非具體的實現細節(jié)；
- 通過各種手段讓端到端自動化測試的調試更容易，如提供完整的日志文件，記錄常用的測試失敗模式，保留所有相關的系統(tǒng)狀態(tài)信息（自動截屏、出錯時現場鏡像保存）等；
- 數據準備?？梢詫⑸a環(huán)境的數據克隆一份請求，原有的請求仍舊通過原來的服務正常處理，而克隆出來的請求引流到新版本的服務。
其他質量檢查方法
差異批注測試方法
一種半自動測試方法，當做預定義的數據集輸入系統(tǒng)后，收集運行后的輸出結果，對其中需要驗證的數據進行提取，并將提取結果放入文本文件中，通過對比前后兩次測試的結果，用人工批注的方式進行半自動測試。需要特別注意動態(tài)信息的處理，常見的工具包括TextTest和ApprovalTests等。
代碼規(guī)范檢查與代碼動靜態(tài)檢測
- 代碼規(guī)范檢查：通過一些工具依賴團隊定義的一些代碼編寫規(guī)范，針對源代碼進行檢查，發(fā)現破壞規(guī)則的代碼并加以指正。常用的工具包括：Checkstyle，PMD，SonarQube等。
- 代碼動靜態(tài)檢測：通過一些工具對產品源代碼進行自動化掃描，發(fā)現代碼中存在的問題或潛在風險。
- 靜態(tài)掃描：無需編譯器編譯而直接使用一些掃描工具對其進行掃描，找出代碼中存在的一些語義缺陷、安全漏洞的解決方案。常用的工具包括：lint，Coverity，ColcWork等。
- 動態(tài)分析：通過在真實或虛擬處理機器上執(zhí)行目標程序進行分析，比如，在可能的漏洞處插入專門編制的故障發(fā)生函數，迫使目標軟件產生異常，然后通過監(jiān)控程序來檢查是否發(fā)生了邊界溢出或者其他異?，F象。常用工具包括：Valgrind，Purify等。
總結
前置周期越短，說明交付效率越高，越能提升客戶的滿意度；對交付頻率的要求越高，希望前置周期越短，自動化測試就越為重要。秉承著快速、便捷、可信和即使的自動化測試原則，遵循自動化測試金字塔結構，合理設計自動化測試的實施策略，降低自動化測試的成本，從而增加自動化測試的收益。
