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

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

如果不想看下面的细节，这里是结论：

1-要有核心流程列表，每次上线前都需要测试，无论本次开发是否涉及修改。
2-产品文档的制作，要有利于之后测试用例的制作和检查：

* 基于流程图制作关键流程用例* 关键流程用例的完备性，穷尽所有测试路径* 所有待测点都在文档中要有对应编号

3- 交叉测试：专业测试人员，产品经理，核心流程相关方都应该参与到上线前的测试，以尽量降低问题被遗漏的可能性。新增问题提交到1.核心流程列表。

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

程序员客栈服务

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

举例如下：

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

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

发现 ：项目组同事使用过程中发现并反馈

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

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

发现 ：本次雇佣的测试者

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

总结以上问题：

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

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

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

这个问题如何解决？

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

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

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

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

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

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

这个问题要如何解决：

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

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

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

这个问题如何解决：

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

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

文／喵在野

关键字：产品经理, 测试

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！