浅谈软件测试人员如何更好地测试需求文档，及完善不合理或遗漏需求点的几点经验

       软件测试人员越早介入测试，越早发现问题，就能越早的修复问题，越早发现问题，修复的成本越低，越晚发现问题，修复的成本越高。

       软件测试人员测试需求文档，有几个路径，其中的一个方法，就是需求评审。

       需求评审通常是由产品人员组织的，由相关人员参加，相关人员指的是参与这个项目的人员；项目经理，开发管理人员，测试管理人员也会参与，以便对项目有所了解，更好的安排排期，及工作；如果此项目涉及到不同部门，有条件的情况下，可邀请不同部门的相关人员来讲解这个需求的背景。

       并不是所有的项目都必须要兴师动众地进行需求评审，有些很小的模块或者项目，可以由产品人员召集项目的参与者，或者，项目的参与者，如测试人员或者开发人员，如果发现有疑问的地方，也可以召集产品，开发，进行小范围的需求评审。

       需求评审前的几点准备：

       1、在需求评审会前，先看需求文档，有时，会有几个项目同时在进行测试，而没有时间看需求文档的现象，这个要测试管理者在项目排期时，考虑到这种情况，而预留一定的看文档的时间；

        2、在读需求文档的时候，记录下对文档不同的异议，或者，不明白的地方；

        3、了解该项目的需求背景；

        4、了解该项目所涉及到的原理；

        5、了解该项目所涉及的知识点。

        需求评审会的几点注意事项：

        1、产品人员要解读需求，以便相关人员，更好地理解需求；

         2、需求评审会上，有争论的歧义点，要做好记录；

         3、做好会议记录；

         4、会后，将会议记录发送给相关人员；

         5、及时的更新需求文档。

         因为一些原因，需求文档，会有一些遗漏的点，比如，这个需求未召开需求评审；或者，由于，时间紧迫，未充分解读需求文档；或者，参加需求评审会的测试人员与实际执行测试的人员不同，且测试人员经验不同等情况。此时，在写测试用例时，或者，在测试时，也可以去发现需求文档不合理或者遗漏的点。

        我就曾经在好几个项目测试时，发现需求文档的不合理的点，以及，需求文档遗漏的路径点。