标签：状态 photo dep 一个 效率 code chm ids 范围
1.2 介绍
基于 Python 开发的测试框架 httprunner为核心，Jenkins 实现持续集成，并选取 Python3.X 作为编程语言实现。
1.2 httprunner介绍
HttpRunner 是一款面向 HTTP(S) 协议的通用测试框架，只需编写维护一份 YAML/JSON 脚本，即可实现自动化测试、性能测试、线上监控、持续集成等多种测试需求。
1.3 httprunner设计理念
- 充分复用优秀的开源项目，不追求重复造轮子，而是将强大的轮子组装成战车
- 遵循 约定大于配置 的准则，在框架功能中融入自动化测试最佳工程实践
- 追求投入产出比，一份投入即可实现多种测试需求
1.4 httprunner核心特性
- 继承 Requests 的全部特性，轻松实现 HTTP(S) 的各种测试需求
- 采用 YAML/JSON 的形式描述测试场景，保障测试用例描述的统一性和可维护性
- 借助辅助函数（py），在测试脚本中轻松实现复杂的动态计算逻辑
- 支持完善的测试用例分层机制，充分实现测试用例的复用
- 测试前后支持完善的 hook 机制
- 响应结果支持丰富的校验机制
- 基于 HAR 实现接口录制和用例生成功能（har2case）
- 结合 Locust 框架，无需额外的工作即可实现分布式性能测试
- 执行方式采用 CLI 调用，可与 Jenkins 等持续集成工具完美结合
- 测试结果统计报告简洁清晰，附带详尽统计信息和日志记录
- 极强的可扩展性，轻松实现二次开发和 Web 平台化
1.5 项目目录结构
1.6 项目文件说明
在 HttpRunner 自动化测试项目中，主要存在如下几类文件：
- YAML/JSON（必须）：测试用例文件，存储接口测试相关信息
- debugtalk.py（可选）：存储项目中逻辑运算辅助函数
- 该文件存在时，将作为项目根目录定位标记，其所在目录即被视为项目工程根目录
- 该文件不存在时，运行测试的所在路径（CWD）将被视为项目工程根目录
- 测试用例文件中的相对路径（例如.csv）均需基于项目工程根目录
- 运行测试后，测试报告文件夹（reports）会生成在项目工程根目录
- .env（可选）：存储项目环境变量，通常用于存储项目敏感信息
- .csv（可选）：项目数据文件，用于进行数据驱动
- reports：默认生成测试报告的存储文件夹
1.7 测试用例结构
在 HttpRunner 中，测试用例组织主要基于三个概念：
- 测试用例集（testsuite）：对应一个文件夹，包含单个或多个测试用例（YAML/JSON）文件
- 测试用例（testcase）：对应一个 YAML/JSON 文件，包含单个或多个测试步骤
- 测试步骤（teststep）：对应 YAML/JSON 文件中的一个 test，描述单次接口测试的全部内容，包括发起接口请求、解析响应结果、校验结果等
1.8 测试用例分层机制
2. 接口自动化实施目标
2.1 实施原则
ECHO采用接口自动化测试，主要目的是为了应对迭代版本测试过程中的重复工作任务，以期达到效果如下：
- 降低测试成本
- 提高测试效率
- 更频繁地执行覆盖重要接口
- 提供更高的准确性和一致性
- 节约时间成本
虽然能达到上述预期效果，但实际实施过程中需要注意的是，接口自动化的高效应用，对于被测系统有着更高的要求，也需要遵循合理的方法流程，现总结如下：
- 接口自动化的实施应该被用于解决测试过程中高重复性的工作，很大一部分是用于回归测试旧的功能接口，否则其本身工作量投入会大于其收益，所以不能盲目对所有接口或功能追求自动化。
- 对于提测版本，自身稳定性需要有一定程度的保障。过于频繁的接口变动，会加大后续接口自动化的实施难度，增加自动化脚本维护地成本。
- 接口自动化的整体实现应采用分步进行，测试过程中优先覆盖功能稳定且比较重要的接口，进而逐步扩展到整体项目的接口回归。
- 接口自动化测试是一个长期的过程，随着项目版本的不停迭代优化，项目本身的接口也会不断优化或新开发，所以后续自动化测试脚本的代码维护和调优也具有可观的工作量。
2.2 接口自动化测试思路
- 理解接口参数，熟悉接口参数输入要求、输入范围、必填项等；
- 理解接口输出，熟悉返回json的结构构成、返回值类别、返回data类型等；
- 理解接口的逻辑、接口的业务关联，熟悉技术方案中的接口相互关联、依赖关系，接口与接口之间的数据传递等；
- 规划测试用例，根据输入、输出、关联关系，进行用例设计，具体可参考3.1和2.3.2
2.2.1 通用场景测试
对于接口测试的入参需考虑以下几个方面，设计用例需要考虑交叉的情况：
测试参数名称的正确性
测试参数值的正确性
2.2.2 逻辑场景
基于使用场景及接口逻辑关系，设计用例。例如：停止作业运行接口，设计场景如下：
登录-新建作业-添加数据源-添加目标-建立映射-发布-运行-停止运行
2.2.3 断言检查
对接口的返回结果进行核对，一般为：状态码、msg等。
例如，登录接口返回结果：
{‘code‘: ‘SUCCESS‘, ‘data‘: {‘department‘: ‘q‘, ‘email‘: ‘1111111@qq.com‘, ‘gender‘: 1, ‘id‘: 131, ‘mobile‘: ‘11111111111‘, ‘password‘: ‘E29CE3B2D57AE4E82D1875F2221F49C5‘, ‘phone‘: ‘111‘, ‘photo‘: ‘‘, ‘roleIds‘: ‘‘, ‘roles‘: [], ‘serialNumber‘: ‘‘, ‘trueName‘: ‘系统管理员‘, ‘type‘: ‘FRONT‘, ‘username‘: ‘admin‘}, ‘execTime‘: 1, ‘key‘: ‘‘, ‘msg‘: ‘登录成功‘, ‘params‘: [], ‘timestamp‘: ‘2019-12-19 10:33:04‘}
2.3 接口自动化测试范围
2.3.1 接口测试的主要内容
接口测试的主要内容如下，如果进行全面的测试，需要详细的接口文档
2.3.2 自动化测试范围
业务功能测试的正常场景测试
2.3.3 自动化测试阶段
|
自动化实施阶段
|
被测模块
|
备注
|
|
第一阶段
|
|
|
|
第二阶段
|
|
|
|
第三阶段
|
|
|
2.4 自动化测试计划
风险：无详细接口文档、未做接口手工测试，不熟悉接口参数，会导致自动化代码调试时间增加
|
阶段
|
计划时间
|
输入
|
输出
|
备注
|
|
测试计划
|
|
|
|
|
|
接口文件导出
|
|
|
|
|
|
测试用例编写
|
|
|
|
|
|
接口测试用例编写
|
|
|
|
|
2.4.1 用例设计
调度子系统接口尚未添加
3. 测试环境需求
3.1 硬件环境
目前暂未涉及到性能相关或者需要分布式执行的内容，因此对硬件要求不是很高，日常办公硬件即可。如果后续有涉及性能相关内容，硬件环境需要再另外的性能测试方案中体现。
3.2 软件环境
|
软件相关
|
版本号
|
备注
|
|
Python
|
V3.6.5
|
|
|
PyChram
|
V2019.1.2
|
|
|
httprunner
|
v2.3.3
|
更换测试报告模板需要修改report.py源代码
|
|
pymysql
|
/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3.3 测试环境
根据产品特性，需要准备多种数据库以及测试用的数据。该环境应尽量稳定。
疑问
新开发的接口+echo原有接口
接口文档尚未整理。建议一：开发整理接口文档；建议二：开发整理接口列表，测试人员熟悉功能使用——调试接口——形成接口自动化脚本
优缺点：后者的接口测试不够严谨，并不知晓接口设计的规范，如必填项、参数长度限制等
用例场景设计完全、时间计划
详见计划。
接口覆盖统计，100%
测试范围：仅测试接口是否正常使用，接口的容错性未作测试
后期丰富接口测试范围，对详细功能指标的覆盖率暂时不易统计
目前没有详细的接口文档。常规的是根据接口文档编写接口测试用例，从中找出可以自动化的用例，计算接口自动化测试和手工测试的占比
建议：完善接口文档——编写接口测试用例——手工测试——自动化测试；
功能指标颗粒度
例如：转换器分为字符串、拆分字段、去重等。字符串操作又可分为1 去除空格 2 大小写 3 填充 4 首字母大写 5 是否数字 6 转义符 7 删除特殊字符
测试报告样例
测试报告附件
附录
接口列表
接口自动化测试选型-httpRunner
标签：状态 photo dep 一个 效率 code chm ids 范围
原文地址：https://www.cnblogs.com/l7planet/p/12458009.html