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

产品环境下的QA可以做什么呢？有什么挑战，又有哪些好处？

它跟类产品环境的QA有何区别，是否就是类产品环境QA方法的延伸？

产品环境有运维支持团队（Ops），产品环境下的QA跟Ops所做的事情又有什么区别与联系？

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

一个产品环境Bug的解决办法

先来跟大家分享一个产品环境下的Bug：

一个在线订购葡萄酒的系统，订购流程相对复杂，下单过程中后台会有随机的失败，系统采取的措施是重试，就是说顾客下单后，后台如果有错误就会不停的重试，直到成功，这个过程对顾客是不可见的。这听起来没什么问题，用户体验似乎也不错。

后来有个新版本上线了，顾客下单后还是会有随机失败，系统依然不停的重试，但这次不一样的是有的随机失败，下单却能够成功，这样就导致用户虽然只订购一箱葡萄酒，由于后台的多次重试都成功了，用户最终拿到的可能是好几百箱葡萄酒。

这是一个非常严重且昂贵的Bug！对于这样的问题，作为QA，你能想到的解决办法有哪些？

瀑布式QA流程

瀑布式软件开发模式下，测试是计划驱动的，基本是根据需求文档进行验证，测试的目的就是找到尽可能多的bug，而且测试阶段处于开发阶段结束之后的一个相对独立的阶段，测试结束之后发布产品到产品环境。基本流程如下：

瀑布式QA流程

对于上述葡萄酒订购系统的Bug，通常的办法就是加强在测试阶段的测试保证，除了验证系统功能跟需求文档的一致性以外，还可以增加一些ad hoc测试，确保发布到产品环境的系统尽量的稳定。

敏捷QA流程

敏捷测试则提倡尽早测试、频繁测试，QA要从需求分析阶段就开始介入，QA参与从需求到发布的整个生命周期中各个阶段。在整个QA的过程中，会依据敏捷测试象限，在不同阶段采取不同的测试；还会根据测试金字塔的分层指导，加强自动化测试，制定有利于项目质量保证的测试策略，同时也会做探索性测试，尽量去发现更多不易发现的缺陷。敏捷QA的流程如下：

敏捷QA流程

对于葡萄酒订购系统的bug，处理方式也无非就是加强上线前各个阶段的测试，提高发布到产品环境的产品质量。

除此之外，我们还有什么处理办法呢？

上面两种开发模式下，QA的重点都是放在发布前的类产品环境的质量保证上，而较少考虑产品环境的系统质量。随着敏捷开发和持续交付的出现，QA角色逐渐转变到需要分析软件产品在产品环境下的质量。这需要引入产品系统的监控, 制定检测紧急错误的警报条件，持续质量问题的确定以及找出在产品环境下使用的度量以保证这种方式可行。

回到前面葡萄酒订购系统的那个Bug，如果在产品环境下设置监控预警，对于一个订单购买葡萄酒数量异常的情况进行监控，将能及时发现bug，并且比较容易在损失发生之前及时阻止产生更严重的后果。这就是产品环境下的QA内容之一！

产品环境的特点

为了更好的实践产品环境下的QA，先来分析下产品环境有哪些特点：

1. 真实、不可破坏

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

2. 基础设施差异

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

3. 系统复杂度

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

4. 数据复杂度

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

5. 用户行为千奇百怪

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

6. 访问受限

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

7. 真实的用户反馈

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

产品环境的特点

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

产品环境下的QA有这么多挑战，听起来是不是很沮丧？不要着急，针对产品环境独有的特点，一定能找到相应的解决方案。接下来，咱们一起来看看产品环境下（不仅是QA）可以做什么。

产品环境下可以做什么

一、监控预警

前面讲到不能随便去操作产品环境下的系统对其进行测试，但是可以通过监控的方式去获得我们需要的信息，对异常情况进行预警。提到监控预警，不得不提大家都了解或者至少听说过的日志和网站分析工具，这两者都是做好产品环境下的QA非常有帮助的工具。

监控预警

日志

日志就像是飞机上的黑匣子，可以记录系统运行的各种信息，包括错误、异常和失败等。一旦程序出现问题，记录的这些信息就可以用来分析问题的原因；同时可以利用记录的日志设置好预警，提前预测系统可能出现的问题。产品环境下日志所提供的监控和预警信息，将有利于：

阻止不良后果，避免大的损失：前面提到的葡萄酒订购系统就是一个很好的例子；

发现潜在的性能问题：通过对日志进行分析，可能发现还没暴露出来的性能问题，提前修复；

指导类产品环境的测试：通过产品环境下日志的分析，可以看出哪些功能易出什么样的错误，从而相应调整测试策略，加强类产品环境的相关功能的测试。

网站分析工具

网站分析工具根据具体工具不同，所能记录信息也有差异，但基本都可以记录如下信息：

用户使用的操作系统、浏览器等信息

用户行为习惯，包括使用的时间、关键路径、关键业务流程等

用户所在地区、语言等区域信息

用户访问量，请求的响应时间，网站性能等

利用网站分析工具收集到的以上数据，可以帮助我们调整类产品环境的测试侧重点，指导类产品环境的测试；根据用户行为习惯等信息，还可以帮助优化产品业务价值。

二、用户反馈

介绍产品环境特点的时候提到一点就是产品环境能够收到真实的用户反馈，这是非常有价值的，要做好产品环境下的QA一定要利用这些反馈。由于用户行为和习惯的千奇百怪，用户提供的反馈也可能是各种各样的，为了更好的利用它们，需要一个严格的Triage的过程，对所有反馈进行分类并相应处理。用户反馈，可以总结为下面几类：

用户反馈

缺陷

用户在使用过程中，系统所出现的问题，并且能够稳定重现的，我们定义为缺陷，缺陷通常会影响到功能的使用，是需要修复的，根据优先级和严重程度，安排相应的修复计划并对其进行修复，同时还需要对修复的缺陷增加（自动化）测试，以防被再次破坏。

除了能够稳定重现的缺陷，有时候还会有一些随机的失败（比如前面提到的葡萄酒订购系统的bug）或者难以重现的问题，这类问题很难找到原因，但是又给用户带来很大的不爽。其实，它们通常也是一些缺陷引起的，只是根源可能隐藏的比较深，对于这种问题的处理办法就是前面部分提到的可以添加日志对相关功能进行监控和预警，利用日志协助找到问题根源并进行修复。

抱怨

用户在使用系统过程中由于行为习惯、网络环境等差异，总会有各种抱怨，一般以非功能性的问题居多，比如易用性、性能、可维护性、可扩展性等，当然也有可能是某个功能设计的不能满足真实的用户需求。需要对所有抱怨进行分类，确定是非功能的缺陷，还是新的需求。用户的抱怨有可能千奇百怪，不是所有的都能满足，需要根据分类定义优先级，确定哪些是需要改进和修复，从而采取相应的措施。

建议

除了反馈问题和提出抱怨，用户也会对系统使用方面提一些建议。但一般用户很难提出好的建议，要想收集到有价值的信息，需要提前设计好问卷进行问卷调查，有针对性的去收集；或者对一些重要用户进行访谈，或者发布一个简单的新功能收集用户的使用建议等。然后对收集到的建议进行分析，确定可行性，并将可行的建议应用到后续的系统和业务流程的改进中。

利用用户反馈，改进系统功能，可以优化业务价值，扩大产品的市场影响力，提高企业的竞争力。常被用来收集用户反馈的实践有：

Beta测试：很多有前瞻性的网站或应用会发布新功能给特定用户组（Beta用户），收集用户使用新功能的统计数据；

AB测试：同时发布两个不同版本的系统到产品环境，并将用户引导到两个版本，统计使用每个版本的用户数据；

Observed Requirement：发布一个简单的功能，或者发布一个MVP版本，观察用户使用情况，从而引出并收集到用户的真实需求。

监控预警、收集和分析用户反馈并不是QA能独立完成的，需要与不同角色协作，QA在整个过程中主要充当分析者和协调者的角色，对产品环境下的质量保证工作起到至关重要的作用：

跟DEV一起讨论监控标准，把日志标准化的要求融入到软件开发流程中，确保日志能够记录到真正需要记录的信息。

跟运维团队一起分析收集到的统计数据，指导和优化各个阶段的测试，以预防和减少系统在产品环境下的缺陷。

跟业务分析人员一起分析和梳理从产品环境收集到的需求相关的反馈，提炼出合理的需求，优化业务价值。

QA与不同角色协作

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

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

日志分析和优化

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

Splunk日志分析

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

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

每天会有专人负责错误日志的分析，找出其中的优先级高的问题给团队修复。QA会协助重现、跟踪并负责测试这些重要的需要修复的问题，通过对错误日志的分析，QA可以大概的统计出哪些功能特性比较容易产生错误，在接下来的类产品环境的测试中要重点关注。

另外，对于某些功能由于测试环境的数据等局限性，担心部署到产品环境会产生错误或者有性能问题，一般上线后会着重关注这样的功能，除了日常的监控分析之外，还要单独对该功能的日志进行检查，以防产生严重问题。

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

把产品环境错误日志的分析方法应用于测试环境，对测试环境的错误日志进行监控，尽量把环境无关由功能引起的错误找出来，尽早修复，不让其流落到产品环境。据不完全统计，最近两三个月通过这种方式发现并修复了好几个潜在的Bug。

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

Ops在Splunk里设置有专门的统计和监控系统性能的Dashboard，QA会定期从里边拿出潜在的存在性能问题的功能模块，创建对应的任务卡由开发团队来做性能调优。

4. 日志记录标准化

通过对产品环境错误日志的分析，发现现有日志记录存在如下问题：

存储位置不统一，有些日志没有办法通过Splunk统计分析，造成分析成本的增加；

记录格式不一致，有些日志虽然可以通过Splunk看到，但是没有记录很有用的信息，比如没有记录错误发生时候的一些有意义的message，或者是Post请求没有记录输入参数，导致排查错误日志的工作增加了难度；

日志级别定义混乱，有些没有到达错误级别（error）的日志也记成了错误（error）日志，这也是错误日志数量大的原因之一。

为了让日志分析更轻松、让日志更全面的记录系统的各种情况，针对上面的问题，团队讨论并达成共识：

将日志输出到各个服务器的同一个路径；

统一日志记录格式，并且尽量记录更全面的信息帮助后期的日志分析；

清晰定义各个日志级别（Debug，Info，Warning，Error，Critical，Fatal），将已有的误记成错误的日志降低到正确的级别，对于新功能则严格按照所定义级别记录日志；

QA在用户故事（Story）的开发机验收（Dev-box Testing or Desk Check）阶段负责跟开发人员确认相关日志记录是否符合标准，并且通过测试环境的日志监控可以及时验证新功能的日志记录情况。

Google Analytics数据分析

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

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

根据GA数据统计分析出用户使用的操作系统和浏览器分布情况，从而相应的调整QA用来测试的操作系统和浏览器，尽量让测试环境跟真实用户更接近。比如，前两年客户内部员工使用的浏览器最多的是IE9，那么我们QA的测试也是主要关注IE9，而今年变成了IE11，我们重点关注的浏览器也相应调整为IE11（当然，鉴于IE9的特殊性——容易出问题，只要还有用户使用，我们还是需要关注），而对于没有用户使用的Firefox，我们则不用来测试。

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

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

QA测试路径

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

用户使用路径

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

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

一个开发好几年的系统，其功能必然是比较复杂的，由于自动化测试覆盖率不是很理想，过去回归测试需要的投入比较大，而且由于功能相对复杂，又不是很清楚哪些功能对用户来说最为重要，测试很难做到有效覆盖。这种情况对于人员比例低下的敏捷团队QA来说，是一件非常有挑战的事情，通常QA们在发布前忙得不行。利用GA的数据结合客户业务人员对系统各功能使用情况的介绍，我们提炼出来系统最为关键的一些业务场景，并且尽量分层（参考测试金字塔）实现自动化测试覆盖，从而不需要花费太多的人力去做回归测试，同样可以保证主要的业务流程不至于被破坏，而QA则可以有更多的时间和精力去做探索性测试等更有价值的事情。

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

关键场景就是用户使用频率较高的功能，类似的，我们还可以通过GA发现一些用户较少使用的功能，这可能的原因是不符合用户真实行为习惯，喜欢用其他路径去完成同样的事情，或者不符合真实业务需求，也就是说真实的业务环境下根本没有要用到这个功能的地方。对于这种功能，首先从QA角度来讲，我们的测试基本不需要太多去关注，如果有相关功能的缺陷，它的优先级也很低很低；另外，可以跟业务分析人员一起分析下原因，在后续的功能开发过程中可以作为借鉴，从而优化业务流程。

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

系统用户遍及全球，使用时间段分布也就变得复杂，为了不影响正常使用，有些事情是需要尽量在系统没人使用的时候去做的，比如统计某类数据需要定时执行SQL脚本等定时任务。通过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协助业务人员分析用户使用后的反馈，梳理更具体的用户需求。

产品环境下的QA有什么特点

1. 不同于类产品环境的QA

产品环境的特点决定了产品环境下的QA是跟类产品环境的QA不同的，不是主动的去测试产品环境的系统，而是通过设置监控条件，收集用户使用系统的反馈，对反馈进行分析并改进，从而让产品质量获得提高。因此，产品环境下的QA并不是类产品环境QA活动的简单后延，它有着自己独特的特点。

2. 不能独立存在

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

良性环路

3. 有别于Ops

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

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

产品环境下的QA与Ops

4. 跟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给QA的工具箱添加了更多的工具，提供了更多评估和提高系统质量的选项，是QA们值得深入研究的话题。

产品环境下的QA不能走的太远，必须先做好类产品环境的质量保证，并且仅适用于持续交付实践的比较好的组织，如果连类产品环境的质量保证都做不好，而就想着去做产品环境下的QA，那只能是舍本逐末、事倍功半。