书城计算机网络综合应用软件设计
8724600000036

第36章 软件测试的理论及实践(2)

②程序环境复杂性:从程序的环路复杂性可导出程序基本路径集合中的独立路径条数,这是确定程序中每个可执行语句至少执行一次所必需的测试用例数目的上界。

③导出测试用例。

④准备测试用例,确保基本路径集中的每一条路径的执行。

⑤图形矩阵:是在基本路径测试中起辅助作用的软件工具,利用它可以实现自动确定一个基本路径集的功能。

3.正确性测试

正确性测试又称功能测试,它检查软件的功能是否符合规格说明。由于正确性是软件最重要的质量因素,所以其测试也最重要。基本的方法是构造一些合理输入,检查是否得到期望的输出,这是一种枚举方法。测试人员一定要设法减少枚举的次数。成功的关键在于寻找等价区间,因为在等价区间中,只需用任意值测试一次即可。等价区间的概念可表述如下:

记(A,B)是命题f(x)的一个等价区间,在(A,B)中任意取x1进行测试。

如果f(x1)错误,那么f(x)在整个(A,B)区间都将出错。

如果f(x1)正确,那么f(x)在整个(A,B)区间都将正确。

上述测试方法称为等价测试,来源于人们的直觉与经验,可令测试事半功倍。

还有一种有效的测试方法是边界值测试。即采用定义域或者等价区间的边界值进行测试。因为程序员容易疏忽边界情况,程序也“喜欢”在边界值处出错。

例如,测试某一段程序,凭直觉等价区间应是(0,1)和(1,+∞)。可取x=0.5及x=2.0进行等价测试,再取x=0及x=1进行边界值测试。

有一些复杂的程序,难以凭直觉与经验找到等价区间和边界值,这时枚举测试就相当有难度。

在用“白盒测试”方式进行正确性测试时,有个额外的好处:如果测试发现了错误,测试者(开发人员)马上就能修改错误。越早改正错误,付出的代价就越低。所以大多数软件公司要求程序员在写完程序时,马上执行基于单步跟踪的“白盒测试”。

4.容错性测试

容错性测试是检查软件在异常条件下的行为。容错性好的软件能确保系统不发生无法意料的事故。比较温柔的容错性测试通常构造一些不合理的输入来引诱软件出错,例如:

①输入错误的数据类型,如“猴”年“马”月。

②输入定义域之外的数值。

粗暴一些的容错性测试俗称“大猩猩”测试,除了不能“拳打脚踢嘴咬”,什么招术都可以使出来。

5.性能与效率测试

性能与效率测试主要是测试软件的运行速度和对资源的利用率。有时人们关心测试的“绝对值”,如数据送输速率是每秒多少比特,有时人们则关心测试的“相对值”,如某个软件比另一个软件快多少倍。

在获取测试的“绝对值”时,要充分考虑并记录运行环境对测试的影响。例如计算机主频、总线结构和外部设备都可能影响软件的运行速度。

在获取测试的“相对值”时,要确保被测试的几个软件运行于完全一致的环境中。硬件环境的一致性比较容易做到(用同一台计算机即可),但软件环境的因素较多,除了操作系统外,程序设计语言和编译系统对软件的性能也会产生较大的影响。性能与效率测试中很重要的一项是极限测试,因为很多软件系统会在极限测试中崩溃。例如,连续不停地向服务器发请求,测试服务器是否会陷入死锁状态不能自拔;给程序输入特别大的数据,看看它是否吃得消。

6.易用性测试

易用性测试没有一个量化的指标,主观性较强。调查表明,当用户不理解软件中的某个特性时,首先会向同事、朋友请教。要是再不起作用,就向产品支持部门打电话。只有30%的用户会查阅用户手册。一般认为,如果用户不翻阅手册就能使用软件,那么表明这个软件具有较好的易用性。

7.文档测试

文档测试主要检查文档的正确性、完备性和可理解性。好多人甚至不知道文档是软件的一个组成部分。正确性是指不要把软件的功能和操作写错,也不允许文档内容前后矛盾。

7.5.3在测试过程中应该注意的几点问题

①明确测试的目的。

测试的目的是为了发现尽可能多的缺陷。这里缺陷是一种泛称,它可以指功能的错误,也可以指性能低下、易用性差等。测试总是先假设程序中存在缺陷,再通过执行程序来发现并最终改正缺陷。理解测试的目的是个很重要的意识问题。如果说测试的目的是为了说明程序中没有缺陷,那么测试人员就会向这个目标靠拢,因而下意识地选用一些不易暴露错误的测试示例,这样的测试是虚假的。

一个成功的测试示例在于发现了至今尚未发现的缺陷。

②测试的心理要求。

测试主要是由人而不是由机器执行,这就不免与心理因素相关。为了测试的真实性,对测试的心理要求是“无情”的,这似乎太残酷了。开发人员不能很好地测试自己的程序有时候是因为做不到“无情”。而测试人员如果做到了“无情”却会引起开发人员的愤怒,影响开发团队的团结。尽管已经明白了测试的目的是为了发现尽可能多的缺陷,但当测试人员真的发现了一堆缺陷时,却不可恭喜那个倒霉的开发者,否则会引起不必要的麻烦。

③测试的真理。

测试只能证明缺陷存在,而不能证明缺陷不存在。这个真理告诉我们,对于一个复杂的系统而言,无论采取什么样的测试手段都不能证明缺陷已经不复存在。“彻底地测试”只是一种理想。在实践中,测试要考虑时间、费用等限制,不允许无休止地测试。

④测试最重要的一件事就是考虑所有的出错可能性。同时还要做一些不是按常规做的、非常奇怪的事。

测试的过程就像黑客的攻击过程那样。可以这么说,像黑客是最好的软件安全测试员,他们专门找软件的漏洞,从而破坏这个软件,但这样也可以促使修复这些漏洞,保证软件的性能。如果找不到这种漏洞,说明软件的质量已经很好了。

⑤测试还要考虑性能问题,也就是要保证软件运行得很好,非常快,没有内存泄漏,不会出现那种越来越慢的情况。

⑥其他技巧和经验。

在制订测试计划的时候,就要考虑到测试的风险,并选择要执行哪些测试,放弃哪些测试;测试计划的评审应该让开发人员参与。

测试模型的制作应该尽可能贴近用户,或者站在用户的使用立场上来评测软件,此时应该能发现更多的问题。

由于在解决问题后还要重新测试,因此测试的时间可能会比实际更长一些。

识别和注意少数重要的方面,而忽略多数次要的方面。有时候少数的问题足以致命,这些问题将是软件测试结果中很严重的错误。

定位错误有时是很难的,要找出必然发生的前因后果,而不至于因为描述错误而误导开发人员。有时候确实存在错误不能重建的问题,解决办法之一就是在错误报告中给予说明。

对错误的描述,应该是准确、完整而简练。因为不准确的描述或者不完整的描述会引起开发人员的误解,其后果是可以想见的。

有时有经验的测试人员凭借直觉就可以发现一些问题,这可称为“错误猜测”。

测试人员容易犯两种错误:一是测试人员发生判断错误,将本没有错误的系统行为报告为错误,或者将错误指定了过高的严重级别,或者过高估计了问题的严重性,这样会引起对开发人员的不信任;二是测试人员将错误的严重性或优先级定得过低,从而产生“测试逃逸”,这样会造成产品质量的风险。

7.6测试自动化工具

测试自动化工具越来越多地出现在市场上,这些工具可以自动执行测试活动。迄今为止,现有工具中还没有哪一种工具能够自动执行所有测试活动。事实上,多数工具是一个或几个活动专用的,有些工具的功能针对性很强,只能处理一个活动的某一部分。评估不同的测试自动化工具时,有必要了解工具类型、工具限制及工具能够处理和自动执行的活动情况。

功能测试工具可以按其执行的功能分类。典型的测试工具有以下几种分类。

①数据获取工具,用于获取要在测试活动中使用的数据。数据可以通过转化、析取、变换或捕捉现有数据来获取,也可通过从用例或补充规约生成获取。

②静态评测工具,用于分析设计模型、源代码或其他固定源中包含的信息。该分析将生成有关逻辑流、数据流或质量指标的信息,如复杂性、可维护性或代码行。

③动态评测工具,用于在代码的执行过程中进行分析。这些评测包括代码运行时的操作,如内存性能和错误检测。

④模拟器或驱动程序,它们执行由于时间、费用或安全原因而无法用于测试的活动。

⑤测试管理工具,用于辅助测试活动或工件的计划、设计、实施、执行、评估和管理。

7.7测试案例

7.7.1单元测试的实例

本实例采用nunit对VB.NET类中的方法进行测试。在极限编程的思想中体现了测试先行的思想。这里我们将采用这一思想,首先构建我们的测试类。我们还要导入NUnit.Framework这个名称空间,这是nunit工具自身所带的。

Imports System

Imports NUnit.Framework

Namespace NUnit.Samples

Public Class SimpleVBTest

Public Sub Add()

dim Test as new TestClass()

Assert.AreEqual(6,Test.add(3+3))

Assert.AreEqual(6,Test.add(2+4))

End Sub

End Class

End Namespace

通过nunit运行上面的代码会报错。因为我们还没有实现类和它里面的方法Add(),下面我们添加类和它的实现方法。

Imports System

Public class TestClass

Public function add(byval a as integer,byval b as integer)as integer

Return(a+b)

End function

End class

再运行测试类,nunit可以成功地通过测试。以后我们对实现类的方法进行改动或者添加其他的方法,只需要在测试类中添加相应的测试类就可以了。这样,如果代码进行改动,我们只需要通过运行测试类就可以看到代码改动对程序的影响。当然设计一个好的测试类是非常必要的,因为要考虑很多的情况,尽可能地进行覆盖测试。

7.7.2压力测试的实例

在Web工程进行集成测试或系统测试中,我们通常要进行许多方面的测试,如压力测试、容量测试、链接测试等。我们以其中的压力测试为例来简单介绍工具为Microsoft的Web Application Stress Tool(WAS,Web应用负载测试工具)在Web服务器性能测试中的应用。

要对网站进行负载测试,首先必须创建WAS脚本模拟用户活动。我们可以用下面四种方法之一创建脚本:通过记录浏览器的活动、通过导入iis日志、通过把WAS指向Web网站的内容或者手工制作。

页面摘要部分提供了页面的名字,接收到第一个字节的平均时间(TTFB),接收到最后一个字节的平均时间(TTLB),以及测试脚本中各个页面的命中次数。TTFB和TTLB这两个值对于计算客户端所看到的服务器性能具有重要意义。TTFB反映了从发出页面请求到接收到应答数据第一个字节的时间总和(以毫秒计),TTLB包含了TTFB,它是客户机接收到页面最后一个字节所需要的累计时间。报表中还包含了所有性能计数器的信息。这些数据显示了运行时各个项目的测量值,同时还提供了最大值、最小值、平均值等。报表实际提供的信息远远超过了我们这里能够介绍的内容。

7.8主流自动化测试工具

思考题

1.软件测试的目的是什么?

2.软件测试过程主要涉及哪些文档资料?

3.简述软件测试的分类。

4.在任何时候,单元测试都是可能的吗?都是需要的吗?