标签：状态   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