自動化測試模型概述

1. 概念

自動化測試模型可以看作自動化測試架構與工具設計的思想。自動化測試不僅僅是單純寫腳本運作就可以了，還需要考慮到如何使腳本運作效率提高，代碼複用、參數化等問題。自動化測試模型分為四大類：線性模型，子產品化驅動測試，資料驅動，關鍵詞驅動

2. 線性模型

線性腳本中每個腳本都互相獨立，且不會産生其他依賴與調用，其實就是簡單模拟使用者模拟操作流程的腳本。

例如，将一個登入網頁和退出的過程，用python+selenium，順序寫成腳本，就是一個線性模型。

再例如，錄制/回放測試架構。它采用的原理是通過錄制應用程式産生的線性腳本進 行回放進而到達自動化測試的目的。

線性模型的優點是簡單，通過錄制或按照順序編寫即可得到所需腳本。但同時也有很大的缺點，它不具有邏輯判斷的能力，可維護性差，效率低下。

3. 子產品化驅動測試

線性子產品雖然每個用例都可以拿出來獨立運作，但是用例之間重複代碼很多，開發、維護成本高。其實把重複的操作代碼封裝為獨立的公共子產品，當用例執行時需要用到這部分，直接調用即可，這就是子產品驅動的方式。比如登入系統、登出、截圖函數等等。

4. 資料驅動

資料驅動簡介

子產品驅動的模型雖然解決了腳本複用的問題，但是需要測試不同資料的用例時，子產品驅動的方式就不很合适了。資料驅動就是資料的改變進而驅動自動化測試的執行，最終引起測試結果的改變。簡單來說，就是參數化的應用。資料量小的測試用例可以使用代碼的參數化來實作資料驅動，資料量大的情況下建議大家使用一種結構化的檔案（例如yaml，json等）來對資料進行存儲，然後在測試用例中讀取這些資料。加載資料的方式可以是清單、字典或是外部檔案（txt,csv,xml,excel），目的就是實作資料和腳本的分離。

該種架構的原理是采用了資料驅動腳本進行測試，資料驅動腳本是将資料輸入存儲在獨立的資料檔案中，腳本隻存放控制資訊，測試時輸入直接從檔案中讀取，這樣同一腳本可以運作于不同的測試用例中，實作了腳本與資料的分離。

其優點是可以快速增加相似測試，測試者增加新的測試不必掌握測試工具語言，對側後的類似測試無額外維護開銷；缺點是初始建立測試腳本的開銷較大，進行資料擴充的腳本需要針對相同的測試内容并具有相同的測試邏輯。

資料驅動應用場景

App、Web、接口自動化測試

測試步驟的資料驅動

測試資料的資料驅動

配置的資料驅動

配置驅動執行個體

代碼如下：

import pytest
import yaml

class TestDemo:
    @pytest.mark.parametrize("env", yaml.safe_load(open("./env.yaml")))
    def test_demo(self, env):
        if "test" in env:
            print("這是測試環境")
            """
            由于parametrize 要求傳入的參數為list 或 tuple，
            但是我們傳入的為字典，是以列印結果為 “test”,是以應修改yaml檔案為list
            """
            print(env) 
            print(f"測試環境的ip為{env['test']}") # 修改env.yaml檔案後結果為127.0.0.1

        elif "dev" in env:
            print("這是開發環境")
           

如果env.yaml 内容如下，則 print(env) 的結果為 ‘test’ ，因為 parametrize 裝飾器要求傳入的參數為list 或 tuple，但是我們傳入的為字典，是以列印結果為 “test”,是以應修改yaml檔案為lis

運作結果

collecting ... collected 1 item

test_demo.py::TestDemo::test_demo[test] PASSED                           [100%]這是測試環境
test


============================== 1 passed in 0.06s ==============================

Process finished with exit code 0
           

修改 env.yaml 檔案如下後

-
  test: 127.0.0.1
           

運作結果

collecting ... collected 1 item

test_demo.py::TestDemo::test_demo[env0] 

============================== 1 passed in 0.06s ==============================

Process finished with exit code 0
PASSED                           [100%]這是測試環境
{'test': '127.0.0.1'}
           

4. 關鍵字驅動

關鍵字驅動（表驅動）是對資料驅動的邏輯擴充，它的核心思想可以概括為三個分離，其核心思想就是對象、操作、值概念的诠釋。

1）界面元素名與測試内部對象名的分離 在被測應用車需和錄制生成的測試腳本之間增加一個抽象層，它可以将界面上的所有元素映射成相對應的一個邏輯對象，測試針對這些邏輯對象進行，界面元素的改變置灰影響映射表，而不會影響測試。

2）測試描述與具體實作細節的分離 把測試描述和測試的具體實作分離開來。測試描述值說明測試要做什麼以及期待什麼樣的結果，而不管怎樣執行測試或怎樣證明結果。這樣做是因為測試的細節通常與特定的平台以及特定的測試執行工具有着密切的連寫。這用分離是的測試描述對于應用實作細節是不敏感的，而且有利于測試在工具和平台間的移動。

3）腳本與資料的分離 最後，可以把測試執行過程中所需的測試資料從腳本中提取出來，在運作時測試腳本再從資料存放處讀取預先定制好的資料，這樣腳本和資料可以獨立維護。

以上這三個分離各司其職、互相獨立，最大程度地減少互相之間的影響。從關鍵字驅動的思想可以看出，該種測試架構不僅實作了将資料和腳本相分離，而且實作了測試邏輯和資料的分離，大大提高了腳本的複用性和維護性，進而更大限度地實作了測試工具的自動化。

5. 關鍵字驅動和資料驅動的差別

資料驅動是從資料檔案（excel,csv,yaml,資料庫）讀取輸入，輸出的資料，然後通過變量傳入自動化測試用例中，在整個過程中，資料的讀取，測試狀态，測試資訊全部在測試用例裡面，測試資料都是資料檔案中，通過修改資料達到驅動自動化用例執行的方式叫做資料驅動。

關鍵字驅動時從面向對象的思維出發，同樣的業務邏輯會封裝成一個函數，這個函數的名字就叫關鍵字，不同的關鍵字實作不同的業務邏輯，當所有的業務邏輯都可以通過調用關鍵字來實作的時候，就是關鍵字驅動架構。

一般情況下企業裡面都是資料驅動和關鍵字驅動一起使用。

原文連結

原文連結2