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

* * * * * * 与规格说明书类似好比建筑师 其 他 10% 软件产品说明书（需求） 56% 编写代码 7% 设 计27% 软件复杂文档不足时间紧低级错误 不全面常更改沟通不好 软件缺陷--构成 为什么软件产品规格说明书中缺陷最多？ 用户一般是非计算机专业人员,软件开发人员和用户的沟通存在较大困难，对要开发的产品功能理解不一致。 由于软件产品还没有设计、开发，完全靠想象去描述系统的实现结果，所以有些特性还不够清晰。 需求变化的不一致性.用户的需求总是在不断变化的，这些变化如果没有在产品规格说明书中得到正确的描述，容易引起前后文，上下文的矛盾。 对规格说明书不够重视，在规格说明书的设计和写作上投入的人力，时间不足。 没有在整个开发队伍中进行充分沟通，有时只有设计师或项目经理得到比较多的信息。 需求 设计 编码 测试 发布 时间 缺陷数 早期缺陷发现（70%-90%）测试前 在真正的程序测试之前，通过审 查、评审会可以发现更多的缺陷。 软件缺陷—不同阶段分布 软件缺陷—修复成本 完整的软件开发流程 项目规划 项目需求分析 项目概要分析 项目详细分析 代码编写 测试代码编写 测试需求分析 系统测试计划 集成测试计划 单元测试计划 产品发布 系统测试 集成测试 单元测试 软件测试与软件开发生命周期的关系 用户需求测试的手段 ? ? 编写测试用例 编写用户使用手册 问题探讨： 测试用例作为系统验收标准合适吗？ 功能点测试概念 1、? 主要期望目的：描述此功能点是为了什么目的而开发的，即需求要求实现的目的。 2、? 次要期望目的：描述此功能点在对错误的描述，在各种环境中的适应情况等。 立足需求分析过程 是需求的测试方法 是需求明晰性评审的新视角 功能点测试技术总结 在描述需求时分解过程采取描绘轮廓、分解单元、细化等步骤，其中： 第一步描绘轮廓，描绘被测程序的测试范围包括测试目标、对象等。 第二步分解单元，对测试范围进行分解，根据结构分解成不同级别的单元，形成树形需求。例如子系统、模块等。 第三步单元细化，对已分解的单元进行细化，细述每项需求，并设定其优先级。 1、需求分析过程 在编写需求时有一些依据，需要注意以下几点： 完整性，一份完整的需求就是一份测试方案，所以必须强调完整性。 无歧异性，需求、测试用例设计和测试执行人员通常不是一个人完成，所以需求的无歧异性至关重要。 一致性，与软件需求和测试用例设计均保持一致。 可追踪性 可测试性，因为后继的测试用例设计和缺陷报告均以需求为基础，所以需求必须具有可测试性。 2、需求的测试方案 以“用户登录”需求为例，描述测试用例的撰写方法。 1、功能需求的示例 第一步，如图以软件需求说明书为依据。 功能点测试技术案例 第二步，为“用户登录”功能总结功能点如下表。 设计者 ：王丽 编写日期：2009-7-20 校阅人 ：杨立阳 校阅日期：2009-7-24 类型 ：系统功能 状态 ：已审核 需求编号 功能分类 第一层 功能分类 第二层 功能点测试项 优先级 11.1 启动条件 -- “用户登录”页面正常打开 高 11.2 用户登录 成功 常规 [登录]成功，页面跳转至用户Default.aspx画面 高 11.3 必须 输入项 设定[用户名] 高 11.4 设定[密码] 高 11.5 设定[验证码] 高 11.6 用户登录 失败 失败 原因 检查数据库连接 高 11.7 检查Web服务连接 高 11.8 检查网络连接是否超时 高 （1）为了总结全面的功能点，从示例“功能第一层分类中”可以看出从“启动条件”、“用户登录成功”、“用户登录失败”三方面进行考虑。 （2）“用户登录成功”的功能分类第二层“必须输入项”功能点包含“用户名”、“密码”和“验证码”，都是必输入项，并且都不能进行再拆分，满足最小测试项的要求，如果再进行拆分就需考虑各功能点的等价类、边界值的取值即测试用例设计了，测试用例设计不属于需求阶段的工作。 功能点测试用例规范 功能点测试的模板参见下表。 如果不存在子分类及测试项时可使用“--”表示。以模块为单位组织功能需求，如果一个模块包括多个页面，则分页面进行描述。 功能分类第一层 功能分类第二层 测试项 页 面 1 启动条件 -- 导航条启动 页面正常打开 其它 关联输入项检查 控件与数据库表的关联 …… 控件与控件的关联 重置按钮 复位键 其它 功能1 成功 常规 数据库新建数据的确认 功能键按钮的确认 默认