- 最新动态
- 功能总览
- 产品介绍
- 快速入门
-
用户指南
- 测试计划服务(CodeArts TestPlan)使用流程
- 开通CodeArts TestPlan服务
- 访问CodeArts TestPlan服务首页
- 配置CodeArts TestPlan测试计划
- 配置CodeArts TestPlan测试版本
-
配置CodeArts TestPlan测试用例
- CodeArts TestPlan生成测试用例方式介绍
- 通过思维导图创建测试用例
- 创建手工测试用例
-
创建接口自动化测试用例
- CodeArts TestPlan接口自动化用例使用流程
- 创建CodeArts TestPlan接口自动化测试用例模板
- 使用自定义URL请求添加CodeArts TestPlan接口脚本
- 使用Postman快速添加CodeArts TestPlan接口脚本
- 使用cURL快速添加CodeArts TestPlan接口脚本
- 使用关键字库快速添加CodeArts TestPlan接口脚本
- 添加CodeArts TestPlan接口脚本的逻辑控制步骤
- 设置CodeArts TestPlan接口脚本的测试用例参数
- 设置CodeArts TestPlan接口脚本的环境参数
- 导入CodeArts TestPlan接口自动化用例测试数据集
-
接口自动化用例内置函数说明
- 在CodeArts TestPlan中调用二元加法运算函数
- 在CodeArts TestPlan中调用二元减法运算函数
- 在CodeArts TestPlan中调用二元乘法运算函数
- 在CodeArts TestPlan中调用二元除法运算函数
- 在CodeArts TestPlan中调用获取当前时间戳函数
- 在CodeArts TestPlan中调用获取指定时间戳函数
- 在CodeArts TestPlan中调用日期转时间戳函数
- 在CodeArts TestPlan中调用时间戳转日期函数
- 在CodeArts TestPlan中调用时间戳加减运算函数
- 在CodeArts TestPlan中调用生成Base64编码函数
- 在CodeArts TestPlan中调用生成SHA512编码函数
- 在CodeArts TestPlan中调用生成SHA256编码函数
- 在CodeArts TestPlan中调用生成MD5哈希值函数
- 在CodeArts TestPlan中调用生成指定范围随机数函数
- 在CodeArts TestPlan中调用生成指定长度随机字符串函数
- 在CodeArts TestPlan中调用指定范围随机生成小数函数
- 在CodeArts TestPlan中调用生成UUID函数
- 在CodeArts TestPlan中调用倒序索引提取数组函数
- 在CodeArts TestPlan中调用倒序索引提取数组元素的值函数
- 在CodeArts TestPlan中调用大写转小写函数
- 在CodeArts TestPlan中调用小写转大写函数
- 在CodeArts TestPlan中调用字符串拼接函数
- 在CodeArts TestPlan中调用字符串切割函数
- 在CodeArts TestPlan中调用获取字符串长度函数
-
接口自动化用例系统关键字说明
- 系统关键字概述与一览表
- 在CodeArts TestPlan接口脚本中调用GetIAMToken关键字
- 在CodeArts TestPlan接口脚本中调用MySQLQuery关键字
- 在CodeArts TestPlan接口脚本中调用MySQLUpdate关键字
- 在CodeArts TestPlan接口脚本中调用MySQLInsert关键字
- 在CodeArts TestPlan接口脚本中调用MySQLDelete关键字
- 在CodeArts TestPlan接口脚本中调用OpenGaussQuery关键字
- 在CodeArts TestPlan接口脚本中调用OpenGaussUpdate关键字
- 在CodeArts TestPlan接口脚本中调用OpenGaussInsert关键字
- 在CodeArts TestPlan接口脚本中调用OpenGaussDelete关键字
- 在CodeArts TestPlan接口脚本中调用PostgreSQLQuery关键字
- 在CodeArts TestPlan接口脚本中调用PostgreSQLUpdate关键字
- 在CodeArts TestPlan接口脚本中调用PostgreSQLInsert关键字
- 在CodeArts TestPlan接口脚本中调用PostgreSQLDelete关键字
- 在CodeArts TestPlan接口脚本中调用MongoDBQuery关键字
- 在CodeArts TestPlan接口脚本中调用MongoDBInsert关键字
- 在CodeArts TestPlan接口脚本中调用MongoDBUpdate关键字
- 在CodeArts TestPlan接口脚本中调用MongoDBDelete关键字
- 在CodeArts TestPlan接口脚本中调用RedisGet关键字
- 在CodeArts TestPlan接口脚本中调用RedisSet关键字
- 在CodeArts TestPlan接口脚本中调用OBSWrite关键字
- 在CodeArts TestPlan接口脚本中调用OBSDelete关键字
- 在CodeArts TestPlan接口脚本中调用OBSQuery关键字
- 在CodeArts TestPlan接口脚本中调用KafkaProducer关键字
- 在CodeArts TestPlan接口脚本中调用KafkaConsumer关键字
- 在CodeArts TestPlan接口脚本中调用TCP关键字
- 在CodeArts TestPlan接口脚本中调用UDP关键字
- 在CodeArts TestPlan接口脚本中调用WSConnect关键字
- 在CodeArts TestPlan接口脚本中调用WSRequest关键字
- 在CodeArts TestPlan接口脚本中调用WSWriteOnly关键字
- 在CodeArts TestPlan接口脚本中调用WSReadOnly关键字
- 在CodeArts TestPlan接口脚本中调用WSDisConnect关键字
- 在CodeArts TestPlan接口脚本中调用DubboClient关键字
- 执行CodeArts TestPlan测试用例
- 管理CodeArts TestPlan测试用例
- 创建与执行CodeArts TestPlan测试套件
- 查看与评估CodeArts TestPlan测试质量
- 配置CodeArts TestPlan全局配置项
- API参考
- 最佳实践
- 常见问题
- 视频帮助
- 通用参考
链接复制成功！
测试金字塔和持续自动化测试
敏捷和DevOps开发模式下，产品要具备随时可发布的能力，本文介绍如何应用测试金字塔和CI/CD持续自动化测试实现高效的测试反馈，保障随时发布产品的质量。
测试金字塔
自动化测试金字塔最早是由Mike Cohn在2009年的著作《Succeeding with Agile: Software Development using Scrum 》（《Scrum敏捷软件开发》）中提出。最早提出来的时候是一个三层的金字塔，从上到下分别是UI界面/Service服务/Unit单元测试，随着敏捷测试的不断推进，测试金字塔出现一些变种。实际使用中不用太拘泥于每层的名字，在服务化软件架构中Service层也可以理解为API测试。
这种下宽上窄的三角形结构，代表在各层自动化的建议投入分配比例，越接近底层的单元测试建议的投入最多，接口测试居中，界面层建议的投入最少。
Martin Fowler关于测试金字塔有这样一段评论：“GUI测试用例还很脆弱，如对系统的一些修正可能导致很多用例的失败，这时候你需要重新录制。你可以放弃录制的方法来解决这个问题，通过写GUI测试代码，但是这样效率非常低。就算你已经很精通了GUI测试代码的编写，端到端的GUI测试用例也很容易出现不可预期结果的问题，因此，基于GUI的自动化测试是脆弱、耗时（包括用例维护和执行）的。所以测试金字塔要表达的是：底层应当有更多的单元测试和接口测试和逻辑测试，GUI测试用例能覆盖到主业务流程即可。”
测试金字塔中每层中涉及的测试技术均有自己的优势和局限性，由于上层GUI测试的脆弱（不稳定性）、耗时（执行效率）问题，以及问题表现位置（UI）和问题根因位置（代码）距离太远的问题，测试金字塔由关注测试数量转向关注测试质量，推荐增加底层的测试投入。
- 层次越靠上，运行效率越低，延缓持续集成的构建-反馈循环。
- 层次越靠上，开发复杂度越高，如果团队能力受限，交付进度受影响。
- 端到端测试更容易遇到测试结果的不确定性。
- 层次越靠下，单元隔离性越强，定位分析问题越容易。
原则上单元测试需要开发人员承担，很多团队中开发人手不足，优先保障功能的实现，在单元测试的投入不够，并且很多开发人员的单元测试经验不足，导致很多团队中不做单元测试或者被动执行流于形式，有人提出了金字塔结构的反模式：蛋筒冰激凌模式和纸杯蛋糕模式。
蛋筒冰激凌模式由Alister Scott在2012年提出，金字塔中界面测试和单元测试的比例倒置形成倒金字塔，界面测试之上有大量的手工测试。反模式不是建议模式，但却是实际团队中大量存在的。团队初期没有自动化测试，完全依赖手工测试，然后从功能测试自动化入手，产生了一些界面自动化测试用例。这种由外向内进行自动化测试的建设方式，导致了这样的反模式。这样的模式在测试效率、测试用例可维护性角度讲，均存在一些问题，但又往往是很多团队自发进行测试自动化能力建设过程中的必经路径，问题积累到一定阶段需要逐步向测试金字塔方向演进。
持续自动化测试
持续自动化测试是在持续集成和持续部署过程中运行自动化测试，快速反馈失败，最早源自开发人员在开发环境中通过单元测试获取快速反馈的思想。持续自动化测试是随着CI/CD（持续集成和持续部署）发展而逐步成熟的。现实需要开发人员能够越来越快的发布产品变更，修复在线问题。如果仍然依赖原来的手工测试或者开发和测试完全分离的方式，难以保障在很短的时间窗口中完成测试质量保障活动，因此需要在CI/CD过程中嵌入自动化测试“持续”保障交付物的质量。
持续测试意味着测试活动纳入到持续集成、持续反馈、持续改进循环中，持续不断的测试，贯穿了整个软件交付周期。持续测试提倡尽早测试、频繁测试和自动化测试。
“持续”体现在贯穿了敏捷、DevOps流程中交付物由小粒度逐步演变为软件成品的全过程，从代码白盒测试，到组件模块测试、接口测试、E2E（端到端）功能测试，甚至交付之后进行生产环境的在线测试。每个阶段正好映射了测试金字塔由下向上的各层，越下层的测试在越早的阶段执行，越上层的测试在越后的阶段执行。这类似于汽车制造流水线的各个环节，每个环节的组装结束后都会进行必要的检查通过才进入到下一个环节，在软件DevOps开发过程中Pipeline流水线承载了这样的组装、检查测试过程。
