自動化測試架構

如果沒有組織的智能測試功能， 隨著系統復雜性的增加， 新開發的成本可能非常高。構建、部署、更新、創新等將會變得麻煩，因為現有的代碼庫需要更多的努力來驗證。保持系統的可靠性和穩定性將獲得對開發和創新的所有權。

現在需要做的是提高發展與創新的比例。那么只需將驗證和驗證系統完整性的人工工作轉移到機器時間即可。人力資源部門有更多的時間來驗證和提高目前正在開發的內容的質量和穩定性。

有人會說測試不適用于 IT 架構。但事實是，軟件的設計和治理方式最終會成為測試完成和自動化方式的藍圖。

在實施和改進自動化測試架構的后期，通常存在技術缺陷。通過這些方式，我將上下文表述并定位為“自動測試化架構”。它包含一個測試策略框架，作為架構的一部分，即技術策略。

1.測試級別

以前的模型將業務和 IT 定義為聯合連接。我們確保技術以預期的方式實現業務 - 以及該業務的IT計數提供基本的構建區域 - 計劃- 以滿足期望。

此模型顯示了測試覆蓋率如何從業務需求開始。但表示產品如何重新連接到最終產品中商定的質量和批準方面的測試級別。本文的其余部分將介紹這三個中的更多內容。

自動化測試以及新的開發旨在減少確保系統穩定性和完整性所需的時間、精力和頻率，同時由于開發和外部壓力因素而發生變化和修改。

2.有意義的測試方法

計算每個測試級別的測試次數，應形成如下金字塔結構。定義和維護測試通常越復雜，金字塔中的位置越高。從權衡創新的角度來看，意義更重大。

最好確保級別之間的測試不重疊。最佳情況下，由于級別的層次結構，測試覆蓋范圍得到擴展和完成。原因是我們不想引入浪費和不必要的維護。因此，這種“經典”的金字塔可視化并不完全正確。

如果金字塔在上層區域正下方有白色間隙，那就更真實了。像左邊這樣的圖表可能更具描述性。

當測試失敗時，這一原則為從哪里開始分析的結論提供了更高的準確性。如下圖所示，將其視為可以根據失敗/成功而更改的顏色。

即，如果 API 和 UI 出現故障，則問題可能出在 API 中。如果 API 已修復，但 UI 仍然失敗，請繼續在 UI 或單元/代碼測試中進行調查。

“如果它在生產或單元測試中失敗，但在 UI 或 API 測試中沒有失敗，我們是否需要考慮擴展測試范圍？”— 是的，很可能。每個生產校正都可能候選在有意義的級別添加測試。

3.測試覆蓋率

自動化測試覆蓋率在三個測試自動化管道中解決。把一個完整的產品想象成一個寓言。

代碼級方法，單元測試，驗證構成產品的每件作品的完整性、功能和預期結果。這些通常應該非常小，并且只驗證它們構建的目的。

API 級別方法提高了視野，其目的是確保依賴外部資源按預期工作。即管道、道路、應急、電力、信件等都可以連接到產品提供服務。它可能被稱為集成測試，但 API 級別用于驗證其他操作組件或服務的有效性和可操作性。即通過充當系統并進行簡單的數據請求和響應查詢，以驗證連接性 - 數據和響應時間。驗證系統代碼內部的實際響應，是單元測試，而不是API。

最后，UI 級別的方法是按照用戶的行為行事。當一個人真正把車停在以上產品的車庫里時。這需要系統的某些部分像現實一樣工作。此方法可以快速添加復雜的依賴項和條件以工作。此級別的測試將主要以業務為重點進行選擇和定義。希望與企業一起，這有助于設定目標和期望。作為回報，測試報告將定期創建和交付。即每個月。這些測試的設置可能很復雜，并且涉及許多步驟和集成。但它們的維護不能復雜或片狀。不允許測試數據因環境中的預期條件更改而失敗。

通常對于所有級別 — 對于每個環境，測試不必完全相同（但應該完全相同，以避免手動異常和配置的額外工作）。自動化可以而且應該在常見的支持的CI / CD工具（如TeamCity或Azure / Amazon DevOps）中自動化。

4.報告、描述和樣式

UI測試必須是每個正在運行的測試環境單獨的套件和配置。在（行為驅動開發）編寫測試場景時使用 BDD 編寫的樣式，通過使用“給定x當y然后z”。例;

理想情況下，報告與級別測試一起在 DevOps 管道中自動構建。即通過測試工具就可以完成。報告可以作為鏈接、電子郵件或附件自動發送給相關利益相關者，即業務用戶或產品所有者。

API 測試驗證并驗證與預期的數據交換。即驗證響應模式或響應中的某些元素。給定的BDD，當樣式完全可以，但在這里定義可能是不必要的開銷。API 測試應該是多變的。下表是 API 級別測試中的實時報告示例。

實時報告的示例顯示，acc & dit 中部署的代碼可能具有相同的問題。即無響應的 API

列描述;集合 - 在腳本中執行的預期/測試的集合。命名約定推斷每個測試環境、每個系統透視和每個依賴終結點都有一個測試集合?；A - 服務的基本可訪問性及其響應時間。驗證 - 獲取并驗證所需的每個 API 方法的架構。如有必要，請驗證響應中的相關值。例外-引發錯誤方案，并根據預期驗證錯誤響應。

建議以 BDD 樣式編寫單元測試，但可以通過任何有意義且對實際測試情況有意義的方式進行。格式和命名的限制較少，因為它們通常不會向 IT 開發團隊以外的任何人公開。在正常情況下，報告應該完全保留在開發團隊和 CI/CD 工具中。

5.自動化測試

嚴格來說，測試架構并不控制自動化和 CI/CD 的建立方式。廣泛接受的工具或平臺有助于跟蹤部署、提交、歷史記錄和可訪問的配置。但是，任何能夠執行自動化并使開發團隊能夠將手動測試工作集中在新開發上的方法或技術都可能成功。

原文轉自：http://www.uml.org.cn/Test/202211074.asp