逢上线必加班？如何做好上线前的产品测试？

2017-02-20 11:39:00

测试方法有多重，最终目的是在有限的时间内发现最多的问题并解决，最大程度降低产品错误带来的负面影响。

新版产品上线是团队多日加班加点的奋斗成果，对于产品经理来说，上线前夕要面临无穷无尽的测试工作，仿佛测试也是万能的产品经理与生俱来的天职。但是我想说，这锅咱们不能背！

那么问题来了，测试到底归谁管？对于大团队预算充足会有专门的测试岗，而小团队往往需要产品经理和程序员共同参与到其中。不管哪种情况，测试是控制产品质量的最重要一道关，都应该由产品经理来组织测试工作。确保产品层层把关的原则，测试步骤分为技术测试、内部测试、用户测试。但并不需要凡是亲力亲为，要善于分配人力资源，一个好的测试机制可以事半功倍，否则产品经理最终沦落成测试员砖家，累个半死还误了进度。东东酱以下就此话题展开讨论。

技术测试

技术测试主要由程序员（或测试员）对编码进行逻辑覆盖测试，遍历程序遇到的所有情况，捕获异常进行处理，模拟访问做高并发的压力测试。该阶段可以发现产品需求中的疏漏或逻辑错误，排除程序员粗心编程而出现的算法、逻辑错误。该阶段可以排除大量Bug，特别是后台或逻辑性很强的工具性产品，把控的好，产品经理后期测试工作量会大大降低，Bug在技术内部进行修改，反复测试无Bug后，可打包提交给产品经理，进入下一阶段测试。

内部测试

内部测试主要由产品经理主导在公司内部进行，设计师可以验收UI效果是否符合预期，产品经理模拟多套用户数据按照流程图对其进行操作测试，确认所有功能都与产品文档中的需求一一对应，测试方法可以参看文末的黑盒测试。另外可以邀请其他部门的同事来充当小白用户进行产品体验。此阶段开始要收集所有人的整改意见，进行归类和排序。对于基础性的Bug可以马上责令技术进行修改，有争议性的修改意见或非重要Bug可待下一阶段的用户测试完后集中修改。

用户测试

用户测试由产品经理（策划/运营共同配合）主导，用户测试分为两个阶段。

第一阶段

寻找固定的用户群体进行测试（即每个版本邀请同一批用户来测试），以问卷或者一对一聊天的方式，获得他们对比新旧版本来直观感受产品好坏。如果无章可循，今天找个路人甲测试，明天找个路人乙测试，面向不同品味的用户，难免会出现下图尴尬情况。

第二阶段

灰度测试，向用户群中的1000人，10000人…依次递增推送测试版本，利用自建数据后台或友盟tlakingdata观察埋点数据的功能使用情况和程序crash崩溃报错信息，如发现数据异动及时下架处理。

以上三步循环进行，直至无Bug方可正式发行新版本。下面东东酱顺带介绍测试过程中常见的问题。

版本管理

产品版本用V2.1.3编号管理可以吗？那仅仅是面向用户的，在软件工程中对软件版本管理，分为Alpha、Beta、Rlease Candidate、Release版。

Alpha是开发人员的内部测试版，一般不向外部发布，会有很多Bug，只有程序员和测试员使用。
Beta：这是供公司内部测试的版本，这个阶段版本仍可适当加入新的功能。
Rlease Candidate：RC是发行候选版本，几乎不会加入新的功能，主要着重于出错，可开放给部分用户体验。
Release：这就是“真的打死不改(6).doc”版本了,交付给用户的最终版本，如果仍出现Bug，那就启动下一版本开发周期了，也就是常见的“v2.1.3”版本迭代了。

因此产品经理在管理安装包的时候，最好把不同阶段的名称设为包名前缀，避免出现错乱。

灰度测试

灰度值是不饱和的黑色，是白色向黑色过渡的一种表现。比如突然熄灯看手机，屏幕亮度逐渐变暗；歌曲由暂停开始播放，音量逐渐提高。这样做的好处不言而喻，灰度是一种思想，应用在项目管理中，为避免辛苦开发出来的产品与用户所期待的相差甚大，摒弃传统冗长的开发流程，将项目按照功能优先级排序，对产品实行分阶段，分版本开发，第一个版本满足用户基础需求，后续版本在原基础上反复迭代，这样试错成本最低。对于某一版本内的测试，也可以实行灰度机制，测试版本先邀请100名用户进行测试，反馈问题修改Bug，如此类推放量1000人再测试。最终发行版的用户满意度会提高很多，项目成员也不会上线Bug频频出现而压力山大。

A/B测试其实是灰度测试的一种。如果产品方案发生了分歧，可以针对多个方案进行等量推送，查看数据从中择优。Tlakingdata的运营平台就能提供此类方法。