第1章 软件测试概述
1.1 概述
软件工程出现的原因:
软件危机的爆发
软件测试的定义:
测试是为了发现错误而执行的一个程序或系统的过程——《软件测试艺术》
测试是以评价一个程序后者系统属性为目标的任何一种活动,是对软件质量的度量——《软件测试完全指南》
测试是为了度量和提高被测软件的质量,贯穿软件的整个生命周期——《系统的软件测试》
1.2 软件测试和软件项目的关系
软件测试的根本目的:提高软件质量,降低软件项目的风险
目的:将交付/发布的软件的错误控制在一个合理的范围内
软件测试只能证明软件存在错误,而不能证明软件没有错误
1.3 测试发展趋势
-
测试工作前移
-
与其他人员协调:架构师、开发、QA,矛盾统一
-
专业化:独立部门、第三方机构外包
第2章 软件测试基础
2.1 软件测试相关概念
软件测试
对软件的文档、数据、程序进行测试,发现其中的错误,对软件质量进行评估,贯穿软件的整个生命周期。
软件质量
ISO 9126定义:软件满足规定或潜在的用户需求的能力,从内部质量、外部质量和使用中的表现来衡量
-
QA:着眼软件开发的过程、步骤和产物,不直接对软件本身的问题进行测试
-
软件测试:不关心开发过程,只关心过程中的产物和软件本体,是保证软件质量的一环
验证与确认(V &V)
验证(Verification):验证软件是否满足需求说明书,实现需求说明书规定的所有特性
确认(Vaildation):验证软件是否有效,是否满足用户的预期用途和应用
软件缺陷(Bug)
软件失效的机理:软件错误→软件缺陷→软件故障→软件失效
-
软件错误
error
:强调是软件存在人为错误,导致软件缺陷的产生 -
软件缺陷
defect
:存在于软件(文档、数据、程序)的偏差,满足缺陷出现的一定条件时,缺陷被激活 -
软件故障
fault
:软件运行过程中出现的不希望或不可接受的内部状态 -
软件失效
failure
:软件运行时产生的不希望或不可接受的外部行为结果
软件缺陷的定义:
①软件未达到产品说明书中标明的功能
②软件出现了产品说明书中指明的不会出现的错误
③软件功能超出了产品说明书指明的范围
④软件未达到说明书虽未指出但应达到的目标
⑤测试人员认为软件难以理解、不易使用、运行速度慢,或用户认为不好使用的
Bug的生命周期
-
新信息(New)/发现:
-
打开(Open)
-
修正(Fixed):若验证不通过则Reopen
-
拒绝(Declined)
-
延期(Deferred)
-
关闭(Closed):Bug已被修复
2.2 软件测试的目的
目的
-
测试的目的是发现错误
-
好的测试用例在于能发现至今没发现的错误
-
成功的测试是发现了至今没发现的错误
2.3 软件测试的原则
-
溯源性原则:测试可追溯至客户需求
-
工程性原则:软件测试应尽早介入、不断进行
-
合理性原则:完全测试是不可能的,测试需要中止
-
不完全性原则:测试不能证明缺陷不存在,无法显示潜在缺陷
-
相关性原则:注意测试中缺陷的群集现象(二八原则)
-
独立性原则:程序员应避免检查自己的程序
-
可接受性原则:已发现的缺陷经过各方确认,可以不修复
-
风险性原则:构造测试用例时避免影响软件工作,开展风险评估
2.4 软件测试的对象
-
设计文档:需求规格说明、概要设计、详细设计
-
源程序:单元测试、集成测试、系统测试、确认测试
-
数据
2.5 软件测试的分类
2.5.1 按开发阶段
定义 | 目的 | |
---|---|---|
单元测试 | (模块测试)对软件设计的最小单位——程序进行的测试 | 验证详细设计中说明的功能 |
集成测试 | 在单元测试的基础上,对程序模块进行有序、递增的测试 | 验证单元或部件的接口关系 |
确认测试 | 确认软件是否满足预期用途的需求 | 检测软件是够满足软件说明书规定的要求 |
系统测试 | 确认系统是否达到原始目标,对集成的软硬件进行测试 | 检查软件能否和系统正确配置、连接,并满足用户需求 |
验收测试 | 按照项目任务或合同、约定等验收依据文档测试并评审系统是否达到验收标准 | 决定是否接收或拒收系统 |
2.5.2 按测试实施单位
-
开发方测试(α测试):开发方在测试环境执行的测试,可与系统测试一起进行
-
用户测试(β测试):应用环境下,用户的使用性测试(一般未达到验收测试级别,仅体验性使用)
-
第三方测试:由技术、管理和财务上与开发方和用户方相对独立的组织进行、模拟用户真实应用环境下的软件确认测试。
2.5.3 按照测试技术划分
黑白灰
-
白盒测试(结构性测试、静态测试)
-
黑盒测试:在程序界面进行检查,仅检查程序是否按照规格说明书中的规定正确进行
-
灰盒测试:及关注输出对于输入的合理性,又关注内部表现。
动静
-
静态测试:走查、符号执行、需求确认
-
动态测试:人工或使用工具执行测试
2.6 软件测试模型
2.6.1 V模型
单元测试、集成测试:验证程序执行是否满足设计要求
系统测试:功能、性能是否达到系统指标
验收测试、确认测试:追溯需求说明书,软件实现是否满足需求
局限性
将测试过程视作开发过程的后一阶段,容易忽略文档设计阶段隐藏的问题
2.6.2 W模型
基于“尽早地和不断地进行软件测试”原则,针对V模型的补充和完善,强调测试伴随整个软件开发周期,测试对象除程序还包括需求、功能、设计。
局限性
仍然依赖开发,具有串行的特点
2.6.3 H模型
体现测试独立的流程
2.6.4 敏捷测试模型
与敏捷开发对应,强调迭代,循序渐进
2.7 软件测试策略
输入
-
测试软硬件资源的详细说明
-
针对测试和进度的限制,人力资源
-
测试方法、测试标准和完成标准
-
系统的功能性和非功能性需求指标、技术指标
-
系统局限(系统不能实现的功能)
输出
-
已经批准的测试策略、测试计划、测试用例文档
-
确定测试的额需求
-
评估测试风险和测试优先级
-
确定测试策略
2.8 自动化测试
优点
-
提高软件质量:软件迭代中用于测试重复的内容,避免人为因素影响
-
提高测试效率
-
提高测试覆盖率
-
执行手工测试无法完成的测试:压力测试、负载测试、大数据量测试
-
便于重现缺陷
局限性
-
定制型项目
-
短周期项目
-
业务规则复杂的项目:投入自动化的人力较多
-
人体观感与易用性
-
不稳定的软件
-
涉及物理交互
第3章 软件评测标准
3.1 质量的定义
实体特性的总和,满足明确的和隐含要求的能力
3.2 软件质量模型
ISO 9126
-
可靠性(RELIABILITY)
成熟性、容错性、易恢复性
-
可移植性(PROTABILITY)
适应性、易安装性、一致性、易替换性
-
可维护性(MAINTAINABILITY)
易分析性、易更改性、稳定性、易测试性
-
易用性(USABILITY)
易理解性、易学习性、易操作性、用户差错防御性
-
功能性(FUNCTIONALITY):
适合性、准确性、功能依从性、安全性、(互操作性)
-
效率(EFFICIENCY)
时间特性、资源特性、容量
GB/T 25000,增加下面两个方面
-
兼容性
共存性、互操作性、兼容依从性
-
信息安全性
保密性、完整性、抗抵赖性、真实性、可核查性
3.3 使用质量的质量模型
(1)有效性:实现指定目标的准确性和完备性
(2)效率/生产率:实现有效性的资源消耗
(3)满意度:用户要求被满足的程度,用户的心理状态
(4)抗风险:包括经济风险、(人的)健康风险、安全风险
(5)周境覆盖:在特定环境下,有效性、效率、满意度、抗风险的实现能否达到使用要求
3.4 成本估算
UW:未调整的软件测试人工工作量
TW:软件测试工作量
SR:产品说明评审工作量,SR=TW×10%
DR:用户文档集评审工作量,SR=TW×20%
目前感觉不是很重要,略,后面遇到再补充吧
4.1 测试过程模型
4.2 组织级测试过程
组织级测试规格说明
特点:适用于整个组织的测试,不面向具体项目
-
组织级测试方针:执行级文档,描述测试目的、目标、总体范围
-
组织级测试策略:技术性通用文档,指导如何在组织内执行测试
4.3 测试管理过程
环节 | 输入 | 结果 | 输出 |
---|---|---|---|
测试策划过程 | 组织级测试策略、组织级测试方针;项目测试计划、项目管理计划 | 确定测试范围、测试风险、测试策略、测试环境、测试工具、人员配置等 | 测试计划 |
测试设计和实现过程 | 测试计划、测试策略、测试技术设计 | 导出测试条件、测试用例、测试集 | 测试用例、测试规格说明、测试数据需求、测试环境需求 |
测试环境构建和维护过程 | 测试计划、测试环境需求 | 测试环境就绪 | 测试环境准备报告、测试数据、测试环境 |
测试执行过程 | 测试计划、测试项、(测试环境准备报告) | 记录测试结果、比较实测和预期结果、确定测试结果 | 实测结果、测试结果、测试执行日志 |
测试事件报告过程 | 测试结果、测试用例、测试项、(测试执行日志) | 分析测试结果、创建或更新事件报告 | 事件报告 |
测试监测和控制过程 | 测试计划、产品文档、组织级测试策略和方针、控制指令、测度 | 监测测试计划进度、控制风险、批准停止测试决定 | 测试状态报告、测试计划变更、控制指令、产品和项目风险信息 |
测试完成过程 | 测试计划、事件报告、测试状态报告 | 验证测试要求、编写批准测试完成报告 | 测试完成报告 |
4.4 静态测试过程
代码走查:由编写代码的程序员来组织讨论 ,非正式
代码审查:由高级管理人员来领导评审 ,正式评审活动