第2章 软件自动化测试

软件自动化测试是软件测试的发展方向，但是，如果盲目追求自动化测试，则有可能导致软件测试的失败。本章介绍如何开展软件自动化测试项目，以及软件自动化测试的管理方法。

2.1 手工测试与自动化测试

手工测试和自动化测试是很多测试人员争相讨论的两种测试方法。有人对自动化测试趋之若鹜，也有人对自动化测试嗤之以鼻。在做出如何看待自动化测试的决定之前，首先要对自动化测试有一个清晰的概念。

2.1.1 手工测试的缺点

软件测试的一个显著特点是重复性，重复让人产生厌倦的心理，重复使工作量倍增，因此，人们想到用工具来解决重复的问题。

另外，手工测试还存在精确性的问题，尤其是面对大量的数据需要检查时，人工的比较和搜索不仅存在效率问题，而且容易出错，覆盖面偏低。

手工测试存在效率问题，这在软件产品的研发后期阶段尤其明显，因为随着产品的日趋完善，功能日渐增多，需要测试和检查的内容越来越多，很容易遗漏。加之产品发布日期日益临近，人工重复进行回归测试的难度加大，很难在短时间内完成大面积的测试覆盖。

2.1.2 什么时候使用自动化测试

手工测试有其不可替代的地方，因为人是具有很强智能判断能力的动物，而工具是相对机械、缺乏思维能力的东西。手工测试不可替代的地方至少包括以下几点：

❑ 测试用例的设计：测试人员的经验和对错误的猜测能力是工具不可替代的。

❑ 界面和用户体验测试：人类的审美观和心理体验是工具不可模拟的。

❑ 正确性的检查：人们对是非的判断、逻辑推理能力是工具不具备的。

但是，自动化测试有很强的优势，它的优势是借助了计算机的计算能力，可以重复地、不知疲倦地运行，对于数据，能进行精确的、大批量的比较，而且不会出错。

因此，自动化测试适宜用在需要重复执行机械化的界面操作、计算、数值比较、搜索等方面。我们应该充分利用自动化测试工具的高效率来帮助测试人员完成一些基本的测试用例的执行，从而实现更加快速的回归测试，并且提高测试的覆盖率。

2.1.3 自动化测试——你准备好了吗

在进行项目的自动化测试之前，先要考虑以下5个方面，这5个方面是成功开展自动化测试需要考虑的方面，也可用于衡量目前的项目是否有足够的条件进行自动化测试：

（1）测试自动化类似于软件开发过程

录制/回放的脚本开发方式是不可能应付所有自动化测试的需求的，因此，需要测试人员掌握必要的开发知识和编码技巧。

（2）测试自动化是一个长期的过程

首先，不能期望自动化测试在短期内找到很多Bug，自动化测试只有在长期的多次运行后才能体现出它的价值。其次，不要认为只要购买了工具，录制一些脚本，然后，就可以安枕无忧地看着自动化测试实现想要的效果，需要考虑自动化测试脚本的维护成本，随着被测试应用程序功能的增加和修改，测试脚本的维护工作量会急剧地增加。

（3）确保测试自动化的资源，包括人员和技能

最好有专门的自动化测试工程师来保证测试自动化持续、顺利地进行下去，自动化测试工程师需要对项目的测试自动化负责，设计测试框架和脚本结构，解决各种测试脚本的开发问题，确保自动化测试得以计划、设计和有序地开发、维护。

（4）循序渐进地开展自动化测试

不要一开始就把自动化测试设想得很大，这往往是不可实现的，应该从小开始，先熟悉工具和自动化测试的基本技能，然后，整合资源开始实现一些基本的自动化测试用例，例如，冒烟测试类型的自动化测试脚本。先实现那些容易实现、且相对稳定的功能模块的自动化测试，然后再考虑逐步扩展和补充其他相对难实现，或者是比较不稳定的功能模块。

（5）确保测试过程的成熟度

如果软件企业的测试过程和项目管理过程的能力成熟度比较低，则实现自动化测试的成功率也比较低。在开展自动化测试之前，先考察一下软件企业各方面的管理能力，例如，测试是否独立进行？有无配置管理？进度控制能力如何？如果各方面的能力成熟度都比较差的话，则不要盲目引入测试自动化。

2.2 如何开展自动化测试

自动化测试应该被当成一个项目来开展，自动化测试工程师应该具备额外的素质和技能，并且在开展自动化测试的过程中，要注意合理地管理和计划，从而确保自动化测试成功实施。

2.2.1 选取合适的测试项目来开展自动化测试

自动化测试只有在多次运行后，才能体现出自动化的优势，只有不断地运行自动测试，才能有效预防缺陷、减轻测试人员手工的回归测试的工作量。如果一个项目是短期的，并且是一次性的项目，则不适合开展自动化测试，因为这种项目得不到自动化测试的应有效果和价值体现。

另外，不宜在一个进度非常紧迫的项目中开展自动化测试。有些项目经理期待在一个进度严重拖延的项目中引入自动化测试来解决测试的效率问题，结果适得其反。这是因为，自动化测试需要测试人员投入测试脚本的开发，同时，需要开发人员的配合，提供更好的可测试的程序，有可能需要对被测试的软件进行改造，以适应自动化测试的基本要求，如果在一个已经处于进度Delay状态的项目中开展自动化测试，则很可能带来反效果。

2.2.2 自动化测试介入的时机

过早的自动化会带来维护成本的增加，因为早期的程序界面一般不够稳定，处于频繁更改的状态，这时候进行自动化测试往往得不偿失，疲于应付“动荡”的界面。

那么，什么时候开始自动化测试项目呢？自动化测试不应该在界面尚未稳定的时候开始，但是，并不意味着不需要计划和准备工作。在界面雏形时期，可以基于界面原型提供的控件来尝试自动化测试工具的适用性，因为有些控件是自动化测试工具不能识别和测试的。这时候，就要考虑工具的选择问题。

在开发人员着手开发一些核心的代码时，可能会同时开发出一些核心可重用的控件，而且是那种自定义的个性化控件，那么就需要在这个阶段取到这些控件，并且尝试使用自动化工具来测试这些控件，如果发现有不适用的地方，则要考虑让开发人员重新设计控件，或者提供更多的测试接口。

2.2.3 自动化测试工程师的基本素质和技能要求

自动化测试工程师应该具备一定的自动化测试基础，包括自动化测试工具的基础、自动化测试脚本的开发基础知识等；还需要了解各种测试脚本的编写和设计方法，知道在什么时候选取怎样的测试脚本开发方式，知道如何维护测试脚本；需要具备一定的编程技巧，熟悉某些测试脚本语言的基本语法和使用方法。

另外，自动化测试工程师与手工测试的工程师一样，需要具备设计测试用例的基本方法和能力，具备软件涉及的基本业务的理解能力。而且，应该有把测试用例转换成自动化测试用例的能力。

2.2.4 自动化测试的成本

成功开展自动化测试必须考虑自动化测试的成本问题。成本包括测试人员、测试设备、测试工具等。

（1）应该能抽出专职的测试人员进行自动化测试脚本的开发，并且抽调的测试人员不会对已有的手工测试人员造成影响，需要保证自动化测试的开展不会影响到手工测试的正常进行。

（2）自动化测试可能需要额外的测试设备，例如，测试执行的机器、文件服务器、数据库等。应该能为自动化测试准备专门的测试设备。

（3）有引入测试工具或开发测试工具的成本预算。缺乏工具的自动化测试是不可能实现的。在上马一个项目的自动化测试之前应该进行测试工具的引入准备、测试工具的培训工作的开展等。

（4）某些项目选用了很多第三方控件或自定义的控件，而这些控件的可测试性非常差，那么对这个项目进行自动化测试的成本会非常高，不适宜进行自动化测试。

2.3 自动化测试方案

自动化测试是一项需要计划和设计的活动，在开始测试脚本的开发之前，应该考虑清楚采用怎样的自动化测试方案，采用怎样的自动化测试脚本开发方法。

2.3.1 选择自动化测试方案

采用什么样的自动化测试方案，需要考虑以下几个方面的因素：

（1）项目的影响：自动化测试能否对项目进度、覆盖率、风险有积极的作用，或者让开发更敏捷？

（2）复杂度：自动化是否容易实现，包括数据和其他环境的影响。

（3）时间：自动化测试的实现需要多少时间？

（4）早期需求和代码的稳定性：需求或早期的代码是否能证明是在一定范围内变化的？

（5）维护工作量：代码是否能长期保持相对稳定？功能特性是否会进化？

（6）覆盖率：自动化测试能否覆盖程序的关键特性和功能？

（7）资源：测试组是否拥有足够的人力资源、硬件资源和数据资源来运行自动化测试。

（8）自动化测试的执行：负责执行自动化测试的小组是否拥有足够的技能和时间去运行自动化测试？

以上方面的各因素对于选择什么样的自动化测试方案，达到怎样的目标，投入多少测试资源，自动化测试项目的进度安排，自动化测试用例的设计等都会造成一定的影响。

2.3.2 自动化测试脚本的编写方法

自动化测试项目也像普通的软件开发项目一样，有编码阶段，自动化测试的编码阶段主要是通过编写测试脚本实现所设计的自动化测试用例。自动化功能测试脚本的开发方式主要有以下几种：

❑ 线性的

❑ 结构化的

❑ 共享的

❑ 数据驱动的

❑ 关键字驱动的

2.3.3 线性脚本的编写方法

线性脚本编写方法是使用简单的录制回放的方法，测试工程师使用这种方法来自动化地测试系统的流程或某些系统测试用例。它可能包含某些多余的、有时候并不需要的函数脚本。线性脚本编写方法的特点是：

❑ 一种非结构化的编程方式

❑ 测试用例由脚本定义

❑ 非常低的开发成本

❑ 测试人员所需要的编程方面的技巧几乎可以忽略

❑ 不需要计划、设计

❑ 测试数据在脚本中是硬编码的

❑ 脚本会很脆弱，因此维护成本会很高

❑ 没有公用的脚本，因此可能造成重复劳动

2.3.4 结构化脚本的编写方法

结构化脚本编写方法在脚本中使用结构控制。结构控制让测试人员可以控制测试脚本，或测试用例的流程。在脚本中，典型的结构控制是使用“if-else”，“switch”，“for”，“while”等条件状态语句来帮助实现判定、实现某些循环任务、调用其他覆盖普遍功能的函数。结构化脚本编写方法的特点是：

❑ 结构化的脚本编写方法

❑ 测试用例在脚本中定义

❑ 编程的成本要比线性脚本编写方法略为高一点

❑ 需要测试员的调整编码技巧

❑ 需要某种程度上的计划、设计

❑ 测试数据也是在脚本中被硬编码

❑ 因为相对稳定一点，所以需要相对少的脚本维护，维护成本比线性脚本编写方法的要相对低

❑ 除了编程知识外，还需要一些脚本语言的知识

2.3.5 共享脚本的编写方法

共享脚本编写方法是把代表应用程序行为的脚本在其他脚本之间共享。这意味着把被测应用程序的公共的、普遍的功能的测试脚本独立出来，其他脚本对其进行调用。这使得某些脚本按照普遍功能划分来标准化、组件化。这种脚本甚至也可以使用在被测系统之外的其他软件应用系统。共享脚本编写方法的特点是：

❑ 脚本是结构化的

❑ 测试用例在脚本中定义

❑ 开发成本相对于结构化脚本编写方法来说，要降低一些，因为减少了很多复制的劳动

❑ 需要测试员的调整代码的编程技巧

❑ 由于脚本需要模块化，所以需要更多的计划和设计

❑ 测试数据也是硬编码的

❑ 脚本维护和维护成本要比线性脚本编写方法的相对低

2.3.6 数据驱动脚本的编写方法

数据驱动脚本编写方法把数据从脚本分离出去，存储在外部的文件中。这样，脚本就只是包含编程代码了。这在测试运行时要改变数据的情况下是需要的。这样，脚本在测试数据改变时也不需要修改代码。有时候，测试的期待结果值也可以跟测试输入数据一起存储在数据文件中。数据驱动脚本编写方法的特点是：

❑ 脚本是以结构化的方式编程的

❑ 测试用例由测试数据或脚本定义

❑ 由于脚本参数化和编程成本，这种方法的开发成本跟共享脚本编写方法比较要相对高

❑ 需要测试员较高的代码调整方面的编程技巧

❑ 需要更多的计划和设计

❑ 数据独立存储在数据表或外部文件

❑ 脚本维护成本较低

❑ 推荐在需要测试正反数据的时候使用

2.3.7 关键字驱动脚本的编写方法

关键字驱动脚本编写方法把检查点和执行操作的控制都维护在外部数据文件。因此，测试数据和测试的操作序列控制都是在外部文件中设计好的，除了常规的脚本外，还需要额外的库来翻译数据。关键字驱动脚本编写方法是数据驱动测试方法的扩展，其特点是：

❑ 综合了数据驱动脚本编写方法、共享脚本编写方法、结构化脚本编写方法

❑ 测试用例由数据定义

❑ 开发成本高，因为需要更多的测试计划和设计、开发方面的投入

❑ 要求测试人员有很强的编程能力

❑ 最初的计划和设计、管理成本会比较高

❑ 数据在外部文件存储

❑ 维护成本比较低

❑ 需要额外的框架或库，因此，测试员需要更多的编程技巧

2.3.8 合理选择自动化测试脚本开发方法

总结起来看，对于开发的成本来说，随着脚本编写方法从线性到关键字驱动的改变而不断地增加；对于维护的成本来说，随着脚本编写方法从线性到关键字驱动的改变而在降低。对于编程技能要求来说，随着脚本编写方法从线性到关键字驱动的改变，对一个测试员的编程熟练程度的要求在增加。对于设计和管理的需要来说，随着脚本编写方法从线性到关键字驱动的改变，设计和管理自动化测试项目的要求在增加。

因此，应该合理地选择自动化测试脚本开发方法，在适当的时候、适当的地方使用适当的脚本开发方法。

2.4 实用性自动化测试策略

自动化测试永远是测试人员心中的痛。一方面，测试人员在长期的手工测试中已经不胜其烦，梦想着使用测试工具轻松地实现自动化测试；另一方面，一旦尝试了自动化测试，又会发现有太多的阻碍，这些阻碍来自工具、管理和人。

2.4.1 自动化测试工具的问题

首先碰到的问题是测试工具的问题，现在很多商业上的工具都存在这样或那样的问题。大部分会有这些缺点：

厂商脚本语言

大部分商业测试工具会指定某种语言，例如：WinRunner（TSL），SilkTest （4test），Robot（Test Basic），但是，一些新的工具也开始使用标准语言，例如：QTP（VB Script），XDE Tester（Java）。

所以，在选择测试工具时要考虑这点。最好选择支持标准语言的测试工具，而且，尽量与所在项目组的开发人员所使用并熟悉的语言一致。这样可以充分利用现有的编程知识和语言知识，而不需要花时间去熟悉厂商特定的语言（这些语言只能在这个工具能用上）。并且可以借助开发人员丰富的开发知识来协助进行测试脚本的设计和编写。

对新平台、个性化控件的支持不够好

大部分商业测试工具没能很好地支持新的平台和很多的第三方控件、个性化控件。例如，新的.NET版本、操作系统，以及普遍使用的第三方控件，如Component One、Infragistics、Janus等。

如果项目中使用这些较新的平台或大量使用这些第三方控件的话，就要小心选择测试工具了，否则会导致后面的脚本编写难度加大。建议在选用之前，充分评估并在项目的应用程序上试用。

与源代码控制的结合不好

很多工具没有与源代码控制工具集成，使用临时文件和目录（WinRunner），有些则把信息存储在外部的库中，例如Rational。

源代码控制对于测试脚本的管理非常重要，除非希望每个测试员使用自己的一套脚本，或者通过原始的拷贝方式来进行共享和管理。

在选用工具时，还会碰到选择商业工具还是开源工具的问题。在这里，同样需要考虑项目的上下文，还有成本问题。目前，开源社区的测试工具大部分是单元测试工具，成熟的自动化测试工具还不多，如果选用这些工具的话，需要考虑维护和修改调整工具的成本。

2.4.2 自动化测试的管理规范

当兴冲冲地拿到测试工具准备大展拳脚时，先停一停，考虑一下自动化测试如何开展。首先，对测试人员的培训是必不可少的，培训需要包括工具的内部培训、脚本语言的培训、自动化测试规范的培训。

选用开源的测试工具一般不会有培训课程，即使是购买的测试工具也未必会附带培训课程。所以对于工具的内部培训，一般可由前期负责工具选型和试用的人员进行内部培训。熟悉工具附带的帮助文档和Sample文件会对工具的学习，还有脚本语言的学习有很大的帮助。

培训还包括制定出自动化测试规范，并对参与测试的人员进行培训。规范可以从以下几方面进行制定：

（1）测试用例的选择

并不是所有测试用例都能用自动化的方式执行，自动化测试适合在机械化的执行和比较中使用，让一个自动化测试对用户界面规范性进行检查，那是“不可能完成的任务”。另外，还要注意测试用例自动化实现的顺序，优先实现简单的、主体的，例如，按以下顺序来实现测试用例自动化：

遍历所有界面的冒烟测试→测试用例中的主成功场景→扩展场景、扩展流程→……

（2）脚本命名规范、注释规范

为了让测试脚本的维护性、可读性更强，应该制定出命名规范和注释规范。例如，要求在每个脚本函数前面注明测试目的，简要的测试过程描述等；对脚本中的主要步骤、复杂代码进行注释。

（3）对公用测试数据的维护

如果测试涉及的数据在不同测试人员编写的很多脚本都要使用到，则应该制定出相应的数据维护规范，例如，要求测试脚本对数据的操作要考虑数据的备份和恢复等问题。

另外，还要考虑自动化脚本编写方法，不同的脚本编写方法对脚本的可维护性、开发成本的影响程度不一样，对测试员的编程技能要求程度也不一样。

2.4.3 自动化测试中人的因素

在进行自动化测试时，除了要做好准备，制定好规范和策略外，还少不了对人的管理，项目整体管理流程的配合。

（1）测试人员有时候会不知不觉地陷在测试脚本的编写中，没有很好地评估测试的时间要求，没有选择合适的测试脚本编写方法。这其实也是阻碍自动化测试成功进行的因素之一。

例如，对一些测试工具支持不是很好的控件，有时候会出现无法识别的问题，这时候不要花太多的时间去研究为什么不能识别，或尝试其他很多识别的办法，而是先用最简单的方法解决，即使方法看起来比较老土，例如，很多无法识别的控件都可以通过键盘操作、TAB键定位等方式解决。

（2）造成自动化测试艰难进行的问题，很可能是软件的可测试性问题，也就是说，软件提供的可测试性接口不够强大，或者是在设计时没有很好地考虑可测试性问题，而这些都是开发人员可以为自动化测试提供的，可以让开发人员提供对软件的编程接口、Hook、更换一个等同效果但是测试工具可以识别的控件等。

（3）配置管理。项目的配置管理没有做好也可能会影响到自动化测试。有些开发人员喜欢时不时调整一下自己的代码，重构一下设计，如果这些方面没有控制好的话，可能造成自动化测试的脚本大面积作废和修改，虽然在开发方面看来这些重构和调整是那么的轻而易举和微小。例如，对控件的命名的更改就可能导致大部分操作这些控件的测试脚本的修改。

因此，软件的配置管理工作，对被测试系统的源代码控制有时候可能成为自动化测试成功的关键。应该确保被测系统的更改得到评审和通知，评审要把对自动化测试的影响纳入考虑范围。