軟件測試自動化的最新趨勢

　　過去幾年，QA 行業的一個持續趨勢是測試自動化和持續測試。這一趨勢也將在 2019 年繼續下去。雖然 CI/CD、DevOps 和測試框架在將來一年仍將是突出的主題，但一些新技術正在影響咱們測試的內容和測試方法。

 

　　人們期待在 JavaScript 領域看到更多的開源測試框架，在使用的工具中嵌入更多的人工智能功能，以及來自商業工具供應商的更多創新。另外一個持續的趨勢是功能測試和性能測試的結合（你能夠將其看作 Selenium 與 JMeter 測試相結合）。此外，人們還指望看到更多行爲驅動開發（Behavior Driven Development，BDD 測試）的發展，以及在敏捷組織中如何採用它。自動測試場景生成是咱們與幾個客戶合做的另外一個領域。

　　如下是目前軟件測試自動化水平的完整概述。

 

• 　　物聯網測試

　　物聯網（Internet of Things，IoT）正對測試領域產生顯著的影響。像 Selenium 這樣的傳統自動化方法在嵌入式環境中變得毫無用處。咱們已經看到愈來愈多的基於 Python 和 C/C++ 的測試框架執行單元測試、集成測試和系統測試。大多數測試框架都是測試由這些嵌入式庫導出的 API，其中至關多的框架調用嵌入式代碼來執行單元測試。這須要具備重要軟件開發經驗的專業測試工程師，但咱們看到更多的軟件開發人員將被部署到自動化測試的角色。Python 多是物聯網測試框架開發的首選語言，由於它可以直接使用 ctypes 包來調用 C 代碼。

　　另外一個新趨勢就是物聯網的 DevOps 環境開始標準化。到目前爲止，咱們看到的大可能是 CI 環境的 Ad-hoc 實現。咱們已經預先構建瞭解決方案，用於構建管理、測試管理、鏡像加載、物聯網鏡像在不一樣設備上的部署、不一樣構建物聯網設備的 A/B 測試等。

 

• 　　持續測試

　　持續測試是從去年至今仍在繼續的另外一個趨勢。咱們在過去已經看到了 DevOps 和 CI/CD 框架的爆炸式增加，而今年這種趨勢，將隨着新的框架（如 Nevercode 和 Codefresh）的出現而繼續。

　　持續測試的另外一個趨勢是對每一個版本進行基於人工智能的風險評估。之前，這種操做是手工執行的，以肯定能爲應用程序部署哪些版本。咱們已經實現了幾個 CI/CD 平臺，它們執行應用程序基於人工智能的自動 A/B 部署。

 

• 　　基於人工智能的測試

　　基於人工智能的測試方法已不只僅是時髦語，如今已經進入了主流測試實踐。人工智能和自動化是測試的兩個並行方面：自動化用於功能測試，而人工智能則用於視覺測試。基於人工智能的視覺測試，包括視覺測試和感受測試，並快速瀏覽每一個構建版本的視覺變動，是一個很是有用的發佈驗證方法。咱們已經在 Denver 的不一樣客戶中實施了基於 Applitools 的視覺測試解決方案。

 

　　雖然嚴格來講，視覺測試目前並非基於人工智能的。圖像比較算法是基於傳統的梯度分類。

 

　　咱們所使用的其餘幾個獨特的工具不多可以智能地自動化許多任務。

　　測試套件優化：咱們開發了一些工具來分析日誌模式，並肯定哪些測試用例是重複的。

　　使用日誌分析進行缺陷識別：根據日誌分析突出顯示軟件缺陷。

　　自動測試場景生成相似於 Swagger。

 

• 　　開源測試框架

　　在過去的幾年裏，咱們看到的不斷增加趨勢之一是，從傳統的企業測試解決方案（如 HP QC、ALM、UFT、IBM 等）遷移出來。咱們看到各類規模的組織愈來愈多地採用開源測試平臺。咱們親自將客戶的幾個測試框架從 HP QC/UFT 遷移到其餘開源解決方案。儘管這些開源解決方案涉及到編碼，但從長遠來看，它們具備高度可定製性和可維護性。咱們預計，隨着 2019 年的到來，這些開源解決方案將繼續得到更大的吸引力。

 

• 　　敏捷開發和 DevOps 的合併

　　DevOps 的關鍵原則是開發團隊、測試團隊和運營團隊協做，無縫發佈軟件。這意味着集中或隔離的 QA 部門如今必須與開發和運營團隊合併，以便爲各類版本提供按需測試服務。測試變得更加漸進、迭代，並與應用程序開發和部署過程集成。

 

　　譯註：行爲驅動開發（英語：Behavior-driven development，縮寫 BDD）是一種敏捷軟件開發的技術，它鼓勵軟件項目中的開發者、QA 和非技術人員或商業參與者之間的協做。BDD 最初是由 Dan North 在 2003 年命名，它包括驗收測試和客戶測試驅動等的極限編程的實踐，做爲對測試驅動開發的迴應。在過去數年裏，它獲得了很大的發展。

　　2009 年，在倫敦發表的「敏捷規格，BDD 和極限測試交流」中，Dan North 對 BDD 給出了以下定義：

　　BDD 是第二代的、由外及內的、基於拉 (pull) 的、多方利益相關者的 (stakeholder)、多種可擴展的、高自動化的敏捷方法。它描述了一個交互循環，能夠具備帶有良好定義的輸出（即工做中交付的結果）：已測試過的軟件。

　　咱們如今已看到基於 BDD 的測試機制的採用，它容許在 sprint 週期中開發的新功能進行迭代測試。BDD 表明行爲驅動開發（Behavior Driven Development），它自己源自驗收測試驅動開發（Acceptance Test Driven Development，ATDD）。BDD 迫使團隊在收集需求的同時提出測試場景。測試場景被當即記錄下來並簽入 CI 系統，以強制 CI 系統顯示這些場景的故障。在 Sprint 期間，開發和 QA 團隊的目標如今變成了這些場景。這種測試框架開發機制在方法上是新穎的，很是適合敏捷環境。咱們看到不少客戶在敏捷實踐中轉向基於 BDD 的測試開發。

 

• 　　性能工程的性能測試

　　測試的關鍵趨勢之一是將性能測試角色不斷轉變爲成熟的性能工程角色。性能工程如今不只包括測試方面，還包括監控系統性能。資源的自動伸縮、A/B 測試、ELB、數據庫優化、瓶頸識別和監控。如今已有集中基於雲端的工具能夠準確地監控不一樣雲資源上的各類性能參數，而且經過警報對全部資源進行儀表板監控是咱們在各類客戶端上工做的主要部分之一。

 

• 　　微服務測試

　　隨着愈來愈多的應用程序轉向微服務模型，測試架構也朝着微服務測試模型發展。之前，產品的 QA 遵循黑盒測試模型，但如今，經過微服務測試，咱們正朝着灰盒測試模型邁進。

　　微服務測試包括 API 測試、數據庫測試、身份驗證服務 / 搜索服務測試等。咱們能夠將這個測試模型稱爲更多的組件測試模型，而不是測試集成產品。

　　微服務測試容許咱們在全部變動進行大爆炸式的集成以前發現問題。 它仍然高於單元測試，由於組件必須徹底定義，而且測試基於這些組件的外部 API。

 

• 　　測試即服務（TaaS）

　　測試即服務（TaaS）或 QA 管理服務是一種外包模式，其中組織的測試活動由外部團隊而非員工來執行。在許多狀況下，外部團隊是一個離岸團隊。但咱們也有一些實例，咱們爲自動化開發和項目移交的初始階段開發了離岸團隊，而後是離岸團隊進行 QA 維護。

　　測試即服務（TaaS）的優點包括：

　　支持按需測試資源。測試是一種週期性活動，其中，資源利用率並非恆定的。測試即服務意味着客戶只需爲測試資源使用的時間支付費用。

　　離岸資源下降成本：因爲與離岸組織相關的勞動力成本較低，

　　自動化服務包含在內：測試即服務包括測試自動化框架、CI/CD 框架以及性能測試和監控，從而下降了組織的各類成本。