如何做好产品上线前的测试,将致命错误扼杀在摇篮中

测试 猫行天下 2016-11-28 11:44:24 382 阅读

最近客栈3.7.0 上线,自己对于上线前的测试又有了新的认识,思考了一段时间,总结如下。

如果不想看下面的细节,这里是结论:

测试不是只靠一个人来做的事情,必须要有规则和系统来保障,从根本上降低意外发生可能性

1-要有核心流程列表,每次上线前都需要测试,无论本次开发是否涉及修改。

2-产品文档的制作,要有利于之后测试用例的制作和检查:

  • 基于流程图制作关键流程用例
  • 关键流程用例的完备性,穷尽所有测试路径
  • 所有待测点都在文档中要有对应编号
    3- 交叉测试:专业测试人员,产品经理,核心流程相关方都应该参与到上线前的测试,以尽量降低问题被遗漏的可能性。新增问题提交到1.核心流程列表。

3.7.0 的目的是在发布项目的时候,增加整包和模块外包的分类,增加父子项目关系,以及在程序员列表页增加自由职业者的切换开关,来方便客户使用。

程序员客栈服务

原以为一周可以做完的测试,没料到即使是自以为很严谨的测试(专门雇佣了专业测试人员+产品经理全程参与测试),依然发生不少意料之外的关键问题,且至少有一人没有测试发现这个问题,如果上线,必将导致核心流程无法走通。

举例如下:

一:与本次更新部分无关的功能产生问题:

1 - 发布项目后,对是否第一次发布的检查丢失,导致产生无联系方式的项目发布。

发现:项目组同事试用过程中发现并反馈

二:与本次更新部分结合,但不属于新功能的部分产生问题:

1 - 子项目项目方从草稿箱发布项目(不论是企业方还是项目方保存的),新项目项目方都拥有了企业方权限,原父项目企业方反而无权限查看项目

发现:本次雇佣的测试者

2 - 发布子项目时,对父项目的相关信息的继承或者草稿箱发布信息的继承
包括:产品功能,行业信息,技能信息等

发现 : 产品经理

总结以上问题:

问题一,只是针对新功能的测试是无法发现的,因此测试者和产品经理本次都未发现。

它属于:关键流程测试部分,应该不论是否在新版本中有变更,都需要测试到。对于我们客栈而言,同类的问题还有:

  • 新用户注册,登录,申请签约
  • 用户(各种分类)发布项目流程,发布雇佣流程
  • 开发者(各种分类)接单流程

这个问题如何解决?

1-总结关键流程测试表
2-进行关键流程交叉测试,邀请关键流程相关人员来参与测试,及时收集问题并提交到关键流程测试表

问题二,属于新功能与旧功能结合导致的复杂新情况部分:

新功能:项目经理可以代发布子项目,但权限只有项目经理权限。
旧功能:用户从草稿箱发布项目,发布者是用户本身。

新旧结合导致发布项目由原来的一种情况变成了6种,其中从草稿箱发布项目产生了四种情况:

a - 企业方存草稿,企业方发布
b - 企业方存草稿,项目经理发布
c - 项目经理存草稿,项目经理发布
d- 项目经理存草稿,企业方发布
e - 企业方直接发布
f - 项目经理直接发布

而这四种情况中,产品经理测试了e,f 两种直接发布情况(从流程上来说,是最短测试路径),测试者对从草稿箱发布进行了交叉情况的测试,从而发现了问题(从流程上来说,是完备测试路径)。

这个问题要如何解决:

流程用例,应该根据流程图穷尽所有测试路径,而不能只有某几个部分路径。

问题三,属于文档中有描述,但在流程中未备注的部分,影响使用体验,但不影响核心流程的完成。产品经理因为熟悉需求,因此能测试到;专业的测试人员在这方面则有所欠缺。

理想的情况,这个问题应该在做测试设计的时候,产品经理测试人员在反复核对用例时就应该发现并补充在用例里,然而当用例本身过于复杂时,这件事情的难度变得很大。

这个问题如何解决:

产品文档中需要被测试的每一点,都有测试编号,和测试用例要一一对应。

如果能做到以上三点,基本在功能测试上遗漏会变少,核心流程出错的几率会大大降低,提升上线的成功率。

本帖已被设为推荐主题!
回复数量: 0
    暂无评论~~
    Ctrl+Enter