自動生成測試腳本方案淺析

自動生成測試腳本方案淺析

轉載自 www.sohu.com/a/224590187_748431

自動生成測試腳本方案淺析

2018-02-28 18:15 來源:滬江技術學院 程序設計 /設計

原標題：自動生成測試腳本方案淺析

文：玉婷

本文原創，轉載請註明做者及出處構想篇

做爲一名接口自動化測試工程師，平常面臨最多的工做就是編寫接口自動化測試腳本，那麼，在 coding 的過程當中最讓你以爲枯燥和乏味事情有哪些？

痛點

• 每次拿到新接口，咱們要手動參照文檔在腳本中生成一份接口類，參數越多花費時間越多
• 需求不一樣，但健壯性和部分業務用例重複性高
• 想重構腳本，接口數據和用例這塊純編寫的工做量就會讓人望而怯步

天天都要花上30%的時間去寫那些不太須要思考的腳本，這真不夠自動化！

解決方案

• 解析文檔
• 梳理適合自動生成的腳本
• 經過工具生成這部分腳本

預期目標

解放雙手，下降純手力勞動佔比，進而給本身提供更多的時間去思考、理解產品和設計更多「聰明」的用例

實踐篇 自動化獲取接口信息 分析接口自動化腳本結構和內容

自動化測試腳本結構圖

篩選工做量大又有規律可循的腳本

此處規律不宜太過於複雜，可先選邏輯簡單的部分，咱們主要選取如下兩部分

• 接口類，工做時間佔比30%~50%，特色：結構特定、數據來源於其它平臺

接口類結構圖

• 用例部分，工做時間佔比30%~50%,特色：重複度高於80%左右、生成邏輯可描述

用例結構圖

解析接口文檔

接口信息來源於接口文檔，目前市場上比較主流的幾個接口文檔管理工具備Swagger、RAP、WIKI 或者其餘普通文檔工具。

下面以解析接口文件爲目的分析比較下幾款工具的區別：

.

分類	Swagger	RAP	WIKI
描述	用於生成、描述、調用和可視化RESTful風格的Web服務的框架	可視化接口管理工具	可供多人協同創做的超文本系統
格式	json	json	html
規範	各個參數、返回值的具體結構、類型有統一規範	同swagger	須要本身約定規範
成本	直接嵌入項目中，經過開發時編寫註釋，自動生成接口文檔，成本較低	須要開發按照平臺規則手動輸入，成本較高	須要按照約定規範，手動輸入，成本較高

若是有條件，你們能夠根據開發成本和解析接口文件的難易程度來綜合考慮，肯定使用哪一個平臺管理接口

咱們項目是 Swagger 和 WIKI 混合使用，因爲平常測試看 WIKI 居多，所以早期採用 Python 爬蟲利器 BeautifulSoup 來解析WIKIhtml頁面

1. from bs4 import BeautifulSoup
2. soup = BeautifulSoup(html_doc)
3. title_string = soup.title.string
4. # 後面繼續解析其餘須要用到的接口內容

使用下來發現經過wiki來獲取接口信息的一些弊端

1. 徹底靠人工來約束書寫規則不靠譜
2. 對於複雜的嵌套參數，稍有不按照規範來的，就會致使腳本解析錯誤，很大程度上形成了解析的難度
3. 在html上準確的定位信息遠比在json上難度大，兼容性差

因而，嘗試解析Swagger返回的json來得到接口信息爲後面生成腳本作準備

1. {
2. "swagger": "2.0",
3. "host": "xxx",
4. "basePath": "/",
5. "tags":[
6. {"name":"xxx-controller","deion":"xxx"},
7. ...
8. ],
9. "paths": {
10. "<接口地址1>": { ... },
11. "<接口地址2>": { ... },
12. ...
13. },
14. "definitions": {
15. "<實體類1>": { ... },
16. "<實體類2>": { ... },
17. ...
18. }
19. }

使用如下方式拿到json結果後，就能夠直接按照處理字典的方式來獲取須要的內容。

1. graph LR
2. json-->ApiObj

對於swagger.json的解析和代碼生成官方也提供了一些可供使用的庫swagger-codegen (java),因爲編程語言的限制，咱們使用了python本身解析

如今，咱們已拿到生成代碼所須要的信息

自動生成代碼 代碼生成工具

1. class CodeGeneratorBackend():
3. def begin(self, tab="t"):
4. self.code = []
5. self.tab = tab
6. self.level = 0
8. def end(self):
9. # return string.join(self.code, "")
10. return "".join(self.code)
12. def write(self, string):
13. self.code.append(self.tab * self.level + string)
15. def indent(self):
16. self.level = self.level + 1
18. def dedent(self):
19. if self.level == 0:
20. raise SyntaxError("internal error in code generator")
21. self.level = self.level - 1
24. """調用方法,開始生成代碼"""
25. c = CodeGeneratorBackend()
26. c.begin(tab=" ") # 定義縮進方式
27. c.write("def function(self):n")
28. c.indent() # 縮進
29. # 方法體
30. c.dedent() # 回退上一次縮進

接口類部分腳本生成規則

因爲咱們接口屬因而存儲在類結構中，所以根據當前腳本的API Object接口進行遍歷替換便可

接口用例部分代碼生成規則

特殊值用例

給每一個參數生成爲0、None、空字符串這樣特殊值的用例

定位參數類型

經過接口參數給出的類型，生成符合該類型的值，和一些不符合參數類型的值(健壯性)，賦值後生成用例,以下代碼示例

定位特定關鍵詞參數

• 遇到page相關參數可生成分頁用例，具體分頁測試用例細節就不贅述
• 遇到相似starttime，endtime參數，可生成兩個時間參數和當前時間先後比較的用例，兩個時間參數先後比較的用例

該生成規則須要和開發約定一些基本原則，另外也須要咱們在平常測試中多概括總結，找出那些有固定規律的用例，想辦法定位生成這類用例

定位接口類型

• 查詢類接口：可生單參數查詢、組合參數查詢、全參數查詢等用例
• 更新類接口：可生成單條更新每一個參數，組合更新，全量更新等用例

自動生成測試腳本工具介紹 框架流程圖

工具擴展性

• 用例生成規則可擴展，從框架圖中能夠看到，用例規則這快自成獨立模版，可單獨維護，便於後續新規則的加入
• 代碼模版可擴展，不一樣團隊對於代碼規範、基礎模版的樣式都不同，可自定義生成模版的樣式，增長了工具的靈活性
• 支持多種數據類型轉換，後續可擴展生成API對象、參數字典或其餘數據模式

成果和後續行動 效率提高

以一個優惠券需求爲例，大約新增/更新了10個接口（約150個參數請求參數，100個返回參數），包含增刪改查幾種類型，編寫加調試腳本在使用工具先後所花費時間對比，以下：

類型	工做量描述	不使用工具	使用工具	效率提高
接口類	約250個參數	2日/人	1小時內	94%
健壯性用例	約1000條用例	2日/人	1日/人	50%
平均	---	---	---	74%

從上例能夠看出使用腳本後的效率提升了近一半，而從設計到編寫完初版工具僅花費了2~3個工做日，仍是很是值得一作的。

聚焦測試

• 腳本編寫工做量的減小，會增長產品測試思考的時間，完善用例，檢查覆蓋面等

統一規範

• 統一了接口類輸寫規範，便於團隊內部維護和理解腳本
• 統一基本用例生成思路，規避測試工程師在設計基本用例設計時有所遺漏；統一用例輸出格式，便於他人理解和維護用例

重構利器

• 若是有計劃作腳本重構，使用工具後能夠成倍的節省編寫接口信息和用例部分腳本的時間

後續迭代優化點

• 目前用例的生成思路大多還侷限在單參數上，多參數的生成思路還較少，後續會經過頭腦風暴等形式來擴展更多的用例的生成思路
• 經過實際調用接口，獲取結果，提升自動生成用例指望結果的準確性,繼而節省更多對部分指望結果作調整的時間投入

最後想說的是，這個小工具的設計思路遠比實現更重要，不管使哪一種語言或庫均可以實現解析文件和代碼的生成，重要得是按照怎樣的思路去生成腳本，在這部分上後續咱們也有不少須要摸索的地方。

手把手教你開發一個 Webpack Loader

Android.Arch.Paging: 分頁加載的新選項

React Native 網絡層分析

如何實現VM框架中的數據綁定

探索自動化測試的高效執行返回搜狐，查看更多