Testing - 软件测试知识梳理 - 测试阶段

测试计划

开发测试计划
目标:
详细的描述怎样能成功的完成测试工作，其中应包含必须的资源和实施计划。
可能的不利因素：

• 没有得到足够的培训
• 心里准备不足
• 缺乏测试工具
• 缺乏管理的标准和支持
• 缺乏客户和最终使用者的参与
• 没有足够的时间进行测试
• 对于独立的测试人员过度信任
• 版本改变的太快
• 测试人员处于不受重视的情况中
• 不能说不

实施过程

• 听取各方面的意见和建议
• 标明项目风险:测试要素/联系测试矩阵
• 建立测试计划
• 对计划进行评审

建立测试计划
定义测试目标
开发测试矩阵

• 软件模型
• 结构特性
• 批量测试的阶段和用例
• 为在线系统作概念上的测试脚本
• 软件测试矩阵
  定义测试管理
• 测试计划的一般性信息
• 定义测试里程碑
• 定义管理上的检查点
  书写测试计划

评审测试计划
涉及评审的问题

• 评审测试的开始时间是否会延期
• 有没有抵触评审的角色
• 一段时间内是否很难得到工作的检查信息。
• 更换工具有可能导致他们反感评审工作
• 评审结果可能会影响对个人的工作评价
  对于最终成品的检查
• 项目的需求规格说明书
• 软件返工/维护的文档
• 升级后的技术文档
• 被更改的源程序
• 测试计划
• 用户手册（包括在线帮助）
  正式评审中的角色
• 缓和剂（SQA）
• 读者
• 记录者
• 作者
• 检测员
  正式评审发现的缺陷应包含的信息
• 起因
• 类型
• 分类
• 级别

评审流程
计划和组织
通篇的讲解（可选）
个人准备
评审会议
修订和反复

---

需求阶段的测试

测试成本
被设计用来减少测试成本
IBM的数据:大约 60个缺陷/千行;2/3的缺陷产生在需求和设计阶段
在需求和设计阶段发现的缺陷修正的花费最小
修正系统测试阶段发现的缺陷，花费是以上的10倍
发布产品以后，修正缺陷的花费是原来的100倍

生命周期的测试概念

• 在软件开发过程中持续的进行测试
• 在尽可能早的阶段点去修正缺陷
• 需要正式的开发流程来支持
• 组建测试团队
• 当开发开始进行的时候，测试就开始进行了

需求阶段的测试
所有的花费都是值得的
大部分缺陷将不会进入到设计&编码阶段
目标

• 需求正确的表现出了用户的需要
• 需求已经被定义和文档化了
• 花费和收益成正比
• 需求的控制被明确
• 有合理的流程可遵循
• 有合理的方法可供选择
  准备风险列表
• 确定风险组
• 确定风险（风险分析 & 风险检查表）
• 建立控制目标
• 确定有足够的控制力度

分析测试要素

• 需求的设计是否遵循了已定义的方法
• 提交了已定义的功能说明
• 定义了系统界面
• 已经估计了性能标准
• 容忍度被预先估计
• 预先定义了权限规则
• 需求中预先定义了文件完整性
• 预先定义了需求的变更流程
• 预先定义了失败的影响
• 权限定义

需求走查

• 建立基本规则
• 选择小组/通报参与者
• 项目介绍
• 问题/建议
• 形成最终报告

---

设计阶段的测试

设计阶段的测试任务

• 给测试要素打分
• 分析测试要素
• 对设计进行评审
• 检查修改的部分

交付的产品

• 输入说明
• 过程说明
• 文件说明
• 输出说明
• 控制说明
• 系统流程图
• 硬件和软件的需求
• 操作手册说明书
• 数据保留的策略

分析测试要素涉及的内容

• 设计了对数据完整性的控制
• 设计了权限规则
• 设计了对文件完整性的控制
• 设计了审计追踪
• 设计了发生意外情况时的计划
• 设计了如何达到服务水平的方法
• 定义了权限流程
• 定义了完整的方法学
• 设计了保证需求一致性的方法
• 进行了易用性的设计
• 设计是可维护的
• 设计是简单的
• 交互界面设计完毕
• 定义了成功的标准
• 需要同实际操作者沟通

对设计进行评审
选择评审组成员
对评审组进行培训
通报项目组
分配足够的时间
只对文档化的事实进行评审
和项目组一起进行评审
对评审形成建议
和项目组对建议一起进行评审
准备正式的报告

---

编码阶段的测试

测试的职责

• 编码是一个纯技术的工作，几乎不需要用户的参与
• 项目领导者有参与测试的责任
• 监督过程的有效性

形成的输出

• 编码说明书
• 程序文档
• 计算机程序列表
• 可执行的程序
• 程序流程图
• 操作介绍
• 单元测试结果

关注点

• 完成对数据完整性的控制
• 定义完毕授权的规则
• 完成对文件完整性的控制
• 实现审计追踪
• 规划出意外情况发生后的处理计划
• 对系统如何达到预定义的服务水平做了计划
• 完成了对安全问题的处理流程
• 编码工作是依据规定的方法完成的
• 编码与设计相一致（正确性）
• 编码与设计相一致（易用性）
• 代码是可维护的
• 编码与设计相一致（简洁性）
• 编码与设计相一致（耦合性）
• 已开发了操作流程
• 定义出程序成功的标准（性能上）

建议的测试方式
桌面调试

• 语法上的
• 结构上的
• 功能上的
  代码互查
• 建立基本的互查规则
• 选择互查的team
• 对成员进行培训
• 选择互查的方法
• 提供互查的材料
• 流程图，源程序，典型的处理流程
• 对互查进行必要的管理
• 给出互查结论
• 提供最终的报告

编码阶段测试需要解决的问题

• 系统是可维护的吗？
• 系统说明是否已经完成了？
• 编码是否按照既有的标准进行，过程是否易于实践？
• 是否有足够的测试计划用来评估可执行的程序？
• 是否编制了足够的文档。

---

测试阶段

在需求，设计，编码阶段多进行一些测试，在系统测试阶段就会少一些问题。

文档

• 测试阶段的测试计划
• 测试用例
• 前期测试的测试结果
• 第三方测试反馈，例如：计算机操作人员
• 正式的测试总结报告

测试用例的概念是简单的
建立有效的测试用例是复杂的
设计测试文件

• 测试用例应当包含合法的和非法的输入
• 每一个动作只进行一次关键操作
  输入测试数据
  分析结果
  尝试将测试文件违反程序的规则进行输入

典型的测试类型

• 手册，回归，功能点测试
• 一致性测试（授权）
• 功能点测试（完整性）
• 功能点测试（审计，追踪）
• 覆盖性的测试（测试的连续性）
• 压力测试（服务水平）
• 一致性测试（安全性）
• 依照预先定义的测试方法
• 功能点测试（正确性）
• 支持手册的测试（易用性）
• 检查（可维护性）
• 灾难性的测试（可携带性）
• 功能和回归测试（耦合性）
• 一致性的测试（性能）
• 操作性的测试（易用性）

---

测试总结

测试报告
目标

• 表示出目前项目的实际状况
• 明确什么是测试做的工作，什么是不作的工作。
• 给出系统的操作性能的评价
• 明确什么时候系统可以进行产品化的工作
  关注点
• 测试报告只有真正需要的时候才有用，需要配合市场和管理
• 测试的信息是不充分的（对于评价一个项目来说）
• 测试状况并不能真实的反应个人的状况

测试期间的数据收集
有关测试结果的积累数据
测试任务，测试集合和测试事件的描述
缺陷分析:

• 由于计划的问题，导致没有发现的缺陷的数据
• 严重的缺陷
• 缺陷类型
• 为什么缺陷没有发现
  效果

测试报告

• 报告目前的软件状态
• 功能/测试矩阵
• 功能测试的状态报告，侧重点分析
• 关于功能的工作时间轴
• 期望发现 VS 实际发现的缺陷比
• 没有发现的缺陷和改正的缺陷的差距
• 按照类型分类，没有改正的缺陷的平均值
• 缺陷分类报告
• 测试活动报告

报告汇总

• 各个阶段的项目测试总结报告
• 继承性测试报告
• 系统测试报告
• 确认测试报告

---