通过用例设计来测试需求
我们从V模型上可以知道，验收测试是以系统需求为基础的，系统测试是以功能测试为基础。每个开发阶段的活动都与相应的测试活动是并行进行的。在需求阶段进行系统(验收)测试计划和设计，除了能指导最终的系统测试和验收测试执行外，其本身也是对需求的一个验证过程。
通过阅读软件需求规格说明书，通常很难想象在特定环境下的系统行为。以功能需求为基础或者从使用实例派生出来的测试用例可以使项目参与者看清系统的行为。虽然没有在运行系统上执行测试用例，但是设计测试用例的简单动作可以解释需求的许多问题。如果你在部分需求稳定时就开始开发测试用例，那么就可以及早发现问题并以较少的费用解决这些问题。
设计概念性测试用例可以发现需求的错误、二义性、不可测性、遗漏等方面问题，为了获得最大的效果，要求测试人员能够独立的去对需求进行思维，从一个不同于开发的角度上进行分析，这可能会是一个逆向的思维过程，在这个过程中，测试人员可能会设计出不同于需求的测试用例，而这最终可能会有两个解释：
1、需求不完整或者需求有错;
2、遗漏了测试用例或者测试用例本身有错误;
不管是哪种解释，最终肯定会提高整个系统的质量。但这个质量的获得是通过冗余的人员来完成的，即：开发人员在对系统需求进行进一步分析的时候，有一组独立的测试人员也在对系统需求进行独立的思维，并从中获取测试用例。尽管这两种思维可能会出现重复，但由于思维的方式不同，最终肯定会使得需求变得更清晰和更完善。
需求建模测试
需求的建模包括把需求转换成图形模型或形式化语言模型。需求的图形化分析模型包括数据流图(Data Flow Diagram，DFD)、实体关系图(Entity-Relationship Diagram，ERD)、状态转化图(State-Transition Diagram，STD)、对话图(Dialog Map)和类图(Class Diagram)。这些图形化模型一般都需要借助一定的CASE(Computer-Aided Software Engineering)工具。这样就可以借助于自动化分析工具本身提供的检测手段来对需求进行测试，而这类检测主要可以提供描述上的完整性检查，需求项之间的不一致性检查等方面的功能。同时，使用这类自动分析工具有助于获得需求的质量特性，包括：有效性、一致性、可靠性、可存活性、可用性、正确性、可维护性、可测试性、可扩展性、可交互性、可重用性、可携带性等。
文章来源于领测软件测试网 https://www.ltesting.net/
