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

2 评论 20764 浏览 146 收藏 10 分钟

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

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

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

技术测试

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

内部测试

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

用户测试

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

第一阶段

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

第二阶段

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

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

版本管理

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

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

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

灰度测试

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

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

测试用例

白盒测试

白盒测试顾名思义内部是透明可见的,是通过检查软件内部的逻辑结构,对软件中的逻辑路径进行覆盖测试,在程序不同地方设立检查点,检查程序的状态,以确定实际运行状体与预期是否一致。

测试方法包含:逻辑覆盖测试(语句,判定,条件,判定条件,条件组合,路径),循环覆盖,基本路径测试。

看不懂没关系,产品经理只需督促程序员或测试员完成这一流程即可,感兴趣的自行搜索。

黑盒测试

黑盒测试也称为功能测试,测试者在看不到程序内部代码情况下采用穷举输入测试,主要用于发现:功能不正确或遗漏;界面错误;输入和输出错误;数据库访问错误;性能错误;初始化和终止错误。

该部分可由产品经理或测试员来负责。

黑白盒测试是专业测试知识,如需详解要另开篇章。产品经理只需确保做到如下几点:

  1. 产品功能与需求文档保持一致。
  2. 对所有用户输入值的合法范围内,非法范围,边界值进行抽样取值测试,确保程序在合法和非法输入值情况下都能正常运行。
  3. 凭借测试经验,推测有可能出现错误的地方。
  4. 准备多种测试数据,判断输入和输出结果之间的因果关系是否一致。

写在最后

测试是产品输出的最关键也是最后一步,在实际项目中,因为项目进度紧等诸多原因,可以适当省去灰度发布过程,但是技术测试和产品经理内测工作不能省,不然功亏一篑。测试方法有多重,最终目的是在有限的时间内发现最多的问题并解决,最大程度降低产品错误带来的负面影响。如有更多测试好方法,欢迎留言交流。

文章内容均来自于项目实践经验,拒绝盲目照搬。

 

作者:东东酱,眼蜜-产品经理。微信号:pengoneeast

本文由 @东东酱 原创发布于人人都是产品经理。未经许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 真的打死不改(6).doc,这个就很有灵性了 :mrgreen:

    来自湖北 回复
  2. 微信加不上 😉 写的很棒!

    来自广东 回复