高效的敏捷测试第八课 静态测试工具和生成测试报告
第18講：增加自動的靜態測試和測試報告生成功能
在之前的講解里，我曾經提到過，靜態測試的對象包括需求、設計和代碼，也提到過代碼審查的兩種方式：一種是人工評審，另一種是基于工具的自動靜態測試。在?CI?環境中我們可以通過?GitHub?的?Pull Request?特性來進行代碼的人工評審。這一講，我將帶你學習自動的靜態測試方法、工具和靜態測試報告，以及自動化測試報告的生成。
代碼分析（靜態測試）
代碼的靜態測試，也叫靜態分析，它不需要運行應用程序就可以對軟件代碼進行檢查，并找出其中的缺陷。自動靜態測試是指利用靜態分析工具對代碼進行自動掃描發現缺陷的技術，相對人工評審來說，它不需要投入太多人力就可以發現代碼中的缺陷，是效率比較高的代碼審查方式。
自動靜態分析方法一般能夠發現代碼中的下列問題。
代碼結構問題：重復性代碼、高度耦合的代碼等。
實現問題：資源泄漏、空指針引用、死循環、緩沖區溢出等。
可讀性差、不規范的問題：有些代碼沒有縮進、變量在使用前未定義等。
這些功能對于查找一些代碼的安全漏洞缺陷特別實用，比如有些程序如果接收到超出緩沖區的數據和參數，就會導致緩沖區溢出，攻擊者利用精心構造的溢出數據就可以讓程序執行其惡意代碼，從而獲得系統的控制權，達到入侵系統的目的。如果在研發階段不能發現此類問題，上線后可能會造成重大的信息安全事故。比如?2003?年美國?Davis-Besse?核電站受到?Slammer?蠕蟲攻擊，就是因為程序中的緩沖區溢出漏洞被黑客利用而造成的。
要實現自動的靜態測試，團隊需要完成以下幾方面的工作。
?
首先需要選擇合適的靜態分析工具。對于自動靜態測試，僅僅借助工具進行測試還不夠，并且無論采用哪種工具，團隊都需要一起定義掃描規則，使用統一的規則進行靜態測試。比如在開發過程中對發現的代碼缺陷進行總結、提煉或抽象，把這些代碼缺陷模式借助規則集、模型、解析樹、形式化方法等方式描述出來，結合編程規范就形成了自定義的掃描規則。
其次，開發人員提交代碼前應該先在本地開發環境里執行靜態測試，結果可以做為人工評審（Code Review）的輸入項進行分析，如果其中的典型或重大問題能讓團隊成員知曉并討論如何避免，則可以有效地提高整個團隊的代碼能力和質量意識。
最后，將靜態測試工具集成在?CI?環境中，靜態測試將會成為持續集成活動的一部分，并且自動生成可視化的代碼分析報告，發送郵件通知開發人員進行分析和修復工作。
優秀的靜態分析工具
我們先從靜態分析工具開始講起，常用的工具有很多，這里只列出其中的一些，比如?Java 可以選擇?PMD、FindBugs?等，C/C++?語言可以選擇?C++ Test、CppTest、Splint?等，Python?語言可以選擇?Pylint、Pychecker、PyCharm?等。
FindBugs 通過檢查?JAR 文件，將字節碼與一組缺陷模式進行對比，從而發現可能的代碼問題，它既提供可視化 UI 界面，同時也可以作為 Eclipse 或?IntelliJ DEA（簡稱 IDEA）插件使用。FindBugs 還為用戶提供定制 Bug Pattern 的功能，用戶可以根據需求自定義 FindBugs 的代碼檢查條件。
PMD?可以檢查、分析 Java?源程序代碼，并通過內置的編碼規則對 Java 代碼進行靜態檢查。同時，它也支持開發人員對代碼檢查規范進行自定義配置，主要檢驗潛在的 bug、未使用的代碼、重復的代碼、循環體創建新對象等問題。另外，PMD 還可以和多種?IDE 進行集成。
Checkstyle?是針對 Java?代碼風格的檢查工具，它偏重于代碼編寫格式的檢查，包括?Javadoc?注釋、命名約定、標題、Import?語句、修飾符等。
靜態測試報告的自動生成
在實際使用中，代碼分析工具一般通過各自的插件集成到?IDE（Elipse、IntelliJ DEA、Pycharm等）環境中，開發人員在提交代碼前會對代碼進行實時的靜態測試。如圖?1?所示，在?IDEA中安裝了?3?個代碼分析插件：SonarLint、Checkstyle?和?PMD。其中，PMD?和?Checkstyle?可以添加工具自帶的代碼規則，以及團隊自定義的代碼規則。
圖?1 IDEA?中添加代碼分析工具的插件
在?IDEA?中選擇需要分析的源文件和分析工具，就可以得到如圖?2?所示的代碼分析結果。
圖?2 代碼分析結果
SonarLint?一般作為?IDE?的插件，用于開發人員進行本地的代碼分析，以便在編程中及時發現問題、及時修改，以確保代碼?push?到代碼庫前的代碼質量，如圖?3?所示。
圖3 IDEA 中的 SonarLint 插件
SonarLint?可以和?SonarQube?集成，從而擁有更加豐富的代碼規則集，而且在代碼掃描分析完之后，其測試結果會上傳到?SonarQube?服務器上，如圖 4 所示，它以直觀的可視化界面來展現代碼質量及單元測試覆蓋率。雙擊顯示頁面上的某個數字，就可以查看具體的信息等內容。
圖?4 SonarQube 的測試報告
靜態分析工具和?CI?調度工具的集成讓靜態測試成為持續集成的一部分，如果我們要讓靜態測試和 Jenkins 集成，就需要用到?SonarQube Scanners，實現代碼自動掃描并上傳報告到?SonarQube，這也是目前比較主流的應用方式。也就是說， SonarQube Scanners?依據?SonarQube?服務器中的代碼規則庫進行遠程代碼分析，而且可以和構建工具?Gradle、Maven、Azure DevOps 等集成。
圖?5?就描述了這種?CI?環境中代碼分析的工作流程。開發人員在本地開發代碼并利用?SonarLint?進行實時代碼分析，然后將代碼?push?到代碼倉庫中，觸發持續構建，之后采用?SonarQube Scanners?進行代碼分析，持續集成結束后將代碼分析結果發布到?SonarQube?服務器以呈現測試報告。SonarQube?服務器將代碼規則集和分析結果存儲在數據庫中，缺陷則提交給開發人員。
圖?5 SonarQube 在 CI 環境中的集成
下面是?Jenkins?流水線腳本示例，構建過程包括編譯、部署、單元測試、代碼覆蓋率分析等，這些過程完成之后，Jenkins 會自動調用?sonarQube Scanners?執行代碼靜態測試，測試報告會自動上傳到?sonaQube?的界面上。
自動化測試報告的自動生成
除了單元測試和代碼靜態測試，BVT、回歸測試、性能測試等自動化測試也可以在?CI?環境中自動觸發測試活動并生成測試報告。
下面的?Jenkins?流水線腳本給出了調用?Robot Framework?進行自動化測試的示例。當然，你需要在?Jenkins?里安裝相應的?Robot Framework?插件。
Jenkins?可以生成?HTML?格式的報告，就像上面腳本里定義的。但是要得到更加美觀的報告則需要集成第三方的測試報告生成工具。報告的生成有兩種方式：
在?Jenkins?中集成測試報告生成工具然后自動生成報告；
在自動化測試框架中實現自定義的測試報告生成功能模塊，然后通過?Jenkins?和測試框架的集成生成測試報告。
先說第?1?種方式，首先我們介紹兩個測試報告生成的工具，即 Grafana?和?Allure2。
Grafana?是一款用?Go?語言編寫的開源框架，它通過對采集數據的查詢，以可視化的方式展現大規模的指標數據，是目前網絡架構和應用分析中流行的時序數據（指帶有時間戳的數據）展示工具。
Grafana?可以關聯多種數據源，比如?MySQL、InfluxDB（開源分布式時序數據庫）等。在 Jenkins?中安裝?InfluxDB?插件后，將每次構建的信息存入數據庫，就可以發送到?Grafana，按照時間順序展示測試結果，包括由單元代碼覆蓋率統計工具和代碼分析工具生成的結果。同時，利用?Grafana?可以建立測試結果和測試指標的實時監控面板，圖?6?展示了?Jenkins?中多個流水線部署管道每次構建后的代碼覆蓋率。
圖?6 Grafana?展示的代碼覆蓋率
順便提一下，Grafana 的功能還不止如此，把它集成在部署流水線中，可以幫助我們實時呈現、監控?Kubernetes?容器集群的負載情況，包括集群?Pod、CPU、內存和外部存儲等使用狀態，如圖?7?所示。
圖7 ?Grafana?監控?Kubernetes?集群負載
另一款比較優秀的測試報告框架是?Allure2，它可以提供如圖?8?所示的比較美觀的測試結果概覽，而且可以查看每個測試用例的測試結果、測試用例的描述等。
圖?8 Allure 生成的測試報告 Overview
下面的?Jenkins?流水線腳本給出了自動化回歸測試之后?Allure?自動生成的測試報告示例。腳本定義只有在測試失敗時才會用郵件通知相關人員，但每次都會生成?Allure?測試報告，Allure?報告的鏈接會顯示在?Jenkins?管理界面上。具體的配置方法你可以自己學習。
用戶自定義的測試報告
只要把?Allure?這樣的測試報告框架和?CI?環境進行集成，就可以自動生成比較美觀的測試報告。如果團隊需要自定義的測試報告以滿足進一步的需求，Allure?還可以提供與自動化測試框架的集成，通過在測試腳本中添加?Allure?注解比如?@Story、@Issue、@Attachment，來實現測試報告的定制，這些功能包括關聯用戶故事、關聯測試用例、定義測試用例級別、關聯缺陷、為失敗用例添加 UI 界面的截圖等。
另外還有?ExtentReports，它也是一款可以和多個自動化測試框架集成，從而實現定制化測試報告的框架。圖?9?展示了?ExtendReport?和測試框架集成后生成的自定義?HTML?報告，來自我公眾號里的一篇文章，介紹了基于?Spock?的測試自動化框架，有興趣的可以去看看。
圖?9 ?ExtentReports 生成的自定義測試報告
這部分內容就介紹到這里了，下面我簡單總結一下這一講的內容：
代碼的靜態測試可以有效提高代碼質量，合適的靜態測試工具有?PMD、Splint、Pylint?或 SonarLint；
靜態測試工具與?CI?環境集成后可以自動生成代碼分析報告并讓結果和缺陷信息可視化；
介紹了?3?種測試報告框架，即 Allure、ExtendReport?和?Grafana，前兩個和自動化測試框架集成可以實現用戶自定義的測試報告。
最后給你留兩道思考題：你還知道有哪些用于生成測試報告的開源框架嗎？平時希望生成怎樣的測試報告？歡迎留言參與討論。
第19講：搭建敏捷自動化測試框架及其案例分析
在前幾講已經介紹了虛擬化技術、CI/CD 環境、DevOps 下的基礎設施及自動部署、BVT 等，而上一講介紹了靜態測試技術和工具，這一講將側重介紹動態測試工具，從而形成一個完整的測試基礎設施的體系。
如果只是討論工具，感覺不夠恰當，所以會提升到自動化測試框架這個層次上。因為工具很多，變化也很快，而且換工具是比較容易的，今天喜歡這個工具，就用這個，明天有更好的工具，就可能想換了。經常望著這山比那山高、頻繁換工具，也是不合適的，因為團隊已經熟練使用工具并積累了良好的經驗，與工具聯系在一起的腳本值得繼承，這些無形資產都值得保護。
自動化測試框架是測試基礎設施的核心部分，不僅提供了各種測試服務，比如測試腳本的開發、執行、調試和管理，測試過程的管理、測試資源的管理，以及支持不同類型的測試（比如性能測試、安全性測試、易用性測試等）執行與分析，而且也希望基于這個框架，讓測試與開發平臺、CI/CD 環境更加融合，構建更高效的研發平臺。
自動化測試框架的構成
可以設想一下自動化測試開發與執行的場景：首先，研發人員根據測試任務的要求，開發和調試自動化測試腳本，并能基于腳本和測試環境組合成測試任務，在下班前預先安排好測試任務，比如在某個 Web 頁面上提交測試任務，而這些任務能夠在當晚自動執行，第二天我們一上班就可以查看測試結果或瀏覽測試報告。如果晚上執行不順利，系統則會發消息或郵件給相關人員，讓我們檢查并處理存在的問題，使得測試能夠繼續跑下去。當然，如果測試都在半夜執行，不適合人工干預，那就增加一些異常處理機制、重試機制來自動處理這類問題。
這種測試任務能夠按某種機制（比如定時機制、版本構建成功后消息觸發機制等）自動啟動執行，而且需要自動發現可用的測試資源來執行測試任務，這依賴于資源監控和調度工具 或 平臺來完成，并借助代理獲得機器狀態、運行測試工具和將測試日志發送到特定服務器上以供分析。
為此，我們需要構建一個自己的自動化測試框架，能夠集成測試腳本開發環境、測試執行引擎、測試資源管理、測試報告生產器、函數庫、測試數據源和其他可復用模塊等為一體，而且還可以靈活地集成其他各種測試工具，包括單元測試工具、API 測試工具和 UI 測試工具等。不同于工具，框架只是實現一個架構，用戶可以根據自己的需求進行填充，比如進行二次開發增加具體、特定的功能，還可以集成其他不同的測試工具。圖1就展示了自動化測試框架的邏輯結構，由多個組件構成。
? ?
圖1 ?自動化測試框架的基本構成
Harness/IDE：TA 框架的核心，相當于“夾具”，框架的其它組成部分都能與之集成，而且具有腳本的創建、編輯、調試和管理等功能。
TA 腳本的管理，包括公共腳本庫、項目歸類的腳本庫，這部分可以與 GitHub 這類（代碼庫）配置管理工具集成。
測試資源管理：增加、刪除和配置相應的測試設備（軟硬件資源），并根據它們的使用狀態來分配測試資源，這部分可以和容器管理工具集成。
測試數據管理：測試數據的自動生成、存儲、備份和恢復等，也可以演化成一個數據平臺，甚至是數據中臺。
開放的接口：提供給其他 CI 環境或其他測試環境的集成接口，這種接口以 API 形式提供，類似之前提到的“基礎設施即代碼”的概念。
代理（Agents）：負責 Harness 與工具的通信，控制測試工具的運行。
任務安排（Scheduler）：安排和提交定時任務、事件觸發任務等，以便實現無人值守的自動化測試執行。
數據統計分析：針對測試結果（含測試工具運行產生的日志），生成可讀性良好的測試報告（如 HTML 格式的測試結果），如上一講提到的 SonarQube、Allure2 等。
自動化測試框架能夠與 CI 環境、配置管理系統和缺陷管理系統等集成起來，持續構建后直接觸發 BVT、后續的深度自動化測試。這種集成，不僅發生在單元測試、接口層次上，而且還可以在系統層面、業務層面的測試。下面我們就介紹不同層次的自動化測試框架。
自動化測試框架的分類
結合前面分層自動化測試策略——金字塔模型來劃分自動化測試框架更合適一些，從單元測試、接口測試再到 UI 層、ATDD/BDD 的自動化測試框架。
單元測試框架，由 JUnit 演化成單元測試框架家族 xUnit 最具代表性，形成了單元測試的基本規則，包含了面向各種編程語言的框架，比如 JUnit、CppUnit、NUnit、PyUnit、JsUnit、QUnit、DBUnit、HttpUnit 等。JavaScript 語言，也有一些其他的測試框架，比如 Jasmine、Mocha、Buster.js、DaleJS、PhantomJS、TestSwarm、JsTestDriver 等。
接口測試框架，比如 HttpRunner、Karate、APIfortress、Swagger 等。從框架的角度看，JMeter、SoapUI、Postman、PyTest、APIAutoTest 等算接口測試工具，還不能算框架，而 REST Assured 通常也算 API 框架，它更是為了簡化基于 REST 服務的測試而建立的 Java 領域特定語言（DSL），但將它和 JUnit 集成起來，如同 APIAutoTest +TestNG + HttpClient、Unittest + Request + HTMLRunner 等集成，也可形成接口測試框架。Robot Framework 和 Requests 庫集成起來，也能執行 API 的測試。
UI 自動化測試框架，比如面向 Web 的 Selenium + WebDriver、TestCafe 和 Cypress，面向移動 App 的 Appium，面向 Windows 客戶端軟件的 AutoIT 等。移動 App 還有更多的自動化測試框架，比如基于 Android 的 TA 框架 Robotium、Selendroid、ATAF 等，基于 iOS 的 TA 框架 KIF、Kiwi 等，以及跨平臺的 Ranorex Studio、Calabash 等。
ATDD/BDD 自動化測試框架：Robot Framework、Ginkgo、Cucumber、JBehave/ NBehave / CBehave、SpecFlow、RSpec、JDave、Chakram（REST API）、Concordion、Fitnesse、Guage 等。
在敏捷測試中，更推薦單元測試和基于接口的自動化測試，如果再進一步，ATDD 和 BDD 也是敏捷測試中所推薦的，是更為徹底的自動化，即讓需求可執行，將需求變成真正的活文檔。而基于 UI 的自動化測試框架更適合傳統的開發，或者說不是為敏捷測試而生，所以我們重點會關注單元測試和基于接口的測試、支持 ATDD/BDD 的驗收測試等三類自動化測試框架。下面將從這三類框架中各拿出一個工具，做進一步的案例分析。
單元測試框架 JUnit 5
先說單元測試框架。談起單元測試框架，不得不介紹 JUnit，它是最為經典的自動化測試框架，也成為了事實上的單元測試框架的業界標準。JUnit 最新版本是 JUnit 5，它不再是一個單一的 jar 包，而是由 JUnit platform（平臺）、Jupiter（木星）、Vintage 等三部分組成，如圖 2 所示，其顯著的新特性有擴展模型、嵌套測試、條件測試、參數化測試等。
? ?
圖2 ?JUnit 5 架構示意圖
JUnit platform，其主要作用是在 JVM 上啟動測試框架，包含一個內部的 JUnit 公共庫以及用于測試引擎、配置和啟動測試計劃、配置測試套件的注釋等公共 API，同時還支持通過控制臺（Console Launcher）命令、IDE 或構建工具 Gradle、Maven（即借助 surefire-provider、gradle-plugin）等來啟動測試。
JUnit Jupiter，包含了 JUnit5 最新的編程模型（注釋、類、方法）和擴展機制的組合（Jupiter API）和一個測試引擎（Test Engine），用于編寫和執行 JUnit 5 的新測試，其中 junit-jupiter-params 為參數化測試提供支持。
JUnit Vintage，一個測試引擎，允許在平臺上運行老的 JUnit 3 和 JUnit 4 測試用例，從而確保必要的向后兼容性。
通過上面這張注釋列表，能感受到 JUnit 5 更強大的功能。例如，擴展機制通過 @ExtendWith 定義，簡單明了。
可以通過 @ParameterizedTest 來定義參數化測試方法，而且還可以和其他注釋組合使用，指定多個來源，包括 @ValueSource、@MethodSource、@CsvSource、@ArgumentSource 等。
? ? ??
API 層的 TA 測試框架 Karate
API 層的自動化測試框架，如上所列，也有很多，要選擇適合自己的框架，也不是容易的事情，可以選擇自己熟悉的工具，比如 HttpRunner、JMeter、Postman 等。這里介紹一個由 Intuit 公司開發并開源的 API 測試框架 Karate，它不僅提供了源代碼，而且還提供了比較完整的文檔和演示實例，值得關注。這個框架，官方列出了 30 多個優點（特性），這里從中選出十大優點，供參考。
（1）純文本腳本，可以調用其他腳本，能調用 JDK 類、Java 庫，并具有嵌入式 JavaScript 引擎，可構建適合特定環境的、可重復使用的功能庫，具有良好的可擴展性。
（2）標準的 Java / Maven 項目結構，以及與 CI / CD 管道的無縫集成，并支持 JUnit 5。
（3）優雅的 DSL 語法原生地支持 JSON 和 XML，包括 JsonPath 和 XPath 表達式，覆蓋數據的輸入和結果的輸出。
（4）基于流行的 Cucumber / Gherkin 標準，支持 BDD（Cucumber 場景 Scenario Outline 表），并內置與 Cucumber 兼容的測試報告。
（5）內置對數據驅動測試的支持，原生支持讀取 YAML 甚至 CSV 文件，并能夠標記或分組測試，其場景數據支持友好的 JSON、XML 或其獨有的 payload 生成器方法。
（6）全面的斷言功能，容易定位故障，清楚地報告哪個數據元素（和路徑）與預期不符。
（7）多線程并行執行，內置分布式測試功能，可用于 API 測試而無需任何復雜的“網格”基礎架構，從而顯著節省測試時間，簡化測試環境準備工作。
（8）API mocks?or test-doubles 甚至可以在多個調用之間維持 CRUD 的“狀態”，從而支持微服務和消費者驅動的契約測試。
（9）模擬 HTTP Servlet，可以測試任何控制器 Servlet，例如，Spring Boot / MVC 或 Jersey / JAX-RS- 無需啟動應用程序服務器，可以使用未更改的 HTTP 集成測試。
（10）全面支持不同類型的 HTTP 調用：
SOAP / XML 請求
HTTPS / SSL，不需要證書、密鑰庫等
HTTP 代理服務器
URL 編碼的 HTML 表單數據
Multi-part?文件上傳、Cookie 處理的支持
HTTP ?head、路徑和查詢參數的完全控制
WebSocket 支持
這里展示了一個簡單的 WebSocket 測試示例，用到了 Given-When-Then 這種 BDD 的場景描述方式。
??
驗收測試框架 Ginkgo
最后來分析一個驗收測試的自動化測試框架，比較著名的有前面提到的 Cucumber 和 Robot Framework，今天介紹一個用 Go 語言開發的框架 Ginkgo（銀杏），它對 BDD?有很好地支持，擁有自己的 DSL，包括嵌套的 Describe、Context 和 When 容器模塊，BeforeEach / AfterEach、BeforeSuite / AfterSuite、It / Specify 等也一應俱全，這樣就能幫助我們組織和編排測試用例了。
先上一個例子，讓你感受一下，測試用例的業務場景是多么清晰、腳本的可讀性多么良好，這會大大降低腳本后期的維護成本。?
Go 語言擅長并行處理，Ginkgo 并行執行能力也就是原生的能力，實現了進程級并行執行測試的能力，既節省時間，穩定性也大大提高，也特別適合現在流行的容器環境，一個容器跑一個進程，可以直接在每個容器上運行命令 ginkgo -p 來執行測試。而且，ginkgo CLI 工具在并行執行測試時，會起一個監聽隨機端口的服務來實現不同進程之間的消息同步、日志和報告的聚合工作，從而輸出整齊漂亮的日志和測試報告。
下面給出 ginkgo 幾個命令，可以看出：非常方便地實現并行執行、代碼覆蓋率度量和 XUnit 測試包的轉換。
ginkgo -nodes = N 在N個并行進程中運行測試，并實時打印出一致的輸出
ginkgo -cover 使用Go的代碼覆蓋率工具運行測試
ginkgo -coverprofile=FILENAME 指定覆蓋率文件名稱
ginkgo -outputdir=DIRECTORY 指定覆蓋率文件存放目錄
ginkgo convert將XUnit樣式的測試包轉換為Ginkgo樣式的包
通過 ginkgo build、ginkgo -notify 等命令，還能進行測試服務分發、執行工作流時實現消息通知，這樣很容易和 CI/CD（如 Jinkins）集成起來，實現全流程的自動化測試。通過 ginkgo bootstrap、ginkgo generate 可以創建測試集、測試用例模板，從而更好地實現測試復用。
ginkgo build PACKAGE_PATH編譯測試集成.test文件，可部署到其他地方執行
ginkgo -notify 執行完成后觸發通知，需要按照對應插件
ginkgo -r ?遞歸執行文件夾內的所有測試用例
ginkgo bootstrap 創建測試集模板文件，會生成xxx_suite_test.go文件
ginkgo generate xxx 創建測試用例模板文件
Ginkgo 也支持第三方測試庫：Gomock 和 Testify，還能和 Google Go 的 Agouti（基于瀏覽器的驗收測試測試庫）集成。
Ginkgo 借助 Gomega（匹配器 / 斷言庫，是 Ginkgo BDD 測試框架的最佳搭檔）的 Eventually 和 Consistently 兩大功能提供了原生的異步支持，能大大降低死鎖或者未設置超時而異常卡住等問題的風險，提升執行的穩定性，而且能夠減少沒必要的等待時間。
Eventually(func() []int {
? ?return thing.SliceImMonitoring
}, TIMEOUT, POLLING_INTERVAL).Should(HaveLen(2))
Consistently(func() []int {
? ?return thing.MemoryUsage()
}, DURATION, POLLING_INTERVAL).Should(BeNumerically("<", 10))
針對分布式系統進行集成測試時，這個功能也很有用。
externalProcess.DoSomethingAmazing()
Eventually(func() bool {
? ?return somethingAmazingHappened()
}).Should(BeTrue())
至此，完成了本講要討論的內容，主要討論了自動化測試框架的構成與分類，并從中選了三個具有代表性的框架進行了分析與展示，它們分別是單元測試框架 JUnit 5、API 層的 TA 測試框架Karate 和驗收測試框架 Ginkgo。
最后留一個思考題，如果讓你在 Ginkgo 和 Robot Framework 中選擇一個框架，你會選擇哪一個？為什么？歡迎留言參與討論。
總結
以上是生活随笔為你收集整理的高效的敏捷测试第八课 静态测试工具和生成测试报告的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： SAP 月末结账步骤
- 下一篇： Unity开发 Photon Pun 多