后台产品设计（三）如何测试

    点击蓝字关注我↑，持续获取产品设计相关内容     

后台设计的系列最后一篇。

目录： 

一、了解业务 二、梳理业务，区分角色 三、如何设计（基础数据、权限系统、业务、拓展性） 四、如何测试

之前讲了业务分析、流程图、产品设计，之后就会进入产品评审和开发的环节。开发之后，就是重要的产品测试环节。

不同的产品，产品测试流程也不尽相同：

ToC的产品，一些App，一般需求定了之后，测试会写用例进行测试。

一部分ToB的产品也会按这个流程走，但是也有另类的产品。比如，以客户导向的定制类需求。

这类情况下我们一般不写测试用例，而是以业务路径图和功能模块列表进行测试。

这里我只讲最后一种测试方式，因为它适用于其他的产品测试。

测试前准备

在需求收集之后，我一般会将需求进行梳理，通过Excel进行模块划分，细化到每个模块有哪些功能点。（功能会在设计完成之后，再整理一次，产品经理很会改需求的。） 

为了看起来方便，做了左右栏展示

这里测试表在我目前的场景下，会给两种角色用：产品测试、客户。 

由于项目需求是客户导向的，我们出具用户手册的成本很高，一旦变更需求，改动太大，所以通过这种列表的方式，先让需求对接人通过列表对产品功能进行验收（一般对接需求的人会了解产品如何使用，如果不会，请帮助他）。 

当内部测试和客户对列表中的功能进行验收之后，你再出用户手册。

补充的产出

需求边界说明

功能列表在这个流程还是不完善，一方面他缺少一些边界说明。

新增用户时：以什么为登录账号？哪些字段不能重复？哪些字段是必填的？ 

这部分内容会在需求文档中详细说明。 

那需求文档需要提供给用户吗？ 

答案是：不用。因为客户对系统是有预期的，凡事在他测试过程中他失误的地方，经常是不符合业务需求的地方，这就是完善需求或者修改需求。 

那么需求文档给谁看？ 给开发和测试看，虽然开发看的不多。更多的是给测试看，测试会在产品测试过程中不断的去探索功能的边界，功能是否按需求完成。  （测试是为了验证功能是否按需求完成；客户是验证功能是否按他的预期完成。这不是一个概念。）

业务逻辑图

功能和功能之间往往有依赖关系，前置业务未开发完成的情况下，下一个业务无法测试。 而测试的人需要知道哪些业务是前置业务，分配他们的测试优先级。例如，『订单管理』依赖『商品管理』、『品类管理』，那么在『商品管理』还没做完的情况下，完全没有测试『订单管理』的必要。 

这里你会发现，如果你要测试发货功能：『邮费管理』、『订单管理』做为前置功能，先要测试好这两个功能才进入到『发货』的测试。

后台系列写完了，下一个写作目标也定了，之后会去重设计一些我看着不爽的产品，然后写一些自己的设计逻辑。

产品设计相关内容，关注我吧~