前言 大家好，我是IT小学生蔡坨坨。 前些日与朋友聊天，谈及需求评审，作为测试人员，我们应该在需求评审会议上做些什么？ 记得第一次参加需求评审，傻傻的过去坐着，然后听别
前言
大家好，我是IT小学生蔡坨坨。
前些日与朋友聊天，谈及需求评审，作为测试人员，我们应该在需求评审会议上做些什么？
记得第一次参加需求评审，傻傻的过去坐着，然后听别人巴拉巴拉说半天，自己一头雾水、一脸懵逼，会后又花大量的时间看需求，等到提测的时候可能需求都没怎么搞明白……
那么问题来了。怎样能够让需求评审更高效呢？作为测试人员又如何在其中发挥价值呢？
首先参与评审的可能是产品、开发、测试，时间一般控制在1个小时左右，如果过长，如两三个小时可能就不是很高效，如果过短，对于稍微大一点的需求一些详细的点就可能没有考虑到。
需求评审会议前：
进行需求评审之前，产品经理一般会给到需求相关资料，像我们公司会由产品经理建一个jira单，单子上附有客户背景、客户需求、产品方案、PRD、原型图等。我们需要提前阅读相关文档，深刻理解需求，对于有疑问的点提前标注出来，然后在开会的过程中积极地去参与这个会议，抛出疑问点。除了关注功能要求，还需要关注数据类型、接口定义、性能要求、安全性等，这个根据具体业务进行评估，像我们公司是做电子合同业务的，就会考虑文件缩略图频繁请求、加盖印章过多等是否会导致性能问题。同时还需要考虑一些隐性需求。
会议中：
- 需求澄清的时候不要在会议上面玩手机或者干其他事情，因为如果需求理解不深刻，后面测试相关的工作就很难开展。如：不能正确编写测试用例，找不准测试点，业务相关知识串不起来等。
- 需求中产品设计不合理、很难理解、逻辑有问题、以及可能影响原功能的地方，对于这些点我们要抛出疑问进行澄清，从而推动产品进行修改，最终达成一致。
- 需求中没有被量化的点，例如：某个功能涉及的字段类型、长度和规则，如：标题栏位类型为普通文本，长度为100个字符、手机号栏位应该符合规范，首位为1，11位数字。为什么需要量化？因为只有量化之后，才有利于测试后续用例的编写，测试才有可能用等价类、边界值进行用例设计，开发才能进行一些数据库字段的设计（如varchar（11）、int、bigint）。
- 思考需求中的测试点，影响我们做测试的地方让产品经理给出说明，比如这种异常情况怎么处理？有多少种状态？状态之间如何转化？总之就是影响我们测试的地方都要让产品经理给出说明，这样给我们后面写测试设计和测试用例扫清障碍。
会议后：
- 评审结束之后，需要把一些待确认的地方整理并发出来。
- 经过评审会议的讨论，可能会有需求点发生了变更，这时就需要让产品将最新的PRD整理完整重新发出来，再对修改的地方进行确认。
经过以上需求评审，你会得到什么？
- 符合软件测试的原则，“测试应该尽早进行，最好在需求阶段就开始介入，因为最严重的错误不外乎是系统不能满足用户的需求”，从而在产品初期帮助整个团队避免很多的错误。
- 充分理解被测需求，深刻熟悉被测业务，为后续测试工作的开展、测试用例的编写扫清障碍。