测试工程师如何进行需求评审

        需求文档是测试过程的重要输入之一，测试工程师根据需求文档进行测试活动，包括测试方案的制定，测试设备的准备，测试环境的搭建以及测试用例的设计。需求文档的质量直接影响到测试工作效率。在一个成熟的软件开发过程中，测试工程师需要尽早地进入项目对需求文档进行评审，一方面可以更好地理解需求文档中每个需求项，另一方面可以对需求的可测性进行评估，尽早发现问题。

        通常，需求分成显性需求和隐性需求，显性需求一般在需求文档中会很清楚地列出，而隐性需求需要测试人员根据以往的项目经验以及对于行业标准地了解进行挖掘。显性需求通常包含以下几个部分：

       功能性需求, 描述功能的规格说明，输入输出行为，状态变化过程，界面格式的定义，错误行为的响应。功能需求需要表述准备，避免歧义。

       性能需求，描述系统的响应时间，并发线程数，最大支持用户数等数据，性能需求需要绝对数量化以便测试目标清晰

       安全需求，描述系统需要满足安全条件下进行工程。

        此类需求一般比较明确，测试人员在评审此类需求时，主要从以下几个方面进行考量

          1. 需求的准确性，任何一条需求需要清晰完整地描述，不能出现歧义，避免评审人员随意猜测。

           2.需求的完整性，需求文档中的需求项是否覆盖了所有用户需要的功能项

          3. 需求的唯一性， 每个需求项，只需要在一处进行准备完整地表述。

          4. 需求的一致性，任何一条需求在文中的表述需要完全一致，不能出现前后矛盾或者不一致的地方。

          5. 需求的可测性，需求是否可测，每条需求是否可以用测试用例进行覆盖，需求是否有内部和外部依赖。

           6.需求的优先级： 需求地优先级属性是否合理。

           7..需求的约束性：一些需求的行为成立有一定的前提条件，针对这些需求，是否有明确的先决条件进行说明。

          隐性需求包括可维护性、可补充性、易读性、可靠性、运行环境可转换性等，其中还包括行业标准需求，约束性需求。针对这些需求，需要测试人员有丰富的经验和行业标准的了解。可以通过以下渠道去挖掘这些需求：

         1. 和系统人员，软件开发人员进行需求讨论和交流，了解软件架构从中发现架构中的局限性

          2. 参与前期客户沟通会议，了解客户地使用习惯，运行条件

           3. 和测试设备厂商或者芯片供应商地技术交流去了解行业标准和动态

          4. 学习竞争对手的类似产品的规格说明书，了解相关的技术和标准

         当发现存在以上隐性需求时，需要把隐性需求转换成显性需求，在需求文档中进行定义，从而在后期的测试策略的制定时，有更好地测试和覆盖率，避免出现测试死角。