设计过程中如何认识到产品的需求（从测试的角度来总结分析产品设计）

产品经理在项目开发中扮演的是一个连接者的角色，连接的前提是要熟悉连接对象即兼容对方，善于从对方的角度思考问题。本文将从测试的角度来总结分析产品设计，以此来提升产品设计全面性。

在苏杰大神的博客文章中有这样一个观点：

产品新人如何快速上手的方法之一是写测试用例。

测试用例是从测试的视角写的产品描述。测试与产品的逻辑不同，产品抓大放小，测试就是要想清楚各种边边角角。

所以，如果团队正好没有TC，你来写一遍，保证对产品的各种细节都很熟悉，也会知道背后用的技术，因为各种限制而造成的各种坑。

一、关于软件测试

• 从测试方法来分：软件测试分为黑盒测试、白盒测试、灰盒测试、静态测试、动态测试、手工测试、自动化测试。
• 从测试阶段来分：软件测试分为需求测试、单元测试、集成测试、系统测试、验收测试。

黑盒测试也叫功能性测试，在软件测试过程中大多采用此方式。我所说的产品经理懂测试，针对的即是功能性测试，从功能性的角度做产品的需求文档，遍历尽可能多的功能场景。一定不能让开发和测试找到你的漏洞，那将是产品经理最尴尬的时刻。

有数据表示：

在许多失败的项目中，70%~85%的返工是由于需求方面的错误导致的。

二、限制边界值

如果没有限制输入框的长度，专业的测试分分钟可以把开发认为没问题的程序搞挂。

因此对输入框的长度限制，是一个产品最底层的功能，我想这也是产品经理的基本素养。进一步的要求是对可输入字符类型的限制，此项不至于影响到功能，但属于产品最基本的友好性需求。

下图是作者好不容易找的一个反面例子：

数值「0」是开发容易忽视的边界值，在很多场景中0值其实是没有意义的，比如金额为0元、数量为0等。自己的亲身经历：之前做过一个资金分配的功能，由于PRD没有说明字段的规则（以为开发小哥哥用脚想想都会明白），然而在做功能验收的时候，我成功给好友分配了0元。。。

对于这些字段的规则，其实没有必要在文档上一一标注，因为很多页面的字段其实是重复的，这个方法也很容易漏掉一部分字段。一个很好的工作方法是：在全局规范中建立字段规则表。这个方法让我想起了：大学编程的时候，会统一将全局变量的定义集中放置。

作者抛出一个输入框对空格的处理的测试用例供大家思考：

1. 前面存在空格
2. 后面存在空格
3. 前后都存在空格
4. 中间存在空格

二、遍历异常逻辑

正常流程只有一个，异常流程却异常的多。在很多PM的PRD中，仅仅陈列了正常的业务流程。

很少有开发是会替产品考虑异常逻辑的，所以为了不给自己挖坑，在写PRD的时候，就要将所有的异常流程都描述清楚，我想在需求评审的时候会更容易通过，也会在开发的眼里树立权威。

有人说，无反馈是产品大忌。我想说，反馈不完全也是产品不专业的体现。对于特定事件的反馈，既然有成功的结果，必然会存在对立面——失败。对于这些事件的总结其实很容易找到规律，很多优秀的PM都会整理一份交互设计自查表，然后会不断的更新迭代。

善于总结是一个优秀学习者的必要品质，在项目经历中总结积累遇到的异常情况。有句话这样说：

“你现在经历的每一件事，都会在未来某一时刻用上”。

登录注册可能是大多数PM童鞋的处女级产品功能，根据我个人的经验：如果没有从零到一将这个需求落地，一定是存在认知漏洞的。

我说一个场景，看大家有没有考虑到：手机号验证码输入框在同一个页面，在手机号无误、验证码输入正确的情况下，然后更改手机号（手机号格式合法），提交之后应该如何反馈？

三、关联性的问题

在项目中，大多数功能模块往往不是独立的，一般存在交集或者需要进行模块间的数据交互。因此一个模块如果发生了需求变更或者数据丢失，就会影响到相关联的功能模块。

曾经做过一个项目，由于平台新增了直营店功能，之前设计的订单详情就不适用了，需要融合新需求，财务管理模块也要做字段的扩展。

关联信息不允许删除，比如商品类别，假如商品类别是商品的必要属性，此时就应该禁止正使用的类别被删除。还有一个很重要的关联性问题是，正在生效的规则是不能被删除。

四 、性能的问题

性能无止境，性能的优化伴随着产品的整个生命周期。测试过程，性能测试处于功能测试之后，也就是说功能大于性能。翻越异常逻辑的大山，从性能角度设计产品，是产品经理进阶的又一指标。

作者分别从数据加载、信息的筛选跨度、图片处理三个方面总结，希望可以抛砖引玉。

关于数据加载其实是一个很大的话题，不仅涉及产品的性能，还影响用户的使用体验。我在这里只是蜻蜓点水，想要突出对产品性能的重视。

这个问题主要在数据列表等相关的信息流模块，如果没有做数据加载条数的限制，一个经验不足的开发童鞋很可能一下子请求所有的历史数据，结果可以预见：轻则加载缓慢，严重的话直接导致应用崩溃。

对于信息流页面的数据加载，一般都会限制单次加载10-20条。

与此相关的另一个问题就是：数据筛选的请求限制。像支付宝这样大体量的产品，在筛选账单的时候，也仅仅支持查找6个月跨度的账单。

图片是影响产品性能的又一大因素，在前端上传图片注意做图片大小的限制，即使上传之后技术也要做压缩处理。图片的压缩分为分辨率的压缩和大小的压缩，根据业务需求，如果需要展示缩略图，要在服务端自主生成。

五、写在最后

说了这么多，作者并没有误导大家把产品重心向测试的角度偏移，毕竟产品还有很多重要的事要做。

一个好的产品经理既不能技术化，也不能业务化，掌握好工作中的「度」，做好「中庸的」连接者。

当然，懂测试，能从测试的角度设计产品只是优秀产品的一个方面。产品经理这个岗位之所以吸引人正是因为它的定位不明确，它的「难」与「坑」我想也是这个原因。

持续不断的学习，时刻都在拓宽自己的边界。懂技术、懂心理、懂设计、懂运营才能更好的连接。

本文由 @ 产品范 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自unsplash，基于CC0协议

,