软件测试基础、流程与规范 适合0基础学习

1.前言

2. 软件测试理论-基本概念

测试目的

⚫ 检查产品需求是否全部实现
⚫检查产品完整性（包括相关的组件）
⚫确保软件产品在发布前软件缺陷均定位并解决
⚫ 一个成功的测试是发现了至今尚未发现的错误

测试目标

⚫ 发现缺陷；
⚫ 增加对质量的信心；
⚫ 为决策提供信息；
⚫ 预防缺陷

软件测试的类型

⚫ 按开发阶段划分
⚫ 按测试实施的组织划分
⚫ 按测试技术划分

测试与调试的区别

⚫ 测试：找错
⚫ 调试：排错（定位、修改）

3. 软件测试模型

⚫ 瀑布模型

⚫ V模型

V模型
⚫特点：V模型是瀑布模型的延伸，其开发各阶段结构清晰，软件开发与测试分离
⚫作用：早期的软件开发模型，能够明确软件开发的各个阶段，适用于小型软件项目的开发。
⚫ 局限：测试在编码后，软件缺陷发现的较晚，修复成本较高。

⚫ H模型

H模型
⚫ 特点：较早发现软件中的缺陷，能够适应软件项目的动态变更。
⚫ 作用：将软件测试过程贯穿于整个项目周期，各阶段测试按层次进行，并且测试过程可循环实施。
⚫ 局限：前期投入较大，各阶段交互时间较长，变更频繁也对软件产品质量构成威胁

⚫ X模型

X模型
⚫ 特点：该模型左半部分是针对程序片段进行相互分离后进行频繁的交接，最后合成可执行程序；右半部分即对生成的可执行程序进行测试，
同时有针对性进行各种测试。
⚫作用：能够节约时间，较早发现软件产品的缺陷
⚫ 局限：前期的拆分过多，对测试人员要求较高，实施较难。

⚫ 迭代开发测试

4.软件测试计划

测试计划的目的

⚫使软件测试工作进行更顺利
⚫促进项目参加人员彼此的沟通
⚫ 使软件测试工作更易于管理
⚫任何测试计划都是保证软件质量，提高工作效率。

测试计划的原则

⚫制定测试计划应尽早开始
⚫保持测试计划的灵活性
⚫ 保持测试计划简洁和易读
⚫ 尽量争取多渠道评审测试计划
⚫ 计算测试计划的投入

《测试计划》文档内容

⚫ 目标
⚫ 概述、术语
⚫ 组织形式
⚫ 角色及职责
⚫ 测试对象
⚫ 测试通过/失败的标准
⚫ 测试挂起的标准及恢复的必要条件
⚫ 测试任务安排
⚫ 应交付的测试工作产品
⚫ 工作量估计

测试计划的变更

5.软件测试环境

软件测试环境组成

配置测试环境主要遵循以下原则

⚫被测试软件运行的是低配置要求，即测试环境首先要保证支撑软件正常运行；
⚫ 测试环境应量简单、独立，避免不相关的软件影响测试的实施；
⚫ 软件版本保持最新，同时避免安装多个版本；
⚫保证测试平台没有病毒；
⚫ 保证环境前后一致；
⚫ 兼容性检查等

通用测试环境的要求

⚫ 尽可能真实的环境
⚫ 符合软件运行的最低要求
⚫选用比较普及的操作系统和软件平台
⚫营造纯净、独立的测试环境
⚫无毒的环境

测试环境与测试阶段的关系

测试环境的备份

⚫测试过程中会遇到多种不可预测的事情发生，一但造成系统崩溃，则会造成测试数据丢失、测试过程中断或者测试环境的重新搭建
⚫经常对测试环境进行多次必要的备份是一个必备的预防措施和一个比较好的习惯
⚫对测试环境的备份可以挽回不必要的损失、节省测试的时间、保持测试的连续性

6.软件测试方法

什么是白盒测试（white-box testing）

⚫白盒测试是依据被测试软件，分析程序内部构造，并根据内部构造设计用例后进行测试。

白盒测试方法

白盒测试一般会用到静态分析和动态分析
两类技术，常用的有：
⚫ 静态分析：控制流分析，数据流分析，信息流分析等
⚫ 动态分析：逻辑覆盖测试（分支测试，路径测试等），程序插装

白盒测试测试用例设计方法

⚫ 语句覆盖
⚫判定覆盖
⚫条件覆盖
⚫ 判定/条件覆盖
⚫组合覆盖
⚫路径覆盖

白盒测试的优缺点

⚫⚫优点：
⚫针对程序内部进行覆盖测试，覆盖率较高
⚫能较早期的发现程序中的缺陷
⚫⚫ 缺点：
⚫设计过于复杂
⚫无法验证程序的外部特性
⚫需求变更时，付出的代价较大

什么是灰盒测试（Gray-box testing）

⚫ 灰盒测试是介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但这种关注不像白盒测试
那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。
⚫ 最常见的灰盒测试是集成测试，它关心集成模块之间的接口数据。

灰盒测试用例设计方法

灰盒测试的优缺点

⚫⚫优点：
⚫借助测试工具实现手工无法实施的测试
⚫能够重复利用设计的测试用例
⚫ 可靠性高
⚫ ⚫缺点：
⚫ 软件项目前期投入大，成本较高
⚫不利于变更
⚫无法替代手工测试

什么是黑盒测试（black-box testing）

⚫ 黑盒测试主要关注被测试软件的功能和非功能属性的实现，测试人员对被测试产品的验证主要是根据其需要规格，验证其与规格的一致性

黑盒测试用例设计方法

等价类划分法

⚫ 有效等价类：有效等价类是程序规格说明有意义，合理的输入数据，
⚫ 无效等价类：无效等价类是程序规格说明无意义，不合理的输入数据。

边界值分析法

⚫边界值分析的理论基础，是假定大多数的错误是发生在各种输入条件的边界上，如果在边界附件的取值不会导致程序出错，那么其它的取值导致程序错误的可能性也很小。

因果图法

⚫因果图法是一种适合于描述对于多种条件的组合、相应产生多个动作的形式的测试用例设计方法

错误推测法

⚫根据经验猜想可能有什么问题并依据此设计测试用例

场景分析法

正交实验设计方法

黑盒测试的优缺点

⚫⚫优点：
⚫不需了解程序内部的代码
⚫ 从用户角度出发，能尽早发现常见的错误
⚫ 易于实施
⚫⚫ 缺点：
⚫ 覆盖率较低
⚫重复工作量较大
⚫依赖设计的测试用例，对测试结果影响较大
⚫对于《软件规格说明书》等文档缺陷无法发现

7.软件测试阶段

测试级别

ISTQB定义

⚫⚫测试级别 test level ：
⚫统一组织和管理的一组测试活动。测试级别与项目的职责相关联。例如，测试级别包括组件测试/单元测试、集成测试、系统测试和验收测试

单元测试

⚫测试的最早期阶段，焦点在于最小的被测软件单元

集成测试

⚫ 在运行（可能是不完整）的应用中保证软件单元被结合后能正常操作的测试执行的阶段

系统测试

⚫ISO9126：系统测试是进行全面的系统工程级测试，其内容包括产品功能、性能指标、兼容性(包含互连性)、可靠性(包含满负荷)、容错能力、可维护性等方面。
⚫ ISTQB：测试集成系统，以验证它是否满足指定需求的过程。
⚫ 系统测试，英文是System Testing。是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试确认测试，系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，而提出更加完善的方案。系统测试发现问题之后要经过调试找出错误原因和位置，然后进行改正。是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。对象不仅仅包括需测试的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。

系统测试目的

⚫验证系统功能是否符合需求规格定义
⚫验证系统的可靠性、安全性、可维护性、适用性、稳定性、容错性等.

系统测试常见类型

⚫功能测试 ⚫性能测试 ⚫压力测试⚫容量测试 ⚫安全性测试
⚫可用性测试 ⚫GUI测试 ⚫异常测试(破坏性测试) ⚫安装测试 ⚫配置测试
⚫ 备份测试 ⚫健壮性测试⚫文档测试⚫在线帮助测试⚫网络测试 ⚫稳定性测试

安装测试

⚫⚫定义：
可安装性测试，主要是根据软件的测试特性列表、软件安装、配置文件、设计安装过程的测试用例，发现软件在安装过程中的错误。
⚫⚫目标：
⚫系统可安装性测试的目的不仅是找安装软件本身的错误。在安装软件系统时，会有多种选择，要分配和装入文件和程序，布置适当的配置，进行程序和联结。而安装测试就是要找出这些安装过程中出现的错误。

配置测试

定义：
配置测试主要测试系统在各种软硬件配置，不同的参数配置下系统具有的功能和性能。
目标：
验证全部配置的可操作性和有效性，特别需要
对最大配置，最小配置或特殊配置进行测试。

文档测试

⚫指验证用户文档是正确的并且保证操作手册的过程能够正确工作。

在线帮助测试

⚫主要用于验证的实时在线帮助的可用性和正确性

网络测试

⚫⚫ 定义
⚫网络测试是在网络环境下和其他设备对接，进行系统功能，性能与指标方面的测试，保证设备对接正常。
⚫⚫目标
⚫网络测试考察系统的处理能力，系统兼容性，系统稳定可靠性及用户使用等方面。

稳定性测试

⚫⚫ 定义：
系统稳定性测试目的是评价系统在一定负荷情况下，长时间的运行情况。
⚫⚫目标:
包括系统在一定负荷下，再增加新的业务，原有的业务是否影响，新的业务是否能正常工作，系统资源有无泄露，数据有无不一致的情况，系统测试是否会降下来，关键点是长时间的运行后，系统的状况如何，系统平均无故障时间是否满足系统设计要求。

安全性测试（Security Testing）

⚫用来验证集成在系统内的保护机制是否能够在实际中保护系统不受到非法的侵入。用来保证系统本身数据的完整性和保密性。如当受到恶
意攻击时，设备的自我保护能力，病毒防护能力，自定义通信协议安全性等。广义的还包括物理安全性测试，业务安全性测试

异常测试（又称破坏性测试）

⚫容错性
⚫可恢复性
⚫ 网络故障
⚫断电
⚫传输异常中断
⚫病毒影响等

备份测试

⚫备份测试（Backup Testing）是恢复性测试的一个补充，目的是验证系统在软件或者硬件失败的事件中备份它数据的能力。

健壮性测试

⚫健壮性测试（Robustness Testing）用于测试系统在出现故障时，是否能够自动恢复或者忽略故障继续运行。

验收测试

⚫产品经过严格测试后最终提交验收
⚫⚫ 特点：
⚫用户参与验收
⚫ 测试环境尽可能模拟用户实际运行环境
⚫ 按《软件需格说明书》和《验收测试计划》实施

验收测试的整个过程

⚫ 根据软件需求和验收要求编制计划，制定需测试的测试项，制定测试策略及验收通过准则，并经过客户参与的计划评审
⚫ 根据验收测试计划、项目或产品验收准则完成测试用例的设计，并经过评审
⚫ 准备测试数据、执行测试用例，记录测试结果
⚫ 根据验收通过准则分析测试结果，做出验收是否通过及测试评价

回归测试

⚫回归测试指软件缺陷修复后再次测试

回归测试策略

⚫ 完全重复测试
⚫ 选择性重复测试
⚫仅回归修复的缺陷

8.测试用例设计

一个优秀的测试用例应该满足的条件

⚫找出软件错误的可能性较大
⚫ 不是冗余的，即不过于复杂，又不过于简单– 格式统一，描述清晰、简洁
⚫无二义性

测试用例模板

9.软件缺陷管理

缺陷的定义

⚫软件未达到产品说明书的功能要求
⚫软件出现了产品说明书指明不会出现的错误
⚫软件功能超出产品说明收范围
⚫软件未达到产品说明书虽未指出但应达到的目标
⚫软件被认为难以理解、不易操作、运行速度慢或最终用户认为不好。

缺陷的生命周期

缺陷的优先级

⚫⚫软件缺陷有四种级别，分别为：致命的(Fatal)，严重的(Critical)，一般的(Major)，微小的(Minor)。
⚫A类—致命的软件缺陷(Fatal):造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误等
⚫B类—严重错误的软件缺陷（critical）：系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件
⚫C类—一般错误的软件缺陷（major）：次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等
⚫D类—较小错误的软件缺陷（Minor）:使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如错别字、界面不规范（字体大小不统一，文字排列不整齐，可输入区域和只读区域没有明显的区分标志），辅助说明描述不清楚
⚫E类- 建议问题的软件缺陷（Enhancemental）：由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。

缺陷的状态

⚫New：报告一个Bug。
⚫Open：验证后分配给相关的开发人员进行修改状态。
⚫Fixed：开发人员修改后的状态。
⚫Verified：等待测试人员验证的状态。
⚫ Reject：拒绝修改Bug。
⚫Reopen：如果没修改成功，则重新打开。
⚫ Closed：如果修改成功，则关闭Bug。

缺陷报告模板

测试完成-测试何时结束？

⚫⚫一、基于测试用例的规则
⚫（1）先构造测试用例（并请有关人员进行评审）。
⚫（2）在测试过程中，当测试用例的不通过率达到20％时，则拒绝继续测试，待开发人员修正软件后再进行测试。
⚫（3）当功能性测试用例通过率达到100％，非功能性测试用例通过率达到90％时，允许正常结束测试。
⚫ 该规则的优点是适用于所有的测试阶段，缺点是太依赖于测试用例。如果测试用例非常糟糕，那么该规则就失效了。
⚫⚫二、基于“测试期缺陷密度”的规则
⚫把测试一个CPU小时发现的缺陷数称为“测试期缺陷密度”。
⚫绘制“测试时间－缺陷数”的关系图，如果在相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m时，则允许正常结束测试。例如n大于10，m小于等于1。
⚫该规则比较适用于系统测试阶段。
⚫⚫三、基于“运行期缺陷密度”的规则
⚫ 把软件运行一个CPU小时发现的缺陷数称为“运行期缺陷密度”。
⚫绘制“运行时间－缺陷数”的关系图，如果在相邻n个CPU小时内“运行期缺陷密度”全部低于某个值m时，则允许正常结束测试。例如n大100，m小于等于1。
⚫该规则比较适用于验收测试阶段，即客户试运行软件期间。

10.软件文档管理

⚫《测试计划》
⚫ 《测试方案》
⚫《单元测试计划》
⚫《集成测试计划》
⚫ 《系统测试计划》
⚫《验收测试计划》
⚫《性能测试计划》
⚫《测试用例》
⚫《测试规程》
⚫《测试报告》
⚫《缺陷报告》
⚫《用户手册》
⚫《在线帮助》