让测试告别点点点:ZadigX 全流程自动化测试解决方案

原创
2023/06/27 14:17
阅读数 2.7K

01、测试行业现状分析

快速获得反馈以了解在软件交付生命周期内更改所产生的影响,是构建高质量软件的关键。以前,团队依靠人工测试和代码检查来验证系统的正确性。此类检查和测试工作通常在开发完成后的一个单独阶段进行。然而,这种方法存在一些缺点:

  1. 手动回归测试耗时且费用高昂,成为整个流程中的瓶颈,导致无法频繁发布软件,开发者无法快速获得反馈。
  2. 人工检查和测试不可靠,人们在手动回归测试等重复性任务中通常表现不佳,并且很难通过检查来预测复杂软件系统的更改会产生什么样的影响。
  3. 开发者必须等待很长时间才能获取其更改的相关反馈,并且需要大量工作来对缺陷进行分类和修复。性能、安全性和可靠性问题通常需要进行设计更改,如果在此阶段发现这些问题,费用更高。
  4. 较长的反馈周期让开发者难以了解如何构建质量代码,质量有时会被视为“其他人的问题”。
  5. 开发者不负责测试自己的代码,很难了解如何编写可测试的代码。
  6. 对于不断改进的系统,及时更新测试文档需要大量的努力。

相反,团队应该:

  • 在软件交付生命周期内持续执行所有类型的测试。

  • 创建并定制快速可靠的自动化测试套件,在持续交付流水线[1]中运行自动化测试。

ZadigX 具备管理软件开发全生命周期能力,几乎支持市面上所有测试工具和服务、以及平台系统,同时支持多种测试框架和不同的测试类型,通过强大的运行时环境治理和自定义工作流能力,为测试团队提供强有力的工程支撑

ZadigX 帮助测试团队,将测试服务和能力左移、右移到开发团队、运维团队等全生命周期中,尽早发现问题,让其他角色也参与到质量建设中来,规避因修复此类问题而造成额外成本。

02、持续测试实践思路

持续测试[2]是一种具体的工程实践,旨在确保系统在可靠性、安全性、操作性能和可用性方面的稳定性。它涵盖了多种测试类型,包括左移测试、右移测试、冒烟测试、单元测试、集成和消息传递测试、性能测试、功能测试、回归测试和用户验收测试等等。将持续测试[3]融入 ZadigX 的整个 DevOps 流程,能够实现高效的业务部署、快速发现和修复错误、改善用户体验,并最小化业务中断的成本。

03、用 ZadigX 落地持续测试

编排不同测试类型

静态代码扫描 

支持主流的静态安全工具例如 SonarQube、Coverity,和任何自定义扫描工具。

如何配置:以 SonarQube 示例,新增代码扫描,指定扫描工具 <SonarQube>,配置待扫描的代码库、扫描脚本,开启质量门禁检查并配置触发器,具体的配置步骤可参考文档:如何配置静态代码扫描[4]。

如何编排:编辑自定义工作流,在指定阶段(比如:构建之前)添加<代码扫描>任务即可。

单元测试

支持对 Java、Golang、Python、C++、JavaScript、C#、PHP、Ruby 等各种语言的技术栈执行单元测试

如何配置:新增测试,配置基本信息、代码信息和测试脚本,在<测试报告配置>中指定报告目录,添加触发器配置并增加 IM 通知,具体的配置步骤可参考文档:如何配置测试[5]。

如何编排:编辑自定义工作流,在指定阶段(比如:部署之后,执行自动化测试)添加<测试>任务即可。

集成测试

支持的测试类型包括但不限于:API 接口测试、UI 测试、端到端测试、压力测试、场景测试...

配置过程和单元测试类似,此处不再赘述。具体编排:编辑自定义工作流,添加<测试>任务并填写配置,以下图示例说明参数:

  • 任务名称:根据实际语义配置,比如 apitest-for-service

  • 任务类型:选择服务测试

  • 服务组件:选择待测试的服务组件,配置服务组件和测试的关联,当部署服务后将会运行指定的测试

此外,为自定义工作流配置触发器和通知,实现基于代码变更自动运行测试、测试结果及时同步 IM。参考文档:触发器配置[6]、通知配置[7]。

系统测试

支持产品级别的测试,对产品进行全面的系统测试,从整体充分把握系统质量。测试配置中的任务类型选择<产品测试>,其他的配置和集成测试类似,此处不再赘述。

 

运行持续测试场景

开发阶段:静态扫描打基础

流程:代码实现 > 代码提交 > 自动触发静态代码扫描质量门禁 > 开发人员及时获得反馈 > 有的放矢改进

代码开发完毕提交 PR 后会自动触发代码扫描执行,可有效拦截未通过质量门禁的代码变更。扫描结果会自动 comment 在代码变更中,开发人员可点击快速获得扫描结果,针对反馈进一步优化代码。从代码源头来规避质量风险,做到 fail fast > feedback fast > fix fast。

测试阶段:组合策略赋能力

流程:静态扫描(开启质量门禁) > 构建 > 部署 > 自动化测试 > IM 通知

ZadigX 可一键拉起独立的开发、测试环境(参考文档:创建环境[8]),只需要将测试编排进自定义工作流中就可以实现在开发环境、测试环境分别建设自动化测试套件,将测试能力编排进团队日常合作的每一个环节中:

  • 开发自测阶段,更新开发自测环境并执行自动化测试。

  • 多名开发联调测试阶段,可以将多人的改动同时部署更新进行集成测试验证。

  • 测试工程师验收阶段,可在 ZadigX 中分析测试报告,并根据覆盖情况持续补充自动化用例集,确保自动化测试套件与业务功能一同迭代,持续为团队提供价值,测试工程师的能力也在平台中得到充分展现。

此外,工作流运行结果可及时通知到 IM 群中,团队内每个人都能及时感知自动化执行情况,为质量负责。

 

发布阶段:多重保障保质量

流程:发布质量门禁 > 发布委员会人工审核 > 分批次灰度发布 > 系统测试 > IM 通知

测试验收通过后进行发布上线操作,建议几种配置策略:

  1. 建设发布门禁,通过自定义任务自动获取安全扫描、单元测试、集成测试等质量结果来判断是否允许上线,作为上线过程的卡点,确保版本验收通过并且符合质量要求后再做上线操作。

  2. 灵活编排蓝绿、金丝雀、分批次灰度、Istio 等发布策略,以确保发布可靠性,可参考:发布工作流[9]。

  3. 发布工作流适当增加测试团队人工审批,以确保业务流程上的发布合规性。

04、One More Thing:如何度量持续测试效果

任何实践都要讲求投入产出比,而持续测试的效果可以通过:测试的编写人员比例,发现的 Bug 数量,自动化测试的有效性,以及是否在 CI/CD 中运行自动化测试来衡量等方面来度量,具体如下:

05、小结

通过 ZadigX 支撑持续测试和自动化测试的实施,帮助测试团队更好地应对当前的测试行业挑战,确保软件交付的质量和稳定性,提高开发和交付过程的效率。

参考链接

阅读原文 https://mp.weixin.qq.com/s/meO6yqzZdMQfBoEsAcr1Ig

[1]持续交付流水线:https://continuousdelivery.com/implementing/patterns/#the-deployment-pipeline

[2]持续测试:https://cloud.google.com/architecture/devops/devops-tech-test-automation

[3]持续测试:https://www.ibm.com/cn-zh/topics/continuous-testing

[4]如何配置静态代码扫描:https://docs.koderover.com/zadig/ZadigX%20v1.5.0/project/scan/

[5]如何配置测试:https://docs.koderover.com/zadig/ZadigX%20v1.5.0/project/test/

[6]触发器配置:https://docs.koderover.com/zadig/ZadigX%20v1.5.0/project/common-workflow/#触发器配置

[7]通知配置:https://docs.koderover.com/zadig/ZadigX%20v1.5.0/project/common-workflow/#通知配置

[8]创建环境:https://docs.koderover.com/zadig/ZadigX%20v1.5.0/project/env/k8s/

[9]发布工作流:https://docs.koderover.com/zadig/ZadigX%20v1.5.0/project/release-workflow/

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
0 评论
1 收藏
0
分享
返回顶部
顶部