以云图为例，回顾反思一下超大项目的质量保障该如何做。

背景

云图项目是设计工具一次大升级，涉及敏捷组 20+，项目参与者 100+，项目历时 11 个月；其中启动到发布历史 6 个月；用户迁移历时 5 个月。

核心难点:

难点 1 涉及核心底层改造，影响面广测试覆盖难度大。

之前设计工具是各个业务独立各自的前端模块，在页面上，各模块有不同的入口。这样好处是模块间没有耦合，研发不需要考虑太多不同业务间可能产生的相互影响；但坏处是，不同模块业务交互有越来越多的相似之处，比如都允许撤销恢复，都有选中、拖动等基础交互功能；不同模块分别独立维护这些功能，研发资源投入呈线性增长，同时还可能出现同样的功能但交互视觉体验不一致的现象。

为了降低整体开发成本，提升基础公共交互的可复用性和一致性，前端开发了一套基础应用框架。由框架层提供统一的数据管理机制，标准组件库（比如导航、消息框等），公共基础库（http，throttle，repromise）等。各模块都在该框架提供的基础能力之上扩展业务功能。

随之而来不得不考虑的是: 基础框架提供的能力边界是否明确?如何保证框架的升级扩展对业务保持透明？如何保证数据在不同模块间传递的正确性和完整性？如何评估框架升级的影响面？这些问题都需要有相应测试手段做兜底保障。架构、设计、开发环节的任何疏漏都需要在测试阶段最终反映出来。

难点 2 不同工具模块入口和功能融合，对用户机器资源的消耗也大幅增加，如何保障性能体验不衰退？
既然带来机器性能消耗增加，为什么要做这样的交互和功能变化？ 因为装修设计工具本身是一个复杂体系，设计师使用工具完成一个完整装修方案的设计，少则需要数小时，多则需要几天。设计工具本身的交互使用便利性，对设计师的工作效率有至关重要的影响。通过融合工具的各个模块，降低设计师在不同模块下的切换次数和交互次数，可以大大提升设计师工作效率和设计体验。克服随之而来的性能问题自然是研发当之无愧的职责之一。毕竟互联网技术也是伴随用户流量的增长和体验要求的提升，而变革升级！

难点 3 整体交互体验和布局上的改进，难以避免会带来用户习惯的改变，如何平衡用户体验和用户习惯的关系？
在功能和交互变化决策上，产品都是经过深思熟虑和多轮讨论的。但是当变化的点比较多的时候，我们仍然很难准确评估到用户的反应；事实上我们原计划 3 月份完成设计师用户迁移，直到 9 月份才最终完成。这个过程中既有产品各种不完美，不断迭代；也有在运营手段策略上不断调整帮助用户尽快适应。

解决方案

在这样的项目中，QA 需要担当怎样的职责？这么多敏捷组如何高效协同？有哪些关键抓手? 最终要达成怎样的目标？如何量化目标是否达成？
首先，关于测试的职责，看起来似乎是个挺简单的问题；但是细节边界值得追究，比如：各个模块测试是不是只保证自己负责的模块质量就可以了？是不是产品定义过的问题测试都不需要再关注？历史存在未解决的问题是否需要测试关注？符合质量红线就可以高枕无忧的发布了么？测试是不是只汇报问题就好，能否改或者改成怎样产品决策就好？

在不同角度，对这些问题可能有不一样的答案，作为整体项目质量负责人有必要把这些问题和大家澄清，确保大家达成一致，并且有一致的执行方案。这是作为一个职能团队的基本专业性体现。

其次，大项目涉及人多，互联网公司一般没有特别严格细化的流程要求，信息不对称协作不顺畅是常有的事情，如何最大限度降低这类问题对产品交付质量的影响？

1. 由测试负责整体部署和发布。负责部署和发布，其实是一件比较繁琐的事情，涉及细节问题和跨组沟通较多。但是同时，部署和发布也直接决定了最终交付到用户的产品质量。所以掌控发布，是测试重要关键抓手之一。这一环节的可控性保障了交付质量的可控性。除此之外，掌控部署和发布，使得我们可以更流畅的把质量卡点和持续集成融入到发布流程中，不断优化系统流程，降低协作成本。在云图项目中，我们掌控发布的同时，和前端协作推广新的前端发布系统，并将自动化用例和基础配置检测纳入部署前自动检测流程；结合企业微信机器人在各个关键集成点和灰发点做自动提醒和红线检测，这些手段都有效的保障了各组的有序高效协同。
   

2. 对项目关键里程碑设定保障策略，质量目标和 check 机制。这里容易出现的是，只设定一个最终质量目标，不关注阶段策略和目标，这样很容易导致要么过程质量问题没有及时得到关注，导致最终结果无法达成预期；要么过程该做的事情没做到位，数据结果看起来很好但上线后问题频发。在这个项目中，我们分三个阶段：模块测试阶段，集成测试阶段，灰发阶段都制定了相应的测试范围和阶段质量目标。对应的测试内容和目标都要经过大家充分讨论一致认同。实际执行中，出现阶段目标未能达成也是不可避免的事情，但是有了前期的标准，使得我们可以针对问题现状开展讨论，引起大家对质量风险的关注并制定相应的解决措施。测试本身保持对质量的严谨和前后一致的态度，才能逐步把这种态度感染到整个团队；而一个有高度质量意识的研发团队才能是一个靠谱高效的团队。这里讨论的设定目标，范围和保障机制看起来是蛮简单的事情，但是特别容易出现关键细节遗漏，以及过程变化带来的风险遗漏。所以这里需要经过严谨的评审，和对变化的时刻关注。在云图项目中，我们的性能测试方案虽然各个模块都经过了评审，但是仍然忽略了数据融合情况下性能表现。这一关键细节，导致上线后卡顿的反馈远超我们预期。

3. 关注模块间的边界和耦合部分。组织结构上，不同组负责各自模块，模块间耦合的部分往往边界不清职责不明，容易出现问题且不易被发现，即使发现了排查成本也相对更高。而测试作为交付用户的最后一道防线，需要特别关注这类问题。测试手段上，除了集成阶段规划专门的模块集成测试用例外，为了避免 bug 修复和版本迭代引入新的问题，我们对模块基础功能做了自动化脚本，保障 A 模块改动不会导致关联的 B 模块不可用。但仍然需要探索更有效的保障手段尽早发现模块耦合导致的功能衰退。

4. 尽一切可能用技术手段协助发现问题。这是作为一名有追求的测试的需要不断突破的。在云图项目中，我们建立了性能基线自动化；完成了核心业务的监控看板和告警；开发了多个企信机器人实时通报质量数据；推进了多语言检测工具支持国际版翻译完整性检测...目前随着对线上暴露问题的不断分析，开始着手做 chrome 插件工具，在测试应用工具过程中自动检测并上报重复请求，异常日志，低帧率场景等各类问题。
   最后，发布上线不是终点，顺利稳定交付到用户才算走完项目全程。

云图从发布上线，到完成用户迁移历经 5 个月；这中间经历了一轮又一轮的引流，搜集反馈，优化改进。值得骄傲的是我们制定的引流策略，结合运营策略很好的控制了用户流量；使得尽快搜集到问题的同时不至于问题的影响面过大，也为后端扩容预留了一定空间。而云图项目发布后最大的问题还是性能体验问题。我们老版中缺乏有效的性能数据度量，在云图上线初期也没有性能数据度量。导致我们单纯依赖测试结果认为性能符合预期。直到收到大量反馈性能体验不如老版本，才意识到需要尽快建立数字化线上性能度量，单靠测试阶段小样本的评估数据是远远不够的。（这里也有前面提到的性能测试方案本身存在关键细节遗漏）.

所以吸取经验，不能单纯依赖测试阶段的结果作为能否交付用户的评估依据。一方面需要健全度量机制，结合引流阶段的用户反馈和产品数据（比如用户主动退回老版本比例），做出更准确的判断。另一方面，需要提前制定数据搜集响应机制，在搜集到数据和反馈后尽快速制定策略，优化后再做新一轮的引流评估。

关注我们

酷家乐质量效能团队热衷于技术的成长和分享，几乎每个月都会举办技术分享活动（海星日），每半年举办一次技术专题竞赛分享（火星日），并将优秀内容写成技术文章。

我们尽可能保障分享到社区的内容，是我们用心编写、精心挑选的优质文章。如果您想更全面地阅读我们的文章，请您关注我们的微信公众号"酷家乐技术质量"。

如果您有兴趣了解我们的职位和团队情况，请参考最新职位招聘，并联系 caibao@qunhemail.com。感谢您的阅读！