软件测试自动化电子教案

软件测试自动化[本章目标]1.了解自动化测试应考虑的各种因素以及如何衡量自动化测试成本。2.掌握自动化测试和手工测试的优缺点。3.了解测试工具的分类、使用目的及其选择，了解几种常用的测试工具。4.了解自动化测试的过程。

7.1进行自动化测试的适当时机通常，软件测试的工作量很大（据统计，测试会占用到40%的开发时间；一些可靠性要求非常高的软件，测试时间甚至占到开发时间的60%）。而测试中的许多操作是重复性的、非智力性的和非创造性的，并要求做准确细致的工作，计算机就最适合于代替人工去完成这样的任务。软件自动化测试是相对手工测试而存在的，主要是通过所开发的软件测试工具、脚本等来实现，具有良好的可操作性、可重复性和高效率等特点。在进行自动化测试前，首先要建立一个对软件测试自动化的认识观。软件测试工具能提高测试效率、覆盖率和可靠性等，自动化测试虽然具有很多优点，但它只是测试工作的一部分，是对手工测试的一种补充。自动化测试绝不能代替手工测试，它们各有各自的特点，其测试对象和测试范围都不一样：

7.1.1概述当针对产品的一些特征来设计一系列测试时，对每一个测试都需要决定是否对其进行自动化测试。在决定是否要进行自动化测试之前，通常需要考虑如下几个主要问题：1．同手工测试相比，只运行一次的自动化测试要多付出多少代价？2．自动化测试的生命周期是有限的。那么，这类测试是否迟早要终止？什么事件将会导致测试中止？3．在整个生命周期内，这次测试能捕获到新bug的可能性会有多大？这些难以预计的收益能够使自动化测试的成本得到补偿吗？7.1.2自动化测试的成本创建一次自动化的测试所花费的时间要比一次手工测试所花费的时间多得多。测试成本因产品的架构以及自动化测试的方式不同而异。介绍如下几种(费用由高至低)：

<1>通过图形用户界面来测试产品；

<2>使用GUI捕捉/回放工具来跟踪测试与产品之间的交互，同时建立脚本；

<3>测试的是一个编译器；测试成本还要考虑测试时间、Bug的多少等问题。

7.1.3自动化测试的生命周期测试的生命周期如下图7-1所示：

在决定是否进行自动化测试之前，必须首先估计一下，产品的代码变动在什么范围内，测试仍能存活。如果要求代码不能有太多变动，要做的测试最好是非常善于捕获bug的测试.介于需要被测试的代码和测试之间的代码称作中介代码（interveningcode）。一、中介代码的变动对测试周期的影响

中介代码是使测试中止的一个主要原因。例如，用户界面以前要求输入电话号码，现在变为提供一个可视的电话键盘，使用鼠标点击数字来模拟使用真实的电话。虽然通过两种界面向被测试的代码传递的都是相同的数据，但是因为没有了提供输入电话号码的地方，自动化测试可能就会中止。为了使测试免受中介代码变化的影响，应该从以下几个方面考虑：1、评估一下中介代码的改变会不会影响测试。如果绝不会影响到测试，使用自动测试就能节省大量的时间。2、如果中介代码的变化会影响到测试，就必须考虑一下使用测试库函数能够使测试不受影响的可能性会有多大。3、假如没有测试函数库——如果是在捕捉/回放的模式下使用GUI测试自动化工具——不要指望测试会不受影响。

二、被测试代码的改变对测试周期的影响需要判断一下被测试的代码的稳定性。首先，需要重点考虑代码的行为。其次，考虑功能的增加会不会影响测试。

7.1.4自动化测试的价值进行自动化测试要解决的问题就是：自动化测试的价值必须要超过所有因此而放弃的手工测试的价值。考虑问题如下：1.测试代码的结构要清晰。2.测试通常是用来测试功能代码。支撑代码对于测试者来说通常是不可见的。

3.但功能代码的改变通常会改变代码的行为。因此，极有可能会使测试中止，而不是报告bug。

4.测试的价值主要在于支撑代码改变以后仍能捕获bug的能力。5.如果我们一点也不了解支撑代码，无法知道测试是否能捕获bug?如何估计测试是否有助于我们捕获bug?6.可以认为与被测试的代码进行交互的其他代码大多数是支撑代码，支撑代码的变化也会产生自动测试所能捕获的bug。

一、分析被测试代码的结构对测试的影响。例子：被测试的是一段处理从银行账户里提款的代码。（例子详见教材）把被测试的代码分成两部分：①功能代码（featurecode），它直接实现被测试代码所完成的功能。测试会专门对其进行调用。功能代码（supportcode）可以完成用户所进行的操作（通过使用用户界面的关联代码）。②支撑代码(supportcode)，它起到支持功能代码（supportcode）的作用。测试代码会对其进行调用，但并没有针对这些代码的特殊测试。图7-2功能代码和支撑代码示意图

在这里，支撑代码位于水平线以下。功能代码位于水平线以上，共有五种不同的功能，我们只针对其中的两个功能进行测试。二、被测试代码的变化所带来的影响。主要考虑这样一些问题：1．就给定的结构而言，代码的变化将会产生什么样的影响？2．什么样的变化具有测试价值？假设一些功能代码发生了变化，如图7-3中灰色图形所示：这种变化极有可能会导致调用功能代码的测试中止。因此，如果希望使用自动化测试的方法在发生变化的功能代码（featurecode）中找到bug，就必须终止原有测试。如果测试的成本很高，这样做是很不经济的。为了使原有的测试行为仍然能够保留，通常采用的做法是更改支撑代码（supportcode）以便能够支持其他功能代码的变动。请看图7-4：图7-3图7-4三、支撑代码的变化对测试的影响主要从以下两方面来考虑这个问题：代码的变化有多少？这些变化会引入多少bug?7.1.5例子假设我正在测试一个产品，测试已经完成一半。产品已经实现了主要的功能，但是还需要增加一些辅助功能。现在我要对这些主要的功能进行测试。测试过程中，在同如下人员进行交流的过程中提出的问题如下：程序员：这些辅助的功能是否有可能需要改变产品的支撑代码？程序员有可能精心设计了支撑代码，并且考虑坚持使用可视化的用户界面来完善各种功能。如果是这样的话，那么自动化测试的价值就不大。但是因为要急于完成测试，程序员也可能知道程序的支撑代码的结构不会一成不变的。由于大部分工作将会重复进行，所以可能会特别需要进行自动化测试。或者程序员也不知道支撑代码是否要改变。项目经理：在新版本中，新增的功能是一个十分重要的部分吗？如果是这样的话，由于市场竞争激烈，图形用户界面有可能改变吗？以前，用户界面改动有多大？为什么会希望今后的改动越少越好？这些变化是为了增加功能，还是用来代替现有的功能？我们需要切实的估计一下变动的可能性，因为任何变化都可能会提高自动化测试的成本，缩短测试的生命周期。了解并熟悉测试工具的人员：如何应对产品的变化？什么样的变化会使测试中止？对于新增加功能的测试，遇到这些情况的几率会有多大？一次自动化测试所花费的成本相当于几次手工测试，并且要特别重视测试价值的大小和生命周期的长短，这样做可能不对。但这都是为了避免犯下灾难性的错误，如果自动化测试的成本很高而生命周期很短，我们最好使用手工测试。但是这并不意味着不能使用自动化测试，而是要判断与衡量。

在测试中，要不断跟踪bug报告并加以修改，保留所有和测试相关的文档。从这些资料当中，我们常常能够发现更为重要的信息。如：•什么样的因素与产生的bug无关？•哪里存在bug？•代码行为的稳定性如何？经过一段时间，要进行自动化测试还是手工测试的想法就会逐渐成熟，可能会形成一个更大的测试套。7.1.6另外一些需要考虑的问题

1.手工测试有时候会发现一些自动化测试所不能发现的问题。2.尽管人善于发现问题，但很容易疲劳。并且不能对结果做出精确的分析。

3.由于我们不能保证每次手工输入的数据完全相同。因此，重复的手工测试多少会有些不同，那么就有可能捕获支撑代码中的bug。4.要求对配置测试进行更多的自动化测试。5.如果在进行第一次测试的时候就捕获了bug。表明这部分程序代码将来有可能发生变化，要进行更多的自动化测试。

6.如果自动化测试的技术支持足够强大，开发人员很容易就能做回归测试，自动化测试也要比手工测试快得多，但是并不是所有的公司都具有这样的自动化测试技术支持水平。7.使用手工测试的时候捕获了bug,但又不能再现bug时会使人很沮丧。8.程序更改之后，测试人员应该对其进行检查。9.因为进行自动化测试的创建要花费一些时间，因此把第一个bug提交给程序员所花费的时间要比手工测试花费的时间长。10.把测试设计得简单有利于进行自动化测试，但不善于捕获bug。11.如果产品的行为改变了，自动化测试就有可能会报告一些不真实的bug。12.如果自动化测试创建的十分好，能够有序的运行，并且可以改变测试运行的顺序。13.我们可以在产品需要测试之前先设计测试。14.也许自动化测试的价值直到下一个新版本发布之后才能体现出来。

7.2自动化测试和手工测试比较

自动化测试并不能完全取代手工测试，二者各有优缺点。

7.2.1自动化测试与手工测试的比较

表7-1显示了手工测试与自动化测试的比较结果。这个测试案例中包括1750个测试用例和700多个错误。测试步骤手工测试自动化测试通过使用工具改善测试的百分比测试计划的开发3240-25%测试用例的开发26211755%测试执行4662395%测试结果分析1175850%错误状态/更正检测1172380%产生报告961683%时间总和109027775%表7-1自动化测试和手工测试比较7.2.2短测试周期中手工测试面临的挑战

迭代式的开发过程已逐渐取代传统的瀑布式开发，成为了目前最流行的软件开发过程。在迭代开发中强调在较短的时间间隔中产生多个可执行、可测试的软件版本，这就意味着测试人员也必须为每次迭代产生的软件系统进行测试。随着软件开发过程的进展，测试工作越来越繁重，如果使用手工测试的方法，将很难保证测试工作的进度和质量。

7.2.3手工测试的问题手工测试的方法是根本不可能符合软件快速开发的要求的。大公司用自动化测试因为它适合自动化测试的特点和有较高的投资回报率。

1、针对产品型项目的测试2、针对增量式开发、持续集成项目的测试3、针对能够自动编译、自动发布的系统的测试4、回归测试5、需要多次重复、机械性动作的测试6、需要频繁运行的测试7、将烦琐的任务转化为自动化测试

7.2.4自动化测试的问题自动化测试并不能完全取代手工测试。例如：在下面几种情况下就不适合使用自动化测试。

<1>定制型项目（一次性的）<2>项目周期很短的项目<3>涉及业务规则复杂的对象

<4>关于美观、声音、易用性的测试<5>很少运行的测试，如：一个月只运行一次的测试。<6>测试的软件不稳定<7>涉及物理交互的测试

7.2.5自动化测试的优点

1、对程序的新版本运行己有的测试，即回归测试。2、可以运行更多更频繁的测试。3、可以进行一些手工测试难以完成或不可能完成的测试。4、充分地利用资源。5、测试具有一致性和可重复性。6、测试具有复用性。7、缩短软件发布的时间。8、增强软件的可靠性。

7.2.6自动化测试的缺点1、自动化测试不能取代手工测试，测试主要还是要靠人工的。2、新缺陷越多，自动化测试失败的几率就越大。3、工具本身不具有想象力4、技术问题、组织问题、脚本维护

5、测试工具与其他软件的互操作性

7.3自动化测试工具的选择和使用

7.3.1应用自动化测试工具的目的

一般而言，在测试过程中应用自动化测试工具主要为了以下几个目的：

1、提高测试质量；

2、减少测试过程中重复的手工劳动，提高测试效率；

3、实现测试自动化，充分利用测试资源。

7.3.2自动化测试工具的概要介绍根据软件生命周期中的定义，可以把自动化测试工具分为白盒测试工具、黑盒测试工具和测试管理工具三大类。这些工具和软件开发过程中相关活动的关系如图7-6所示：图7-6测试工具与开发过程关系图一、白盒测试工具白盒测试工具一般是针对代码进行测试的工具，测试中发现的缺陷可以定位到代码级，根据测试原理的不同，又可以分为静态测试工具和动态测试工具。1、静态测试工具所谓静态测试就是不运行测试而直接对代码进行分析的测试。静态测试工具的代表是PR公司的PRQA软件。

2、动态测试工具动态测试主要采用“插桩”的方式，即向代码生成的可执行文件中插入一些监测代码，运行框架程序，统计程序运行时的数据，可以针对所有类的成员函数进行测试，也可以只针对类的公共接口函数进行测试。代表有Jtest，C++test等。

二、黑盒测试工具黑盒测试工具包括功能测试工具和性能测试工具。主要代表是WinRunner。

三、测试管理工具测试管理工具用于对测试进行管理。一般而言，测试管理工具主要对软件缺陷、测试计划、测试用例、测试实施进行管理。7.3.3自动化测试工具的选择

在考虑选用工具的时候，建议从以下几个方面来权衡和选择：

1、功能除了基本的功能之外，以下的功能需求也可以作为选择自动化测试工具的参考：1)报表功能；2)自动化测试工具的集成能力；3)操作系统和开发工具的兼容性；

2、价格3、对自动化测试工具进行评估。4、引入自动化测试工具的目的是使测试自动化。

7.3.4自动化测试工具在测试过程中的应用很多引入测试软件的公司并没有能够让测试软件发挥应有的作用，其原因主要有三个方面：1、没有考虑公司的实际情况，盲目引入自动化测试工具

2、没有形成一个良好的使用自动化测试工具的环境

3、没有进行有效的自动化测试工具的培训

7.4性能测试实例本节列举了一个使用LoadRunner进行的性能测试实例。

7.4.1LoadRunner简介LoadRunner®是一种预测系统行为和性能的负载测试工具。通过模拟成千上万名用户和实施实时性能监测来确认和查找问题，LoadRunner能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。其主要功能如下： 1、轻松创建虚拟用户2、创建真实的负载 3、定位性能问题

4、分析结果精确定位问题所在7.4.2案例分析

该案例仍然是针对电厂两票管理系统的性能测试，电厂工作人员可以使用该管理系统开出工作票和操作票。假设开设100个账号和密码可供100个工作人员同时开出工作票或操作票。要求，每台机器只能由一个用户使用，每个用户只能使用各自不同的账号登录该管理系统，开票结束后，要求把工作票或操作票内容存档，若在规定的时间内没有存档，则系统强制存档。但是，一般测试部门不可能有100台机器同时进行测试的。所以，使用Loadrunner模拟IP地址，修改脚本来协助测试。但是，为了保证测试结果，建议使用所有可用的机器进行复测，因为有时候测试工具是不可以完全信赖的。

现场测试环境：

硬件：100台PC机，一个Web服务器操作系统：Windows2000Server测试工具：Loadrunner8.0

浏览器：IE5.0和IE6.0

测试人员：质控小组4人，执行现场测试

项目小组22人，提供现场环境

技术小组各1人，提供技术支持

测试要求：

100个用户拥有独立IP地址，不同的用户及密码登录，开票操作完成后各自同时把工作票或操作票内容存档。测试内容：

100个用户以不同的用户名和密码登录该管理系统。开票完成后，把工作票或操作票内容存档。测试系统是否能正常开票以及正确存档。

测试方案：

1、完全50台实际的PC机进行现场测试。（1）准备工作，并做计划。第一轮测试执行三遍，设定50个用户开出的工作票或操作票内容同时提交，第一遍全部使用IE5.0，第二遍25台使用IE5.0，25台使用IE6.0，第三遍全部使用IE6.0

（2）At9：00，50个用户同时登录系统

（3）At9：05，50个用户同时提交

（4）分别记录第一轮测试（三遍）的结果

（5）第二轮测试准备工作，设定30个用户开出的工作票或操作票内容同时提交，另外20个用户延时5分钟提交，全部使用IE5.0

（6）At9：15，50个用户同时登录系统

（7）At9：20，30个用户同时提交

（8）At9：25，剩余20个用户同时提交

（9）记录第二轮测试结果

（10）第三轮测试准备工作，设定30个用户开出的工作票或操作票内容同时提交，另外20个用户延时5分钟提交，全部使用IE6.0（11）At9：15，50个用户同时登录系统

（12）At9：20，30个用户同时提交

（13）At9：25，剩余20个用户同时提交

（14）记录第三轮测试结果

（15）第四轮测试准备工作，设定30个用户开出的工作票或操作票内容同时提交，另外20个用户延时5分钟提交，正常提交用户使用IE5.0，延时提交用户使用IE6.0

（16）At9：15，50个用户同时登录系统

（17）At9：20，30个用户同时提交

（18）At9：25，剩余20个用户同时提交

（19）记录第四轮测试结果

（20）第五轮测试准备工作，设定30个用户开出的工作票或操作票内容同时提交，另外20个用户延时5分钟提交，正常提交用户使用IE6.0，延时提交用户使用IE5.0

（21）At9：15，50个用户同时登录系统

（22）At9：20，30个用户同时提交（23）At9：25，剩余20个用户同时提交

（24）记录第五轮测试结果

（25）第六轮测试准备工作，设定30个用户开出的工作票或操作票内容同时提交，另外20个用户延时5分钟提交，正常提交用户其中20个使用IE5.0，10个使用IE6.0，延时提交用户使用IE5.0

（26）At9：15，50个用户同时登录系统

（27）At9：20，30个用户同时提交

（28）At9：25，剩余20个用户同时提交

（29）记录第六轮测试结果

（30）第七轮测试准备工作，设定25个用户开出的工作票或操作票内容同时提交，另外25个用户分两次分别延时5、15分钟提交（31）At9：35，50个用户同时登录系统（32）At9：40，25个用户同时提交

（33）At9：45，剩余的其中15个用户同时提交

（34）At9：55，其他10个用户同时提交

（35）记录第七轮测试结果，参见第二轮测试－第六轮测试过程分别对IE5.0和IE6.0的情况进行测试

（36）第八轮测试准备工作，设定其中25个用户开出的工作票或操作票内容不提交，由系统强行提交

（37）At10：10，50个用户同时登录系统

（38）At10：15，25个用户同时提交

（39）其余用户的内容由系统强行提交

（40）记录第八轮测试结果，参见第二轮测试－第六轮测试过程分别对IE5.0和IE6.0的情况进行测试

（41）第九轮测试准备工作，设定其中25个用户开出的工作票或操作票内容同时提交，15个用户延时5分钟提交，其余用户由系统强行提交（42）At10：25，50个用户同时登录系统

（43）At10：30，25个用户同时提交

（44）At10：35，剩余的其中15个用户同时提交

（45）剩余10个用户系统强制提交

（46）记录第九轮测试结果，参见第二轮测试－第六轮测试过程分别对IE5.0和IE6.0的情况进行测试

2、模拟50个用户进行测试。其中，18台是PC机，另外32台机器的IP地址是Loadrunner模拟出来的。（1）在18台实际的PC机中抽取其中一台虚拟32个IP地址，包括自身的IP地址，这台机器上共33个IP地址，这33个IP地址只能全部使用IE5.0或者全部使用IE6.0

（2）其余17台实际的PC机分别由17个人操作，另外一台机器由一位质控小组人员操作

（3）对于异常情况，延时提交和强制提交全部由实际的机器来模拟

（4）其余过程参见1

3、模拟50个用户进行测试。其中，10台是PC机，另外40台机器的IP地址是用Loadrunner模拟出来的。

（1）在10台实际的PC机中抽取其中一台虚拟40个IP地址，包括自身的IP地址，该机器上共41个IP地址，这41个IP地址只能全部使用IE5.0或者全部使用IE6.0

（2）其余9台实际的PC机分别由9个人操作，另外一台机器由一位质控小组人员操作

（3）对于异常情况，延时提交和强制提交全部由实际的机器来模拟

（4）其余过程参见1

4、模拟75个用户进行测试。其中，35台是PC机，另外40台机器的IP地址是用Loadrunner模拟出来的。（1）在35台实际的PC机中抽取其中三台分别虚拟13、13、14个IP地址，这40个IP地址只能全部使用IE5.0或者全部使用IE6.0

（2）其余32台实际的PC机分别由32个人操作，另外三台机器由两位质控小组人员操作

（3）对于异常情况，延时提交和强制提交全部由实际的机器来模拟

（4）其余过程参见1

5、模拟100台用户进行测试。其中，40台是PC机，另外60台机器的IP地址是用分别用四台实际的PC机模拟出来的。记录测