需求测试的几种方法

 

需求测试的几种方法

陈能技

2007-7-26

 

通过评审规格说明书来测试需求

•正确性：对照原始需求检查SRS

•必要性：不能回溯到出处的需求项可能是多余的

•优先级：恰当划分并标识

•明确性：不使用含糊的词汇

•可测性：每项需求都必须是可验证的

•完整性：不能遗漏必要和必需的信息

•一致性：与原始需求一致、内部前后一致

•可修改性：良好的组织结构使需求易于修改

 

注意，其实现在很多公司做的所谓需求规格说明书评审并不是真正的需求评审，他们更多的是关注有没有需求，需求打算如何实现，而没有把精力放在评价上面的几个“性”上。

 

SRS测试步骤

•第一步：获取最新版本的SRS，同时尽量取得用户原始需求文档

•第二步：阅读和尝试理解SRS描述的所有需求项

•第三步：对照SRS Review Checklist进行检查并记录

•第四步：针对检查结果进行讨论、修订SRS后回到第一步，直到Checklist的所有项通过

 

软件需求规格说明书评审检查单模板

项目编号
检查人
检查日期
序号	检查项		检查结果	说明
1	是否所有需求都体现了		是[ ] 否[ ] NA[ ]
2	用语是否清晰无歧义（查找诸如也许、可能、大概、大约等关键字）		是[ ] 否[ ] NA[ ]
3	是否清楚描述软件要做什么及不做什么？		是[ ] 否[ ] NA[ ]
4	是否描述了软件使用的目标环境，指明并简短描述了目标环境中其它相关软件产品/子系统/模块		是[ ] 否[ ] NA[ ]
5	是否每一个具体需求都有唯一的编号		是[ ] 否[ ] NA[ ]
6	每一个需求是否切实可行、可测试、前后一致、彼此不冲突		是[ ] 否[ ] NA[ ]
7	是否说明了对每个输入的验证措施，并描述了每个输入的属性，如：度量单位、边界值、时序要求等		是[ ] 否[ ] NA[ ]
8	是否说明了对每个输入的处理		是[ ] 否[ ] NA[ ]
9	是否说明了对每个输出项是如何输出的，并且描述了每个输出的属性，如：度量单位、边界值、时序要求等		是[ ] 否[ ] NA[ ]
10	是否描述了性能需求		是[ ] 否[ ] NA[ ]
11	所描述的性能需求是否能通过测试来进行验证		是[ ] 否[ ] NA[ ]
12	是否说明了所有对系统可能的约束		是[ ] 否[ ] NA[ ]
13	质量属性是否以可测量或可验证的术语进行描述		是[ ] 否[ ] NA[ ]
14	是否清楚描述了系统中与其它子系统、模块或硬件设备的相关接口		是[ ] 否[ ] NA[ ]

 

其他测试需求的方法

•通过用户调查来测试需求

•通过设计测试用例来测试需求

•利用现存的产品对需求进行测试

 

通过用户调查来测试需求

•保证用户会对最终的设计感到满意的最简单和最可靠的方法就是开始设计时测量他们的满意度

•周期性地调查、关注变化

•对于任何评论都要给予关注，尤其是他们表达了强烈的愿望时

 

注意，其实很多时候调查用户是不现实的，或者调查的机会不多，这时候应该邀请业务专家、领域专家、业务市场人员对需求进行评审和检查。

 

通过设计测试用例来测试需求

•构建并回答黑盒测试主要是为了测试需求的完备性、准确性、明确性以及简明性

•通过想象产品已经制造出来，构建一系列的测试用例，并且问“假设”问题

•回答这些用例并且与设计人员讨论答案

•试图认同答案通常会导致其他“假设”问题，引发的“假设”问题都必须得到很好的回答

 

实践证明，这种方法是非常有效的，但是前提是测试人员需要投入足够的精力和时间进行测试用例的编写，并且不能被动地接受和相信需求规格说明书，要对其抱着怀疑的态度。

 

利用现存的产品对需求进行测试

•比较产品，提出一份在新需求中可能遗漏的功能列表

•访谈一些旧产品的使用者，提出一份在当前系统中不需要的功能列表

•比较旧产品和其原始的需求，准备一份新产品开发中的潜在问题的列表。尤其要注意那些没有被实现的或是实现了之后又被丢弃的需求

•避免因为每个旧产品而把产品做成一把瑞士军刀的诱惑。不要让那些不属于整个需求过程的特征悄悄混进来