自動(dòng)化測試架構

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

現在需要做的是提高發(fā)展與創(chuàng )新的比例。那么只需將驗證和驗證系統完整性的人工工作轉移到機器時(shí)間即可。人力資源部門(mén)有更多的時(shí)間來(lái)驗證和提高目前正在開(kāi)發(fā)的內容的質(zhì)量和穩定性。

有人會(huì )說(shuō)測試不適用于 IT 架構。但事實(shí)是，軟件的設計和治理方式最終會(huì )成為測試完成和自動(dòng)化方式的藍圖。

在實(shí)施和改進(jìn)自動(dòng)化測試架構的后期，通常存在技術(shù)缺陷。通過(guò)這些方式，我將上下文表述并定位為“自動(dòng)測試化架構”。它包含一個(gè)測試策略框架，作為架構的一部分，即技術(shù)策略。

1.測試級別

以前的模型將業(yè)務(wù)和 IT 定義為聯(lián)合連接。我們確保技術(shù)以預期的方式實(shí)現業(yè)務(wù) - 以及該業(yè)務(wù)的IT計數提供基本的構建區域 - 計劃- 以滿(mǎn)足期望。

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

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

2.有意義的測試方法

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

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

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

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

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

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

3.測試覆蓋率

自動(dòng)化測試覆蓋率在三個(gè)測試自動(dòng)化管道中解決。把一個(gè)完整的產(chǎn)品想象成一個(gè)寓言。

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

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

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

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

4.報告、描述和樣式

UI測試必須是每個(gè)正在運行的測試環(huán)境單獨的套件和配置。在（行為驅動(dòng)開(kāi)發(fā)）編寫(xiě)測試場(chǎng)景時(shí)使用 BDD 編寫(xiě)的樣式，通過(guò)使用“給定x當y然后z”。例;

理想情況下，報告與級別測試一起在 DevOps 管道中自動(dòng)構建。即通過(guò)測試工具就可以完成。報告可以作為鏈接、電子郵件或附件自動(dòng)發(fā)送給相關(guān)利益相關(guān)者，即業(yè)務(wù)用戶(hù)或產(chǎn)品所有者。

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

實(shí)時(shí)報告的示例顯示，acc & dit 中部署的代碼可能具有相同的問(wèn)題。即無(wú)響應的 API

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

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

5.自動(dòng)化測試

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

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