关键词:需求测试
由于软件系统的复杂性，在需求分析阶段可能存在着开发方对委托方业务需求理解不全面、不准确的情况。在这种情况下，如果不进行相关的质量控制，往往会造成开发结果与用户需求不一致的后果。需求测试的目的就在于保证软件设计最大可能地满足有关用户的所有需求，降低额外风险和未预料的成本。
通过开展需求测试，测试人员应能及时发现需求定义中存在的问题，使相关单位在认知上达成一致，采取有效的预防措施，降低变更的成本；更好地理解产品的功能性和非功能性需求，为制定测试计划和用例打下基础。
人工的静态分析是需求测试中最常使用的手段，测试人员可以通过需求评审和设计测试用例的方式来测试需求。
测试需求分析过程
测试需求分析
一、测试需求
什么是测试需求
测试需求主要解决“测什么”的问题 ，即指明被测对象中什么需要测试。
测试需求通常是以软件开发需求为基础进行分析，通过对开发需求的细化和分解，形成可测试的内容。
测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求。
测试需求的特征
制定的测试需求项必须是可核实的。即，它们必须有一个可观察、可评测的结果，无法核实的需求不是测试需求；
测试需求应指明满足需求的正常的前置条件，同时也要指明不满足需求时的出错条件；
测试需求不涉及具体的测试数据，测试数据设计是测试设计环节应解决的内容；
为什么要测试需求
软件测试需求是开发测试用例的依据；
有助于保证测试的质量与进度；
测试需求是衡量测试覆盖率的重要指标；
二、测试需求分析过程
需求采集
需求采集的过程是将软件开发需求中的那些具有可测试性的需求或特性提取出来，形成原始测试需求；
测试需求分析
测试要点是对原始测试需求表每一条开发需求的细化和分解，形成的可测试的分层描述的软件需求；
三、需求评审
需求评审必须要有用户或用户代表参与，同时还需要包括项目的管理者、系统工程师、相关开发人员、测试人员、市场人员、维护人员等。在项目开始阶段就应当确定不同级别、不同类型的评审必须要有哪些人员的参与，否则，评审可能会遗漏部分人员的意见，导致需求的缺失。
对需求的评审应从以下几个方面进行：
完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
正确性：每一项需求都必须准确地陈述其要开发的功能。
一致性：一致性是指与其它软件需求或相关标准规定不相矛盾。
可行性：每一项需求都必须是在已知系统和环境的限制范围内可以实施的。
无二义性：对所有需求说明都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的语言表达出来。
健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
必要性：每项需求的制定都是必要的且能够追溯的。
可测试性：每项需求都能通过设计测试用例或其它的验证方法来进行测试。
可修改性：每项需求只应在软件需求说明书中出现一次，这样更改时易于保持一致性。
可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接，这种可跟踪性要求每项需求以一种结构化的方式编写并单独标明。
四、设计测试用例
设计概念性测试用例可以发现需求的错误、二义性、不可测性、缺失等方面问题，为了获得最大的效果，要求测试人员能够独立的去对需求进行思维，从一个不同于开发的角度上进行分析，这可能会是一个逆向的思维过程，在这个过程中，测试人员可以采取需求建模的方式对需求进行分析。
需求的建模包括把需求转换成图形模型或形式化语言模型。需求的图形化分析模型包括数据流图、实体关系图、状态转化图、对话图和类图。这些图形化模型可以借助于自动化分析工具本身提供的检测手段来对需求进行测试，而这类检测主要可以提供描述上的完整性检查，需求项之间的不一致性检查等方面的功能。同时，使用这类自动分析工具有助于获得需求的质量特性，包括：有效性、一致性、可靠性、可用性、正确性、可维护性、可测试性、可扩展性、可交互性、可重用性等。
需求测试不等同于后面阶段集成测试或者系统测试，后面的测试都是软件已经编写完成的条件下，判断软件是否会出错。而需求测试，只是验证需求是否真正是用户所期望的。对于需求的功能测试，可以用快速开发工具建立界面原型，用户通过原型的操作来确定是否需求跟他的期望相同。对于用户不合理的需求，测试人员应能够分辨，并跟用户进行核对，确定用户的真实需求。可以说需求测试是需求测试人员和用户共同来执行的。
网友评论