软件测试中排错的基本方法

软件测试中,排错(即调试)与成功的测试形影相随。测试成功的标志是发现了错误。根据错误迹象确定错误的原因和准确位置,并加以改正的主要依靠排错技术。

1、排错过程

如下图所示,排错过程开始于一个测试用例的执行,若测试结果与期望结果有出入,即出现了错误征兆,排错过程首先要找出错误原因,然后对错误进行修正。因此排错过程有两种可能,一是找到了错误原因并纠正了错误,另一种可能是错误原因不明,排错人员只得做某种推测,然后再设计测试用例证实这种推测,若一次推测失败,再做第二次推测,直到发现并纠正了错误。

排错是一个相当艰苦的过程,究其原因除了开发人员心理方面的障碍外,还因为隐藏在程序中的错误具有下列特殊的性质:

(1)错误的外部征兆远离引起错误的内部原因,对于高度耦合的程序结构此类现象更为严重;

(2)纠正一个错误造成了另一错误现象(暂时)的消失;

(3)某些错误征兆只是假象;

(4)因操作人员一时疏忽造成的某些错误征兆不易追踪;

(5)错误是由于风时而不是程序引起的;

(6)输入条件难以精确地再构造(例如,某些实时应用的输入次序不确定);

(7)错误征兆时有时无,此现象对嵌入式系统尤其普遍;

(8)错误是由于把任务分布在若干台不同处理机上运行而造成的。[nextpage]

在软件排错过程中,可能遇到大大小小、形形色色的问题,随着问题的增多,排错人员的压力也随之增大,过分地紧张致使开发人员在排除一个问题的同时又引入更多的新问题。

尽管排错不是一门好学的技术(有时人们更愿意称之为艺术),但还是有若干行之有效的方法和策略,下面介绍几种排错方法。

2、排错方法

无论采用哪种排错方法,目标只有一个,即发现并排除引起错误的原因,这要求排错人员能把直观想象与系统评估很好的结合起来。

常用的排错策略分为三类:

① 原始类(brute force)

② 回溯类(backtracking)

③ 排除类(cause eliminations)

原始类排错方法是最常用也是最低效的方法,只有在万般无奈的情况下才使用它,主要思想是“通过计算机找错”。例如输出存储器、寄存器的内容,在程序安排若干输出语句等,凭借大量的现场信息,从中找到出错的线索,虽然最终也能成功,但难免要耗费大量的时间和精力。

回溯法能成功地用于程序的排错。方法是从出现错误征兆处开始,人工地沿控制流程往回追踪,直至发现出错的根源,不幸的是程序变大后,可能的回溯路线显著增加,以致人工进行完全回溯到望而不可及。

排除法基于归纳和演绎原理,采用“分治”的概念,首先惧与错误出现有关有所有数据,假想一个错误原因,用这些数据证明或反驳它;或者一次列出所有可能的原因,通过测试一一排除。只要某次测试结果说明某种假设已呈现倪端,则立即精化数据,乘胜追击。

上述每一类方法均可辅以排错工具。目前,调试编译器、动态调试器(“追踪器”)、测试用例自动生成器、存储器映象及交叉访问示图等到一系列工具已广为使用。然而,无论什么工具也替代不了一个开发人员在对完整的设计文档和清晰的源代码进行认真审阅和推敲之后所起的作用。此外,不应荒废排错过程中最有价值的一个资源,那就是开发小组中其他成员的评价和忠告,正所谓“当事者迷,旁观者清”。

前面多次提到,修改一处老问题可能引入几处新问题,有时程序越改越乱,但若能做到每次纠错前都扪心自问三个问题,情况将大为改观:

① 导致这个错误的原因在程序其他部分还可能存在吗?

② 本次修改可能对程序中相关的逻辑和数据造成什么影响?引起什么问题?

③ 上次遇到的类似问题是如何排除的?

软件测试中排错的基本方法

时间: 2024-11-11 00:10:50

软件测试中排错的基本方法的相关文章

软件测试中遇到的常见问题及沟通方法

1.这个bug我这边重现不了 解决办法 Bug应该简明扼要,重点突出.如果描述存在歧义,一定要总结并尽快改进.有时会遇到概率性的bug,要告诉开发概率是多少,尽可能多的提供重现的条件. 在复现问题时,希望能大致判断几个问题点,然后和测试人员沟通下,需要如何捕获信息,捕获那类信息?是不是提供debug版本进行复现,或者根据预判的点增加打印信息版本进行复现? 2.这个不是代码问题,需求这么定义的 解决办法 需求也是人定的,如果觉得有异议,可以找需求人员询问清楚,为什么这样定义,把自己的想法告诉他们,

软件测试中的那些不可遗忘的基础知识

软件测试是一项批判性的工作,目的就是找出软件中的缺陷.这里暂时不去深究为什么要进行软件测试,以及软件测试带来的好处.只介绍软件测试中一些基本的测试方法.根据是否查看代码程序分为黑盒测试和白盒测试:根据是否运行软件又可分为静态测试和动态测试. 黑盒测试:又叫功能测试或行为测试,只需考虑各个功能,不需要考虑整个软件的内部结构及代码. 白盒测试:访问代码,通过检查代码的线索来协助测试. 静态测试:测试软件不运行的部分,只是检查和审核. 动态测试:使用和运行软件进行测试. 1.静态黑盒测试:检查产品说明

软件测试的几种基本方法

上次我们介绍了软件测试的基本概念及基本原则,今天我们就来看看软件测试的几种基本方法吧. 首先,当然就是我们大家熟悉的黑盒测试和白盒测试,这是按是否查看程序内部结构分的.其次,还可以按是否运行程序分为静态测试和动态测试,按阶段可分为单元测试.集成测试.系统测试.验收测试.回归测试.除此之外还有冒烟测试.随机测试等.接下来就详细介绍一下以上几种测试. 一.按是否查看程序内部结构分为: 1.黑盒测试(Black Box Testing): 黑盒测试是根据软件的规格对软件进行的测试,这类测试不考虑软件内

软件测试中的八大浪费现象

在测试书籍中有一句这样的话:软件测试目的是用最少的人力.物力.财力发现最多的软件缺陷,提高软件的质量.为达到此目的,除想方设法提高测试的效率,同样对测试过程中出现的各种浪费现象的关注也是不可缺少的,在测试过程中最容易出现以下八大浪费现象. 1.过多的执行 我们都在担心测试不够全面,测试覆盖不全.因为我们知道过少的测试是犯罪,但同样过多的测试是浪费.设计测试用例本意是为了规避测试的随意性,让我们测试时既不多测也没有少测. 很多测试同行都提到在总结测试的时候认为在测试过程中有些功能可以不需要测试得那

Android中Handler的使用方法及实例(基础回顾)

Handler使用例1 这个例子是最简单的介绍handler使用的,是将handler绑定到它所建立的线程中.本次实验完成的功能是:单击Start按钮,程序会开始启动线程,并且线程程序完成后延时1s会继续启动该线程,每次线程的run函数中完成对界面输出nUpdateThread...文字,不停的运行下去,当单击End按钮时,该线程就会停止,如果继续单击Start,则文字又开始输出了. 软件界面如下: 实验主要部分代码和注释: MainActivity.java: 1 package com.ex

软件测试中LoadRunner函数中的几个陷阱

软件测试 中 LoadRunner 函数中的几个陷阱 1.atof 在 loadrunner 中如果直接用 float f; f=atof("123.00"); lr _output_message("%f",f); 输出的结果会是1244128.00,根本不是我们想要的. 因为float,double型在不同的平台下长度不一样,所以在loadrunner 软件测试中LoadRunner函数中的几个陷阱 1.atof 在loadrunner中如果直接用 float

软件测试中的杀虫剂悖论

在软件测试中有一种称为杀虫剂悖论(pesticide paradox)的现象,即对软件进行越多的测试,那么该软件对软件测试人员的测试就越具有免疫力. 首先,我们先来看下什么是杀虫剂悖论,每年各种各样的害处袭击田野和农作物,农业专家们要找到正确的对抗方法,用改良的配方设计出杀虫剂.但是害虫适应了新的杀虫剂,产生了免疫力,使新杀虫剂失效.随后的几年里,老的杀虫剂只能用来杀死没有免疫力的害虫,同时还必须引入一些新的改良配方,同更顽强的新编译害虫作斗争.新旧杀虫剂的结合有时阻碍了旧杀虫剂效能的发挥.随着

软件测试中的那些基础知识

软件测试是一项批判性的工作,目的就是找出软件中的缺陷.这里暂时不去深究为什么要进行软件测试,以及软件测试带来的好处.只介绍软件测试中一些基本的测试方法.根据是否查看代码程序分为黑盒测试和白盒测试:根据是否运行软件又可分为静态测试和动态测试. 黑盒测试:又叫功能测试或行为测试,只需考虑各个功能,不需要考虑整个软件的内部结构及代码. 白盒测试:访问代码,通过检查代码的线索来协助测试. 静态测试:测试软件不运行的部分,只是检查和审核. 动态测试:使用和运行软件进行测试. 1.静态黑盒测试:检查产品说明

软件测试中的“黑盒”与“白盒”

软件测试中,最常听到“黑盒测试”与“白盒测试”,它们是软件测试中最基本的测试方法. 那么究竟何为“黑盒”,何为“白盒”呢?下面就对其概念与常用方法进行一下介绍. 黑盒测试: 也称功能测试.数据驱动测试,它将被测软件看作一个打不开的黑盒,主要根据功能需求设计测试用例,进行测试. 概念:黑盒测试是从一种从软件外部对软件实施的测试,也称功能测试或基于规格说明的测试.其基本观点是:任何程序都可以看作是从输入定义域到输出值域的映射,这种观点将被测程序看作一个打不开的黑盒,黑盒里面的内容(实现)是完全不知道