测试人员参与需求评审？
1. 熟悉需求
首先要熟悉需求，这是测试阶段必要的过程。
测试人员对需求不熟悉，是无法完成好测试的。业务越复杂的系统，要想做好测试，对业务就必须熟悉。
在需求过程中，一般产品经理会下发需求，让团队成员熟悉需求，再召集全员进行需求评审会议。
在收到需求第一时间就通读需求，不懂不明白的地方都做好记录，等评审会议上一并解决。
2. 测试需求
需求是由产品经理收集用户需求后转化为软件需求。在转化过程中，会因为产品经理个人思维的局限（技术层面的实现、测试的考量等）而造成需求不完善、描述有歧义、逻辑不够清晰。
人对自己的成果天然的包容性，一些显而易见的问题容易被忽略掉。
那么通过需求评审，借助团队的力量弥补产品经理个人思维的不足，从而达到完善需求的目的。
2.1 解决需求歧义
比如给你一个需求：
这是一个活动，满300-50， 用户只要购买活动商品，自动扣减订单金额，每张订单只扣减一次。
这个需求未描述同一个账户是否可重复多次参与，那么就容易产生歧义了。作为一个用户，是否可以拆成多个订单来购买，达到多次参加活动的目的呢？
2.2 需求描述不完整
在需求中，某些重要的功能，只有输入没有对输出结果的描述。
2.3 不可测
主要针对数据来源不明确的情况。
比如某模块数据来源第三方，但是第三方没有提供测试环境等。
2.4 站在用户和业务角度，觉得不合常理
比如某电商系统中，未登录不能添加购物车。
2.5 不符合行业规范和法律法规相关规定
需要测试人员要有意识了解行业业务规范。
如增值税票开票信息中，纳税人识别号非必填。
2.6 业务知识
每个行业都是该行业的专业知识，通过对行业知识的学习，可以提高对软件隐性需求的理解。可以提高测试人员在需求过程中的参与度。
