自动化测试的前期准备工作

自动化测试前期准备工作

在项目启动阶段，我们就可以开始一些自动化测试准备工作了，主要包括一下几点：

∙编写自动化测试用例

∙封装第三方控件、自定义控件的测试方法

∙制定测试脚本规范

∙系统平台

∙测试范围

∙项目的开发语言

∙项目的需求

一．选择合适的项目实施自动化测试

在实施自动化的时候，往往会进入一个误区：进度紧、测试资源不够的情况下，可以通过自动化测试来减轻测试人员手工测试的负担，以便更快的完成测试任务。

然而，自动化测试与开发一样，都需要投入足够的资源和时间进行自动化的计划、设计、脚本调试开发等。

因此，在使用自动化测试的项目选择上，需要选择一个进度不紧，测试人员相对充裕的测试项目来实施自动化测试。尤其是初次尝试自动化测试的项目组而言，自动化测试的成功率会有相应的提高。

自动化测试需要多次运行后，才会体现出自动化的优势。脚本需要不断更新，才能有效的预防问题的产生、减少测试人员手工回归测试的工作量。若是一个短期项目或为一次性的项目，不建议使用自动化测试。因为这种项目得不到自动化测试应有的效果和价值体现。（按阶段划分，按照项目类型划分等多方面）

在某个项目资源相对充裕的情况下，做自动化测试的同时，我们也应选择对的时间去实施自动化测试：如项目前期，需求变更较频繁亦或需求不是很稳定的时候就展开自动化测试，这么在维护的时候会浪费更多的时间，同时也无法体现出自动化测试的优势也得不到自动化测试应有的效果和价值体现。若我们把自动化测试放在项目的中后期来做的话，这个时候项目的需求变更不是很大，系统功能相对稳定，这个时间主

要是针对项目初期发现的缺陷进行修正，测试人员的任务也相对轻松，这个时期我们有足够的时间和经历来实施自动化测试以及对脚本进行维护。

二．选择恰当的测试用例实现自动化

在实现自动化测试的前期有一点需要特别关注：选择恰当的用例来实现自动化测试。

大部分自动化项目的失败的原因主要归根于被测试应用程序的快速变化、选择不恰当的测试用例、不完善的测试框架以及脚本的编写问题等。

在做自动化测试时，需要分阶段逐步进行，不能局限在某一个阶段完成自动化测试，所以自动化测试应从选择重要的、恰当的测试用例开始，慢慢向其他方面扩展，这样会带来较低的维护成本，能实现更重要的业务价值。

那么，我们选择什么样的测试用例才能叫做恰当呢？

通常需要结合手工测试用例复杂度的评估以及功能重要性来设计自动化测试用例以及确定测试用例的个数。首先，我们可以参考手工测试用例优先级的划分把自动化测试用例分为：简单、中等、复杂三大类。然后，从这三大类的测试用例中选取一定的比例来选取需要的自动化测试用例。

自动化测试用例的复杂度分组可通过综合分析测试用例包含的操作步骤，以及该测试用例包含的检查点个数来划分。分类方式可参考图2.1。

图2.1 测试用例复杂度分类

从表中可以看出：

1)若用例中包含的操作步骤少于5，检查点个数也少于5，则判定为简单测试用

例，对于此类用例，脚本的录制及调试相对于比较简单，可适当的多选择一些

实现自动化。（如登录、注册、菜单的点击等功能的测试）

2)若用例中包含的操作步骤在5~15间，检查点格式也5~15个，则判定为中等

测试用例，对于此类用例，脚本的录制及调试过程稍复杂，可少选择一些实现

自动化。（如提交数据，或者傻瓜式的Next操作等）

3)若用例中包含的操作步骤大于15，检查点的个数大于15，则判定为复杂测试

用例。对于此类用例，脚本的录制级调试过程相对比较复杂，可更少的选择一

些实现自动化。（在这里，自动化测试只要求做一下回归的功能，以便来确定

系统流程是否可以顺利走通，主要的功能建议大家手工去测试，毕竟自动化测试不可完全替代手工测试）

对于用例个数选择，可根据一定的项目经验以及项目的实际情况进行一个调整。这种通过测试用例复杂度分组来筛选出自动化测试用例的方法比较简单易行，又不失科学性。自动化测试脚本的复杂度，在很大程度上取决于测试用例的复杂度，而测试用例的复杂度又在很大程度上取决于测试步骤和检查点的复杂度。

三．对控件的熟悉程度与自动化成功实施之间的关系

我们拿界面上面的GUI为例，基于GUI层面的测试需要与各种界面元素打交道。对于自动化测试工程师而言，如果能够充分了解不同控件的属性和方法的话，对用户自动化测试的脚本开发会有很大的帮助。如图3.1,这是一个JavaScript的Edit控件

图3.1, JavaScript的Edit控件

对于这个控件，使用普通的测试工具（QTP）录制将得到以下脚本：

我们分析一下录制下来的这个脚本可以发现，它是以控件的Text属性来对控件进行一个Click事件。当我们对控件的Text进行Edit后，界面的Text值就会发生变化，这样的话，QTP在回放的时候就会报错。提示找不到对象。这样的话，脚本的可读性差，并且在回放的时候很容易失败。

熟悉这个控件的人可以通过访问控件的内部属性来打到控制控件的目的，同样的Click操作，在得到适当的处理之后我们得到了如下的脚本：

我们把这种通过内部描述控件属性的方法叫做描述性对象编程，这样书写脚本，使脚本更容易理解，回放的时候不会受Text的变化而影响，精确的定为到控件的位置。

但是需要注意的是，在使用描述性对象编程来写自动化测试脚本的时候，一定要即使的打上注释，否则后期维护起来也会比较麻烦。

四．自动化测试计划

当我们在计划一个自动化测试项目时，必须考虑一下几方面的内容：

1)时间

过早地用自动化测试会带来维护成本的增加。因为在早期的程序界面尚未稳定，项目需求也处于频繁更改的状态，这是进行自动化测试往往得不偿失。

虽然我们说自动化测试不应该在界面尚未稳定的时候开始，但是还是需要制定计划和做一些准备的工作。在界面处于雏形时期，可以基于界面原型提供的控件来尝试自动化测试测试工具的适用性。这时候，就要考虑工具的选择。

在开发人员着手开发一些核心的代码时，可能会同时开发出一个核心可重用的控件，而且属于可自定义类型的控件。这时，我们需要尝试使用自动化工具来抓去并测试这些控件。如果获取不到，可以提供更多的测试接口。

2)人员

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

3)工具

说到工具，首先我们要了解一些常用工具所支持的脚本语言，例如：WinRunner(TSL)、SilkTest(4test)、Robot(Test Basic)等这些制定某种语言的工具一般都是商业测试工具，也有一些测试工具使用标准语言：QTP(VB Script)、LoadRunner (C)等。所以我们在选择自动化测试工具的时候，最好选择标准语言，而且尽量与项目组的开发人员所使用的语言一致（项目使用VB开发，自动化测试工具建议使用QTP），这样的话可以充分利用现有的编程知识和语言知识，而且不需要花费大量的时间去了解开发商所制定的脚本语言（一些语言只有在该脚本上才能使用）。若脚本的语言与开发人员所使用语言一致的话，在遇到问题的时候可以请开发来协助我们完成脚本的编写和调试工作。

并且一些商业测试工具不能良好的支持新型平台和第三方空间以及个性化控件。这样的话，会导致录制完成后对脚本的编写和调试有很大的难度。所以我们在选择测试工具的问题上需要慎重考虑。