|
估算 测试对软件工作量的估算的准确性
测试评估软件系统的状况的准确性
关注点： 如何知道对工作量的估算是正确的
估算工作量的工具很容易出错
对软件工作量的估算需要策略 五个一般的方法 - 推测
- 加入一些约束条件
- 以一些数据为基础
- 模拟进行工作
- 将一些参数模型化
参数模型 - 回归模型：将现有的参数与已有的历史数据相拟和。
- 启发式模型：对历史数据进行观察和解释
- 现象模型：假设软件开发过程可以依据一些更广泛的可适用的过程解释。
模型遵循的共同模式 - 估算软件的大小
- 将大小转化成人力的估算，并且作出可能的成本的估算
- 依据项目的特性进行估算的调整
- 将整体的估算划分到不同的项目阶段中
- 估算不包括技巧上面的人力和计算机的运行时间
- 将以上内容相加
对估算进行检验 - 检验估算模型的合理性
- 检验模型是否包含了必须的测试要素
- 检验模型的正确性
检验估算模型的正确性 - 重新进行估算:输入是否正确;输入是否合理;对数据的计算是否合理有效
- 比较延期的估算是否符合项目实际情况
- 让谨慎的人来作测试验证工作
- 对软件中的冗余价值估算
影响估算正确与否的因素 - 软件规模
- 新设计新代码的比例
- 复杂程度
- 设计和编码的困难
- 使用什么语言
- 安全性
- 需求的挥发性
- 组织因素:项目计划/人员/开发环境/硬件资源/人员利用率/膨胀因素
- 估算就是估算，不是保证书
追踪测试工作的瓶颈 - 工作完成点
- 同配置管理系统紧密的结合
- 如何使用:模块列表/里程碑/工作完成点
- 用计算所有工作的完成度来检查系统工作过程。
测试计划开发测试计划
目标:
详细的描述怎样能成功的完成测试工作，其中应包含必须的资源和实施计划。
可能的不利因素： - 没有得到足够的培训
- 心里准备不足
- 缺乏测试工具
- 缺乏管理的标准和支持
- 缺乏客户和最终使用者的参与
- 没有足够的时间进行测试
- 对于独立的测试人员过度信任
- 版本改变的太快
- 测试人员处于不受重视的情况中
- 不能说不
实施过程 - 听取各方面的意见和建议
- 标明项目风险:测试要素/联系测试矩阵
- 建立测试计划
- 对计划进行评审
建立测试计划
定义测试目标
开发测试矩阵 - 软件模型
- 结构特性
- 批量测试的阶段和用例
- 为在线系统作概念上的测试脚本
- 软件测试矩阵
定义测试管理 - 测试计划的一般性信息
- 定义测试里程碑
- 定义管理上的检查点
书写测试计划
评审测试计划
涉及评审的问题 - 评审测试的开始时间是否会延期
- 有没有抵触评审的角色
- 一段时间内是否很难得到工作的检查信息。
- 更换工具有可能导致他们反感评审工作
- 评审结果可能会影响对个人的工作评价
对于最终成品的检查 - 项目的需求规格说明书
- 软件返工/维护的文档
- 升级后的技术文档
- 被更改的源程序
- 测试计划
- 用户手册（包括在线帮助）
正式评审中的角色 - 缓和剂（SQA）
- 读者
- 记录者
- 作者
- 检测员
正式评审发现的缺陷应包含的信息 - 起因
- 类型
- 分类
- 级别
评审流程
计划和组织
通篇的讲解（可选）
个人准备
评审会议
修订和反复
需求阶段的测试测试成本
被设计用来减少测试成本
IBM的数据:大约 60个缺陷/千行;2/3的缺陷产生在需求和设计阶段
在需求和设计阶段发现的缺陷修正的花费最小
修正系统测试阶段发现的缺陷，花费是以上的10倍
发布产品以后，修正缺陷的花费是原来的100倍 生命周期的测试概念 - 在软件开发过程中持续的进行测试
- 在尽可能早的阶段点去修正缺陷
- 需要正式的开发流程来支持
- 组建测试团队
- 当开发开始进行的时候，测试就开始进行了
需求阶段的测试
所有的花费都是值得的
大部分缺陷将不会进入到设计&编码阶段
目标 - 需求正确的表现出了用户的需要
- 需求已经被定义和文档化了
- 花费和收益成正比
- 需求的控制被明确
- 有合理的流程可遵循
- 有合理的方法可供选择
准备风险列表 - 确定风险组
- 确定风险（风险分析 & 风险检查表）
- 建立控制目标
- 确定有足够的控制力度
分析测试要素 - 需求的设计是否遵循了已定义的方法
- 提交了已定义的功能说明
- 定义了系统界面
- 已经估计了性能标准
- 容忍度被预先估计
- 预先定义了权限规则
- 需求中预先定义了文件完整性
- 预先定义了需求的变更流程
- 预先定义了失败的影响
- 权限定义
需求走查 - 建立基本规则
- 选择小组/通报参与者
- 项目介绍
- 问题/建议
- 形成最终报告
设计阶段的测试设计阶段的测试任务 - 给测试要素打分
- 分析测试要素
- 对设计进行评审
- 检查修改的部分
交付的产品 - 输入说明
- 过程说明
- 文件说明
- 输出说明
- 控制说明
- 系统流程图
- 硬件和软件的需求
- 操作手册说明书
- 数据保留的策略
分析测试要素涉及的内容 - 设计了对数据完整性的控制
- 设计了权限规则
- 设计了对文件完整性的控制
- 设计了审计追踪
- 设计了发生意外情况时的计划
- 设计了如何达到服务水平的方法
- 定义了权限流程
- 定义了完整的方法学
- 设计了保证需求一致性的方法
- 进行了易用性的设计
- 设计是可维护的
- 设计是简单的
- 交互界面设计完毕
- 定义了成功的标准
- 需要同实际操作者沟通
对设计进行评审
选择评审组成员
对评审组进行培训
通报项目组
分配足够的时间
只对文档化的事实进行评审
和项目组一起进行评审
对评审形成建议
和项目组对建议一起进行评审
准备正式的报告
编码阶段的测试测试的职责 - 编码是一个纯技术的工作，几乎不需要用户的参与
- 项目领导者有参与测试的责任
- 监督过程的有效性
形成的输出 - 编码说明书
- 程序文档
- 计算机程序列表
- 可执行的程序
- 程序流程图
- 操作介绍
- 单元测试结果
关注点 - 完成对数据完整性的控制
- 定义完毕授权的规则
- 完成对文件完整性的控制
- 实现审计追踪
- 规划出意外情况发生后的处理计划
- 对系统如何达到预定义的服务水平做了计划
- 完成了对安全问题的处理流程
- 编码工作是依据规定的方法完成的
- 编码与设计相一致（正确性）
- 编码与设计相一致（易用性）
- 代码是可维护的
- 编码与设计相一致（简洁性）
- 编码与设计相一致（耦合性）
- 已开发了操作流程
- 定义出程序成功的标准（性能上）
建议的测试方式
桌面调试 - 语法上的
- 结构上的
- 功能上的
代码互查 - 建立基本的互查规则
- 选择互查的team
- 对成员进行培训
- 选择互查的方法
- 提供互查的材料
- 流程图，源程序，典型的处理流程
- 对互查进行必要的管理
- 给出互查结论
- 提供最终的报告
编码阶段测试需要解决的问题 - 系统是可维护的吗？
- 系统说明是否已经完成了？
- 编码是否按照既有的标准进行，过程是否易于实践？
- 是否有足够的测试计划用来评估可执行的程序？
- 是否编制了足够的文档。
测试阶段在需求，设计，编码阶段多进行一些测试，在系统测试阶段就会少一些问题。 文档 - 测试阶段的测试计划
- 测试用例
- 前期测试的测试结果
- 第三方测试反馈，例如：计算机操作人员
- 正式的测试总结报告
测试用例的概念是简单的
建立有效的测试用例是复杂的
设计测试文件 - 测试用例应当包含合法的和非法的输入
- 每一个动作只进行一次关键操作
输入测试数据
分析结果
尝试将测试文件违反程序的规则进行输入
典型的测试类型 - 手册，回归，功能点测试
- 一致性测试（授权）
- 功能点测试（完整性）
- 功能点测试（审计，追踪）
- 覆盖性的测试（测试的连续性）
- 压力测试（服务水平）
- 一致性测试（安全性）
- 依照预先定义的测试方法
- 功能点测试（正确性）
- 支持手册的测试（易用性）
- 检查（可维护性）
- 灾难性的测试（可携带性）
- 功能和回归测试（耦合性）
- 一致性的测试（性能）
- 操作性的测试（易用性）
测试总结测试报告
目标 - 表示出目前项目的实际状况
- 明确什么是测试做的工作，什么是不作的工作。
- 给出系统的操作性能的评价
- 明确什么时候系统可以进行产品化的工作
关注点 - 测试报告只有真正需要的时候才有用，需要配合市场和管理
- 测试的信息是不充分的（对于评价一个项目来说）
- 测试状况并不能真实的反应个人的状况
测试期间的数据收集
有关测试结果的积累数据
测试任务，测试集合和测试事件的描述
缺陷分析: - 由于计划的问题，导致没有发现的缺陷的数据
- 严重的缺陷
- 缺陷类型
- 为什么缺陷没有发现
效果
测试报告 - 报告目前的软件状态
- 功能/测试矩阵
- 功能测试的状态报告，侧重点分析
- 关于功能的工作时间轴
- 期望发现 VS 实际发现的缺陷比
- 没有发现的缺陷和改正的缺陷的差距
- 按照类型分类，没有改正的缺陷的平均值
- 缺陷分类报告
- 测试活动报告
报告汇总 - 各个阶段的项目测试总结报告
- 继承性测试报告
- 系统测试报告
- 确认测试报告
【转载】仅作分享，侵删
链接：http://www.cnblogs.com/anliven/p/6074016.html
| 
收藏
淘帖
踩
