作者：京東物流劉紅妍

導讀：

在自動化測試實踐中，為了更好的契合被測業務場景，需要不斷最佳化框架分層結構。本文結合產品模組化思路，意在介紹透過策略模式改造原本複雜分支語句程式碼，透過理論講解、思路分析、方案設計、及程式碼演示，提供自動化指令碼重構的落地方案。

在今年的敏捷團隊建設中，我透過Suite執行器實現了一鍵自動化單元測試。Juint除了Suite執行器還有哪些執行器呢？由此我的Runner探索之旅開始了！

1 痛點

隨著運輸業務場景的不斷豐富和自動化指令碼量的不斷累積，日常在review用例時發現，目前大家仍停留在針對需求定製化用例編寫，無法提高用例可複用性和可編排性。當業務流程中間某一環節發生變化時，不但需要重新修改指令碼，還會影響當前應用其他用例執行結果。所以，如何設計高複用性指令碼成為目前自動化建設的關鍵節點。

設計理論

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目標頁面展示到螢幕。從設計稿出發，提升頁面搭建效率，亟需解決的核心問題有：

2.1 設計理念

根據物件導向程式設計理念，設計者應遵循高內聚與低耦合原則，通常程式結構中各模組的內聚程度越高，模組間的耦合程度就越低。高內聚意味著一個類所能提供的功能應該是相關的，即一個類不要設計得包括很多互不相干的功能，低耦合代表要合理規劃模組的顆粒度，即要保證一個模組可獨立存在，降低模組之間複雜依賴關係。

2.2 策略模式

策略模式定義了一系列的演算法，將每一組相關的演算法封裝起各個策略分支，從而將分支相關的程式碼隱藏起來，並且使它們之間可以相互替換。策略模式讓演算法的變化不會影響到使用演算法的客戶，希望可以提高程式的可擴充套件性。

解決思路

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目標頁面展示到螢幕。從設計稿出發，提升頁面搭建效率，亟需解決的核心問題有：

3.1 基本思路

根據運輸業務同一個流程存在不同場景，如詢價服務接上游下發詢價單節點，需要區分來源執行不同邏輯，目前設計五個演算法能力，根據後期業務不斷擴充套件，還會有更多演算法加入進來，這個時候需要考慮一個好的結構對程式碼進行最佳化。可能前期大家透過if...elif...else 分支語句就可實現，但在考慮系統的健壯性和可維護性，這裡就不能大量使用if分支語句。因為每一種演算法能力的程式碼量極大且演算法引數幾十個，在隨著更多上游接入可能存在十幾個甚至更多else分支，很容易顧此失彼，牽一髮而動全身。所以，利用策略模式設計一系列演算法，再供用例拼裝呼叫，提高程式碼的可讀性和可複用性。

3.2 方案分析

優點：

程式碼解耦，便於維護；
避免使用難以維護的多重條件選擇語句；
可以執行時動態切換演算法；
開閉原則。無須對上下文程式碼進行修改，就可以新增新的程式碼。

缺點：

如果演算法邏輯，較為固定，不經常修改，使用策略模式只會增加程式碼量
必須知道所有的具體策略類及它們的區別。

方案概述

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目標頁面展示到螢幕。

4.1 環境依賴

Laputa框架簡介：

Laputa框架基於 Pytest 整合了對API介面自動化, 以及對 Web應用, 移動端應用和 Windows 桌面應用 UI 等自動化的能力。具有視覺化的Web介面工具, 便於配置執行規則，關聯執行指令碼，觸發用例執行，檢視執行結果。提供CI整合服務，呼叫Jenkins API跟蹤持續整合結果，開放介面，實現流水線自動化測試。

圖1 自動化框架架構圖

4.2 分層改造

圖2 自動化用例分層圖

4.3 策略設計

圖3 策略模式設計圖

4.4 操作步驟

將頻繁修改的演算法進行抽取，獨立為具體的演算法類；

2.建立抽象基類，實現一個約定的抽象策略方法；

所有獨立的演算法類，必須實現基類中的抽象策略介面；
建立上下類，該類可以動態的對演算法進行setter，建立呼叫具體演算法的方法，上下文可透過該方法與具體的策略互動；
客戶端進行呼叫，傳入具體的演算法類，上下文動態執行具體的演算法任務。

設計實踐

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目標頁面展示到螢幕。

5.1 詢價接單介面改造

如原始碼結構，根據不同業務來源，寫在一個方法裡透過if...else...分別組裝場景，一旦上游任一系統存在需求變動，當前接單介面呼叫邏輯需要變動：

【python】
def receive_enquiry_bill(**kwargs):
params=[{}]
params[0].update(kwargs)
if params[0].get("enquirySource") == 8:
pass
elif params[0].get("enquiryWay") == 2 and params[0].get("payMode") == 2:
pass
elif params[0].get("enquiryWay") == 2 and params[0].get("payMode") == 3:
pass
if params[0].get("enquirySource") == 46:
pass
if params[0].get("enquirySource") == 20:
pass

改造結構：

上下文類

【python】
class AlgorithmStrategy(object):
    def __init__(self, algorithm_name):
        self.algorithm_name = algorithm_name


    @property
    def algorithm(self):
        return self.algorithm_name


    @algorithm.setter
    def algorithm(self, name):
        self.algorithm_name = name


    def execute_algorithm(self, params):
        return self.algorithm_name.execute(params)

演算法基類：

【python】
class CreateEnquiryBillBaseAlgorithm(ABC):# 演算法能力基類
    @abstractmethod
    def read_params(self, **kwargs):
scenario=kwargs['scenario'] if "scenario" in kwargs and kwargs['scenario'] else 'base'
        return resource_custom_data[self.__class__.__name__][scenario][0].update(kwargs)


    @abstractmethod
    def execute(self, params):
        return jsf_receive_enquiry_bill(data=json.dumps(params)

不同演算法：

【python】
class CreateTFCEnquiryBill(CreateEnquiryBillBaseAlgorithm):
    def read_params(self, **kwargs):
        params = super().read_params(**kwargs)
        params[0].update({"businessCode": kwargs['businessCode'] if 'businessCode' in kwargs else f"TJ{laputa_util.date_time_str(fmt='%y%m%d')}{laputa_util.get_random_num(8)}","receiveBeginTime": tms_util.data_time_str(minutes=100),"deliveryBeginTime": tms_util.data_time_str(minutes=180)})
        return params


    def execute(self, params):
        return super().execute(params)


class CreateECLPClodEnquiryBill(CreateEnquiryBillBaseAlgorithm):


    def read_params(self, **kwargs):
# 若當前場景引數與基礎引數改動較大建議直接在Yaml裡另寫Key
params = super().read_params(**kwargs)
params[0].update({"businessCode": kwargs['businessCode'] if 'businessCode' in kwargs else f"ECO{laputa_util.date_time_str(fmt='%y%m%d')}{laputa_util.get_random_num(8)}","receiveBeginTime": tms_util.data_time_str(minutes=100),"deliveryBeginTime": tms_util.data_time_str(minutes=180)})
return params


    def execute(self, params):
        super().execute(params)
return jsf_do_assign(data=json.dumps(params))

演算法注入使用：

【python】
def receive_enquiry_bill(algOne=None, sceOne=None, **kwargs):
    """
    Args:
        algorithm: 業務型別
        scenario:  測試場景：執行步驟，執行資料
    Returns:
    """
 if algorithm:    
 # 採用字典形式進行手動註冊演算法，由python動態查詢
 st = {"TFC": CreateTFCEnquiryBill(), "ECLP冷鏈": CreateECLPClodEnquiryBill(), "TC": CreateTCEnquiryBill(),"終端用車": CreateTerminalEnquiryBill()}
    query_algorithm = st.get(algOne)
    return query_algorithm.execute(query_algorithm.read_params(scenario=sceOne, **kwargs))
 else:
  pass

當有需求變動，只需修改其一策略規則內部程式碼，如【分單策略需求】，除運輸內部系統TFC下發詢價指定個體標籤，其他上游沒有增加標籤下發功能，則只需修改CreateTFCEnquiryBill()程式碼即可。

5.2 Common用例組裝

拼接task客戶端方法組成case，利用feature組裝測試資料，資料驅動測試方法執行。

【python】
@pytest.mark.parametrize("params", test_data('test_enquiry_core'), indirect=True)
def test_enquiry_core(params):
    enquiry_code = receive_enquiry_bill_core(**params).get("data")
    return quote_enquiry_bill_core(enquiry_code=enquiry_code, **params)

總結

理解，首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板，當獲取到模板後進行模板載入，載入階段會將產物轉換為檢視樹的結構，轉換完成後將透過表示式引擎解析表示式並取得正確的值，透過事件解析引擎解析使用者自定義事件並完成事件的繫結，完成解析賦值以及事件繫結後進行檢視的渲染，最終將目標頁面展示到螢幕。

隨著運輸八大產品建設方向逐步明確，自動化平臺需要從應用維度重構到產品維度，在指令碼不斷融合和解耦過程，如何在新的分層模式設計高複用性指令碼，需要大家結合各自業務條線不斷最佳化改進。

高複用性自動化指令碼設計實踐

導讀：

1 痛點

設計理論

2.1 設計理念

2.2 策略模式

解決思路

3.1 基本思路

3.2 方案分析

方案概述

4.1 環境依賴

4.2 分層改造

4.3 策略設計

4.4 操作步驟

設計實踐

5.1 詢價接單介面改造

5.2 Common用例組裝

總結

相關文章