这是鼎叔的第九十九篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。本人新书《无测试组织 - 测试团队的敏捷转型》已出版（机械工业出版社）。

完成端到端测试（也可以称为系统测试）阶段后，进入灰度发布或正式发布阶段，测试人员除了采集和分析缺陷外，也需要抽出一定精力，持续进行高价值的质量保障活动，它们包括：

1）参与/组织可用性测试。

2）关注持续部署和发布。

3）压力测试与混沌工程。

4）服务质量监控。

5）用户行为埋点与用例优化

与其全身而退（立刻投入下个新版本的测试准备），不如花一些精力对当前发布版本多做一些高价值的质量活动，获得宝贵技能，再通过问题反思不足，验证测试策略的有效性，以便在下一个发布周期做得更好。

参与/组织可用性测试

可用性测试，让一群有代表性的用户对待发布产品做典型的操作，产品或观察人员在一旁观察，聆听，记录，得出改进结论。

可用性测试来源于人因工程（human factor），又称为工效学，是一门涉及多个领域的学科，包括心理学，人体健康，环境医学，工程学，工业设计等等。ISO 将 “可用性（Usability）” 定义为 “特定使用情景下，软件产品能够被用户理解、学习、使用、能够吸引用户的能力。”

可用性测试在团队中通常由交互设计/用户调研组来组织，也可以是产品经理来组织，项目成员可以参与观察，测试人员从中亦可以获得意料之外的收获，学习真实用户如何使用和认知产品的。

通常的可用性测试做法，是找 5-6 个典型用户，花费 30-50 分钟，自由使用 5-8 个基本功能点，组织者会给一定的使用目的（但不会很详细），激发用户自行使用，不会给具体的操作要求。因此，用户其实并不是在刻意做测试。

在该过程中，观察者除了利用专业设备（如眼动仪）记录用户视线和行动步骤，察看使用过程中的交互步骤和视觉路线是否合理，离开主界面和主流程的时间是否异常，并搜集用户的优化建议。参考用户体验的模型，分析可用性有五个递进层次：能用，有用，易用，好用，爱用。

基于同样的思路，我们可以定制产品可用性调查问卷，特别适合参与灰度体验或者众包体验的用户来填写，问卷的核心是获取下面四个评价：

高参与：能否完成既定目标，如工作需求，或满足娱乐需求。

低门槛：学习曲线是否足够低，在多短时间内能掌握新功能。

高效率：操作流程是否足够短，完成任务耗时是否足够短，导航是否快捷。

强稳定：用户感受有安稳感，甚至满足感，下次使用产品时无需记忆，手到擒来。

完成可用性测试后，测试人员可以反思一下目前的测试策略和覆盖场景，验收条件，是否已关注到用户容易不爽的地方，有什么改善的空间？

关注持续部署和发布

关于持续部署和发布，这篇文章主要从三个方面展开介绍。

一 关注持续部署

DevOps 时代的部署应该是持续进行的，这个过程高度自动化，为了做到这一点，配置部署的流水线，能够快速反馈部署的问题，去除手动配置的成本和风险。我们可以在日常环境、预发环境和生产环境分别部署流水线，也就可以把相应的测试检查内容纳入到部署流水线门禁中，真正做到测试右看。

为了提高部署的成功率，也就是提高交付效率，我们应该维护一个单一源的仓库，把测试脚本、属性文件、数据库概要、安装文件和第三方库放置在一起，即所有用来构建产品的东西都放到版本控制系统里，一旦其中某个对象发生了变更，那么依赖它的所有对象都需要被重新构建。为了缩短部署和发布的耗时，测试可以关注应用的瘦身大小，把它作为专项改进目标。

二 灰度发布的测试活动

灰度发布，就是导入一定比例的真实用户，研发和产品团队观察用户使用的效果，如果没有异常再进行更大范围的灰度或者全量发布。灰度发布也可以仅仅只是获得关于新试验功能的结论（用户是否喜欢）。灰度发布可以在大规模推向用户之前，尽可能地发现并修正严重问题。同时降低发布压力，避免产品团队闭门造车，用低风险收集用户使用的反馈。

灰度发布阶段，测试可以做哪些事？

首先，要明确自己的灰度阶段测试（观测）目标。是观察性能问题，新版本体验问题，还是新旧功能的指标对比？注意关注已发布的机器是否有流量打进来，避免表面上启动成功，实际上服务并没有生效。

其次，参与灰度用户的选择策略，和产品及开发沟通，灰度策略对于测试目标是否有代表性和准确性。比如：是否覆盖了重要的终端类型，是否覆盖了指定的角色特征，是否能针对特定场景采集测试结果。

最后，灰度测试报告的输出，明确灰度发现的问题及严重性，能够给产品一定的改进意见，判断是否达到全量发布的质量标准，或者明确给出灰度 “实验” 的观测结论。

注意，如果针对灰度版本发起众包测试，在搜集灰度反馈方面有很高的效益。

三 主干开发和主干发布

参考硅谷 Meta 等大公司的经验，高度敏捷的研发团队应该追求单主干开发，其好处是巨大的，可以尽可能降低分支开发带来的版本冲突，以及长生命分支合入主干带来的高评审成本。但是想要实施单主干开发及发布，团队的各项质量及效率实践需要足够成熟，如可靠的持续构建门禁和代码审查门禁，TDD 的良好习惯，高度的自动化测试覆盖率，每次提高变更的颗粒度足够小，以及未实现功能可以用开关统一控制。

当团队在单主干上进行日常开发和发布时，质量负责人可以联合团队确立合并代码的质量要求，包括前置要求（满足什么测试结果才能合入主干）和后置要求（合入代码后应该立刻启动保障型测试，确保红线标准不被破坏，一旦被破坏需要采用相应优先级的处理手段）。

此外，如果大量工程师在单主干提交了大量代码，那么如此复杂逻辑的产品在运行中可能会产生很多不稳定的测试结果，我们称之为 Flaky Test，这类问题会降低团队持续交付的信心，但是小团队对此的解决手段非常有限。开发和测试团队需要逐步建立治理 Flaky Test 的方案，包括消除各种外部依赖和用例依赖关系，做好并发处理和异步等待，尽可能减少随机行为，最后对本轮测试产生的 Flaky test 进行标记，并在持续测试中隔离处理。参考：聊聊持续测试的进阶 https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484566&idx=1&sn=98279f739095026f1692109f35d0f9bf&chksm=c24fb1f4f53838e26e58c6d1c424ea7316bec8a36f3f769ec2e26012905965fb09c3268eb5f4&scene=21#wechat_redirect

压力演习与混沌工程

对于复杂逻辑链条和海量用户的互联网业务，不论日常花多少精力做接口测试和性能测试，都不能保证真实用户场景的充分覆盖。尤其是分布式系统，一旦遇到大量用户的集中访问和各色操作，经常会暴露意想不到的问题，甚至会形成雪崩效应，造成核心服务的瘫痪。因此，光有敬畏之心是不足够的。

测试团队作为质量保障的核心角色，可以和业务负责人及开发团队一起实施压力演习（或称现网演练），针对特定的海量用户使用场景，在预发布环境实施，尽可能模拟真实活动的全过程，测试所处的环境数据库及配置，使用和线上一致的备份。施加压力的大小、时间、被压接口、变化过程，都是事先设计好的压测模型脚本，同时对复杂的后端服务链条做全链路监控。

压测前做好充分准备，尽可能不影响真实的线上用户；压测后对性能数据问题做复盘分析，找到性能瓶颈，给出改进措施，优化下一次演练的方案。

为了避免压测产生的脏数据不对真实用户的数据库产生影响，被测系统在保持线上环境的一致性的前提下，需要具备精准识别测试流量的能力（比如，依赖整个压测链路的流量标签），把产生的测试脏数据隔离保存到特定数据库里。

现网演习中，有一类特殊的工程实践就是混沌工程，这块已经成为独立的技术学科，最早是来自奈飞公司带来的 “混沌猴子” 实践。混沌工程是一种生成新信息的实践，包括常见的故障注入手法。例如，引入特定的一类故障，针对被测系统的某个位置引入超时、错误响应、链路不可用等错误状态，在一段时间内观察系统如何处理，能否自动恢复，花费多长时间恢复，以及是否产生链式灾难反应。混沌工程也可以引入激增的流量、特殊的组合消息、激烈的资源竞争等模式。

实践混沌工程的推荐时机是当生产事故的 MTTR（故障平均恢复时长）越来越差，故障根因不明的情况逐渐增多之时。正式实施前要和相关团队人员做好预告说明，明确实施动作和时长，给出相应的应对指南，将生产环境中受影响的范围控制到最小，按照现实世界中影响系统的事件发生概率来安排运行混沌实验。整个过程应该尽量自动化执行，具备可快速终止实验的能力，以及实时观测各项指标的能力，能判断系统在混沌实验结束后是否回归稳定状态。

利用混沌工程主动制造 “非稳态”，观察系统在压力下的行为，我们通常能发现一系列的系统脆弱性问题。通过探索产生的影响，团队逐步建立了被测系统能够应对生产环境动荡状态的信心。我们鼓励测试人员和开发人员联合进行混沌工程实践，共同获得新的知识。

参考文章：聊聊混沌工程 https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484183&idx=1&sn=07ee33f846220e7687fe9bfaf965dd72&chksm=c24fb675f5383f638ee8f13a0c5dada5c695293cfe4ad758becc5353d4fb48c12450b7ccd1fa&scene=21#wechat_redirect，聊聊混沌工程的企业实践

服务质量监控

对于在线技术服务而言，任何一个时刻发生的严重问题都有可能造成用户的投诉，甚至成为影响公司品牌和收入的严重事故。与其被动地在线上质量事故突然发生后灭火和检讨，不如主动建立线上服务质量监控网，在第一时间觉察出质量风险并采取行动。

测试人员参与这类线上监控技术建设是有自身优势的。业务开发和运维更多是从应用接口、网络系统资源的层面进行底层监控，而测试人员可以利用已有的自动化脚本进行用户基础场景拨测，定时进行。

测试人员在进行质量监控时遇到的主要困惑，就是不清楚如何明确监控指标。监控指标不是越细越好，而是能快速锁定突发问题出现在什么地方，还能通过指标大盘全局了解业务的健康程度，因此指标大盘一定要简洁直观，聚焦核心。

那么，阻碍服务监控产生预期效果的原因有哪些呢？除了本身技术能力不足，还有下列情况值得让集体停下来改进：

破窗效应。监控出了问题没人关注，没有严格的响应处理机制。

告警海洋。告警频繁，数量大，重复，不及时，急需精简。告警监控指标太多，导致监控界面复杂，界面美观可视化对于长期运营非常重要。

告警没有分级，也导致员工不清楚响应告警的时效纪律要求。

误报严重。如何降低告警的噪音，是各大公司的共同痛点。大部分告警数量来自于某些告警的持续性产生，因此我们是可以聚焦其相似性合并告警的。而基于 AI 的告警处理手段也是热门技术趋势。

定位问题根因的工具效率低，步骤多，准确性不足，严重拖长了 MTTR。

服务质量监控系统和研发管理系统没有打通，没有形成线上缺陷单的一键跟进，不便于研发质量分析。

一旦研发团队发现了线上服务异常问题，并处理妥当后，大家可以一起进行复盘分析。思考故障恢复时间能否缩短，技术架构是否有不合理之处，能否完善监控看板的视图，强化日志定位工具的效率等。测试人员还可以从右看中获得有价值的输入，把获得的负面案例转化成性能场景用例或者接口测试用例，让未来的版本测试更完善。

用户行为埋点与用例优化

测试用例的设计、自动化和执行占据了测试团队的巨大精力。如果从用户体验角度出发，这些用例对用户真实使用场景的代表性有多高？排除掉一些难以承担风险的 “质量红线” 用例，普通用例的执行优先级该怎么确定？

引入触达该用例场景的 “用户渗透率” 作为挑选用例的权重，则是很自然的思路。

例如：根据每一个交付价值的能力（场景），我们可以进行场景埋点，上线后统计用户使用该功能的渗透率，用深色表示高渗透率功能，浅色表示低渗透率功能，这样就生成了测试策略的优先级提示，在有限的精力下，多挖掘高用户渗透的核心能力相关测试用例，如图所示（以 WiFi 管家产品为例）。

另外一方面，我们在实验室难以重现的缺陷（包括性能问题），也是需要通过服务后台针对用户的监控，捕获同类缺陷的操作场景上下文、输入日志和性能数据，辅以直接和用户电话沟通，才有更多的机会重现问题，改善产品体验。

但需要指出的是，对用户行为数据监控上报的方法也会带来不小的风险，比如：

1 因为泄漏用户隐私（电话，位置等）而违反隐私合规；

2 因为上报方案不合理导致流量异常增大，或者频繁上报导致耗电异常。可能会引发用户投诉或严重线上事故。

我们对应的优化技巧列举如下。

1 隐私合规：告知用户相关数据采集的必要性，让用户自主选择。

2 隐私数据加密。

3 流量控制，合并上报字段，压缩上报资源，设置为在 Wi-Fi 环境上传，延迟打包上报。

4 后台可以对是否上报，上报哪些，做配置开关。

5 产品内嵌的上报 SDK 要提高质量，确保 SDK 的体积、响应性能，内存/CPU 的影响等，对产品性能影响极低。