关于接口自动化测试的规则说明

接口自动化框架一共分为3层:base层,api层,case层

1. base层

1.1 helper.py文件:

1 JsonHelper:提取json信息的方法
2 MysqlHelper:连接mysql的方法
3 TimeHelper:与时间相关的方法,如获取当前时间或时间戳
4 StringHelper:与字符串相关的方法,如随机生成一个字符串
5 AllureHelper:与allure相关的方法,用例断言方法。
常用功能介绍

1.2  request.py文件:模拟http请求

1 通过python的requests库对常用的http请求方法和请求类型进行了封装。
2 每个请求返回的消息体为一个数据字典,其包含有请求参数,响应参数及其他一些必要的参数。
3 如果http响应码为常见的错误码,则会抛出异常或直接退出程序。
http请求封装内容

1.3 decorators.py文件:定义装饰器

1 retry_common_api装饰器:在一些场景下,调用common_api时可能会随机触发到接口的异常使用场景,从而会影响到测试用例的执行。使用此装饰器后,可以捕获到已知的的业务异常,并重新执行此api。
2 allure_attach装饰器:将接口的所有相关信息加工后返回给allure在报告中做数据呈现。
3 wait_until装饰器:有些情况下,数据写入数据库动作较慢。导致调用查询接口时,并没有及时得到期望结果。使用此装饰器后,在规定时间内可以快速灵活的返回查询的数据内容。
装饰器功能说明

2. api层

api层又可分为base api层和common api层。

2.1 base层封装

规则说明:

1. base层中接口的业务参数命名规则:必填选填_参数类型_参数名称

2. 对于每个api的返回内容都会使用@allure.step标签,以便在allure报告中做内容呈现。

3. base层的代码一般都可以通过辅助工具来自动生成。

2.2 common层封装

规则说明:

1. common层api会继承base层api;必要情况下需要从数据库获取相关信息来辅助common层的封装。

2. 每个业务模块会对应一个py文件。common_api.py会继承所有业务模块的py文件,并提供给case层使用。

3. 每个业务模块的接口分为3类:数据提交类,数据呈现类,衍生类。

1 数据提交类:向数据库写入数据的接口。如新增,编辑,删除。
2 数据呈现类:向数据库读出数据的接口。如查询。
3 衍生类:针对上面两类接口的业务细化。如数据提交类中有一个添加人员的接口,而衍生类的接口会继续对添加人员的接口进行封装,进而封装出添加平台管理员,添加运营人员,添加商场员工等接口。
接口分类说明

4. 每个接口的业务返回码分为3类:成功业务码,已知异常业务码,未知异常业务码。

1 成功业务码:默认返回api请求成功后的所有参数信息。也支持精确返回某个参数值。
2 已知异常业务码:默认返回接口的异常信息。也支持抛出异常。
3 未知异常业务码:直接抛出异常。
接口业务码分类说明

5. 函数入参的命名规范:时间参数,列表类参数,编辑类参数,设定默认参数

1 时间参数:
    startDateTime: 2019-09-06 00:00:00     # 可设置默认
    endDateTime: 2019-09-06 23:59:59      # 可设置默认            
    startDate: 2019-09-06
    endTime: 23:59:59
2 列表类接口中以list_开头的参数
    list_pageNo        # 列表页码,默认为1
    list_pageSize        # 列表页大小,默认为20
    list_order        # 列表排序
3 编辑类接口: 
    以edit_开头的参数,代表可编辑的接口参数
    可编辑参数的默认值来源于接口详情或接口列表信息
参数命名规范说明

2.3 api的应用场景说明

1. 场景1:做接口字段级的参数校验

    使用方法:在case层直接调用api层下的base_api.py文件下的函数

2. 场景2:业务的反向用例

    使用方法:在case层直接调用api层下的common_api.py文件下的函数,且参数business_exception=False。

3. 场景3:业务的正向用例或用例的前置条件

    使用方法:在case层直接调用api层下的common_api.py文件下的函数,且参数business_exception=True。此时在retry_common_api装饰器的修饰下,可以排除接口已知业务异常对测试用例的干扰。

3. case层

3.1 用例设计的规则说明

1. 用例集分层:分为字段级用例,模块级用例、场景用例。

2. 测试用例内分层:通过allure.step注释来实现测试步骤的分层。

3. 每个用例都必须使用allure的feature,story标注,根据情况添加description标注。

4. 用例函数名的命名规范:test_用例标题。

5. 用例等级分为3类:blocker,normal,minor。

3.2 用例步骤的复用方法

1. 前置条件的复用:接口的测试依赖问题尽量通过pytest的fixture或conftest来解决。

2. 后置条件的复用:使用频率高的用例步骤,单独封装到utils中。命名规则:positive_* 和 negative_*

3.3 注意事项

1. 用例测试点的耦合度要尽量低,一个用例不要涉及太多的测试点

2. 对于复杂接口需要做适当拆分。保证用例的可读性和可维护性

3. 基于模块级别的前置条件,需要进行合理的设计。

4. 辅助功能

4.1 自动生成api层的模板代码。

1. 首先在yaml_dir目录下编写接口信息的yaml文件。

2. 执行辅助命令后,将临时区的代码拷贝到需要的位置。

4.2 业务数据的参数化

1. 业务数据分为固定业务参数和随机业务参数。

2. 固定业务数据:存放在testdata/fixed_businessData.py

3. 随机业务数据:存放在testdata/gen_businessData.py

posted @ 2019-09-08 23:14  后来者2012  阅读(1090)  评论(0编辑  收藏  举报