关于接口自动化测试的规则说明
接口自动化框架一共分为3层:base层,api层,case层
1. base层
1.1 helper.py文件:
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
1 JsonHelper:提取json信息的方法 2 MysqlHelper:连接mysql的方法 3 TimeHelper:与时间相关的方法,如获取当前时间或时间戳 4 StringHelper:与字符串相关的方法,如随机生成一个字符串 5 AllureHelper:与allure相关的方法,用例断言方法。
1.2 request.py文件:模拟http请求
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
1 通过python的requests库对常用的http请求方法和请求类型进行了封装。 2 每个请求返回的消息体为一个数据字典,其包含有请求参数,响应参数及其他一些必要的参数。 3 如果http响应码为常见的错误码,则会抛出异常或直接退出程序。
1.3 decorators.py文件:定义装饰器
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
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类:数据提交类,数据呈现类,衍生类。
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
1 数据提交类:向数据库写入数据的接口。如新增,编辑,删除。 2 数据呈现类:向数据库读出数据的接口。如查询。 3 衍生类:针对上面两类接口的业务细化。如数据提交类中有一个添加人员的接口,而衍生类的接口会继续对添加人员的接口进行封装,进而封装出添加平台管理员,添加运营人员,添加商场员工等接口。
4. 每个接口的业务返回码分为3类:成功业务码,已知异常业务码,未知异常业务码。
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
1 成功业务码:默认返回api请求成功后的所有参数信息。也支持精确返回某个参数值。 2 已知异常业务码:默认返回接口的异常信息。也支持抛出异常。 3 未知异常业务码:直接抛出异常。
5. 函数入参的命名规范:时间参数,列表类参数,编辑类参数,设定默认参数
![](https://images.cnblogs.com/OutliningIndicators/ContractedBlock.gif)
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