软件测试与软件质量
软件测试经典定义（多看教程）
为了发现软件中存在的错误而进行的操作。目的：为了发现错误
软件测试目的
- 发现软件中的错误
软件测试只能证明软件中存在错误，不能证明软件没有错误。
软件测试的对象
- 软件代码
- 文档
- 数据
数据库的测试对象
- 数据库的连接
- 数据库的安全测试
- 数据库接口测试
- 定义的存储过程和触发器的测试
软件质量
软件特性的总和
也是满足规定或潜在用户需求的能力
也是软件特性具备“能力”的体现。
组成
- 内部质量
- 外部质量
- 使用质量——从用户角度出发
质量保证（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
自动化测试相关工具
使用质量模型
系统/软件产品模型
测试记录的内容
测试计划或者包含测试用例的测试规格说明- 测试中涉及的
人员身份 - 测试用例相关的所有
结果，包括在测试期间出现的所有失败
造成软件测试风险的主要原因
测试计划的不充分测试过程的偏差测试方法有误