业精于勤,荒于嬉,行成于思,毁于随。

软件测试演义——第二部分 执行篇

上一篇 / 下一篇  2007-08-21 17:31:08

作者:朱少民 出处:CSDN
 

执行篇

第23回 严格执行测试

虽然我们都认为,有效的测试计划是指导测试用例设计、测试执行的指导性文件,是成功测试的前提和必要条件,测试用例设计是测试工作的核心,测试用例的成功设计已经完成了一半的测试任务,但是测试的执行是基础,是测试计划和测试用例实现的基础,严格的测试执行使测试工作不会半途而废。而且,测试执行的管理相对复杂些,在整个测试执行阶段中,我们需要面对一系列问题,如:

  • 如何确保测试环境满足测试用例所描述的要求?
  • 如何保证每个测试人员清楚自己的测试任务和要达到的目标?
  • 如何保证每个测试用例得到百分之百的执行?
  • 如何保证所报告的软件缺陷正确、描述清楚、没有漏掉信息?
  • 如何在验证Bug或新功能与回归测试之间寻找平衡?
  • 如何跟踪Bug处理的进度使严重的Bug及时得到解决?

要实现上述目标,得到一个真实、符合要求的执行过程,需要很好地全程跟踪测试过程、过程度量和评审、借助有效的测试管理系统等来实现。主要的方法和措施有:

  1. 提高测试人员素质和责任心,树立良好的质量文化意识和专业素质,奖惩分明。
  2. 严格审查测试环境,包括硬件型号、网络拓扑结构、网络协议、防火墙或代理服务器的设置、服务器的设置、应用系统的版本,包括被测系统以前发布的各种版本和不定包、以及相关的或依赖性的产品。
  3. 将要执行的所有测试用例进行分类,构造成测试套件(Test Suite),然后在此基础上建立要执行的测试任务,这样任务的分解有助于进度和质量的有效控制,减少风险。
  4. 所有测试用例、测试套件、测试任务和测试执行结果,都通过测试管理系统进行管理,使之测试执行的操作、过程记录在案,具有良好的可跟踪性、控制性和追溯性,容易控制好测试进度和质量。
  5. 对每个阶段的测试结果进行分析,保证阶段性的测试任务得到完整的执行并达到预定的目标。
  6. 缺陷的跟踪和管理一般由数据库系统来执行,容易对缺陷进行跟踪、统计分析和趋势预测,并设定一些有效的规则和流程来配合测试执行
    如通过系统自动发出邮件给相应的开发人员和测试人员,使得任何缺陷都不会错过,并能得到及时处理。
  7. 良好的沟通,不仅和测试人员保持经常的沟通,还可以和项目组的其他人员(保持有效的沟通,如每周例会,可以及时发现测试中问题或不正常的现象。

第24回 测试进度和成本的控制

项目的进度管理是一门艺术,是一个动态的过程,需要不断调度、协调,保证项目的均衡发展,实现项目整体的动态平衡。项目开始前的计划,对任务的测试需求有一个大体的认识,但深度不够,进度表可能只是一个时间上的框架,其中一定程度上是靠计划制定者的经验来把握的。随着时间的推移、测试的不断深入,对任务会有进一步的认识,对很多问题都不再停留在比较粗的估算上,项目进度表会变得越来越详细、越准确。

项目的进度管理主要通过里程碑、关键路径的控制并借助工具来实现,同时要把握好进度与质量、成本的关系,以及充分了解进度的数量和质量的双重特性。

1.进度的数量和质量的双重特性

任何一项工作,最开始总是很容易看到进度,就比如盖房子,从无到有,变化是很明显的。可是越到后来,它的进度越来越不明显。软件测试也是如此,开始测试之初,Bug比较容易发现,但测试的进展并不是按Bug的数量来计算的,越到后面,Bug越来越难发现。要提高测试进度的质量,将严重的、关键的问题在第一时间发现出来,这样才不至于在最后阶段使得开发人员要对代码做大规模的变动,无法保证测试的时间,从而影响软件的质量。这就是测试项目进度的数量和质量的双重特性,我们在关注进度的同时要把握好这两个特性,在注重进度速度的同时,还要看进度前期的质量。

2.测试进度的管理方法

首先,尽量利用历史数据,从以前完成过的项目来进行类比分析,以确定质量和进度所存在的某种数量关系,来控制进度和管理质量。可以采用对进度管理计划添加质量参数的方法,也就是通过参数调整进度和质量的关系。

其次,可以采用测试项目进度的度量方法:测试进度S曲线法和缺陷跟踪曲线法。在进度压力之下,被压缩的时间通常是测试时间,这导致实际的进度随着时间的推移,与最初制定的计划相差越来越远。而如果有了正式的度量方法,这种情况就很难出现,因为在其出现之前就有可能采取了行动。

第25回 准确报告软件缺陷

软件缺陷的描述是是软件缺陷报告的基础部分,也是测试人员就一个软件问题与开发小组交流的最初且最好的机会。一个好的描述,需要使用简单的、准确的、专业的语言来抓住缺陷的本质。否则,它就会使信息含糊不清,可能会误导开发人员。准确报告软件缺陷是非常重要的,因为:

  • 清晰准确的软件缺陷描述可以减少软件缺陷从开发人员返回的数量
  • 提高软件缺陷修复的速度,使每一个小组能够有效的工作
  • 提高测试人员的信任度,可以得到开发人员对清晰的软件缺陷描述有效的响应
  • 加强开发人员,测试人员和管理人员的协同工作,让他们可以更好的工作

在多年实践的基础上,我们积累了较多的软件缺陷的有效描述规则,主要是:

  • 单一准确。每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常常会导致缺陷部分被注意和修复,不能得到彻底的修正。
  • 可以再现。提供缺陷的精确操作步骤,使开发人员容易看懂,可以自己再现这个缺陷,通常情况下,开发人员只有再现了缺陷,才能正确地修复缺陷。
  • 完整统一。提供完整、前后统一的软件缺陷的步骤和信息,例如:图片信息,Log文件等。
  • 短小简练。通过使用关键词,可以使软件缺陷的标题的描述短小简练,又能准确解释产生缺陷的现象。如“主页的导航栏在低分辨率下显示不整齐”中“主页”、“导航栏”、“分辨率”等是关键词。
  • 特定条件。许多软件功能在通常情况下没有问题,而是在某种特定条件下会存在缺陷,所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件(如特定的操作系统、浏览器或某种设置等),能够提供帮助开发人员找到原因的线索。如“搜索功能在没有找到结果返回时跳转页面不对”。
  • 补充完善。从发现bug那一刻起,测试人员的责任就是保证它被正确的报告,并且得到应有的重视,继续监视其修复的全过程。
  • 不做评价。在软件缺陷描述不要带有个人观点,对开发人员进行评价。软件缺陷报告是针对产品、针对问题本身,将事实或现象客观地描述出来就可以,不需要任何评价或议论。

软件缺陷属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。

1. 缺陷标识:是标记某个缺陷的唯一的表示,可以使用数字序号表示。

2. 缺陷类型:是根据缺陷的自然属性划分缺陷种类,如表1所示

表1软件缺陷类型列表

缺陷类型

描述

功能

影响了各种系统功能、逻辑的缺陷

用户界面

影响了用户界面、人机交互特性,包括屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷

文档

影响发布和维护,包括注释,用户手册,设计文档

软件包

由于软件配置库、变更管理或版本控制引起的错误

性能

不满足系统可测量的属性值,如执行时间,事务处理速率等。

系统/模块接口

与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。

3. 缺陷严重程度:是指因缺陷引起的故障对软件产品的影响程度,所谓“严重性”我指的是在测试条件下,一个错误在系统中的绝对影响。如表2所示

表2软件缺陷严重等级列表

缺陷严重等级

描述

致命(Fatal)

系统任何一个主要功能完全丧失、用户数据受到破坏、系统崩溃悬挂、死机,或者危及人身安全

严重(Critical)

系统的主要功能部分丧失、数据不能保存,系统的次要功能完全丧失系统所提供的功能或服务受到明显的影响

一般(Major)

系统的次要功能没有完全实现,但不影响用户的正常使用。例如:提示信息不太准确;或用户界面差、操作时间长等一些问题。

较小(Minor)

使操作者不方便或遇到麻烦,但它不影响功能的操作和执行,如个别的不影响产品理解的错别字、文字排列不对齐等一些小问题。

4. 缺陷产生的可能性:指缺陷在产品中发生的可能性,通常可以用频率来表示,如表3所示。

表3 缺陷产生可能性列表

缺陷产生可能性

描述

总是(Always)

总是产生这个软件缺陷,其产生的频率是100%

通常(Often)

按照测试用例,通常情况下会产生这个软件缺陷,其产生的频率大概是80-90%

有时(Occasionally)

按照测试用例,有的时候产生这个软件缺陷,其产生的频率大概是30-50%

很少(rarely)

按照测试用例,很少产生这个软件缺陷,其产生的频率大概是1-5%

5. 缺陷优先级:指缺陷必须被修复的紧急程度。“优先级”的衡量抓住了在严重性中没有考虑的重要程度因素,如表4所示。

表4 软件缺陷优先级列表

缺陷优先级

描述

立即解决(P1)

缺陷导致系统几乎不能使用或测试不能继续,需立即修复

高优先级(P2级)

缺陷严重,影响测试,需要优先考虑

正常排队(P3级)

缺陷需要正常排队等待修复

低优先级(P4级)

缺陷可以在开发人员有时间的时候被纠正。

一般来讲,缺陷严重等级和缺陷优先级相关性很强,但是,具有低优先级和高严重性的错误是可能的,反之亦然。例如,产品徽标是重要的,一旦它丢失了,这种缺陷是用户界面的产品缺陷,但是它阻碍产品的形象。那么它是优先级很高的软件缺陷。

6. 缺陷状态:指缺陷通过一个跟踪修复过程的进展情况,也就是在软件生命周期中的状态基本定义,如表5所示。

表5 软件缺陷状态列表

缺陷状态

描述

激活或打开

Active or Open

问题还没有解决,存在源代码中,确认“提交的缺陷”,等待处理,如新报的缺陷。

已修正或修复

(Fixed or Resolved)

已被开发人员检查、修复过的缺陷,通过单元测试,认为已解决但还没有被测试人员验证

关闭或非激活

(Close or Inactive)

测试人员验证后,确认缺陷不存在之后的状态。

重新打开

测试人员验证后,还依然存在的缺陷,等待开发人员进一步修复

推迟

这个软件缺陷可以在下一个版本中解决

保留

由于技术原因或第三者软件的缺陷,开发人员不能修复的缺陷

不能重现

开发不能复现这个软件缺陷,需要测试人员检查缺陷复现的步骤。

需要更多信息

开发能复现这个软件缺陷,但开发人员需要一些信息,例如:缺陷的日志文件,图片等。

7. 缺陷来源:指缺陷所在的地方,如文档、代码等,如表6所示。

表6 软件缺陷来源列表

缺陷来源

描述

需求说明书

需求说明书的错误、或不清楚引起的问题

设计文档

设计文档描述不准确、和需求说明书不一致的问题

系统集成接口

系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷

数据流()

由于数据字典、数据库中的错误引起的缺陷

程序代码

纯粹在编码中的问题所引起的缺陷

8. 缺陷根源:指造成上述错误的根本因素,以寻求软件开发流程的改进、管理水平的提高,如表7所示。

表7 软件缺陷根源列表

缺陷根源

描述

测试策略

错误的测试范围,误解了测试目标,超越测试能力等

过程,工具和方法

无效的需求收集过程,过时的风险管理过程,不适用的项目管理方法,没有估算规程,无效的变更控制过程等。

团队/

项目团队职责交叉,缺乏培训。没有经验的项目团队,缺乏士气和动机不纯等。

缺乏组织和通讯

缺乏用户参与,职责不明确,管理失败等。

硬件

硬件配置不对、缺乏,或处理器缺陷导致算术精度丢失,内存溢出等

软件

软件设置不对、缺乏,或操作系统错误导致无法释放资源,工具软件的错误,编译器的错误,2000千年虫问题等。

工作环境

组织机构调整,预算改变,工作环境恶劣,如噪音过大。

第26回 提高测试覆盖度

测试覆盖度评估是衡量阶段性软件测试执行状态的重要手段之一,来确定测试是否达到事先设定的测试任务完成的标准。测试覆盖率则是测试覆盖度评估中一种量化的表示方法,一般通过被测试的软件产品需求、功能点、测试用例数或程序代码行等来进行计算。

软件测试覆盖率常用的计算公式:

  1. 功能覆盖率= 至少被执行一次的测试功能点数/ 测试功能点总数 (功能点)
  2. 需求覆盖率= 被验证到的需求数量 /总的需求数量 (需求)
  3. 覆盖率= 至少被执行一次的测试用例数/ 应执行的测试用例总数 (测试用例)
  4. 语句覆盖率= 至少被执行一次的语句数量/ 有效的程序代码行数
  5. 判定覆盖率= 判定结果被评价的次数 / 判定结果总数
  6. 条件覆盖率= 条件操作数值至少被评价一次的数量 / 条件操作数值的总数
  7. 判定条件覆盖率= 条件操作数值或判定结果至少被评价一次的数量/(条件操作数值总数+判定结果总数)
  8. 上下文判定覆盖率= 上下文内已执行的判定分支数和/(上下文数*上下文内的判定分支总数)
  9. 基于状态的上下文入口覆盖率= 累加每个状态内执行到的方法数/(状态数*类内方法总数)
  10. 分支条件组合覆盖率= 被评测到的分支条件组合数/分支条件组合数
  11. 路径覆盖率= 至少被执行一次的路径数/程序总路径数

除此之外,覆盖率还包括类覆盖率、函数覆盖率、代码块覆盖率等,如EMMA中

测试评估可以说贯穿整个软件测试过程,可以在测试每个阶段结束前进行,也可以在测试过程中某一个时间进行,目的只有一个,提高测试覆盖度,保证测试的质量。通过不断的测试覆盖度评估或测试覆盖率计算,及时掌握测试的实际状况与测试覆盖度目标的差距,及时采取措施,就可以提高测试的覆盖度。

测试覆盖度的评估依赖于不同的测试阶段或不同的测试方法。如在单元测试中,测试覆盖率是建立在被测试的代码行、程序分支和程序路径等的度量之上,从软件质量保证的要求出发,单元测试的覆盖率要达到80%之上。白盒测试方法主要以程序语句、判定-条件、条件组合和(基本)路径等覆盖率来衡量,和单元测试是吻合的。而在系统功能测试中,则以功能点、测试用例、需求数等覆盖率来衡量。

要获得、提高测试覆盖率,常常需要借助测试工具。下面就以两个测试工具为例。

1. EMMA

EMMA 是一个用于检测和报告 JAVA 代码覆盖率的开源工具,支持许多种级别的覆盖率指标:包,类,方法,语句块(basic block)和行,特别是能测出某一行是否只是被部分覆盖,如条件语句短路的情况。EMMA能生成 text、xml、html 等形式的报告,以满足不同的需求,其 html 报告提供逐层细化查询功能,能够从 package 开始一步步链接到我们所关注的某个方法。EMMA 能和 Makefile 和 Ant 集成,效率很高,便于应用于大型项目。

EMMA 是通过向 .class 文件中插入字节码的方式来跟踪记录被运行代码信息的。EMMA 支持两种模式:On the fly 和 Offline 模式。On the fly 模式往加载的类中加入字节码,相当于用 EMMA 实现的 application class loader 替代原来的 application class loader。On the fly 模式比较方便,缺点也比较明显,如不能为被 boot class loader 加载的类生成覆盖率报告,也不能为像 J2EE 容器那种自己有独特 class loader 的类生成覆盖率报告。这时,必须求助于 Offline 模式,Offline 模式是在类被加载前,加入字节码。EMMA 也支持两种运行方式:Command line 和 Ant。

2. Rational PureCoverage

PureCoverage 是一个面向VC, VB 或者Java 开发的测试覆盖程度检测工具,可以自动检测测试完整性和未被测试的范围,在每一个测试阶段生产详尽的测试覆盖程度报告。PureCoverage 将在一个对话框中列出所有应用程序模块,开发人员只需针对每个应用程序构件,就可以简单地设置基于代码行或函数的代码覆盖级别。不仅可以查看每次程序运行的图形化覆盖数据,还可以直接地、实时地控制覆盖数据的记录。对于最关心或最重要的功能模块,可以详细地收集覆盖数据;而对于不太重要的模块, 只收集较常规的覆盖数据,帮助开发人员进行有效地测试。

系统的测试活动,依据测试目标,建立在至少一个测试覆盖策略基础上,而覆盖策略帮助进行测试覆盖度的有效评估。覆盖策略有

  • 基于需求的测试覆盖评估,依赖于对已执行/运行的测试用例的核实和分析,所以基于需求的测试覆盖评测就转化为评估测试用例覆盖率:测试的目标是确保100%的测试用例全部成功地执行。
  • 基于代码的测试覆盖评估,是对被测试的程序代码语句、路径或条件的覆盖率分析。如果应用基于代码的覆盖,则测试策略是根据测试已经执行的源代码的多少来表示的。这种测试覆盖策略类型对于安全至上的系统来说非常重要。

如果测试需求已经完全分类,则基于需求的覆盖策略可能足以生成测试完全程度评测的量化指标。例如,如果已经确定了所有性能测试需求,则可以引用测试结果来得到评测,如已经核实了90%的性能测试需求。除此之外,如果测试软件的数量较大,还要考虑数据量。

第27回 测试结果分析和质量报告

如同代码是程序员的成果之一,测试报告和质量报告是测试人员的主要成果之一。对于一个好的测试报告,是建立在正确的、足够的测试结果的基础之上,不仅要提供必要的测试结果的实际数据,同时要对结果进行分析,发现产品中问题的本质,对产品质量进行准确的评估。

1.缺陷分析

对缺陷进行分析,确定测试是否达到结束的标准,也就是判定测试是否已达到用户可接受的状态。在评估缺陷时应遵照缺陷分析策略中制定的分析标准,最常用的缺陷分析方法有:

  • 缺陷分布报告,允许将缺陷计数作为一个或多个缺陷参数的函数来显示,生成缺陷数量与缺陷属性的函数,如缺陷在程序模块的横向分布、严重性缺陷在不同的产生原因上的分布等。
  • 缺陷趋势报告,按各种状态将缺陷计数作为时间的函数显示,如缺陷数量在整个测试周期的时间分布。趋势报告可以是累计的,也可以是非累计的,可以看出缺陷增长和减少的趋势;
  • 缺陷年龄报告,是一种特殊类型的缺陷分布报告,显示缺陷处于活动状态的时间,展示一个缺陷处于某种状态的时间长短,从而了解处理这些缺陷的进度情况。
  • 测试结果进度报告,展示测试过程在被测应用的几个版本中的执行结果以及测试周期,显示对应用程序进行若干次迭代和测试生命周期后的测试过程执行结果

同时,也可以在项目结束后进行缺陷分析,以改进开发和测试进程,如:

  • 通过缺陷(每日或每周新发现的缺陷)趋势分析来了解测试的效率,也可根据丢失的Bug数目和发现总的Bug数,可以了解测试的质量。可以根据执行的总测试用例数,计算出每发现一个Bug所需要的测试用例数、测试时间等,对不同阶段、不同模块等进行对比分析。
  • 通过缺陷数量或在模块的分布情况,可以掌握程序代码的质量,如通过对每千行代码所含的Bug数分析,了解程序代码质量。通过缺陷(每日或每周修正/关闭的缺陷)趋势分析开发团队解决Bug的能力或状态

2.产品总体质量分析

对测试的结果进行整理、归纳和分析,一般借助于Excel文件、数据库和一些直方图、圆饼图、趋势图等来进行分析和表示,主要的方法有对比分析、根本原因(Root Cause)查找、问题分类、趋势(时间序列)分析等。

  • 对比分析,软件来执行测试结果与标准输出的对比工作,因为可能有部分的输出内容是不能直接对比的(比如,对运行的日期时间的记录,对运行的路径的记录,以及测试对象的版本数据等),就要用程序进行处理。
  • 根本原因(Root Cause)查找,“分析”是找出不吻合的地方并指出错误的可能起因。
  • 问题分类,“分类”包括各种统计上的分项,例如,对应的源程序的位置,错误的严重级别(提示、警告、非失效性错误、失效性错误等),新发现的还是已有记录的错误。
  • 趋势(时间序列)分析,根据所发现的软件缺陷历史数据进行分析,预测未来情况。
  • 其它统计分析,通过对缺陷进行分类,然后利用一些成熟的统计方法对已有数据进行分析,以了解软件开发中主要问题或产生问题的主要原因,从而比较容易提高软件质量。

第28回 测试过程和结果度量

测试阶段的过程度量内容或项目比较多,包括软件测试进度、测试覆盖度、测试缺陷出现/到达曲线、测试缺陷累积曲线、测试效率等。在进行测试过程度量时,要基于软件规模度量(如功能点、对象点等)、复杂性度量、项目度量等方法,从三个不同的测度来完整度量测试的过程状态:

  1. 测试广度的测量提供了多少需求(在所有需求的数目中)在某一时刻已经被测试,来度量测试计划的执行、测试进度等状态;
  2. 测试深度是对被测试覆盖的独立基本路径占在程序中的基本路径的总数的百分比的测度,基本路径数目的度量可以用McCabe环形计算复杂度方法来计算。
  3. 过程中收集的缺陷数度量,发现的、修正的和关闭的缺陷数量在过程中的差异、发展趋势等,为过程质量、开发资源额外投入、软件发布预测提供重要依据。

如前所述,测试过程的度量可以将过程状态度量和过程结果度量结合起来分析,是测试过程度量更有效。

在测试阶段,主要的过程质量度量有: