标签：状态   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   软件环境

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