8.4 三种需求的测试验证
本节要阐述的3种测试验证来源于8.1.1节提到的验证方式，将假设系统存在的、基于黑盒子的、采用系统测试用例和用户手册方式的测试验证方式分解，得到了具体的三种需求的测试验证。它们是有经验者共同之成果，也是我们深入了解需求验证的基础。
1.基于测试用例验证
基于人工技术的需求评审除了采用有组织的评审工作之外，还可以对需求进行模拟测试，即对每一个需求通过设计一个或者多个可能的测试用例，将这些用例用于检查系统是否满足需求。需求测试不仅是发现不完整、不准确的需求的有效方法，还可以作为软件测试计划的基础，同时导出测试软件系统的用例。
为需求设计测试用例的目的是确认需求而不是确认系统。通过阅读需求规格说明书虽然很难想象在特定环境下的系统行为，但以功能需求为基本或者从用例派生出来的测试用例可以使项目的参与者看清楚系统的行为。如果在部分需求稳定时就开始测试用例，及时发现问题，就能以较少的费用解决这些问题。
以功能需求为基础，将功能视为一个黑盒子，编写关于该功能或黑盒子的测试用例。这些用例可以明确在特定条件下运行的任务。由于无法描述系统的响应时间，故测试中会出现一些模糊的、二义性的需求。相反，当系统分析员、客户和开发人员通过测试用例进行研究时，就会对产品如何运行的问题会更加清晰。
测试用例是在业务活动的业务需求描述、使用用例描述、功能需求描述及部分对话图描述的基础上设计的。
业务需求：对该系统所支撑的一个业务活动的操作手段、操作对象、操作目标的要求描述。
使用用例：针对该业务活动的业务需求，通过操作者到相应用例和用户关联的单据和数据要素项，同时再采用用例规约和用例实现给出详细描述，以及相应的业务规则约束和异常条件的描述。
功能需求：针对用例采用界面类、功能类、数据类之间的静态关系和动态关系来说明使用用例的具体实体。
对话图：是针对使用用例给出每一个功能项对应的对话要素项及对话要素之间的时序关系和数据关系。(https://www.daowen.com)
测试用例：由于一个用例有许多可能执行路径，可以设计出许多测试用例来描述其正常的处理过程和例外的处理过程。
基于测试用例，并按照用例上的执行路径进行回溯，关联到对话图、功能图、功能需求、使用用例、业务需求，就可能发现不正确或遗漏的需求，然后在对话图中纠错，精化测试用例。
2.基于用户手册的验证
对于大量涉及到人机交互的软件系统，在编写需求规格说明之后，可以编制一份初步的用户使用手册草案，将其作为需求规格说明的参考。编制用户使用手册的好处在于编制过程中可以对需求分析进行强化，帮助揭示与系统实际相关的问题，从而促使软件开发人员一开始就能站在用户的角度进行界面的设计，并及时考虑人机交互中的接口问题。
在编制用户使用手册草案时应以最终用户能理解的方式解释在需求中描述的系统功能，应尽可能采用用户理解的业务术语描述系统的功能，并且注明该怎样使用此功能。
编制用户使用手册草案并不需要十分全面，主要使用简单的语言描述出对所有的用户可见的功能，而性能等用户不可见但可感知的功能，放在需求规格说明书中完成即可。
通过以上需求完成后编制的需求说明文档，不仅可以作为用户界面进一步即可深化设计的要求，也可作为最终软件产品开发完成的验收依据。总之，用户使用手册草案是软件开发过程的一个里程碑，也是系统所有相关人员对软件系统共同理解和共同认识的表达形式。
3.基于需求模型的验证
一般来说，需求模型是利用图形化或形式化语言、符号表示的。若将这些模型用自然语言加以描述，则会有利于评审人员的理解和验证。图形化的模型和自然语言之间具有互证的关系，可以用自然语言解释模型来发现模型中存在的一些错误和遗漏的内容，也可以基于模型找出自然语言描述不准确的地方。这种方式可解决需求模型存在的验证性问题。
