你可以有一个绿色的CI运行，但仍然发布一个破损的应用。构建通过，QA签字，发布出去，然后第一个真正的用户遇到一个永远不会返回的权限提示，一个陈旧的JavaScript包，或者只在一个Android皮肤上出现的崩溃。质量保证流程指南通常会忽略这一部分，而移动团队通常会在实践中学习这一部分。
实用 质量保证流程 是一种闭合循环，而不是一个仅仅在有人报告缺陷时结束的检查清单。它从需求和测试设计开始，但只有当发现反馈到发布决策、监控、回滚和下一轮测试时，它才真正有用。如果您正在部署CapacitorJS或Electron应用程序，那么这个循环就更为重要，因为一个坏的Web包可以一次性影响所有用户，而原生审查仍然会延缓永久性修复。
目录
- 现代质量保证流程实际上涵盖了什么
- 定义目标、范围和可测试的验收标准
- 选择合适的自动化和手动测试的混合
- 将QA集成到CI/CD管道中
- 无需猜测的阶段、金丝雀和分阶段发布
- 可观察性和指标，能够在用户反馈之前捕捉问题
- 事件恢复、回滚和学习正确的教训
现代质量保证过程实际上涵盖了什么
一个现代的 质量保证过程 是一个闭合的循环，具有明确的控制点。实用的顺序是 需求分析、测试规划、测试设计和案例开发、环境设置、执行、缺陷跟踪、重测试和回归、发布验证和测试关闭. 最重要的控制点仍然是那些乏味的 从需求到测试的可追踪性 和一个正式 缺陷分级和验证循环因为修复不算是完成的，直到它们被验证为关闭状态，正如TestSigma的 QA流程指南中描述的.
循环不在发布时停止
良好的QA不仅仅是发布候选版本通过测试时就结束了。它还需要通过生产验证、支持信号、实时更新恢复和下一个迭代的测试设计。很多团队会在这里失去步伐，因为他们把缺陷当作任务，而不是需求、测试或部署防护措施需要改变的证据。
有用的思考QA的方式是把它当作管理系统，而不是评分卡。 质量保证流程步骤 指南指出很多项目忽略了客户反馈循环和跨渠道评估，这个缺失对应用团队来说也很重要。如果支持团队在发布后持续看到同样的反馈，说明过程没有学习，只是测量了结果。
在添加工具之前，需要衡量什么
在购买更多工具之前，需要清晰地确定团队将使用的信号来决定是否安全发布。通常需要定义发布门槛、每个门槛的负责人以及如果漏网之鱼需要回滚的标准。
一个实用的起始集合是简单的：
- 需求覆盖, 表示每个用户可见的规则至少有一个测试.
- 缺陷严重性和归属, 以便团队知道什么阻止发布以及谁负责解决它.
- 回归范围, 以便修复不重新打开邻近流程中的旧问题.
- 发布后信号, 以便生产反馈改变下一个测试周期而不是存储在仪表板中.
对于试图在邻近操作流程中减少手动重复工作的团队, 杜贾劳动成本减少指南 是一个有用的例子,说明如何通过结构化审查和清晰的交接来减少浪费的努力. QA 工作方式相同,当循环是明确的,人们停止猜测.
如果您的当前流程只告诉您什么失败,而不是什么下一个变化,那么它是不完整的. 这就是测试程序和实际质量系统之间的区别. 对于一个适合这种思维方式的发布管理角度,请参阅这个内部指南 发布管理流程 与同样的闭环方法相配
定义目标、范围和可测试的验收标准
QA会变得更尖锐，当产品语言转化为可测试的语言时。一个要求“让结帐过程更快”是无法清晰地验证的，而“在提供商返回成功后显示支付确认屏幕，并在用户关闭应用之前”是可测试的、可追踪的和对工程和支持都有用的。这种可追踪性是闭环模型的核心控制点之一，之前的部分中提到过。
以测试者可以执行的方式写验收标准
对于一个CapacitorJS应用，考虑一下支付流程。如果应用使用第三方支付sheet，验收标准应该涵盖支付sheet成功、失败、超时或被dismiss的场景。如果流程依赖于相机权限、位置权限或推送通知同意，每个branch都需要自己的可见结果，因为权限提示在iOS和Android上可能会有所不同。
一个轻量级的模板效果很好：
- 假设 用户已登录。
- 当 用户点击支付按钮。
- 然后 应用呈现支付 UI，并确认成功或显示可恢复的错误状态。
- 而且 事件可以追溯到一个发布票据，所以 QA 可以将失败映射回一个要求。
重点不是要使每个句子都正式。重点是要确保人类可以告诉是否该功能通过了，而不用争论意图。 validating Capacitor app updates 验证__CAPGO_KEEP_0__应用更新
变得有用，因为更新验证通常会暴露缺失的验收标准。
根据风险来划分发布范围，而不是根据乐观度
划分发布范围更容易辩护，而不是模糊的发布。高风险的界面应该有更广泛的覆盖，而低风险的复制或孤立的 UI 调整可以在依赖关系表面较小的情况下使用更轻的检查。实际上，这意味着标记任何与认证、支付、权限、离线行为或原生桥接有关的内容需要更深入的审查。 实用规则：
如果一个功能可以以阻止核心使用的方式失败，它需要明确的验收标准和至少一个非单元验证路径。
如果你能准确把握范围，QA就不再像是在最后时刻争论一样。团队知道需要证明什么、可以采样什么、需要人工检查什么，因为自动化边界在此结束。
选择合适的自动化和手动测试的比例
自动化得到关注，因为它可以扩展，但它只能捕捉到它可以模拟的内容。手动测试被认为是慢的，但它往往是唯一能捕捉到视觉漂移、设备特定问题或工作流奇怪行为的方法，这些问题会在用户使用应用程序时出现。一个平衡的 质量保证过程 需要两者，并且分配比例应该遵循风险，而不是意识形态。
每层最擅长的内容
单元和集成测试在逻辑是确定性的情况下最强大。在CapacitorJS或Electron堆栈中，这意味着使用Jest进行商业逻辑、状态减少器、辅助函数和组件行为的测试，集成测试用于API边界、更新解析和权限处理Branch。Cypress适合用于浏览器驱动的端到端覆盖Web层，而Detox风格的流程在需要设备级别的移动交互并且可以承担维护成本时非常重要。
手动测试在需要关注的地方发挥作用。探索性会话捕捉到奇怪的导航路径、暗色模式不匹配、在小设备上键盘重叠、或在某个OS版本上关闭的模态。它也很重要的可访问性，因为屏幕阅读器顺序、焦点陷阱和对比度问题通常更容易通过尝试应用程序而不是依赖静态检查来发现。
如果您想要更广泛的自动化类别和权衡的视图 Appjet.ai的测试工具分解 是比较点。对于刚刚标准化他们堆栈的团队 自动化测试概述 帮助定义边界通常在哪里。
自动化测试与手动测试的区别
| 场景 | 最适合 | 原因 |
|---|---|---|
| 仅在共享模块中执行的商业逻辑 | 自动化 | 快速反馈、稳定输入、容易重复 |
| 支付提供商回调处理 | 自动加人工 | 逻辑可以用脚本实现，但用户体验需要人工验证 |
| iOS 和 Android 上的权限提示 | 人工优先 | 操作系统行为和设备状态可能会改变流程 |
| 视觉回归测试一个设置屏幕 | 人工加视觉工具 | 布局错误更容易通过真实设备发现 |
| 离线同步和重新连接行为 | 自动加设备测试 | 时间、重试和状态恢复需要可重复的覆盖 |
| 新特性标志的beta反馈 | 手动 | 真实世界的行为经常揭示测试漏掉的缺口 |
外部beta测试者
外部beta测试者在内部团队有太多共享背景时很有用。他们不会重现你的假设，这就是点。他们尤其适合于触及onboarding、首次运行权限或依赖于不熟悉用户行为的流程的发布候选项。
过度关注任何一边的陷阱。全部自动化的测试计划忽略了人类细微差别。全部手动的测试计划变得昂贵、不一致且在截止日期紧张时容易忽略。正确的答案通常是稳定的自动化基础加上在世界上最容易破坏的表面上有意识的人类覆盖。
将QA集成到CI/CD管道中
CI/CD应该强制质量，而不是仅仅移动工件。管道在每个阶段都有一个单独的作业时，才能发挥最佳作用，因为混合关注点使失败更难理解并且更慢修复。一个好的 质量保证过程 在质量保证过程中，检查应该在阻止坏code的早期阶段进行，然后保留相同的工件以便它向发布移动。
优先使用廉价的检查
每次提交时，运行快速且可预测的检查。检查代码格式、类型、单元测试和集成测试应该在构建原生二进制文件之前失败。这可以降低噪音并使下一个阶段，即构建，值得花费计算资源。
之后，受控的构建应该生成签名的iOS和Android二进制文件，当原生code发生变化时。如果仅在Capacitor应用的Web层发生变化，您仍然需要管道来构建Web包、验证它并以安全的方式打包它。关键是 artifact标识，通过测试的包应该是达到 staging或生产的包。
推送 artifact，而不是环境
仅推送环境而不推送 artifact 是团队会产生漂移的地方。您希望在内部QA、staging和生产之间尽可能使用相同的包，因为否则您是在测试一个东西并部署另一个东西。这种情况同样适用于Electron应用，打包和签名应该是发布门控的一部分，而不是附加内容。
实用规则： 如果一个构建无法从提交到签名的artifact到部署的版本进行追踪，那么您的管道就缺乏了QA所需的证据链。
对于Capacitor团队，实时更新工具可以减少验证和发布之间的差距。经过测试的Web包可以直接推送到staging而不需要重建原生二进制文件，这使得当原生shell未发生变化时的迭代速度大大提高。 持续集成配置 这里的指南是相关的，因为CI应该知道如何自动将验证的包发布到正确的频道。
简而言之，CI CD shouldn’t问，“这次构建是否通过？”而应该问，“这个确切的工件是否通过了正确的检查，在正确的环境中，是否在用户面前有了正确的门槛？”
添加晚期集成检查
只有当外部系统参与进来时，才会出现一些失败。特别是对于认证提供商、支付网关、推送令牌或短信验证流程。需要更广泛的参考点来了解平台工作流程中的集成测试覆盖范围时， 短信激活集成测试指南 是一个有用的提醒，外部依赖项应该得到明确的验证，而不是寄希望于它。
当管道以这种方式构建时，QA停止成为一个单独的仪式。它成为交付本身的一部分。
无需猜测的阶段发布、雪崩发布和分阶段发布
阶段发布、雪崩发布和分阶段发布不是可以互换的。它们解决不同的问题，团队会陷入困境，因为他们把其中一个当作所有三个。一个健康的 质量保证过程 将它们视为单独的发布策略，具有单独的爆炸半径和单独的决策点。
每个发布阶段的作用是什么
预发布 是生产环境前的最后一个完整的高保真检查点。它应该尽可能地模拟生产环境，使团队能够在真实条件下验证构建、数据流和发布包。
金丝雀发布 是学习从小规模真实用户切片中的知识。它暴露了设备特定的和网络特定的问题，因为预发布环境往往会错过这些问题，因为世界比任何预发布环境都复杂。
分阶段发布 逐渐扩大曝光度，直到第一批信号看起来健康。它是扩大爆炸半径的最安全方式，因为你没有把整个用户基数押在一个发布决策上。
如何Capgo样式的频道映射到发布策略
对于实时更新工具，频道设计很重要。一个频道可以服务于内部QA，另一个频道可以针对beta测试，第三个频道可以持有第一个生产波次，第四个频道可以纯粹用于紧急回滚。这种分离给了工程和支持团队一个隔离风险的方式，而不必等待新的商店提交。
这个也是目标设备分配的作用。 如果某个特定用户或设备需要调试，一个通道可以仅为此目的设置，保留其余的基础版本在已知良好的版本上。 Capgo 支持这种针对性的质量保证流程，对于 Capacitor 应用程序，这对于当 bug 很难复制并且需要观察一个设备而不改变其他人发布的状态时是有用的。
毕业标准应该明确
一个构建应该只有在证据表明它可以移动时才前进。 通常意味着早期阶段通过了其定义的检查，没有新的崩溃模式出现，支持队列中没有填满相同的抱怨。 如果信号不明确，应在构建处于当前状态。
一个简单的促进规则有助于：
- 内部QA到阶段，只有精确的工件通过烟雾测试和关键用户流程后。
- 阶段到金丝雀，只有全真实环境与预期行为匹配后。
- 金丝雀到分阶段发布，只有早期用户表现稳定并且支持可以用简单的话语解释发布后。
- 分阶段发布到全生产，只有生产可观察性保持清洁足够长时间以便您的团队信任趋势后。
消除猜测的部分。推广变成了基于证据的决定，而不是进展的庆祝。
可观察性和指标，能够在用户反馈之前发现问题
发布后，QA 不会消失。它的形状会改变。生产可观察性是质量保证过程的部分， 它告诉你发布是否按照测试所说的那样运行， 以及用户是否遇到了实验室环境中未见过的故障。对于移动和跨平台应用来说，
这意味着一起查看设备信号、更新健康状况和错误模式。
观察反映用户痛苦的信号
For a Capacitor or Electron app, per-device logs matter because the same release can behave differently across OS versions, form factors, or update states. A live-update platform can expose adoption and failure data by device, which gives engineering a way to see whether a rollback is needed or whether the issue is isolated to a small slice.
支持团队会在工程团队之前听到问题的报告。
当没有人负责响应时，仪表板会失败。每个指标都需要一个负责人、一个警报条件和一个标准的下一步措施。如果更新失败率突然上升，需要有人决定是否暂停渠道、回滚捆绑包或发布新修复版。
一个实际的设置如下：
- 故障和错误监控, 以快速检测应用程序不稳定。
- 更新采用率跟踪, 以查看用户是否正在接收修复的捆绑包。
- 失败率警报, 以在支持反馈积压之前捕获坏的捆绑包。
- 设备级别的钻取, 以便团队可以将广泛的故障与平台特定的噪音区分开来。
一个仪表板只有在它改变决策时才是有用的，否则它就是一个带有更多标签的截图。
将生产信号反馈到下一个发布
最好的QA团队将发布后数据转换为新测试。如果某个设备类别无法应用更新，添加一个验证用例来处理该路径。如果网络重试在某个平台上表现不佳，将该失败模式纳入下一次测试计划。那样，观察性就变成了质量的输入，而不是运维侧边栏。
发布工具成为QA的一部分，而不是仅仅是部署。当团队可以看到哪些设备更新了，哪些设备失败了，以及哪个版本的包在线时，他们就可以在用户涌入支持之前做出反应。Capgo的每设备日志和频道护栏适合那些需要发布过程在发布后保持可解释的团队。
事件恢复、回滚和学习正确的教训
发布失败的那一刻是质量保证过程的关键时刻。团队可以有强大的规划、合理的测试覆盖和干净的管道，但如果无法快速恢复或从错误中学习，就会失去所有价值。因此，事件响应应纳入QA，而不是放在旁边。
首先进行分类，第二次进行说明
当发布失败时，首要任务是确认范围。它是否仅限于设备子集，仅与一个版本相关，还是影响整个受众？一旦确定，团队就可以选择回滚、暂停频道或进行手术修复
对于实时更新平台，JavaScript 或 CSS 的更改通常可以在几分钟内回滚，而不必等待 App Store 或 Play 的审核。这很重要，因为坏的体验和受控事件之间的差异往往取决于团队可以快速停止传播的速度。 事件响应指南 写事件回顾以改变行为
事件后文件需要更多的根原因。它应该记录观察到的内容、可用的信号、第一个错误的假设以及早期可以捕捉到问题的内容。如果相同类别的缺陷再次发生，文件应该产生接受标准的变化、新的测试用例或 CI 门控。
有用的回顾输出包括：
修正的接受标准
- 如果原始要求太模糊。 新的回归测试
- 如果失败是技术上可以预防的。 发布保护栏
- 如果问题应该在更长时间的开发环境中停留。 incident response guide
- 一个支持说明如果客户端团队需要下一次更好的脚本，
实践规则： 如果后勤报告没有改变门户、测试或发布规则，那么它很可能只是文档。
成熟的QA和发布表演的区别在于学习循环。发布失败，团队控制了它，过程在弱点的地方变得更加严格。
Capgo帮助团队通过实时更新、目标频道和发布所有者在设备级别看到什么时候出了问题来缩短这个循环。如果您试图为CapacitorJS或Electron应用程序构建一个更安全的 质量保证过程 请访问 Capgo 并了解如何将实时更新发布、回滚和可观察性融入同一个运营模型中。
