产品环境下的 QA

2015 年 11 月 ThoughtWorks 发布的技术雷达提到一个新的主题——产品环境下的QA（ QA in Production ），2016 年 4 月再次提到。这个主题第一次出现在技术雷达，就深深的吸引了我，当时我就给测试团队成员转发了这个内容，但同时脑子里却产生这样一系列的疑问：

• 产品环境下的 QA 可以做什么呢？有什么挑战，又有哪些好处？
• 它跟类产品环境的 QA 有何区别，是否就是类产品环境 QA 方法的延伸？
• 产品环境有运维支持团队（Ops），产品环境下的 QA 跟 Ops 所做的事情又有什么区别与联系？

带着这些疑问，结合项目上的一系列实践，于是有了本文。

产品环境的特点

为了尽量减少产品环境出现 Bug，通常采取的措施更多的是从类产品环境考虑，一步步做好质量控制。其实，如果能从产品环境做些 QA 工作，对于产品质量的提高也是有很大的帮助的。想要做产品环境下的 QA，首先得先了解产品环境有哪些特点：

1. 真实、不可破坏

产品环境都是真实用户在使用，是真正的支持企业业务运转的系统，不可以随意在产品环境去做测试，尤其是破坏性的测试。

2. 基础设施差异

产品环境往往有着比类产品环境要复杂和健全的基础设施，可能会出现类产品环境不能预测到的缺陷和异常。

3. 系统复杂度

产品环境需要与多个不同的系统集成，系统复杂度会比类产品环境高很多，这种复杂的系统集成很有可能导致一些意外的情况出现。

4. 数据复杂度

产品环境的数据量和数据复杂度也是类产品环境无法比拟的，通常都不是一个数量级的数据，容易引发性能问题、或者一些复杂的数据组合导致的问题。

5. 用户行为千奇百怪

产品环境的用户分布广泛，使用习惯各种各样，导致用户行为千奇百怪，某些使用行为可能就会产生意想不到的问题。

6. 访问受限

产品环境由于是真实业务线上的系统，对安全性和稳定性要求更高，服务器的通常不是所有 QA 可以随便访问的，这种访问受限的情况对于产品环境的一些缺陷的排查带来了很大的不便。

7. 真实的用户反馈

真实用户在产品环境使用，能够提出一些真实而重要的反馈，但是开发团队往往不能直接接触终端用户，QA 也就没有办法获得第一手的用户反馈，这些反馈常常需要通过支持团队的转述。

产品环境的特点

产品环境的这些特点决定了 QA 在产品环境不是想做什么就能做什么的。原来类产品环境那套质量保证理论和方法都行不通了。那么，产品环境下的 QA 又有哪些特点呢？

产品环境下的 QA 的特点

一、不同于类产品环境的 QA

产品环境的特点决定了产品环境下的 QA 是跟类产品环境的 QA 不同的，前者不能主动的去测试产品环境的系统，但是可以做到下面这些：

产品环境下的 QA

1. 引入产品系统的监控，制定监控预警标准，找出产品环境下使用的质量度量。比如，分析产品环境日志，收集系统运行的错误、异常和失败等信息；或者利用网站分析工具收集用户使用应用程序的数据，分析数据量需求、产品的性能趋势、用户的地域特征、用户的行为习惯和产品在同类型产品市场的占有率等。
2. 收集产品环境下最终用户的反馈，对反馈进行分类分析。用户反馈通常有缺陷、抱怨和建议，对于不同类型需要采取不同的处理方式，利用用户反馈，改进系统功能，提高产品质量，同时优化业务价值，扩大产品的市场影响力，提高企业的竞争力。

因此，产品环境下的 QA 并不是类产品环境 QA 活动的简单后延，它有着自己独特的特点。

二、不能独立存在

产品环境下的 QA 所设置的监控标准是根据系统的行为特点和在类产品环境下的表现来定义的，产品环境下各项反馈的分析结果反过来又影响着类产品环境的 QA 过程，而且这两者是相辅相成的，只有形成了良性环路，才能把产品环境下的 QA 做好。

良性环路

三、有别于 Ops

产品环境设置监控预警和收集用户反馈不都是 Ops 团队可以做的事情吗？还要 QA 参与干什么？那是因为 QA 有着独特的思维模式和视角，QA 的参与能够帮助更好的分析产品环境下收集到的各种反馈，并且结合对于系统的了解，能够将这些反馈更好的应用到日常的开发工作中。QA 在整个监控预警、收集和分析用户反馈的过程中主要充当分析者和协调者的角色，对产品环境下的质量保证工作起到至关重要的作用。

产品环境下的 QA 与 Ops

这时候的 QA 带着 QA 和 Ops 的帽子，兼具 QA 和 Ops 的部分职责，类似于 QAOps，不过现在都提倡不要有独立的 DevOps，我们也不要独立的 QAOps 角色，只是让 QA 这个角色可做的事情得到了延伸和扩展而已，本质上还是 QA。

四、跟 APM 的侧重点不同

可能有人会觉得产品环境下的 QA 跟 APM 有相似之处，那么这两者是不是一回事呢？

维基百科这样解释 APM ：

“In the fields of information technology and systems management , application performance management (APM) is the monitoring and management of performance and availability of software applications. （在信息科技和系统管理领域，APM 是对软件应用程序的性能和可用性的监控和管理。）”

APM 更多的是从性能角度出发去管理和优化应用的可用性，可以发生在各个阶段，不一定是产品环境。产品环境下的 QA 是指在产品环境进行一系列的监控和数据收集，从系统功能、性能、易用性等多个方面进行优化，从而最终优化业务价值。因此，两者是不同的。

产品环境下的 QA 在项目上的实践

我所在的项目是一个离岸交付项目，采用的是敏捷开发模式，四周一次发布到产品环境，开发的系统包括一个内部员工使用系统和一个外部用户使用的网站，用户遍及全球，项目整个已经持续了七年有余。产品环境具备前面所描述的所有特点，并且产品环境每日的错误日志达到几千条。正是由于错误日志的数量到了一个不能忍的程度，产品环境引起了各方的关注，也使得产品环境下的 QA 迎来了试点的最佳时机。产品环境下的 QA 在我们项目上的实践主要是三部分内容：日志分析和优化、Google Analytics 数据分析、用户反馈的收集和分析。下面逐个介绍。

一、日志分析和优化

既然错误日志那么多，首当其冲就是从这些错误日志下手。项目使用的日志分析工具是 Splunk ，这个工具功能强大、使用方便，关于工具的详细信息可以参考官网。下图所示为使用 Splunk 通过指定条件搜索日志文件得到的结果页面，结果集里四条类似乱码的东西就是代表有四种类型的错误日志，每种错误出现的数量和百分比都有统计，点击每条结果可以查看详细的错误日志信息。

Splunk 日志分析

关于日志的分析和优化，我们在项目上做了如下工作：

1. 分析产品环境的错误日志

专人负责产品环境错误日志的分析，挑出优先级高的进行修复处理；对新功能进行日志监控，确保上线后能够运行正常。

2. 监控测试环境的错误日志

把产品环境错误日志的分析方法应用于测试环境，让 bug 发现提前到测试阶段。据不完全统计，最近两三个月通过这种方式发现并修复了好几个潜在的 Bug。

3. 利用日志监控不同功能的性能

Splunk 里设置有专门的统计和监控系统性能的 Dashboard，QA 会定期从里边拿出高优先级的给开发人员进行性能调优。

4. 日志记录标准化

现有的产品环境日志记录存在一些问题，对于分析工作带来不便。团队为此进行讨论并达成共识：

• 将日志输出到各个服务器的同一个路径；
• 统一日志记录格式，并且尽量记录更全面的信息帮助后期的日志分析；
• 清晰定义各个日志级别（Debug，Info，Warning，Error，Critical，Fatal），将已有的误记成错误的日志降低到正确的级别，对于新功能则严格按照所定义级别记录日志；
• QA 在用户故事（Story）的开发机验收（Dev-box Testing or Desk Check）阶段负责跟开发人员确认相关日志记录是否符合标准，并且通过测试环境的日志监控可以及时验证新功能的日志记录情况。

二、Google Analytics 数据分析

Google Analytics （以下简称 GA）是项目用来统计网站使用情况的工具，从 GA 上可以获取很多有价值的信息，对这些信息的分析是我们实践的产品环境下 QA 的另一块内容，具体做了下面几项工作：

1. 操作系统和浏览器使用情况分析

根据产品环境操作系统和浏览器使用比例去调整测试环境所使用的系统，比如从重点关注 IE9 调整到 IE11。

2. 分析 QA 测试跟用户真实行为的差异，及时调整测试

根据 GA 上用户访问的路径可以发现我们 QA 的测试跟一些真实用户使用习惯的差异，这样如果按照我们通常的路径去测试，可能有些问题难以在测试阶段发现。比如，QA 在测试环境通常打开“工作记录”的方式是这样的：

QA 测试路径

而我们从 GA 上发现真实用户使用过程中，打开“工作记录”最多的路径是这样的：

用户使用路径

发现了这种差异，QA 就要在测试时候做相应的调整，让测试更接近用户的行为习惯。

3. 提炼关键业务场景，增加测试覆盖

利用 GA 的数据结合客户业务人员对系统各功能使用情况的介绍，我们提炼出来系统最为关键的业务场景，并且尽量分层（参考测试金字塔）实现自动化测试覆盖，以减轻 QA 回归测试的压力。

4. 发现用户较少使用的功能，优化业务流程

类似的，我们还可以通过 GA 发现一些用户较少使用的功能，QA 的测试基本不需要太多去关注这些功能，同时可以跟业务分析人员一起分析功能不被使用的原因，在后续的功能开发过程中可以作为借鉴，从而优化业务流程。

5. 分析用户地区分布和使用时间段分布，合理安排定时任务运行时间

通过 GA 上的数据，统计出哪个时间段是相对空闲的，在不影响真实业务的前提下，把一些资源消耗较大的任务安排在那个时候执行，合理分配资源以减轻服务器的负担，尽量减少对用户的影响。

6. 监控系统性能变化趋势，规避性能风险

QA 定期查看网站平均访问时间，监控性能趋势，同时要重点关注那些访问非常慢的页面或功能，必要的时候创建性能缺陷卡，由开发人员来调查分析并修复或优化。

7. 确保 GA 能够统计到所有需要统计的功能

GA 数据虽然很有用，但前提是正确记录了所需要统计的数据，所以在开发过程中要确保 GA 嵌入到了各个需要统计的功能或页面，QA 在类产品环境测试的时候需要验证这一点。

下图为从 GA 拿到的浏览器分布情况和页面平均加载时间的一些数据：

GA 数据分析

三、用户反馈的收集和分析

作为开发团队的我们基本是不能直接接触到系统终端用户的，直接接受反馈的是我们客户的 Ops 团队，QA 主要通过下面几个途径去协助分析和梳理用户反馈：

1. 跟 Ops 和业务的定期沟通会议

QA 会定期跟客户的 Ops 和业务人员沟通，了解用户对于现有系统的反馈，找出在测试中需要重视的功能特性，将类产品环境的测试关注点做出相应的调整。

2. 培训 Ops 人员

指导和协助客户 Ops 人员利用鱼骨图（Fishbone Diagram）的方法对收集到的用户反馈进行分析和分类，将分析结果跟现有的测试覆盖情况进行对比，找出测试过程的薄弱环节，并做出改进。比如，如果某个浏览器出现的bug 比较多，而我们的测试则要加强该浏览器的关注；或者是因为不同用户权限导致的问题出现频率高，那就得在测试中注意覆盖不同用户角色的测试，反之则减弱不同用户的覆盖，主要测最常用的那类角色即可。

3. 调查和跟踪产品环境 Bug

帮助重现和调查用户反馈过来的产品环境 Bug，并负责跟踪修复和验证；对于难以重现的问题，则添加日志监控，通过分析收集到的日志信息找出问题根源，从而进行修复。

4. 协助梳理业务需求

系统要增加某个新功能的时候，客户 Product Owner（以下简称 PO）或其他业务人员跟用户会一起沟通该功能相关业务现有的使用习惯、使用场景，QA 也会尽力参与这种会议，收集用户第一手需求信息，这些信息对于后期该业务功能开发时候的 QA 过程将非常有帮助。而还有些功能，PO 可能一时也拿不定主意要做成什么样子，我们会发布 MVP 的版本给用户使用，QA 协助业务人员分析用户使用后的反馈，梳理更具体的用户需求。

总结

1. 产品环境下的 QA 将工作范围扩大到从需求到产品环境，增加了更多的反馈来源，跟持续交付结合，可以帮助持续提高产品质量、持续优化业务价值。
2. 产品环境下的 QA 给的工具箱添加了更多的工具，提供了更多评估和提高系统质量的选项，是 QA 们值得深入研究的话题。
3. 产品环境下的 QA 不能走的太远，必须先做好类产品环境的质量保证，并且仅适用于持续交付实践的比较好的组织。如果连类产品环境的质量保证都做不好，而就想着去做产品环境下的 QA，那只能是舍本逐末、事倍功半。

感谢张凯峰对本文的策划，木环对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。