# 测试行业现状分析
快速获得反馈以了解在软件交付生命周期内更改所产生的影响，是构建高质量软件的关键。以前，团队依靠人工测试和代码检查来验证系统的正确性。此类检查和测试工作通常在开发完成后的一个单独阶段进行。然而，这种方法存在一些缺点：
- 测试流程瓶颈：手动回归测试时间长、成本高，限制了软件的快速迭代和发布。
- 测试准确性与效率：人工测试易出错，对于系统变更的影响预测不可靠，尤其在重复任务中。
- 反馈及缺陷处理：开发者等待反馈的时间长，影响缺陷的快速识别和修复，增加了后期设计更改的开销。
- 代码质量意识：反馈周期延长导致开发者难以掌握构建高质量代码的方法，质量问题容易被忽视。
- 代码测试责任：开发者不参与测试，缺乏编写易于测试代码的意识和技能。
- 测试文档更新：随着系统的持续改进，保持测试文档的更新需要投入大量精力。
相反，团队应该：
- 在软件交付生命周期内持续执行所有类型的测试。
- 创建并定制快速可靠的自动化测试套件，在持续交付流水线 (opens new window)中运行自动化测试。
Zadig 具备管理软件开发全生命周期能力，几乎支持市面上所有测试工具和服务、以及平台系统，同时支持多种测试框架和不同的测试类型，通过强大的运行时环境治理和自定义工作流能力，为测试团队提供强有力的工程支撑。
Zadig 帮助测试团队，将测试服务和能力左移、右移到开发团队、运维团队等全生命周期中，尽早发现问题，让其他角色也参与到质量建设中来，规避因修复此类问题而造成额外成本。
# 持续测试实践思路
持续测试 (opens new window)是一种具体的工程实践，旨在确保系统在可靠性、安全性、操作性能和可用性方面的稳定性。它涵盖了多种测试类型，包括左移测试、右移测试、冒烟测试、单元测试、集成和消息传递测试、性能测试、功能测试、回归测试和用户验收测试等等。将持续测试 (opens new window)融入 Zadig 的整个 DevOps 流程，能够实现高效的业务部署、快速发现和修复错误、改善用户体验，并最小化业务中断的成本。
# 用 Zadig 落地持续测试
# 编排不同测试类型
# 静态代码扫描
支持主流的静态安全工具例如 SonarQube、Coverity，和任何自定义扫描工具。
如何配置
以 SonarQube 示例，新增代码扫描，指定扫描工具 SonarQube，配置待扫描的代码库、扫描脚本，开启质量门禁检查并配置触发器，具体的配置步骤可参考文档：如何配置静态代码扫描 (opens new window)。
访问项目 -> 代码扫描，点击新建代码扫描后填写配置。
如何编排
编辑工作流，在指定阶段（比如：构建之前）添加代码扫描任务即可。
# 单元测试
支持对 Java、Golang、Python、C++、JavaScript、C#、PHP、Ruby 等各种语言的技术栈执行单元测试。
如何配置
新增测试，配置基本信息、代码信息和测试脚本，在测试报告配置中指定报告目录，添加触发器配置并增加 IM 通知，具体的配置步骤可参考文档：如何配置测试 (opens new window)。
如何编排
编辑自定义工作流，在指定阶段（比如：部署之后，执行自动化测试）添加测试任务即可。
# 集成测试
支持的测试类型包括但不限于：API 接口测试、UI 测试、端到端测试、压力测试、场景测试...
配置过程和单元测试类似，此处不再赘述。具体编排：编辑自定义工作流，添加测试任务并填写配置，以下图示例说明参数：
- 任务名称：根据实际语义配置，比如
apitest-for-service - 任务类型：选择
服务测试 - 服务组件：选择待测试的服务组件，配置服务组件和测试的关联，当部署服务后将会运行指定的测试
此外，为自定义工作流配置触发器和通知，实现基于代码变更自动运行测试、测试结果及时同步 IM。参考文档：工作流触发器 (opens new window)、工作流通知 (opens new window)。
# 系统测试
支持产品级别的测试，对产品进行全面的系统测试，从整体充分把握系统质量。
测试配置中的任务类型选择产品测试，其他的配置和集成测试类似，此处不再赘述。
# 运行持续测试场景
# 开发阶段：静态扫描打基础
流程：代码实现 > 代码提交 > 自动触发静态代码扫描质量门禁 > 开发人员及时获得反馈 > 有的放矢改进
代码开发完毕提交 PR 后会自动触发代码扫描执行，可有效拦截未通过质量门禁的代码变更。扫描结果会自动 comment 在代码变更中，开发人员可点击快速获得扫描结果，针对反馈进一步优化代码。从代码源头来规避质量风险，做到 fail fast > feedback fast > fix fast。
# 测试阶段：组合策略赋能力
流程：静态扫描（开启质量门禁） > 构建 > 部署 > 自动化测试 > IM 通知
Zadig 可一键拉起独立的开发、测试环境（参考文档：新建环境 (opens new window)），只需要将测试编排进自定义工作流中就可以实现在开发环境、测试环境分别建设自动化测试套件，将测试能力编排进团队日常合作的每一个环节中：
- 开发自测阶段，更新开发自测环境并执行自动化测试。
- 多名开发联调测试阶段，可以将多人的改动同时部署更新进行集成测试验证。
- 测试工程师验收阶段，可在 Zadig 中分析测试报告，并根据覆盖情况持续补充自动化用例集，确保自动化测试套件与业务功能一同迭代，持续为团队提供价值，测试工程师的能力也在平台中得到充分展现。
此外，工作流运行结果可及时通知到 IM 群中，团队内每个人都能及时感知自动化执行情况，为质量负责。
# 发布阶段：多重保障保质量
流程：发布质量门禁 > 发布委员会人工审核 > 分批次灰度发布 > 系统测试 > IM 通知
测试验收通过后进行发布上线操作，建议几种配置策略：
- 建设发布门禁，通过自定义任务自动获取安全扫描、单元测试、集成测试等质量结果来判断是否允许上线，作为上线过程的卡点，确保版本验收通过并且符合质量要求后再做上线操作。
- 灵活编排蓝绿、金丝雀、分批次灰度、Istio 全链路灰度等发布策略，以确保发布可靠性，可参考：工作流的发布策略 (opens new window)。
- 工作流适当增加测试团队人工审批，以确保业务流程上的发布合规性。
# One More Thing：如何度量持续测试效果
任何实践都要讲求投入产出比，而持续测试的效果可以通过：测试的编写人员比例，发现的 Bug 数量，自动化测试的有效性，以及是否在 CI/CD 中运行自动化测试等方面来度量，具体如下：
| 衡量因素 | 衡量的指标 | 目标 |
|---|---|---|
| 测试的编写人员 | 由公司的开发、测试和其他成员编写的测试所占的百分比 | 验收测试的主要创建和维护人员应为开发者 |
| 在不同阶段发现的 Bug 数量 | 所发现的 Bug 的比例随时间的变化 | 在测试阶段发现更多的 Bug |
| 修复验收测试失败所用时间 | 修复验收测试失败所需的时间 | 修复时间的变化趋势：开发者应能够轻松修复验收测试失败 |
| 自动化测试的有效性 | 测试失败的原因：因实际缺陷导致、编码质量问题导致的自动化测试失败数量 | 自动化测试失败始终表示产品中存在实际缺陷 |
| 自动化测试是否在 CI/CD 工作流中运行 | 检查所有测试套件是否在每个流水线触发器中运行（是/否） | 自动化测试的集成：自动化测试应在主流水线和主工作流中运行 |
# 小结
通过 Zadig 支撑持续测试和自动化测试的实施，帮助测试团队更好地应对当前的测试行业挑战，确保软件交付的质量和稳定性，提高开发和交付过程的效率。
