【腾讯TMQ】众测实战经验小结

导读

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

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

1、测试资源的有限

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

2、终端环境的多样

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

3、实验室数据的不可靠

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

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

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

众测的出现恰恰满足了这个需求。众测用户分散在全国各地、各行各业，他们在生活中就是我们产品用户里最普通的一份子。但另一方面，不同于普通用户，他们充满探索精神，乐于尝试新产品，而