基于测试的需求验证技术.ppt

1与规格说明书类似好比建筑师为什么软件产品规格说明书中缺陷最多？
用户一般是非计算机专业人员,软件开发人员和用户的沟通存在较大困难，对要开发的产品功能理解不一致。
由于软件产品还没有设计、开发，完全靠想象去描述系统的实现结果，所以有些特性还不够清晰。
需求变化的不一致性.用户的需求总是在不断变化的，这些变化如果没有在产品规格说明书中得到正确的描述，容易引起前后文，上下文的矛盾。
对规格说明书不够重视，在规格说明书的设计和写作上投入的人力，时间不足。
没有在整个开发队伍中进行充分沟通，有时只有设计师或项目经理得到比较多的信息。需求软件缺陷—修复成本完整的软件开发流程用户需求测试的手段功能点测试概念立足需求分析过程
是需求的测试方法
是需求明晰性评审的新视角在描述需求时分解过程采取描绘轮廓、分解单元、细化等步骤，其中：
第一步描绘轮廓，描绘被测程序的测试范围包括测试目标、对象等。
第二步分解单元，对测试范围进行分解，根据结构分解成不同级别的单元，形成树形需求。例如子系统、模块等。
第三步单元细化，对已分解的单元进行细化，细述每项需求，并设定其优先级。以“用户登录”需求为例，描述测试用例的撰写方法。
1、功能需求的示例
第一步，如图以软件需求说明书为依据。
第二步，为“用户登录”功能总结功能点如下表。（1）为了总结全面的功能点，从示例“功能第一层分类中”可以看出从“启动条件”、“用户登录成功”、“用户登录失败”三方面进行考虑。
（2）“用户登录成功”的功能分类第二层“必须输入项”功能点包含“用户名”、“密码”和“验证码”，都是必输入项，并且都不能进行再拆分，满足最小测试项的要求，如果再进行拆分就需考虑各功能点的等价类、边界值的取值即测试用例设计了，测试用例设计不属于需求阶段的工作。功能点测试用例规范第一步，如图以软件需求和原型设计为依据。

第二步，为“添加管理员”功能总结功能点测试用例，如下表。设计者：王丽
编写日期：2009-7-20
校阅人：杨立阳
校阅日期：2009-7-24
类型：系统功能
状态：已审核从软件需求分析出，添加“添加管理员”需要设定管理员的基本信息并设定管理员的用户权限，功能点“设定[用户名]”、“设定[管理员姓名]”等均不可拆分，满足最小测试项的要求，如果再进行拆分就得考虑各功能点的等价类、边界值的取值也就是测试用例设计了。设定[用户权限]使用的控件是多选框，从软件需求获知必须为用户划分一到多项权限，所以将设定[用户权限]定义为必须输入项，但是并不意味着多选框所有的权限都勾选，关于控件的需求请参考3.3.1节。
编号25.3，常规指添加管理员后一定要验证的内容，使用任何数据，都能够验证这些，所以叫常规。
编号25.12考虑的是添加管理员成功后有“添加成功”消息框提示，所以要作为后继处理。第一步，如图以软件需求说明书为依据。

第二步，为“添加图书”功能总结功能点如下表。需求编号需求编号需求编号需求编号25.6描述的是控件与表的关联关系。图书分类的内容是用户通过自定义的方式存储到数据表T_BookClass然后通过[图书分类]下拉列表框读取出来的。
需求编号25.7和25.8描述的是控件与控件的关联关系。编号25.7，只有[是否折扣]选择框被选中状态下[折扣]下拉列表框才可用，所以两个控件之间有关联关系；编号25.8，[重置]按钮与所有输入项均有关联，当点击[重置]按钮时所有文本框控件需要清空、所有下拉列表控件需要恢复为默认状态。需求编号25.17至25.26考虑的是非必须输入项。这些控件的设定是可选的，所以在定义测试功能点时将它们归为一类。
需求编号25.27至25.29考虑的是组合测试。当输入多个条件时通常对输入条件进行以下几种情况的组合。
第一种情况，所有必须输入项都设定与所有非必须输入项不设定的组合。
第二种情况，所有必须输入项都设定与所有非必须输入项都设定的组合。
第三种情况，所有必须输入项都设定与非必须输入项选择2-3项设定的组合。根据功能点测试用例设计的结果可以排查出需求间的含混问题。谢谢大家！