后端产品之路（五）-测试，让需求更正确

点击『小生知道』关注我 ，这里有宝贝

上一篇

后端产品之路（四） - 降低耦合性、组件化

说完如何画原型，接下来其实是评审的事，不过评审也是为了调整业务、流程、原型，所以就不赘述了。

原型之后就是产品的开发工作了，开发工作开始了，测试工作其实也开始了。

要测试干嘛？

1、检验功能是否按需开发完成

2、功能是否存在使业务无法流转的bug

3、功能是否影响了其他业务

···

测试是个严谨而又措手不及的过程，你永远都不知道什么地方会出现bug，所以只能尽量将产品的边界想全一点，当然，虽然你永远都想不全。

开发测试：

为什么说开发工作开始了，测试工作也开始了？（我不是想说单元测试）

程序员是按需求开发的，但是在开发过程中，程序员会发现，这个需求无法实现，或者无法按需求完全实现，比如我今天遇到的一个问题：一个积分列表展示功能，由于早期的积分接口不提供某样数据，导致积分列表这个版本之前的数据是没有的，之后才会有。

这个就算没有按需实现，那怎么办呢？

『改需求啊。』

数据库还不知道有多少数据呢，不能把以前的数据都处理一遍的，所以只能以当前版本为界，之后的数据按产品设计的来，之前的就不处理。

新旧版本兼容是一个问题，实现难度也是一个问题。

除了需求实现的问题，开发自己也会跑单元测试，手工测试，这两个他们一般不会跟谁沟通，主要是保证交付给测试的功能是跑的通的，至于边界，就留给『测试员』去探索了。

测试员驾到：

大多数在互联网公司的，应该都知道测试用例吧。

测试用例是用来指导测试员测试用的，一般测试用例上写的都是正确的事。

测试会根据用例，先把正确的流程跑一边，然后把正确的事情拓展开再跑一遍。

比如：一个『输入框』，产品要求该『输入框』仅字母+数字输入，那么测试就会去尝试输入符号、汉字、表情等等规则之外的字符。另外像这种『输入框』还需要对输入『字符上限』做校验。

还有一些如：『文件大小限制』、『图片格式』、『是否必填』、『是否有预设』等等要求。

虽然测试用例是测试写的，但是产品在写文档的时候也要充分而详细把产品的边界给写出来，越清晰，测试员测试的也更详细和彻底，就能尽量多的避免上线后遇到bug。

产品验收、设计师也来吧：

一般测试跑完之后，还需要转交给产品、设计师进行验收测试。

产品测试：

我进行验收的时候，会先按正常的流程进行一次测试，然后试图做够多的边界测试。

明明测试员已经跑过了，为什么还需要产品测试一次？

一、防止产品甩锅，上线后出bug了，第一个就质问产品，如果产品没测试，那就是产品的锅；如果产品测试了，那还是产品的锅。除非是产品的性能bug或者开发bug。

二、虽然有测试用例，但是信息的传递一定是有损失的，功能到底要做成怎样，产品心里应该有点逼数，所以让他测一下还是很有必要的。

三、有的需求可能变更了，但是信息没同步，查遗捡漏。

设计师验收：

要说功能跟开发矛盾最大的是谁？首当其冲的是产品经理，其次就是设计师。

我自己有几个群，群里经常听到设计师吐槽开发说这个实现不了，那个实现不了。然后就来群里问别人，是不是开发忽悠他们。.- -（是）

一般设计师主要还是验收设计稿的还原度：字体对不对、间距够不够、图片比例错了咩、动效实现没、流程有咩有问题等等。

PS：互联网公司就没有统一战线的两个岗位吗？

总结

一般测试就是上述的流程，大一点的公司可能会还会有内测、公测、bate版本等等，不过，哪些问题都不大， 本质上跟正式发布差不多。

测试是个复杂繁琐的工作，我一度没有耐心做这个事，但是，测试多了之后慢慢开始，我写文档、画原型的时候，想的东西也越来越全面了。

所以后来我还是会尽量让自己参与到测试工作中去，而且，你自己的产品，哪里有问题，哪里是怎么操作的，你心里没点逼数怎么行。

另外，测试过程中，希望大家的目标都是为了『让需求更正确』。