众测实战经验小结

作者:phenyzhang 团队:腾讯移动品质中心TMQ

导读

随着互联网浪潮的推进,手机App进入了高速发展期,随之而来App的“不可替代性”也越来越弱化。有数据显示,用户对App出现问题的容忍度呈现越来越低的趋势,在这种背景下,App自身的质量就显得尤为重要。

我们总是希望在产品发布前发现所有Bug,但这对测试来说根本无法做到,因为理论上来说,总有Bug要到产品发布后才能发现。

1、测试资源的有限

作为测试,经常被要求测得“又快又好”,在有限的测试时间里,我们需要沟通新需求、设计测试方案、执行测试用例、回归已解决问题、评估版本风险等等。紧凑的发布节奏下,决定了测试内容是有取舍的,比如我们常用的办法是把80%的时间投入在验证新功能和产品的核心功能上,从而会忽略一些我们自认为的“不重要”测试项。

2、终端环境的多样

你的App在一种测试环境下运行正常,就代表发布之后质量ok吗?当然不是!Android用户终端的多样性决定了几乎所有App产品都不可能做到覆盖完全,最常见的有网络、系统、机器品牌等,一旦出现问题,发布后影响的是该类环境下的所有用户。

3、实验室数据的不可靠

我们设计测试场景时,总是尽可能把自己想象成真正的用户,从他们的视角去测试。但不得不承认,很多时候测试结果和发布后用户的反馈是不相符的。比如性能测试,我们制定了各种方案保证产品的快和流畅,但发布后还是有不少用户反馈慢和卡。这不是谁的错,用户数据的复杂性是任何发布前的实验室数据无法完全模拟到的。

既然发布后有 Bug是不可避免的,那我们能做的,就是在正式发布前让Bug尽可能的暴露,避免流落到更大范围的群体中,影响用户体验和产品口碑。

这里有两个要点,第一,为了更贴近实际效果,我们需要一批“真正的用户样本”(而不是几个测试人员)做测试;第二,区分于论坛等渠道,我们希望这批用户有更积极的反馈动力,能主动帮助我们快速获取产品的短板,优化和提升产品质量。

众测的出现恰恰满足了这个需求。众测用户分散在全国各地、各行各业,他们在生活中就是我们产品用户里最普通的一份子。但另一方面,不同于普通用户,他们充满探索精神,乐于尝试新产品,而且在众测奖励制度的推动下,他们乐意主动反馈使用过程中的问题。

什么样的测试任务适合放众测

1、有效率要求的

众测的核心优势之一在于使用灵活,可以结合任务自身的需要调整,快速获取想要的结果。一类典型的使用是 上手门槛低,但数量庞大的任务,通过发挥众测用户的人数优势,可以快速完成任务。相比人工测试,效率高很多。 众测使用举例:数据标注。

2、有环境要求的

这种适用于 对机器覆盖度、测试人群、运行环境有要求的测试任务。这类任务可以利用众测环境多样化的优势,有选择的对特定用户群分发任务,相比人工测试,可供选择的测试资源更加丰富,环境覆盖更加全面。 众测使用举例:问题复现、兼容性测试。

3、有客观性要求的

测试人员不可避免会带有一定主观性,通过众测的形式能充分利用众测人群年龄/职业/性格的多样化,对汇总的测试结果综合计算,给出更客观的评估结果供产品决策。 众测使用举例:标签准确性判断。

军团的使用

军团是众测为长期任务培养的固定用户群体,也是众测服务的亮点之一。军团的最大优势在于团员长期接同类任务,对测试内容的熟悉度和理解程度会比普通成员更高,反馈的有效性也会更理想。

1、军团的培训

结合测试内容的特点,以任务的方式对军团发布学习文档,并辅助以考题检验军团学习成果,提升军团对基础技能的理解和掌握,从而提升反馈有效率,减少无效、无关反馈。

2、团长审核

要求团长对军团反馈的问题做验证和筛选,标注“重点关注”,减少我们的审核投入。 团长复现:团长用自己手机对重点问题做复现,二次确认复现概率 输出报告:团长汇总输出众测结果,给到提测方。

3、军团自运转

通过添加IMEI方式,对众测军团定向下发灰度包,团长把控测试节奏和输出报告,达到“自运转”的效果。

众测结果的保障

1、反馈正向激励

积分奖励是驱动用户测试的最直接原因。众测的积分体系可以激励用户积极领取任务和反馈问题。在此基础上,众测的等级制度,能鼓励和支持有能力的用户承担更多的管理和汇总工作。

2、无效反馈惩罚

为了保障测试结果的可靠,我们会对测试结果抽样检查,一旦发现与反馈不符,有严格的惩罚机制,以此来提升众测用户反馈的有效性和准确性,减少消极用户。

3、测试过程监控

一种理想的状态是用户提交反馈时,我们能够获取他的测试范围,这有两个好处,第一我们能以此评估他测试结果的可靠性,比如一个用户没有跑测试场景就给出Pass的结论,我们可以判定他的反馈无效,第二对于有效反馈,我们能够拿到用户的问题出现路径,进一步定位解决。

4、线上反馈重合度

产品正式发布后,结合线上反馈对众测结果进行Review和重合度分析,进一步优化众测策略,形成良好的循环。

众测的使用分级

参考Google的Test Certified,我们将众测分级为几大类,每类对应一些指标,众测的使用者可以尝试以此定级,朝着更高级别去努力。以下是几个重要的衡量指标:

任务类型:越能体现众测与外包测试优势的任务,级别越高;

使用阶段:我们知道,Bug发生的越早,解决bug的成本就越低,鼓励众测尽可能在早期应用;

测试准备:对测试环境的限制越少,越贴近用户的真实使用场景,级别越高;

反馈要求:对用户反馈内容依赖性越低的,级别越高。

Level 1

任务类型:用例执行、bug悬赏、场景覆盖 使用阶段:产品集成以后 测试准备:要求用户在指定的测试包或环境下测试。

反馈要求:需要用户提交反馈信息。

Level 2

任务类型:功能探索、风险评估;

使用阶段:增量测试期 发布准备:IMEI自动下发,用户无需准备测试环境;

反馈要求:提测包预埋Log,用户反馈时自动回收。

Level 3

任务类型: 用户数据收集;

使用阶段:需求体验期;

发布准备:模拟环境(比如云测试);

反馈要求:后台长期监控。

军团进阶使用—从有用到好用

什么是军团?

军团是Tesly众测的一种特有模式,简单来说,根据任务需要,将众测用户分组成立军团,并配备团长,定制化的为提测方提供服务。

军团适用于哪些任务模式?

1、同类型任务

有一类任务特点是:数量大,类型比较相近。 比如TBS三方测试,内核发布时,我们需要大批量测试线上头部APP(40-50个),确保新内核的发布不影响线上合作方的基本功能。

【使用技巧一】

由于军团是长期测试人员,对他们进行基础知识培训,不仅有利于提升反馈有效性,更重要的是,可以发挥众测用户的能动性,帮助我们进一步定位问题。 举个例子:TBS基础知识手册里解释了TBS和系统内核的差别,在此基础上,我们请用户在反馈的同时,对比系统浏览器,区分“合作方Bug”和“TBS Bug”,从而能快速筛选出TBS相关问题,提升跟进效率。

【使用技巧二】

团长审核是军团任务中非常重要的一个环节。好的团长可以承担大部分审核工作,大大减少提任务方的后期投入。当然,不同任务对团长的要求以及侧重点是不一样的,我们TBS建立了团长规范,明确指引团长反馈定级、复现、以及报告输出。此方法对我们这种一次提测二三十个APP的任务方,效果还是很明显的。

2、长期任务

长期任务适用于长线的、重要的,需要长期关注的测试内容。 举个例子,前一阵TBS的合作方王者荣耀,部分用户出现登录不上的问题,通过定位排查,发现是TBS网络层一个随机问题。Bug本身随机且发生概率不高,但是王者荣耀用户基数巨大,登录又是个非常关键的入口,因此问题优先级很高。

这之后,一方面,我们跟众测合作,召集众测用户中的王者荣耀玩家,成立“王者荣耀军团”,建立长线任务,收集王者荣耀相关反馈,另一方面,我们对这部分用户添加IMEI,TBS发布时,第一时间对军团成员下发最新内核。这样做有三个好处:

【效果一】针对APP类型划分军团,类似于用户画像,能收集到真正的APP用户,更高效。比如建立购物类、游戏类、音乐发烧友等;

【效果二】我们将测试左移,提前发现真正用户的问题;

【效果三】军团用户可作为反馈复现的定向下发群,随机跟进问题。

3、自运转

“自运转”是军团进阶的最理想状态。 以TBS为例,我们知道,TBS产品是合作应用的UI和TBS内核结合的特殊形态,双方在发布上是解耦、互不干扰的。因此我们跟众测合作,建立五大“自运转军团”:

“游戏迷”:某某荣耀,某某助手,某某联盟,某某火线 ;

“购物狂”:某东、某某会 等;

“视频达人”:某某视频、某某直播 等;

“音乐王子”:某某音乐、某某K歌 等;

“工具高手”:某某宝、某某天气、某某相机 等。

这样做的好处有几点:

(1)我们只要将军团IMEI加入灰度集合,则可自运转,不再需要每版本专门提任务;

(2)相比原来的“提任务”模式,不限制测试期限,有可能发现一些潜在的问题;

(3)同类型app的场景有相似性,更适合发现类似问题;

(4)一旦有线上反馈,我们能更精准的找到合适的人群来帮助复现。

搜索微信公众号:腾讯移动品质中心TMQ,获取更多测试干货!

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏EAWorld

持续交付流水线为何对软件开发如此重要?

作者 Andrew Phillips 译者 张斌 持续交付(CD)是一种软件策略,它使企业尽可能快速有效地向用户提供新特性。持续交付的核心思想是创建可重复、可靠...

2623
来自专栏社区的朋友们

微信 paxosStore : 高性能 Key-Value 存储的挑战

本文从以下四个方面介绍了微信 PaxosStore高性能Key-Value存储的挑战: 分布式协议、存储等功能;微信账号存储等核心存储服务的架构实现;key-v...

3510
来自专栏大前端开发

【新闻】微信公众平台小程序开放公测

小程序是一种新的开放能力,可以在微信内被便捷地获取和传播,同时具有出色的使用体验。开发者可以根据平台提供的能力,快速地开发一个小程序。

733
来自专栏云计算

企业微服务架构转型-实施步骤

在前面的文章中已经谈到过微服务架构转型中的实施策略,今天重点谈下微服务架构转型中的实施步骤。 步骤1:4A和流程平台的下沉和能力开放 在实施微服务架构转型的时候...

2007
来自专栏云计算D1net

云访问安全代理

云访问安全代理可以保护云环境不受威胁,但是,当它们影响到应用性能可用户体验怎么办? 云访问安全代理是一种工具,用于监听和管理云应用与用户之间的流量。虽然它可以帮...

3516
来自专栏腾讯大讲堂的专栏

移动可用性测试 (一): 概述

作者:梁颖蕾,腾讯高级设计师 前言 移动互联网时代,针对移动产品进行的可用性测试,主要是将PC产品可用性测试方法和经验照搬过来。但在实际的工作中,由于移动产品...

1926
来自专栏服务端思维

天天写业务代码,如何成为技术大牛?

工欲善其事必先利其器,不管是小白,还是资深开发,玩Java技术体系,选择好的工具,提升开发效率和团队协作效率,是必不可少的:

952
来自专栏软件成本造价评估

如何度量一个软件的非功能需求?

  非功能需求,指软件产品为满足业务需求而必须具有的,且除功能需求以外的特性。非功能用户需求是描述软件如何实现功能而不是具备什么功能。非功能特性包括产品必须具...

170
来自专栏Android群英传

开源指南

902
来自专栏腾讯移动品质中心TMQ的专栏

测试覆盖与测试工作关系问题的思考

前言 参考原文:http://sauceio.com/index.php/2015/09/can-you-test-it-all-test-coverage-v...

1787

扫码关注云+社区