部门内部讨论了在提交缺陷时在何种情况下应该注明是【需求不一致】。

　　提到这个问题，个人认为应该先明确注明【需求不一致】的目的和作用。个人比较认同采用在缺陷中注明【需求不一致】来达到检验在前期评审需求和评审用例的质量。

　　那么，需求文档评审质量差对测试方而言会引发什么大问题？

　　1、执行完用例后，手工测试发现一大堆缺陷。用例无法较完整覆盖主体功能点。

　　2、产品经理和项目经理在后期频繁地修改需求，导致项目周期延长，测试成员疲于奔命，编写修改执行用例和手工测试成本上升。

　　3、在编写测试用例发现需求问题，如描述不清，前后矛盾，设计不合理等。反复沟通确认修改导致浪费人力物力。

　　评审用例质量差会导致什么问题？

　　1、测试用例质量下降，导致在测试中容易功能点遗留测试，比较用例是软件测试对产品检测的主要依据之一。

　　2、执行用例人员对用例理解存在困难，增加反复沟通的频率。

　　3、增加手工测试的压力，容易导致测试无法按时退出。

　　循着这个目的和影响范围，可以考虑在以下几种情况将缺陷定义为【需求不一致的问题】

　　1、执行测试用例时发现和需求文档实现不一致。需要考虑到测试人员在编写用例发现问题，在口头上和项目经理确认修改某个功能点，但是文档未及时更新的情况。

　　2、对需求存在疑义，认为设计不合理。

　　3、在测试过程中和产品经理、项目经理确认是需求存在问题，需要改动的情况。

　　4、发现产品实现和需求不一致，而且已经和相关人员确认是需求文档存在问题，需求改需求的情况。

　　暂时写到这吧，脑袋有点浆糊了。

　　顺便回顾下自己对功能类缺陷定义的理解：

　　开发方面的缺陷（一般是在冲刺测试、集成测试、系统测试阶段发现）：

　　1、和需求文档不一致，包括软需，用需，UI界面设计稿，产品功能点列表。

　　2、和其他同类产品进行比较，实现不合理。这类一般都是易用性，会被提为建议类。例如用户名字段正常不小于512个字符，但是设计是不大于30个字符。

　　3、需求文档没有描述到，但是从用户角度操作上认为有问题，不合理的功能点。例如增删改查表单应该有提示信息，但是需求没有描述到。

　　文档方面的缺陷（一般是在成果评审阶段和执行测试阶段发现）：

　　1、需求文档中直接存在矛盾，前后不一致。包括软需和用需不一致、阶段性发布的需求文档不一致。

　　2、需求文档设计不合理。

　　测试方面的缺陷（一般是在成果评审阶段和执行测试阶段发现）：

　　1、用例编写错误。

　　2、测试报告错误，数据不准确等。