购买
下载掌阅APP,畅读海量书库
立即打开
畅读海量书库
扫码下载掌阅APP

1.2 测试右移

测试右移是指将软件测试的工作扩展至生产环境,确保软件在生产环境中具备正确的功能、良好的性能和稳定的可用性。测试右移的本质思想是将质量管理延续到服务发布后,通过监控、预警等手段,及时发现问题并跟进解决,将影响范围降至最小。

测试右移最典型的理念是TiP(Test in Production,产品测试)。传统观念中,人们普遍认为生产环境是服务于最终用户的,软件产品只有在测试环境下进行充分测试后,才会发布给用户。然而,我们必须接受的现实是,测试环境和生产环境在稳定性保障、部署形式、数据内容等方面都是有差异的,即使能做到没有差异,测试验证点本身也是难以穷举的。换言之,对于软件质量保障,仅仅依靠测试环境中的测试工作是远远不够的,此时基于TiP理念的各项实践就成了很好的补充。

基于TiP理念的实践有生产测试和性能评估、A/B测试、灰度发布、混沌工程、线上监控、用户体验分析等。其中,针对生产测试和性能评估,我们会在4.1节介绍全链路压测的内容,而混沌工程将在2.5节展开介绍,其余4项实践内容,我们在本节做详细介绍。

1.2.1 A/B测试

当前的互联网环境充满了不确定性,一个功能在上线前,我们往往很难预估市场对该功能的反应,此时A/B测试就有了用武之地。A/B测试是一种比较常见的软件发布策略,但它更是一种业务决策手段。如图1-7所示,为用户同时推送新旧版本的功能并进行对比实验,可以分析这一功能给用户带来的价值是否达到预期,并指导下一步的业务决策。简而言之,A/B 测试能快速帮助我们做出正确决策。

图1-7 A/B测试的流量推送策略

A/B测试是一种“先验”的实验体系——通过科学的实验设计、采样具有代表性的样本、流量分割与小流量测试等手段,获得实验结论。A/B测试一般包含以下5个步骤。

(1)确定优化目标:在实施A/B测试之前,我们需要设定明确的优化目标,确保目标是可量化的,否则后续的实验和分析都会无从下手。举个例子,“将用户满意度提升20%”就不是一个合适的目标,因为它太难量化了;而“通过优化运费的展示格式,提升10%的用户留存率(按每月计算)”就是一个合适的目标,因为它既可以被客观量化,又足够具体。

(2)分析数据:以数据分析的方式,找出现有软件产品中的潜在问题,继而挖掘出相应的优化方案。

(3)提出假设:针对上一步发现的问题,提出优化方案。在A/B测试中,这些优化方案一般是以“假设”的方式被提出的,而且往往会提出多个假设。例如,“假设降低5%的运费,用户留存率可能会提升10%”“假设优化运费的展示格式,用户留存率也可能会提升10%”。基于这些假设制定A/B测试的实验方案,并根据实验结果判断是否符合预期。

(4)进行重要性排序:由于我们提出了较多假设,实际情况下受资源限制很难对这些假设一一进行验证,此时就需要对这些假设进行重要性排序,根据资源成本优先验证最重要的假设。

(5)实施A/B测试并分析实验结果:基于选取的重要假设,实施A/B测试,并得出实验结果。若实验结果证明假设成立,则可以考虑将这一功能版本作为正式版本推送给所有用户;若实验结果证明假设不成立,就进行复盘、积累经验。

在工程领域,已有不少工具能够支撑A/B测试的整个体系,比较著名的开源工具有GoogleOptimize 360,也有一些商用化的A/B测试工具,如Optimizely、AppAdhoc等。如果企业有较强的定制化需求,还可以考虑自研A/B测试工具。

1.2.2 灰度发布

灰度发布又称“金丝雀发布”,是一种在新旧版本间平滑过渡的发布方式。它起源于采矿工人的实践经验,金丝雀对瓦斯气体非常敏感,瓦斯浓度稍高就会中毒,采矿工人在探查矿井时,会随身携带一只金丝雀,如果金丝雀的生命体征出现异常,就意味着矿井中存在瓦斯浓度过高的风险。

灰度发布背后的理念很简单,用较小的代价(一只金丝雀)去试错,这样即便出现了风险(瓦斯浓度过高),主要的用户群体(采矿工人)也仍然是安全的。从软件工程的角度来讲,如图1-8所示,通过引流的方式让少部分线上用户先接触到新版本功能,同时技术人员在新版本功能上做一些验证工作,观察监控报警,确认功能无误后,逐步将流量切换至新版本上,直至所有流量都切换完毕。

图1-8 灰度发布的引流策略

如果在切换的过程中发现新版本功能有问题,则应该立即将所有流量切回旧版本上,将影响范围降至最小。

灰度发布的技术实现并不困难,方案也比较丰富,较为简单的做法是引入带权重的负载均衡策略,将用户请求按比例转发至新旧版本上。一些开源服务组件支持灰度发布功能的定制,例如,我们可以基于Apache Dubbo中的Router/LoadBalance实现灰度发布功能,也可以在Spring Cloud中基于Ribbon定制实现灰度发布功能,甚至可以直接使用Nginx Ingress在网关层实现灰度发布功能。

灰度发布有如下3种常见的策略。

按流量比例:这是最简单的灰度发布策略,也就是将流量按比例转发至新旧版本上,以达到灰度发布的效果。

按人群特点:根据人群的特点(如用户ID、用户所在地区、用户类型、用户活跃度等)进行导流,以便精准地管控灰度范围。

按渠道:根据不同渠道(如注册方式、手机运营商、App平台等)进行导流,这也是一种精确的灰度发布策略。

最后,我们有必要谈一下灰度发布策略的一些常见误区,以帮助读者举一反三。

以偏概全:选择的灰度范围不具备代表性,比如我们上线了一个针对会员的新功能,但选择的灰度发布策略所覆盖的大部分用户不是会员,这就大大影响了灰度发布发现问题的能力。

无效灰度:灰度的本质是提前试错,但前提是有能力试错。笔者曾经历过一次印象深刻的高级别线上事故,研发人员更改了用户下预约单的逻辑,引入了一个bug,这个bug本应在灰度发布阶段被发现,但遗憾的是,灰度发布时已是当天21点,而灰度发布策略所涵盖的门店恰恰在21点全部关店歇业了,导致没有任何灰度流量触及新功能,研发人员误认为一切正常,最终引发了事故。由此可见,灰度发布策略需要保证新功能一定被验证到,不存在无效灰度的情况。

监控缺失:我们不仅需要有效的灰度发布策略,还需要辅以完备的监控,以便及早发现风险,采取止损措施。

1.2.3 线上监控

实施线上监控的目的是第一时间发现线上问题并解决问题,保证服务的正常运行。线上监控是一个很宽泛的话题,涉及的技术点非常多。在本小节中,我们侧重于讨论基于测试右移的理念,都有哪些监控工作是需要测试人员重视的。我们总结为以下几个要点:

服务上线后的可用性和性能监控,如遇到问题需要快速回滚代码;

持续的服务关键指标监控,出现报警时能够初步定位问题,与研发人员配合实现止损和修复;

对生产数据进行监控,对异常数据及时介入干预;

进行线上资金实时/离线核对,对资损风险及时介入干预;

进行安全性监控,初步识别安全风险;

对用户反馈的问题及时跟进,通知开发人员尽快解决缺陷,通知产品人员打磨细节、提升体验。

对于上述最后一点,我们需要强调的是,线上监控不仅仅针对应用服务,舆情监控同样重要。对于用户反馈的问题,由客服人员初步判断为技术问题后,测试人员(或技术支持人员)要能够及时跟进处理或分流,以便尽可能快速地给予用户有效的反馈。

另外,上述要点并不是单纯的监控工作内容,我们需要将其内化为质量保障的能力,通过工具和规范,赋能各个技术人员共同参与线上监控的工作。例如,我们可以先将日常的监控项明确清楚,设计好相关的质量数据报表,再通过采集监控数据进行分析和配置告警,来观察版本发布的情况,最终建立一个线上质量看板,以便相关人员及时获悉线上质量情况。

1.2.4 用户体验分析

用户体验分析是收集真实用户的反馈,分析数据并总结出系统改进措施的过程。它是测试右移的极致追求,不仅仅满足于软件产品的可用性,还很重视用户的情感、喜好、认知印象、生理和心理反应、行为和成就等各个方面。

用户体验分析中最常见的方法是问卷调查——将精心设计的量表,发放给特定的真实用户,收集反馈并得出结论。下面我们以SUS(System Usability Scale,系统可用性量表)为例,学习一下问卷调查的过程。

如表1-1所示,SUS问卷包含10个题目,每个题目的分值均为5分,奇数项是正面描述题,偶数项是反面描述题。我们要求用户在填写SUS问卷时,不要互相讨论,也不要过多思考,而应尽可能快速地完成所有题目。

表1-1 SUS问卷标准版

收回所有的SUS问卷,统计总分。先确定每道题的转化分值,分值范围为0~4。对于正面描述题,转化分值是量表原始分减去1;对于反面描述题,转化分值是5减去量表原始分。将所有题目的转化分值相加后再乘以2.5,得到SUS问卷的总分。所以SUS分值范围为0~100,以2.5分为增量。

将得到的SUS问卷的总分对应到表1-2,即可得到产品的可用程度,我们可以将其作为用户体验的一个重要参考。

表1-2 SUS问卷总分的曲线分级范围

上面介绍的SUS非常实用,但它也有缺点。由于它的评分结果是抽象的,这个分数只能让我们大概了解针对某产品用户体验的好坏,在具体问题上缺乏指引。当我们希望了解产品评分较低时应当如何聚焦产品的优化方向时,SUS就无能为力了。

下面我们介绍一种更通用的用户体验分析方法——雷达图分析法。该方法的实施具体分三步。

第一步,对潜在的用户体验问题进行分类,得到基础的分析项,例如视觉呈现、界面设计、导航设计、信息设计、交互设计、信息架构、功能规格、内容需求等。

第二步,以问卷的形式交由目标用户评估,如表1-3所示。与SUS问卷不同,这些目标用户需要具备一定的可用性分析能力,建议由专家带领讨论,以便解答评估过程中的困惑。

第三步,将问题汇总整理,以雷达图的形式展示出来。

表1-3 用户体验问题记录表

如图1-9所示,雷达图能够以直观的形式展现多个维度用户体验问题的整体情况,便于我们全面分析和解读指标,以及一目了然地发现哪些方面存在用户体验问题。

图1-9 用户体验雷达图

1.2.5 总结

测试右移致力于在生产环境或生产阶段进行测试或相关质量保障工作,作为传统测试工作的有力补充,本节对测试右移理念下的A/B测试、灰度发布、线上监控和用户体验分析这4项实践内容进行了解读,并提供了一些实用的方法。 nlUefdESTdJg7ku1nzNUV0ft5SDH3q7RaBn9Bnfz95JeqJvYDGroltf3u/9Rwuk7

点击中间区域
呼出菜单
上一章
目录
下一章
×