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

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

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

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

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

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

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

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

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

举例如下：

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

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

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

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

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

发现：本次雇佣的测试者

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

发现 ： 产品经理

总结以上问题：

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

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

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

这个问题如何解决？

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

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

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

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

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

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

这个问题要如何解决：

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

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

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

这个问题如何解决：

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

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