估算

测试对软件工作量的估算的准确性

测试评估软件系统的状况的准确性

关注点:

  • 不准确的估算
  • 不适当的开发过程
  • 不真实的状态报告

如何知道对工作量的估算是正确的

估算工作量的工具很容易出错

对软件工作量的估算需要策略

五个一般的方法

  • 推测
  • 加入一些约束条件
  • 以一些数据为基础
  • 模拟进行工作
  • 将一些参数模型化

参数模型

  • 回归模型:将现有的参数与已有的历史数据相拟和。
  • 启发式模型:对历史数据进行观察和解释
  • 现象模型:假设软件开发过程可以依据一些更广泛的可适用的过程解释。

模型遵循的共同模式

  • 估算软件的大小
  • 将大小转化成人力的估算,并且作出可能的成本的估算
  • 依据项目的特性进行估算的调整
  • 将整体的估算划分到不同的项目阶段中
  • 估算不包括技巧上面的人力和计算机的运行时间
  • 将以上内容相加

对估算进行检验

  • 检验估算模型的合理性
  • 检验模型是否包含了必须的测试要素
  • 检验模型的正确性

检验估算模型的正确性

  • 重新进行估算:输入是否正确;输入是否合理;对数据的计算是否合理有效
  • 比较延期的估算是否符合项目实际情况
  • 让谨慎的人来作测试验证工作
  • 对软件中的冗余价值估算

影响估算正确与否的因素

  • 软件规模
  • 新设计新代码的比例
  • 复杂程度
  • 设计和编码的困难
  • 使用什么语言
  • 安全性
  • 需求的挥发性
  • 组织因素:项目计划/人员/开发环境/硬件资源/人员利用率/膨胀因素
  • 估算就是估算,不是保证书

追踪测试工作的瓶颈

  • 工作完成点
  • 同配置管理系统紧密的结合
  • 如何使用:模块列表/里程碑/工作完成点
  • 用计算所有工作的完成度来检查系统工作过程。

测试计划

开发测试计划

目标:

详细的描述怎样能成功的完成测试工作,其中应包含必须的资源和实施计划。

可能的不利因素:

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

实施过程

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

建立测试计划

定义测试目标

开发测试矩阵

  • 软件模型
  • 结构特性
  • 批量测试的阶段和用例
  • 为在线系统作概念上的测试脚本
  • 软件测试矩阵

    定义测试管理
  • 测试计划的一般性信息
  • 定义测试里程碑
  • 定义管理上的检查点

    书写测试计划

评审测试计划

涉及评审的问题

  • 评审测试的开始时间是否会延期
  • 有没有抵触评审的角色
  • 一段时间内是否很难得到工作的检查信息。
  • 更换工具有可能导致他们反感评审工作
  • 评审结果可能会影响对个人的工作评价

    对于最终成品的检查
  • 项目的需求规格说明书
  • 软件返工/维护的文档
  • 升级后的技术文档
  • 被更改的源程序
  • 测试计划
  • 用户手册(包括在线帮助)

    正式评审中的角色
  • 缓和剂(SQA)
  • 读者
  • 记录者
  • 作者
  • 检测员

    正式评审发现的缺陷应包含的信息
  • 起因
  • 类型
  • 分类
  • 级别

评审流程

计划和组织

通篇的讲解(可选)

个人准备

评审会议

修订和反复


需求阶段的测试

测试成本

被设计用来减少测试成本

IBM的数据:大约 60个缺陷/千行;2/3的缺陷产生在需求和设计阶段

在需求和设计阶段发现的缺陷修正的花费最小

修正系统测试阶段发现的缺陷,花费是以上的10倍

发布产品以后,修正缺陷的花费是原来的100倍

生命周期的测试概念

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

需求阶段的测试

所有的花费都是值得的

大部分缺陷将不会进入到设计&编码阶段

目标

  • 需求正确的表现出了用户的需要
  • 需求已经被定义和文档化了
  • 花费和收益成正比
  • 需求的控制被明确
  • 有合理的流程可遵循
  • 有合理的方法可供选择

    准备风险列表
  • 确定风险组
  • 确定风险(风险分析 & 风险检查表)
  • 建立控制目标
  • 确定有足够的控制力度

分析测试要素

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

需求走查

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

设计阶段的测试

设计阶段的测试任务

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

交付的产品

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

分析测试要素涉及的内容

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

对设计进行评审

选择评审组成员

对评审组进行培训

通报项目组

分配足够的时间

只对文档化的事实进行评审

和项目组一起进行评审

对评审形成建议

和项目组对建议一起进行评审

准备正式的报告


编码阶段的测试

测试的职责

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

形成的输出

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

关注点

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

建议的测试方式

桌面调试

  • 语法上的
  • 结构上的
  • 功能上的

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

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

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

测试阶段

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

文档

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

测试用例的概念是简单的

建立有效的测试用例是复杂的

设计测试文件

  • 测试用例应当包含合法的和非法的输入
  • 每一个动作只进行一次关键操作

    输入测试数据

    分析结果

    尝试将测试文件违反程序的规则进行输入

典型的测试类型

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

测试总结

测试报告

目标

  • 表示出目前项目的实际状况
  • 明确什么是测试做的工作,什么是不作的工作。
  • 给出系统的操作性能的评价
  • 明确什么时候系统可以进行产品化的工作

    关注点
  • 测试报告只有真正需要的时候才有用,需要配合市场和管理
  • 测试的信息是不充分的(对于评价一个项目来说)
  • 测试状况并不能真实的反应个人的状况

测试期间的数据收集

有关测试结果的积累数据

测试任务,测试集合和测试事件的描述

缺陷分析:

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

    效果

测试报告

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

报告汇总

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

Testing - 测试基础 - 阶段的更多相关文章

  1. Testing - 测试基础 - 方法

    选择和使用测试方法和工具 按照测试需求用途(或测试技巧)选择 在软件开发生命周期和软件测试流程中适当地选择 按照测试人员实际技能选择 选择可提供的和可执行的 测试方法 类别及技巧 目标 使用方法 举例 ...

  2. Testing - 测试基础 - 自动

    自动化测试模型 一个自动化测试框架就是一个集成体系,在这一体系中包含测试功能的函数库.测试数据源.测试对象识别标准,以及种可重用的模块. 自动化测试框架在发展的过程中,不断有新的模型(概念)被提出,目 ...

  3. Testing - 测试基础 - 探索

    定义 探索性测试(Exploratory Testing)是一种自由的软件测试风格,强调测试人员同时展开测试学习,测试设计,测试执行和测试结果评估等活动,以持续优化测试工作. 其特征有:即兴发挥,快速 ...

  4. Testing - 测试基础 - 概念

    测试是为了度量和提高被测试软件的质量,对测试软件进行工程设计.实施.维护的的整个生命周期过程. 仅仅发现Bug是测试的初步,而分析出根本原因推动问题的解决,却要有很深的功底. 不同的测试岗位从事不同的 ...

  5. Testing - 测试基础 - 流程

    测试存在于各个阶段: 需求测试--->单元测试--->集成测试--->系统测试--->性能测试--->用户测试--->回归测试 需求测试 完整性&正确性 一 ...

  6. Testing - 测试基础 - 分类

    对软件内部结构的深入程度 黑盒测试:又叫功能测试.数据驱动测试或基于需求规格说明书的功能测试. 白盒测试:又称结构测试.逻辑驱动测试或基于程序代码内部构成的测试. 灰盒测试:包含性能测试.自动化测试. ...

  7. Testing - 测试基础 - 用例

    测试用例 是指对一项特定的软件产品进行测试任务的描述,体现测试方案.方法.技术和策略. 内容包括测试目标.测试环境.输入数据.测试步骤.预期结果.测试脚本等,并形成文档. 每个具体测试用例都将包括下列 ...

  8. Testing - 测试基础 - 理解

    理解 目的 测试就是要找到关键信息,有关项目和产品的关键决策都是根据这些信息做出. 对产品质量做出总体评估. 找出并报告团队所有可能会对产品价值产生消极影响的问题(但并不意味着能发现所有问题). 重心 ...

  9. Testing - 测试基础 - 模型

    珠玉在前,不再赘言. 软件测试模型 软件测试模型汇总

随机推荐

  1. php面试题及答案收藏(转)

    php面试题及答案收藏(这套试题是在网上看到的,不知作者是谁) 基础题 1.表单中 get与post提交方法的区别? 答:get是发送请求HTTP协议通过url参数传递进行接收,而post是实体数据, ...

  2. Hadoop2.20集群搭建

    hadoop2.0已经发布了稳定版本了,增加了很多特性,比如HDFS HA.YARN等. 注意:apache提供的hadoop-2.2.0的安装包是在32位操作系统编译的,因为hadoop依赖一些C+ ...

  3. Xamarin.Android中使用ResideMenu实现侧滑菜单

    上次使用Xamarin.Android实现了一个比较常用的功能PullToRefresh,详情见:Xamarin. Android实现下拉刷新功能 这次将实现另外一个手机App中比较常用的功能:侧滑菜 ...

  4. 你写的return null正确吗?

    上次一篇“你写的try…catch真的有必要吗”引起了很多朋友的讨论.本次我在code review又发现了一个问题,那就是有人有意无意的写出了return null这样的代码,例如: public ...

  5. Java语法糖2:自动装箱和自动拆箱

    前言 一开始想学学自动拆箱和自动装箱是被这个名字吸引到,听上去好像很高端的样子,其实自动拆箱.自动装箱是很简单的内容. 自动拆箱和自动装箱 Java为每种基本数据类型都提供了对应的包装器类型.举个例子 ...

  6. nw.js如何处理拖放操作

    nw.js如何处理拖放操作 其实拖放(drag-drop)操作是Html5的功能,不是nw.js的内置API,那么我们采用Html5应用一般的处理方法就可以了. 首先我们看一下一个正常的页面,直接拖放 ...

  7. [ZigBee] 8、ZigBee之UART剖析·二(串口收发)

    前言:上一节讲UART基本知识介绍完了,并深入剖析了一个串口发送工程,本节将进一步介绍串口收发! 1.初始化 在串口初始化部分,和上一节不同的地方是: 51 U0CSR |= 0x40; //允许接收 ...

  8. 在js中对时间类型格式化字符串

    Date.prototype.toString = function (format) { if (format == null) { format = "yyyy-MM-dd HH:mm: ...

  9. 实战使用Axure设计App,使用WebStorm开发(4) – 实现页面UI

    系列文章 实战使用Axure设计App,使用WebStorm开发(1) – 用Axure描述需求  实战使用Axure设计App,使用WebStorm开发(2) – 创建 Ionic 项目   实战使 ...

  10. IOS UIView 04- 自定义控件

    注:本人是翻译过来,并且加上本人的一点见解. 前言 本文将讨论一些自定义视图.控件的诀窍和技巧.我们先概述一下 UIKit 向我们提供的控件,并介绍一些渲染技巧.随后我们会深入到视图和其所有者之间的通 ...