作者：陈爱娇 编辑：毕小烦

自动化本身是为了提高工作效率，不论选择何种框架，何种开发语言，我们最终想实现的效果，就是让大家用最少的代码，最小的投入，完成自动化测试的工作。

基于这个想法，我们的接口自动化测试思路如下：

  1. 不变的内容全部通过配置化来实现，比如：脚本执行的环境、请求的 HOST、URL 路径、测试数据等；
  2. 环境和数据关联变更：依据不同的环境，选择不同的配置及对应的测试数据；
  3. 抽取公共方法，避免冗余代码；
  4. 场景化的用例，实现可配置化；
  5. 数据驱动；

    一. 问题

    在做自动化的过程中，不能只考虑单接口的脚本，也要考虑场景化的用例。 场景化的用例不需要每个步骤都去校验所有的数据，可能更多看重串联后的最终效果。

那什么是场景用例？

其实就是多个接口组成的业务场景，常规写代码的做法是，先调用接口 1，验证结果， 再调用接口 2，再继续接口 3，… 等等； 在测试场景中，可能只是各个接口的入参不一样，或者是调用的接口不一样。这样代码写起来就会冗余。

比如：

  1. def test_01(self):
  2.     # step 01
  3.     result1 = PackDemo().getTest()
  4.     assert result1 == 4
  6.     # step02
  7.     result2 = PackDemo2().getTest2("name")
  8.     assert result2 == 'name'
  10.     # step03
  11.     result3 = DemoApi().getTest()
  12.     assert result3 == 2

这样的用例，对于简单的接口没什么问题，但是对于复杂的接口，校验逻辑比较多，或者入参比较多，实现的方式就过于单一了。且不同场景的话，每个都要更改调用的步骤和返回值，场景越多冗余越多。

如果使用配置化的方式，每次从配置文件中动态加载配置的场景用例， 而且能够做到加载后做对应的断言，那该多好。

怎么做呢？

咱们看看一些核心的实现。

二. 方案

2.1 项目结构

项目结构如下：
如何实现基于场景的接口自动化测试用例？ - 图1
采用当前比较流行的 Python + Pytest + Allure 来实现，具体结构不做展开。

2.2 场景用例的配置数据

  1. # test_scenario.json
  2. {
  3.   "test_01": {
  4.     "step_1": {  ---- 步骤节点名称，可自定义
  5.       "packagePath": "api", --- 这个步骤要运行的方法所属类的包路径
  6.       "class": "DemoApi", --- 这个步骤要运行的方法所属类名称
  7.       "method": "getTest", --- 这个步骤要运行的方法名称
  8.       "request": null,  ---这个步骤运行的方法入参
  9.       "response": 2, ---这个步骤运行的结果，可以是一个值，或者对象
  10.       "verify": { --- 数据校验的节点
  11.         "type": 1, ---数据校验的类型
  12.         "keys": null  ---如果是校验的特定字段，这里需要输入部分校验的字段
  13.       }
  14.     },
  15.     "step_2": {
  16.       "packagePath": "api.demo",
  17.       "class": "PackDemo",
  18.       "method": "getTest2",
  19.       "request": "request -> name",
  20.       "response": 6,
  21.       "verify": {
  22.         "type": 1,
  23.         "keys": null
  24.       }
  25.     },
  26.     "step_3": {
  27.       "packagePath": "api.demo",
  28.       "class": "PackDemo2",
  29.       "method": "getTest3",
  30.       "request": {
  31.         "name": "param-name",
  32.         "num_list": ["a", "b", "c"]
  33.       },
  34.       "response": 8,
  35.       "verify": {
  36.         "type": 1,
  37.         "keys": null
  38.       }
  39.     }
  40.   }
  41. }

2.3 动态加载类

在我们配置了以上的测试场景的数据后，我们希望在用例执行的过程中，通过获取我们的配置，能够动态的加载数据文件中提到的方法，并执行对应的方法，那这个过程的实现我们主要通过如下的动态加载类来实现。

  1. # DynamicLoad.py 
  2. # 部分主要的摘录如下
  3.  def __load_module(self):
  4.         """
  5.         加载对应路径下的模块
  6.         :param package_path: 包路径
  7.         :param class_name: 类名称
  8.         :return:
  9.         """
  10.         return importlib.import_module("." + self.class_name, package=self.package_path)
  12. def __getClassInstance(self):
  13.     """
  14.     加载对应的模块下的类，并返回对应类的实例 
  15.     :param module_name: 对应的模块
  16.     :param class_name:
  17.     :return:
  18.     """
  19.     self.my_module = self.__load_module()
  20.     self.my_class = getattr(self.my_module, self.class_name)()
  21.     return self.my_class
  23. def execMethod(self, method, *args):
  24.     """
  25.     加载对应类下的方法 
  26.     :param instance: 对应的实例
  27.     :param method: 要执行的方法
  28.     :return:
  29.     """
  30.     result = getattr(self.__getClassInstance(), method)(*args)
  31.     return result

有了以上动态加载的方法后，在执行场景用例时，依据上述的方法，就可以执行测试文件中提到的方法。

2.4 场景分析类

在场景用例的测试数据中，除了需要解析需要执行的类、方法外，还要解析文件中涉及到的出入参及数据比对方式，因此，这里还需要一个场景分析类，来解析数据文件中关于具体执行过程的配置。

  1.  #ScenariosAnalyze.py
  2.  def analyse_exe_scenario(self, case_data):
  3.         step_result = {}
  4.         summary = True
  5.         for i in case_data:
  6.             instance = DynamicLoad(case_data[i]['packagePath'], case_data[i]['class'])
  7.             if case_data[i]['request'] is not None:
  8.                 result = instance.execMethod(case_data[i]['method'], case_data[i]['request'])
  9.             else:
  10.                 result = instance.execMethod(case_data[i]['method'])
  11.             if case_data[i]['verify'] is not None:
  12.                 compare_type = case_data[i]['verify']['type']
  13.                 keys = case_data[i]['verify']['keys']
  14.                 step_compare_result = DataCompare().compare_type(compare_type=compare_type, actual=result,
  15.                                                                  expect=case_data[i]['response'], keys=keys)
  16.                 if not step_compare_result:
  17.                     summary = False
  18.             step_result[i] = step_compare_result
  19.         step_result['summary'] = summary
  20.         return step_result

2.5 用例实现

  1. # @File : test_scenario.py
  3. class TestScenario:
  5.     @allure.story('场景用例01')
  6.     @allure.severity(allure.severity_level.BLOCKER)
  7.     @pytest.mark.smoke
  8.     def test_01(self):
  9.         result = None
  10.         case_data = self.test_data_json['test_01']
  11.         result = self.scenario_analyze.analyse_exe_scenario(case_data)
  12.         assert result['summary'] is True

通过上述简单的脚本调用，就可以完成一个场景用例的测试了。

三. 小结

以上就是场景用例配置化的实现思路。

它的优点是：

  1. 配置化： 一切固定不变的内容全部配置化，最终达到：一个环境配置文件，一套脚本，几套测试数据，依据环境的不同选择不同的测试数据执行对应的测试脚本；
  2. 门槛低：因为配置化，测试同学只要把测试数据文件中的关键节点配置好，然后在脚本中写下调用方法，就完成用例编写了；
  3. 好扩展：在后续的实现中，可以将这些配置全部页面化，包括环境、数据、脚本，达到无代码开发的目的；

缺点当然是不够灵活，所以没有完美的方案，只有合适的，以上，仅供大家参考。

（完）
微信搜索“毕小烦”或者扫描下面的二维码，即可订阅我的微信公众号。
image.png
如果文章对你有帮助，记得留言、点赞、加关注哦！