目录：
需求分析的痛点：
需求了解要做什么?
评审时要关注哪些方面？
在测试过程中，理解需求是第一步，也是最重要的一步。只有正确理解了需求，后面的工作才能顺利进行。
但在了解需求的过程中，经常会遇到各种各样的问题，比如说：
产品人员没有提供需求文档，或者提供的文档不清晰、不规范（有时候甚至用几句话描述一个复杂需求）
测试同学小明对某个需求不清楚，在公司里问了一圈都没有一个能准确解答他疑问的人（在一些互联网公司比较常见，产品人员流动性大，公司不重视文档记录）
产品组织需求评审，询问与会人员有什么问题时，测试同学小明一个问题都问不出来
产品给出需求文档后，测试经理安排给某测试同学小明了解需求。一段时间后小明反馈“文档已经看完了”，但测试经理询问“这次改了什么，为什么这么改，有哪些影响范围，什么时候上线”，小明都说不上来
需求开发完了，测试同学小明按照跟研发沟通的结果进行验证，测试通过后，产品人员（或客户）验收时却反馈这不是他们想要的，最后系统返工重做，浪费了人力物力，最后还失去了客户。后来公司内部追责时，小明被严厉批评
需求文档是否规范、全面（写的是否清晰、详尽）。便于节省沟通成本，使项目质量和风险可控。
易用性。所谓易用性，就是“易学习、易理解、易操作”。举几个例子如下，想看更多的话，可以加我的QQ群下载《黑盒测试框架》，里面有完整的说明。
功能是否有冗余，操作路径是否过深
需要进行说明的地方是否有说明？说明是否清晰易懂？
文字、图片、按钮排版是否合理
色调是否符合系统特色？效果是否统一
误操作提示
容错处理，
在需求了解时，多看看竞争产品是如何设计的，或者类似产品（功能）是怎么设计的，这有助于从设计角度去看待产品，也是一条有助于迅速积累易用性经验的建议。
如果公司中出现了上面提到的场景，往往是因为多方面原因导致的。本文不对此展开细述，有兴趣的同学可以加我微信私聊。接下来讲讲需求评审时我们要要做什么?
完整阅读需求，标记疑问（三种不同颜色，灰色代表没有疑问，红色表示有错误，黄色代表有疑问）。即使测试任务紧张，也要抽出时间来了解需求，不提前看需求，就会出现在需求评审时提不出问题来的尴尬局面。另外我习惯用excel表格把疑问整理下来，这样有助于知识传递。
书读百遍其义自见，多读几遍需求可能会自行解决一些疑问，多结合度娘解决一些术语性质的疑问
是否有原型图，新人加入团队时重点关注，多问问。
整个系统的流程图，发现逻辑缺失（整理资源竞争map、相关性map）
口头沟通的，邮件确认。
最后来说说评审时要关注哪些方面？个人认为最重要的就是多问问几个为什么。
需求背景，为什么要做这个需求，要解决什么问题？为什么要这么解决?是否有更好的解决方式，竞争对手怎么处理的这个问题？
用户评论