基于测试需求验证技术.pptVIP

*;与规格说明书类似好比建筑师;为什么软件产品规格说明书中缺陷最多？ 用户一般是非计算机专业人员,软件开发人员和用户的沟通存在较大困难，对要开发的产品功能理解不一致。 由于软件产品还没有设计、开发，完全靠想象去描述系统的实现结果，所以有些特性还不够清晰。 需求变化的不一致性.用户的需求总是在不断变化的，这些变化如果没有在产品规格说明书中得到正确的描述，容易引起前后文，上下文的矛盾。 对规格说明书不够重视，在规格说明书的设计和写作上投入的人力，时间不足。 没有在整个开发队伍中进行充分沟通，有时只有设计师或项目经理得到比较多的信息。;需求; 软件缺陷—修复成本;完整的软件开发流程;用户需求测试的手段;功能点测试概念;立足需求分析过程 是需求的测试方法 是需求明晰性评审的新视角 ; 在描述需求时分解过程采取描绘轮廓、分解单元、细化等步骤，其中： 第一步描绘轮廓，描绘被测程序的测试范围包括测试目标、对象等。 第二步分解单元，对测试范围进行分解，根据结构分解成不同级别的单元，形成树形需求。例如子系统、模块等。 第三步单元细化，对已分解的单元进行细化，细述每项需求，并设定其优先级。;;以“用户登录”需求为例，描述测试用例的撰写方法。 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项设定的组合。; 根据功能点测试用例设计的结果可以排查出需求间的含混问题。;谢谢大家！