软件测试与软件质量
软件测试经典定义(多看教程)
为了发现软件中存在的错误而进行的操作。目的:为了发现错误
软件测试目的
- 发现软件中的错误
软件测试只能证明软件中存在错误,不能证明软件没有错误。
软件测试的对象
- 软件代码
- 文档
- 数据
数据库的测试对象
- 数据库的连接
- 数据库的安全测试
- 数据库接口测试
- 定义的存储过程和触发器的测试
软件质量
软件特性的总和
也是满足规定或潜在用户需求的能力
也是软件特性具备“能力”的体现。
组成
- 内部质量
- 外部质量
- 使用质量——从用户角度出发
质量保证(QA)VS 软件测试
【质量保证】
- 贯穿与软件完成的全流程,着眼于软件开发过程中的
过程
、步骤
和产物
。
【软件测试】 - 不关心过程的活动,只关心过程的
产物
。 - 重要工作:问题的分析、追踪与回归测试
- 是软件质量保证的一个重要环节
软件产品质量的评价标准
- 通过测量内部属性
- 通过测量外部属性——
可靠性
等 - 通过测量使用质量的属性——
生产率
、安全性
、满意度
、有效性
软件测试原则(6)
- 所有的测试都应追溯到用户需求(符合需求)
- 应尽早并不断的进行测试
- 测试工作应避免由原开发软件的人或小组来承担(单元测试或者叫模块测试除外)
- 穷举测试是不可能的,测试需要终止
- 充分重视测试中的集群现象
- 严格按照测试计划来进行,避免测试的随意性
软件测试分类
开发阶段划分(5)
- 单元测试
- 集成测试
- 系统测试
- 确认测试
- 验收测试
单元测试(模块测试)
- 需要从程序的内部结构出发设计测试用例
- 多个模块可以平行的独立的进行单元测试
测试内容
- 桩模块——模拟被测试的模块
所调用的模块
,用来测试上层模块 - 驱动模块——模拟被测模块的
上一级模块
,用来测试下级模块
集成测试(组装测试、联合测试)
涉及到的文档
- 概要设计文档
- 详细设计文档
组装时考虑的问题
- 连接各模块时,穿越模块接口的数据是否会丢失
- 一个模块的功能是否会对另一个模块的功能产生不利影响
- 各个子功能组合起来,是否能达到预期的父功能
- 全局数据结构是否有问题
- 每个模块的误差累积起来,是否会放大,以致达到不能接受的程度
模块组装方式
- 一次性组装(big bang)——全部一次性组装完成后再进行测试(适用于小软件)
优点:操作简单,成本低
缺点:难以定位测试时发现的问题 - 增值式组装
【1】自顶向下的增值方式
优点:容易发现分支的错误
缺点:容易发生错误的底层模块要到最后才会测试发现
【2】自底向上的增值方式
【3】混合增值方式
完成标志
- 成功执行了
测试计划
中规定的所有集成测试 - 修正了所发现的错误
- 测试结果通过了专门小组的评审或达到了业界的标准
系统测试
- 发现软件与系统定义不符合或与之矛盾的地方
- 集成整个系统元素(包括硬件、外设、网络、人员和系统软件、支持平台等)
确认测试
- 验证软件的功能和性能是否与需求一致
- 进行有效性测试——一般采用黑盒测试
- 软件配置复查
一般由独立的第三方测试机构进行,应当严格遵守操作手册和用户手册规定的使用步骤,以便检查文档资料的完整性和正确性
验收测试
用户为主
- 一般使用生产中的实际数据进行测试
- 决定是否接收或拒收系统
测试技术划分
- 白盒测试
- 黑盒测试
- 灰盒测试
实施组织测试
- 开发方测试(α测试)
——测试人员:开发方为主
——测试环境:开发环境下 - 用户方测试(β测试)
——测试人员:用户
——测试环境:用户的应用环境下 - 第三方测试(独立测试)
——测试人员:第三方独立测试机构
软件测试过程模型
V模型
- 底层测试:源代码的正确性测试(单元测试、集成测试)
- 高层测试:用户需求的测试(系统测试、验收测试)
V模型局限性
- 测试在软件开发完成后进行,与“尽早的、不断的进行测试”相冲突
- 早期的问题(需求或者设计的问题)等到最后才发现,使得问题的解决成本大大增加
W模型
W模型特点
- 有利于尽早的发现问题,体现“尽早地和不断地进行软件测试”的原则
- 强调测试伴随着整个软件开发周期
- 在 V 模型中增加软件和开发阶段应同步进行的测试
W模型局限性
软件开发和测试保持一种线性的前后关系,需要有严格的指令表示上一阶段完全结束,才可正式开始下一个阶段。这就无法支持迭代、自发性以及变更调整。
H模型
- 软件测试模型是一个
独立的流程
- 当某个测试时间点就绪时,软件测试即从测试准备阶段进入测试执行阶段
X模型
- 定位了
探索性测试
前置测试模型
- 业务需求最好在设计与开发之前就被正确定义
- 主张根据业务需求进行测试设计,认为
设计阶段
是进行测试执行和测试设计的最好时机 - 将测试执行与开发结合在一起,并在开发阶段以
“编码-测试-编码-测试-编码-测试”
的方式来体现,对每一个交付的开发结果都必须通过一定的方式进行测试 验收测试独立于技术测试
,以保证设计及程序编码能够符合最终用户的需求
几种测试模型的比较
常见的测试模型的比较详解
测试信息流
输入信息流
- 软件配置(需求说明书、概要设计说明书、详细设计说明书等)
- 测试配置
- 测试工具
软件失效分类与管理——大题考察
软件失效术语
- 1、软件错误——
人为
的 - 2、软件缺陷——与产品说明书的
偏差
- 3、软件故障——
内部
的状态 - 4、软件失效——
外部
的行为结果
软件失效的原因
主要:产品说明书有问题
次要:软件设计说明书有问题
软件错误的状态(6)
- 新信息 new
- 打开 open
- 修正 fix
- 拒绝 declined
- 延期 deferred
- 关闭 closed
自动化测试相关工具
使用质量模型
系统/软件产品模型
测试记录的内容
测试计划
或者包含测试用例的测试规格说明
- 测试中涉及的
人员
身份 - 测试用例相关的所有
结果
,包括在测试期间出现的所有失败
造成软件测试风险的主要原因
测试计划
的不充分测试过程
的偏差测试方法
有误