软件测试:决定需求质量的关键因素

软件需求是保证最终软件质量最为关键的一环,也是软件测试的基础。高质量的软件需求,为产品的最终质量打下了坚实的基础。那么高质量的需求具备哪些关键因素呢?

决定需求质量的关键因素

可理解

需求必须是可以理解的,可理解的需求组织方式便于阅读、评审。下面是一些提高可理解性的方法:

1)根据对象(如用户、订单和发票)来组织需求。

2)用户需求应该按业务过程或者场景来进行组织,这样,行业专家就能快速判断是否有遗漏的需求。

3)将功能需求和非功能需求分开,例如,将功能需求和性能需求分开说明。

4)根据详细程度来组织需求。由需求对系统的影响来决定,例如“系统应该能够接收订单”与“系统应该能够接收销售点的零售订单”对系统就有不同的影响。

5)编写出来的需求应该符合语法规则,样式应该便于阅读、评审。如果需求是用word文档编写的,就应该启用拼写检查选项,同时注意上下文,因为word并不检查下文是否合适。

6)需求应该是明确的,在需求中应恰当的使用“应该”一词,而不要使用“将会”或者“应该会”,因为后面两个词讲的是目标,而不是需求。如果使用非命令式的词语,这样表明需求是可选的,可能会导致需求被误解,可能增加项目成本,也可能使时间周期增加,降低质量,或者出现合同纠纷。

必需性

需求应该是必需的。举个非必须需求的例子。假设下面这个需求已包含在需求规格说明书中:“如果有100个测试用例通过,那么系统应该是可接受的。”这实际是一个项目过程,而不是需求,不应该记录在需求规格说明里。需求必须与正在构建的目标应用或系统相关。

可修改

需求及相关信息必须是可以修改的。选用存储需求的技术影响着需求的可修改性,例如,字处理器中的需求比需求管理工具(如CaliberRM)中的更难修改。但是,针对非常小的项目,因为需求管理工具成本与学习曲线的关系,字处理器就成了最佳选择。

一致性也对可修改性有影响。需求的编写模板结构应该使需求很好呈现,从而方便修改。最佳实践应把每个需求用唯一标识符进行标记。任何需求的依赖关系都应该有标注,例如,需求X应该依赖于需求Y。

非冗余

不应该出现重复的需求,否则会引发问题。重复需求会加重维护工作,例如,每次修改某个需求时,也要修改与之重复的那个需求。重复需求还会提高出现注入需求错误的可能性。

简洁

一个好的需求必须杜绝出现冗词赘句或者多余信息。一个简洁的需求表达应该一语中的,诸如“另一方面”、“然而”、“回想起来”这类词眼应该杜绝。

可测试

可测需求必须可以被验证确认,也可以说,需求的意图应该是能够证明的。不可测试的需求适合测试人员要做客观解释的时候。最好就是带着问题:我是否可以测试这个需求,了解它能否行得通?

可跟踪

需求必须是可跟踪的,这是验证是否满足需求的关键。复合需求很难跟踪,可能导致产品测试失败。例如“系统应该计算出退休金和遗属抚恤金”就是一个复合需求。通过列表方法可以避免在评审各个需求的跟踪能力时造成误解。

在范围内

所有需求必须在指定范围内定义。项目的范围是根据为项目建立的所有需求而定的。项目范围按照对需求的标识、分析和基准线来定义和细化。“跟踪能力矩阵”有助于保证需求位于指定范围内。



留言