导读
随着互联网浪潮的推进，手机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，获取更多测试干货！
