软件工程复习笔记 第七章 --测试

前言

       总结自老师的PPT，不只有知识点，还有一些相关内容的介绍顺便复制进来了，自己感兴趣就想多了解一些。 如有问题请多指教

测试概述

测试定义

• 为了发现软件系统的错误而执行的过程。
• “破坏”的过程
• 软件测试是质量控制的重要手段

测试本质

• 好的测试方案是尽可能发现迄今为止尚未发现的错误的方案
• 成功的测试是发现了至今为止未发现的错误的测试

软件测试要素

测试技术

测试类型（级别）

测试管理

测试方法

静态测试（分析）

• 定义：
  不实际运行程序，而是通过检查和阅读等手段来发现错误并评估代码质量的软件测试技术。
• 方法：走查、审查、评审

走查：WalkThrough

• 定义：
  开发组内部进行的，主要是个人通过检查和阅读等手段来查找错误的活动。
• 经验：
  • 检查要点
    • 逻辑错误
    • 代码标准/规范/风格
  • 限时
    • 避免跑题
    • 不要现场修改

审查：Inspection

• 定义：
  开发组内部进行的，分配了相关的角色，采用讲解、提问并使用Checklist方式进行查找错误的活动。
• 经验：
  • 以会议的形式，制定会议目标、流程和规则，结束后要编写报告
  • 参加人员
    • 经验丰富的开发人员
    • 和本模块相关的开发人员
    • 本项目组的新人
  • 由另外一名开发者进行讲解、其他开发者主要按照Checklist进行提问并填表、本模块开发者回答问题并记录
    • 不要现场修改
  • 检查要点
    • 设计需求
    • 代码标准/规范/风格

评审：Review

定义：
       开发组、测试组和相关人员(QA、产品经理等)联合进行的，采用讲解、提问并使用Checklist方式进行的查找错误的活动。一般有正式的计划、流程和结果报告。
经验：
       以会议的形式，制定会议目标、流程和规则，结束后要编写报告。相关资料要在会议前下发并阅读。
参加人员

• 经验丰富的开发人员
• 和本模块相关的开发人员
• 测试组和相关人员

由另外一名开发者进行讲解、其他开发者主要按照Checklist进行提问并填表、本模块开发者回答问题并记录

• 不要现场修改

检查要点

• 设计需求
• 代码标准/规范/风格
• 文档的完整性和一致性

同行（对等）评审（Peer Review）

对等技术评审是由与工作产品开发人员具有同等背景和能力的人员对工作产品进行的一种评审，
目的是早期和有效的消除软件工作产品中的缺陷，并可对软件工作产品和其中可预防的缺陷有更好的理解。

通用代码审查清单

数据引用错误

数据声明错误

计算错误

比较错误

控制流程错误

子程序参数错误

输入/输出错误

动态测试采用的测试技术

       基于代码的测试

白盒测试

白盒测试-基本逻辑覆盖技术

语句覆盖

选择足够的测试用例，使得程序中每一条可执行语句至少被执行一次。

语句覆盖率＝（至少被执行一次的语句数量）/（可以执行的语句总数）
例

判定覆盖

选择足够的测试用例，使得程序中每一个判断的每一种可能结果都至少被执行一次。判定覆盖也叫分支覆盖。

判定覆盖率＝（判定结果被评价的次数）/（判定结果的总数）

例

条件覆盖

选择足够的测试用例，使得程序中每一个判断中的每一个条件的可能结果都至少被执行一次

条件覆盖率＝（条件操作数值至少被评价一次的数量）/（条件操作数值的总数）

例

判定/条件覆盖

选择足够的测试用例，使得同时满足判定覆盖和条件覆盖。

判定条件覆盖率＝（条件操作数值或者判定结果至少被评价一次的数量）/（条件操作数值总数+判定结果的总数）
例

条件组合覆盖

选择足够的测试用例，使得程序中每一个分支判断中的每一个条件的每一种可能组合（分支条件组合）结果都至少被执行一次

条件组合覆盖率＝（被评价的分支条件组合数量）/（分支条件组合总数）

条件组合覆盖特点

条件组合覆盖是前述几种覆盖标准中最强的。满足条件组合覆盖标准的测试数据，也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。
但是，条件组合覆盖标准的测试数据并不一定能使程序中的每条路径都执行到。（测试数据都没有测试到1453 ）

各种逻辑覆盖关系之间的图形表示

路径覆盖

选择足够的测试用例，使得程序中所有的可能路径都至少被执行一次。

路径覆盖率=（至少被执行一次的路径数）/（总的路径数）

三角形程序实现的数据流图

DD-路径（Decision-to-Decision Paths）

判断（决策）到判断（决策）的路径
判断（决策）：一个序列语句

• 开始位置是一个判断（决策）的开始，结束位置是下一个判断（决策）语句的开始。
• 序列语句没有分支
• 

DD路径覆盖

DD路径覆盖率=（至少被执行一次的决策路径数）/（系统中总的决策路径数）

E.F.Miller发现：
DD-路径覆盖可以发现全部缺陷的85%

McCabe的基路径方法

线性独立路径数：V(G)=e-n+2

• e :边数
• n :节点数

基本逻辑覆盖测试方法

其它测试覆盖准则

ESTCA

• Error Sensitive Test Cases Analysis

规则1 :A rel B:Rel为<、＝、>
       A B分别出现一次 （检查rel错误）

规则2 :A rel C:Rel为< 、 >; A 是变量，C是常量
       Rel为<时,适当选择A,使A= C-M
       Rel为>时,适当选择A,使A= C+M
              M为距C最小的允许正数。（检查差1错误）

规则3 :对外部输入变量赋值,使其每一测试用例均有不同的值和符号，并与同一组测试用例中其它变量的值与符号不一致。

IF (I=0) 错写为IF (I>0)
IF (I > 1) 错写为IF (I > 0)
IF (I=X) 错写为IF(I＝0)

MC/DC

• Modified Conditional/Decision Coverage

需求1
       程序的入口点和出口点都必须至少执行一次，程序的判断结果至少被覆盖一次。
需求2
       程序的判断被分解为基本的布尔条件表达式，每个条件独立的作用于判断的结果，覆盖所有条件的可能结果。

例

黑盒测试

基于需求的测试

需求的覆盖率=（被验证的需求的数量）/（总的需求的数量）

边界值分析

测试原理

• 错误更可能是发生在输入的极值附近

例：一个程序输入变量为X1和X2，其取值范围分别为：a<=X1<=b ，c<=X2<=d

基本思想

边界值

• 最小值： Min
• 略高于最小值： ： Min +
• 正常值：Normal
• 略低于最大值： Max －
• 最大值： Max

健壮性测试

边界值

• 略低于最小值：Min－
• 最小值： Min
• 略高于最小值： ： Min +
• 正常值：Normal
• 略低于最大值： Max －
• 最大值： Max
• 略高于最大值： Max +

最坏情况

多缺陷假设

• 多个变量取极值的情况

两变量函数的最坏情况测试用例：

两变量函数的健壮最坏情况测试用例

等价类

       所谓等价类，是输入条件的一个子集合，该输入集合中的数据对于揭示程序中的错误是等价的。
       等价类又分为有效等价类和无效等价类。有效等价类代表对程序有效的输入，而无效等价类则是其他任何可能的输入（即不正确的输入值）。
       有效等价类和无效等价类都是使用等价类划分法设计用例时所必须的。因为被测程序若是正确的，就应该既能接受有效的输入，也能接受无效输入的考验。

例如：三角型测试
｛5,5,5｝与｛10,10,10｝是一个等价类

划分等价类的标准

• 完备测试、避免冗余；
• 划分等价类重要的是：集合的划分，划分为互不相交的一组子集，而子集的并是整个集合;
• 同一类中标识（选择）一个测试用例，同一等价类中，往往处理相同，相同处理映射到"相同的执行路径"。

划分等价类的方法

(1) 若输入条件规定了取值范围或值的个数的情况下，可划分为一个有效等价类和两个无效等价类；
Eg.设置风控指标，其中权重设置范围在[-1000,1000]

(2) 若输入条件为布尔表达式，可划分为一真一假的有效等价类与无效等价类；
Eg.设置产品信息，其中产品份额必填

(3) 若规定了输入数据必须要遵循的原则，可划分为一个有效等价类（符合规则）和若干个无效等价类；
Eg.系统的初始资金只可输入数字

(4)若只要求输入数据符合某几个原则，这时可能存在多个有效类和若干个无效等价类；
Eg. 交易用户登录密码只可输入数字、字母及部分特殊符号，不能输入单/双引号及汉字

(5)若规定了输入数据的一组值（假定n个），且程序对不同输入值做不同处理，则可划分为n个有效等价类（每个允许的输入值为一个有效等价类）和一个无效等价类（所有不允许的输入值的集合）。
Eg. 设置资金账户时，必须选择是否检查自成交

Eg.输入条件规定学历可为:本科、硕士、博士三种之一

(6)在确知已划分的等价类中各元素在程序中的处理方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。

测试用例设计步骤

(1) 划分等价类后，建立等价类表，并为每一个等价类规定一个唯一的编号；
(2) 设计一个测试用例，使其尽可能多地覆盖尚未被覆盖地有效等价类，重复这一步骤，直到所有的有效等价类都被覆盖为止；
(3)设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步骤，直到所有的无效等价类都被覆盖为止。（因为用单个测试用例覆盖无效等价类，是因为某些特定的输入错误会屏蔽或取代其他输入错误检查）
例：三角形等价类划分。

强、弱以及一般和健壮等价类

弱：代表单缺陷假设；
强：代表多缺陷假设；
一般：代表只包含有效等价类；
健壮：代表除包含有效等价类，还包含了无效等价类。
例如：函数F实现一个程序，它有两个输入变量X1和X2，

• X1的输入域是[a,d], 区间 [a,b),[b,c),[c,d]
• X2的输入域是[e,g],区间[e,f),(f,g]

则，变量X1和X2的无效等价类分别为：

• X1d和X2g

弱一般等价类

单缺陷假设

强一般等价类

多缺陷假设

弱健壮等价类

单缺陷假设
无效输入

强健壮等价类

多缺陷假设
无效输入

规范导出

根据相关规范描述来设计测试用例
例如一个计算平方根函数的规格如下：

• 输入一个大于等于0的实数，返回正的平方根
• 输入一个小于0的实数，显示错误信息“平方根非法－输入值小于0，并返回0”
• Print_Line库函数可以用来输出错误信息。

测试用例

• Testcase 1：输入4，输出2（对应陈述1）
• Testcase 2：输入－1，输出“平方根非法－输入值小于0”（对应陈述2和3）

错误猜测

在经验的基础上，测试设计者猜测错误的类型以及特定的软件中的错误的位置，并设计用例来发现他们。
例：
年龄：应该是大于0的数字

• 输入:aaa,看是否出现错误

点数:应该是〔0,12〕的数字

• 输入-20 ,看是否出现错误

基于故障的测试

证明某个规定的故障不存在于代码中。

例如： 对初始参数进行错误配置

因果图法

测试例子
第一个字符A或者B，第二字符是数字，则更新文件；如果第一个字符不正确，则产生X12信息；如果第二字符不正确，则产生X13信息

因（输入）
1：第一字符A
2：第一字符B
3：第二字符是数字
果（输出）
70 ：更新文件
71 ：产生信息X12
72 ：产生信息X13

.通过决策表也可以设计测试用例进行黑盒测试
此时，将条件理解为输入，将动作理解为输出
例：NextDate函数

场景法

       所谓场景就是事务流，主要用在于事件触发流程中，当某个事件触发后就形成相应的的场景流程，不同的事件触发，不同顺序和不同的处理结果，就形成一系列的事件流结果。
       通过分析设计模拟出设计者的设计思想，即整理出充分的场景，同时也较紧密地体现了被测系统的业务关系。
       事务流分为：基本流和备选流，

例子

例
ATM取款例子-基本流

用例开始： ATM 处于准备就绪状态。 准备提款 - 客户将银行卡插入 ATM 机的读卡机。.
验证银行卡 - ATM机从银行卡的磁条中读取帐户代码，并检查它是否属于可以接收的银行卡。
输入 PIN - ATM 要求客户输入 PIN 码（6 位）
验证帐户代码和 PIN - 验证帐户代码和 PIN 以确定该帐户是否有效以及所输入的 PIN
对该帐户来说是否正确。对于此事件流，帐户是有效的而且 PIN 对此帐户来说正确无误。
ATM 选项 - ATM显示在本机上可用的各种选项。在此事件流中，银行客户通常选择“提款”。
输入金额 - 要从 ATM中提取的金额。对于此事件流，客户需选择预设的金额（100元、200元、500元、1000元、2000元）。
授权 - ATM 通过将卡ID、PIN、金额以及帐户信息作为一笔交易发送给银行系统来启动验证过程。对于此事件流，银行系统处于联机状态，而且对授权请求给予答复，批准完成提款过程，并且据此更新帐户余额。
出钞 - 提供现金。
返回银行卡 - 银行卡被返还。
收据 - 打印收据并提供给客户。ATM 还相应地更新内部记录。
用例结束： ATM 又回到准备就绪状态。

ATM取款例子-备选流

备选流 1 - 银行卡无效
备选流 2 - ATM 内没有现金
备选流 3 - ATM 内现金不足
备选流 4 - PIN 有误
备选流5 - 帐户不存在
备选流 6 - 帐面金额不足
备选流 7 - 达到每日最大的提款金
备选流8- 记录错误
备选流 9 -退出客户可随时决定终止交易（退出）。
备选流 10 - “翘起”ATM包含大量的传感器，用以监控各种功能，如电源检测器、不同的门和出入口处的测压器以及动作检测器等。

ATM取款列子—场景

场景 1 - 成功的提款：基本流
场景 2 - ATM 内没有现金：基本流、备选流 2
场景 3 - ATM 内现金不足：基本流、备选流 3
场景 4 - PIN 有误（还有输入机会）：基本流备选流 4
场景 5 - PIN 有误（不再有输入机会）：基本流、备选流4
场景 6 - 帐户不存在/帐户类型有误：基本流、备选流 5
场景 7 - 帐户余额不足：基本流、备选流 6

ATM取款列子—测试用例

测试用例一经认可，就可以确定实际数据值。

电话接续UNI信令基本流程

如何设计电话呼叫处理流程的测试用例？

局内正常呼叫基本流

1. 主叫摘机到交换机送拨号音
2. 送号和数字分析
3. 来话分析并向被叫振铃
4. 被叫应答，双方通话
5. 话终挂机、复原

测试级别

测试过程按测试级别（有小到大）进行；
测试过程和开发过程是一个相反的过程

软件测试V模型

代码审查技术

静态分析

• 走查：WalkThrough
• 审查：Inspection
• 评审：Review

产品质量的过滤器

单元测试

定义：
对软件基本组成单元进行的测试，检验程序最小单位有无错误。

• 单元：软件开发中的最小的独立部分
  • C语言中的单元：函数或者是子过程
  • C++语言中的单元：类

单元测试的角度

单元测试的任务

任务1、模块接口测试

• 检查进出模块的数据是否正确
• Checklist：
  • 模块的实际输入/出与定义的输入/出是否一致
    • 个数、类型、顺序.
  • 模块中对于非内部/局部变量是否合理使用
  • 使用其他模块时，是否检查可用性和处理结果
  • 使用外部资源时，是否检查可用性并及时释放资源
    • 内存、文件、硬盘、端口等
  • 其他

任务2、模块局部数据结构测试

• 检查局部数据结构能否保持完整性
• Checklist：
  • 变量从来没有被使用
    • 可能别的地方使用了错误的变量名
  • 变量没有初始化
  • 错误的类型转换
  • 数组越界
  • 非法指针
  • 变量或函数名称拼写错误
    • 使用了外部变量或函数
  • 其他

任务3、模块边界条件测试

• 检查临界数据是否正确处理
• Checklist：
  • 普通合法数据是否正确处理
  • 普通非法数据是否正确处理
  • 边界内最接近边界的(合法)数据是否正确处理
  • 边界外最接近边界的(非法)数据是否正确处理
  • 其他

任务4、模块独立执行路径测试

• 检查由于计算错误、判定错误、控制流错误导致的程序错误
• Checklist：
  • 死代码
  • 错误的计算优先级
  • 精度错误
    • 比较运算错误
    • 赋值错误
  • 表达式的不正确符号 >、>=；=、==、!=
  • 循环变量的使用错误 错误赋值
  • 其他

任务5、模块内部错误处理测试

• 检查内部错误处理设施是否有效
• Checklist：
  • 是否检查错误出现
    • 资源使用前后
    • 其他模块使用前后
  • 出现错误，是否进行错误处理
    • 抛出错误
    • 通知用户
    • 进行记录
  • 错误处理是否有效
    • 在系统干预前处理
    • 报告和记录的错误真实详细
  • 其他

单元测试环境

单元测试技术

测试设计：

• 依据模块的内部结构，设计测试用例的过程。
• 主要采用白盒测试技术，关注逻辑覆盖

原则：

1. 保证没有死代码
   保证一个模块中的每个独立路径都可能被使用到
2. 保证对所有的逻辑值都测试true和false
3. 在上下边界和合法的范围内运行所有的循环
4. 确保内部数据结构的有效性和完整性

逻辑覆盖测试方法

集成测试

单元测试证明每个独立的模块没有问题，但所有模块组合在一起可能会出现问题。

定义

• 在单元测试的基础上，将所有的模块按照概要设计要求组装成子系统或者系统。
• 用来发现模块接口之间的错误

集成测试的层次

集成测试技术

灰盒测试方法（白+黑）
常用技术：

• 规范导出
• 等价类
• 状态转换
• 错误猜测法
• 故障测试
• 边界值
• 特殊值(特殊边界值)
• 状态转换测试

集成测试策略

大爆炸集成

自顶向下集成

自底向上集成

三明治集成

系统测试

前期测试可以保证软件功能正确，但不能确认在实际运行时，是否满足用户需求，是否会出现错误。

定义：系统测试是将集成好的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对系统进行一系列的组装测试和确认测试。

系统测试的目的

目的
       为了发现缺陷并度量产品质量，按照系统的功能和性能需求进行的测试

• 一般使用黑盒测试技术
• 一般由独立的测试人员完成
• 应用最广泛的测试

系统测试方法

1、功能测试
       目标：对产品的功能进行测试，检验是否实现、是否正确实现

方法：覆盖产品的功能

• 规范导出法
• 等价类划分
• 边界值分析
• 因果图
• 判断表
• 错误猜测法

2、协议一致性测试
       目标：监测实现的系统与标准协议的符合程度

方法：

• 规范导出法
• 等价类划分
• 边界值分析

3、性能测试
       目标：对产品的性能进行测试，检验是否达标、是否能够保持

方法：覆盖系统的性能需求，一般和负载测试结合使用

• 规范导出法
• 错误猜测法

4、压力测试
       目标：在人为设置的系统资源紧缺情况下，检查系统是否发生功能或者性能上的问题

方法：人为减少可用的系统资源，包括：内存、硬盘、网络、CPU占用、数据库反应时间…

• 规范导出法
• 等价类划分
• 边界值分析
• 错误猜测法

5、容量测试
       目标：在人为设置的高负载(大数据量、大访问量)的情况下，检查系统是否发生功能或者性能上的问题

方法：人为生成大数据量，并利用工具模拟频繁并发访问

• 等价类划分
• 边界值分析
• 错误猜测法

6、安全性测试
       目标：检查集成在系统内的保护机制是否能够在实际中保护系统不受非法的侵入。
方法：一般与功能测试结合使用

• 规范导出法
• 错误猜测法
• 基于故障的测试

7、恢复测试
       目标：验证系统从软件或者硬件失败中恢复的能力。

方法：在人为使发生系统灾难(系统崩溃、硬件损坏、病毒入侵等)的情况下，检查系统是否能够恢复被破坏的环境和数据。

• 规范导出法
• 错误猜测法
• 基于故障的测试

8、备份测试
       目标：验证系统从软件或者硬件失败中的事件中备份数据的能力。

方法：参考恢复测试方法

• 规范导出法
• 错误猜测法
• 基于故障的测试

9、GUI测试
       目标：界面实现与界面设计的吻合程度，确认界面处理的正确性。
方法：

• 规范导出法
• 等价类划分
• 边界值分析
• 因果图
• 判断表
• 错误猜测法

10、兼容性测试
       目标：测试应用对其他应用或者系统的兼容性

方法：

• 规范导出
• 错误猜测

11、可用性测试
       目标：检查系统界面和功能是否容易学习、使用方式是否规范一致，是否会误导用户或者使用模糊的信息
一般与功能测试结合使用

方法：可以采用用户操作、观察(录像)、反馈并评估的方式

• 规范导出法
• 错误猜测法

12、安装测试
       目标：验证成功安装系统的能力。

方法：在不同的硬件配置下，在不同的操作系统和应用软件环境中，检查系统是否发生功能或者性能上的问题。

• 规范导出
• 错误猜测

13、文档测试
目标：验证用户文档是正确的并且保证操作手册的过程能够正确工作。
方法：一般由单独的一组测试人员实施
规范导出

14、在线帮助测试
目标：检查系统的实时在线帮助的可用性和正确性
方法：规范导出法

15、数据转换测试
目标：验证已存在数据的转换并载入一个新的数据库是否有效
方法：规范导出法

验收测试

当系统测试完成之后，可以确信已经满足了需求规格说明书的要求，那用户是否满意呢？
以用户为中心进行测试，是用户自己完成测试并评估的过程。必要时，开发人员给予支持。
分为：

• 基准测试：用户设计一组典型的测试用例，测试执行情况并评估；
• 并行测试：新、旧系统同时运行，以验证新的系统可以取代旧的系统。

测试管理流程

测试计划

       定义测试需求，测试策略，测试资源和进度计划等。

测试计划-测试需求

详细说明被测软件的工作情况，指出测试范围和任务。

测试计划－ 测试策略

• 测试技术和工具
• 测试完成的标准
• 特殊的考虑，包括资源需求和进度表等

测试计划－ 资源

人力资源–测试经理

• 职责
  • 全面的管理 -测试计划
  • 采集资源
  • 项目报告 - 测试评估
• 要求
  • 有测试过程的知识
  • 熟悉测试工具
  • 有领导才能
  • 懂得项目的管理

人力资源–测试工程师 (设计者/开发者)

• 职责
  • 分解测试需求
  • 测试设计
  • 测试开发
• 要求
  • 有应用需求方面的知识
  • 熟悉测试工具
  • 编程的技巧(附加)

人力资源–测试工程师 (测试执行者)

• 职责
  • 执行测试
  • 产生日志结果
  • 检查修正的错误
• 要求
  • 了解要测试的系统网络服务器等
  • 熟悉测试工具
  • 有诊断的技巧

人力资源–测试系统管理员

• 职责
  • 管理测试的系统
  • 添加新用户
  • 处理用户的要求
• 要求
  • 系统管理的经验和方法
  • 熟悉测试管理工具

测试计划－ 资源

系统资源

• 测试开发系统
• 测试管理系统
• 测试存储库
• 网络

系统测试计划模板

测试设计

定义测试的具体方案，设计测试用例、构造测试过程

测试设计－找出并描述测试用例

• 分析应用工作流
  • 确定描述测试活动
  • 找到测试用例
• 确定描述测试用例
  • 被测对象说明
  • 期望结果，如输出状态、条件或数据值
• 确定测试用例数据
  • 作为输入数据的值
  • 测试期待结果值
  • 支持用例的数据，不作为输入、输出

测试设计－确定并构造测试过程

构造测试过程

• 建立测试需要的数据
• 测试过程的起始条件、状态、行为
• 测试步骤
• 输入的数据值
• 期待的结果
• 结果评估
• 定义测试过程的结束条件、状态、行为

测试设计－评估测试覆盖

覆盖的度量标准

• 基于需求的覆盖
• 基于代码的覆盖
• 判定标准均采用完成测试项的百分比

测试开发

对在测试设计阶段已被定义的测试案例进行创建或修正的阶段（例如：脚本编写以及注意事项）。

测试开发–编写测试脚本

创建测试脚本

• 参考已有的有价值的脚本
• 建立测试环境
• 建立脚本
• 修改脚本(如果必要)

测试开发–录制和编写测试脚本

创建测试脚本应注意：

• 尽量使测试脚本可重用
• 尽可能减少测试脚本的维护量
• 如果可能，尽量使用已有的测试脚本
• 使用测试工具创建测试脚本，减少手工作业

测试开发–确定测试特需的功能

• 考虑驱动模块
• 考虑桩模块

测试开发－建立外部数据集

创建外部数据集

• 查阅测试用例、测试过程
• 使用适当的工具和方法创建数据集
• 利用数据集对测试脚本调整

调试测试脚本

使用外部数据集的好处：

• 测试脚本中不含数据，易于维护
• 使数据易于修改，不受脚本影响
• 方便增添测试用例，较少或避免修改测试脚本
• 外部数据能够被多个测试脚本共享
• 外部数据集中可包含用于控制测试脚本的数据值

测试执行

对被测软件进行一系列的测试并记录日志结果的阶段（环境准备、意外处理、结果分析）。

测试执行–执行测试过程

建立测试环境

针对不同的测试目的构造不同的测试环境；
测试环境的构造应最大程度上有利于自动化；
测试环境应能够很好的接受测试的输入；
测试环境应能够把测试执行的结果反馈给测试人员；

初始测试环境

执行测试过程

• 自动测试
• 手工测试

配置输入条件；
按用例执行步骤执行用例；
仔细观察每个可能的输出结果，与期望结果比较，记录差异点；
发现可能的缺陷；（由于用例不可能遍历每个可能的输出，因此不同的人在执行同一个测试用例的时候，可能会得到不同的结果，这是一个经验的积累）
避免用例之间的干扰，排除人为产生的错误；
隔离缺陷，协助开发人员定位问题；
如实的记录每个缺陷，缺陷信息应当详尽，避免歧义，并利于问题的重现；

测试执行–评估测试执行

正常：所有的测试过程或测试标准按计划结束
不正常：测试失败或未达到预期的测试覆盖

测试执行-- 从失败测试中恢复

如何从失败中恢复：

• 确定错误发生的真正原因
• 纠正错误
• 重新建立测试环境
• 重新初始化测试环境
• 重新执行测试

测试执行–记录缺陷

记录缺陷
追踪缺陷

测试跟踪

记录测试事件或用户问题，进行调查研究，提出解决它们的方案并进行修改的阶段。

执行日志

在测试执行过程中，每天都应当记录测试执行日志，一般测试执行日志应当包含下列内容：

• 执行了哪些用例，谁执行的，是否通过，发现了哪些缺陷，总体的测试进展情况，可能的风险，遇到的问题等。

工具：例如Buggit

测试评估

分析测试结果并判断测试的标准是否被满足的阶段。

测试评估–测试用例覆盖

覆盖判定：

• 对于测试目标有多少测试用例，已执行的测试用例数
• 成功执行的测试用例数

确保100%的测试用例全部成功地执行

制定测试覆盖标准，考虑：

• 风险和严重性
• 可接受的覆盖百分比

测试评估-分析缺陷

常用的缺陷分析标准：

缺陷分布（按优先级）

缺陷趋势（随时间）

缺陷滞留

测试评估- -确定测试是否达到标准

确定标准：

• 参阅测试计划有关测试覆盖和缺陷评估等策略
• 检查测试结果、缺陷和缺陷分析

软件测试过程的文档

• 测试计划文档
• 测试设计文档
• 单元测试内容
• 集成测试内容
• 系统测试内容
• 软件测试报告

测试总结

测试生命周期

测试文档