标签归档:QAOps

QA与Ops通力合作打造反脆弱的软件系统

软件系统的脆弱性

伴随着不断演进的软件技术和架构,日趋复杂的软件系统基础设施,以及大量增加的业务和数据,开发和运行环境中不稳定的因素也在增加,系统行为变得不可预测,同时软件系统的不确定性日益严重。

人们无法通过预先设定的测试场景和测试脚本去测试软件,预生产环境已经不够用,软件系统的质量保障工作受到挑战,软件系统变得脆弱。

软件系统的脆弱性

面对复杂的环境和脆弱的软件系统,该如何保障软件的质量呢?借用反脆弱[1]的概念,我们可以把软件的质量保障工作延伸到生产环境,利用这些不确定因素,从中受益,构建反脆弱的软件系统。

生产环境下的QA就是利用系统在生产环境的不可预测性,通过监控预警等方式收集生产环境的信息,总结分析以指导软件开发和测试过程,从而提高软件系统的健壮性、优化业务价值。其中,日志处理是最为关键的一个部分。

日志处理的常见误区与改进思考

提到日志处理,通常都会想到Ops(可能有Ops和开发人员组成,下面简称Ops)团队,认为日志处理是Ops该做的事情,往往关注的都是利用什么工具、什么技术来监控和分析,很少听到有对仅仅Ops人员处理日志的质疑。

作为QA,想从QA的角度来考虑一下,如果QA能够参与日志处理,跟Ops人员合作会有什么惊喜发生呢?

当然,并不是质疑Ops人员的能力,我们相信Ops人员在监控分析方面的专业技术能力是完全没有问题的,但是受限于不同的思维模式,Ops人员处理日志还是会有局限性的:

1. Ops人员主要关注的是系统运行的稳定性和系统资源使用情况,做日志监控也会着重关注这些方面,比如内存、CPU利用率等等,缺乏对系统整体质量的关注

2. Ops也会对业务有所了解,但肯定比不上业务分析和QA人员,在做日志监控和分析的时候容易漏掉高业务风险的日志,没有及时止损,导致给业务带来损失。

3. Ops人员很难把生产环境日志信息做详尽的分析,并把结果共享给开发团队来指导上线前的开发和测试工作,难以做到最优化利用日志信息。

QA与Ops一起处理日志

凭着对业务的了解、对系统的熟悉以及对整体质量的关注,QA参与日志处理有着独特的优势。

  • 质量反馈

敏捷QA有一项非常重要的职责就是在每个环节做好质量分析、掌握质量状态,并把质量信息反馈给团队。QA利用生产环境的日志信息,能够更好的了解产品的质量状况,更好的掌握系统易出错的薄弱功能点,对于后续的开发和测试工作有很好的指导意义。

  • 分析优化

QA作为质量的倡导者,不会放过任何有利于做好质量保障的环节。当QA参与日志处理,发现日志处理过程中存在的可改进空间,定会促使优化日志处理,最大化利用日志信息。

  • 业务敏感度

QA是团队里对系统最了解的角色里边业务敏感度最高的,QA参与任何活动都会以用户角度出发,考虑业务价值和业务风险。

QA参与日志处理,对于业务优先级较高的日志会比较敏感,能够更有的放矢的关注日志信息,让日志处理更有效。

同时,QA分析生产环境的日志信息,了解到真实业务的运行状况,从而可以更好的帮助优化业务价值。

下面通过一个项目上日志处理的故事来分享QA与Ops合作做好日志处理的实践。

项目的故事

项目背景

蓝鲸项目是一个历经九年多的离岸交付项目,团队不同阶段有50-80人不等,有三个系统同时并行开发,包括企业系统、客户系统和用户系统。随着业务的不断扩展、微服务的规模化,系统的不确定因素也开始暴露出来,生产环境下的缺陷增多、错误日志增长迅速,日均新增错误日志数达到几千条。

加强日志监控和处理迫在眉睫。

被动日志分析

刚开始项目上的一个Ops人员专职处理生产环境的日志,分析的方法是在Splunk里按Punct[2]查询错误日志重复出现的数量排序,每天处理重复出现数量比较多的一部分日志。这个阶段没有QA介入。

Punct实例
  • 时间和精力原因,每天新增的日志并没有办法全部覆盖到;
  • 分析日志的同事的业务敏感度不够,没法基于风险优先级来处理,可能导致某些关键业务的错误信息漏掉;
  • 没有可能进行详细的总结分析,对后续的处理没有指导意义;
  • 虽然参与处理日志的同事越来越专业,但没有很好的将日志信息共享给团队,形成信息孤岛。

这是一个被动分析日志的过程,处理过程本身存在很多的问题:

在这个过程中发现了很多当时日志记录本身存在的问题:级别定义不清晰、记录信息不够用、记录格式不一致等。

这个时候,QA也想参与,可是心有余力不足,主要是因为以下几个方面的痛点:

  • QA没有权限接触生产环境;
  • 由于没有接触过,对生产环境的基础设施并不了解;
  • 日志记录的信息QA理解起来很有难度。

主动出击内建日志

意识到前一阶段日志处理的问题,团队决定投入更多的精力来加强日志处理。

首先,利用结构化日志技术,优化日志记录本身的问题。同时,QA从流程上把关做好日志内建,控制好每个环节,确保该有的日志能够正确的记录下来。

同时,QA、Tech lead跟Ops人员一起讨论识别出业务风险较高的特性,在监控面板设置对这些特性相关的前端和API的监控,并设置好一些定时Alert,每天通过邮件的方式告知性能和故障情况。每个特性团队的再派出开发人员加入Ops团队,兼职负责对监控得到的信息进行诊断,QA则负责跟踪通过日志信息定位出来的缺陷问题的修复。

另外,也对测试环境的日志进行监控,QA开始分析测试环境的日志信息,尽早发现问题。

这一阶段团队开始主动出击,有了业务优先级,不再是从茫茫日志大海去分析,这一举措给忙季带来很好的效果,顺利度过了忙季。

但是随着忙季的过去,也开始暴露出问题:错误日志在不断减少,团队对此的关注也越来越少,原来加入Ops团队的开发人员主要关注点也是在新的特性开发商,邮件收到的定时Alert也渐渐地被忽视…对于突然出现的错误日志并不能第一时间发现处理。

QA主导进一步优化

错误日志不能及时发现,导致用户报过来的生产环境缺陷也在增加。

项目日志处理的优化

QA作为生产环境支持的主要负责人,承担起处理生产环境缺陷和加强日志监控两项职责。

1. QA组织跟参与日志处理的Ops人员的访谈,收集痛点,针对性的优化Alert机制,改为错误触发,不再是定时的,减少噪音;

2. QA从流程上督促各特性团队Ops人员分析和查看自己组内负责的监控信息,关注Ops处理日志的进度状态更新;

3. 对于Ops人员比较抓狂难以定位的问题,QA也会参与一起pair分析,或者根据Ops人员提供的信息去在测试环境尝试重现;

4. QA对于一些特别重要的特性,定期查看是否有相关错误出现,以免漏掉相关错误信息。 比如,系统有个专供大老板发邮件的功能,某天突然挂掉了,这个错误日志信息在监控里边也有,但是并没有引起重视,QA查看的时候发现了才把优先级提上来赶紧处理;

5. 优化整个生产环境支持流程,把日志处理纳入其中。周期性的对日志处理结果进行分析和回顾,把日志信息跟业务关联起来,识别出易出错的业务功能点,在后续的开发和测试过程中重点关注,同时也进一步优化现有的监控预警设置。

这个阶段QA不管是流程上还是实际日志分析上都有参与,日志处理更高效、生产环境缺陷发现更及时,生产环境的支持收到客户的好评。

项目故事回顾

前面故事主要分享的是随着业务和架构的演进,生产环境缺陷和错误日志都在大量增加,项目团队如何一步步优化日志处理、利用日志信息加强质量保障工作。从QA不参与、QA参与到最后QA主导,QA在整个日志处理过程中承担着以下几个非常关键的作用:

  • 监督协调,流程把控
  • 基于业务风险的分析和优化
  • 日志处理与开发过程形成闭环,持续改进
项目日志处理的演进

写在最后

软件系统所处生态环境的复杂性、不确定性并不是毫无益处,生产环境下的QA技术就是利用这种不确定性,并从中受益,从而增强软件系统的反脆弱性。

QA参与日志处理,主要承担的是分析者和协调者的角色。QA参与,持续的分析、优化,利用生产环境的日志信息来指导和优化软件开发和测试过程,最大化业务价值,是生产环境下的QA最核心内容之一。

同时,QA利用开发和测试过程中对系统的了解,以及对业务的敏感度,可以进一步指导和协调日志处理过程的优化和改进。QA与Ops团队的合作,生产环境日志处理会更高效,也更能体现其价值。

这样,生产环境和预生产环境形成了良性循环,打造出一个反脆弱的软件系统。


注1:反脆弱

脆弱的反面是什么?是坚强?是坚韧?《反脆弱》这本书给出了这样的解释:

脆弱的反面并不是坚强或坚韧。坚强或坚韧只是保证一个事物在不确定性中不受伤,保持不变,却没有办法更进一步,让自己变得更好。而脆弱的反面应该完成这个步骤,不仅在风险中保全自我,而且变得更好、更有力量。

做一个类比的话,坚强或坚韧就像一个被扔到地上的纸团,不会摔坏,但是也只是维持了原貌,这还不够。

和纸团相反,乒乓球扔到地上非但不会摔坏,反而可以弹得更高。乒乓球拥有的就是脆弱反面的能力,也就是反脆弱。

注2:PUNCT

PUNCT是Splunk提供的一个功能,就是将日志信息的第一行的所有字母和数字去掉,剩下的标点符号,其中空格用下划线代替。

产品环境下的QA

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在整个过程中主要充当分析者和协调者的角色,对产品环境下的质量保证工作起到至关重要的作用:

  1. 跟DEV一起讨论监控标准,把日志标准化的要求融入到软件开发流程中,确保日志能够记录到真正需要记录的信息。
  2. 跟运维团队一起分析收集到的统计数据,指导和优化各个阶段的测试,以预防和减少系统在产品环境下的缺陷。
  3. 跟业务分析人员一起分析和梳理从产品环境收集到的需求相关的反馈,提炼出合理的需求,优化业务价值。
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,那只能是舍本逐末、事倍功半。