自动化软件测试前期准备工作
在项目启动阶段，我们就可以开始一些自动化测试准备工作了，主要包括一下几点：[*] 编写自动化测试用例
[*]封装第三方控件、自定义控件的测试方法
[*]制定测试脚本规范
[*]系统平台
[*] 测试范围
[*] 项目的开发语言
[*] 项目的需求
一、选择合适的项目实施自动化测试在实施自动化的时候，往往会进入一个误区：进度紧、测试资源不够的情况下，可以通过自动化测试来减轻测试人员手工测试的负担，以便更快的完成测试任务。然而，自动化测试与开发一样，都需要投入足够的资源和时间进行自动化的计划、设计、脚本调试开发等。因此，在使用自动化测试的项目选择上，需要选择一个进度不紧，测试人员相充裕的测试项目来实施自动化测试。尤其是初次尝试自动化测试的项目组而言，自动化测试的成功率会高很多。自动化测试需要多次运行后，才会体现出自动化的优势。脚本需要不断更新，才能有效的预防问题的产生、减少测试人员手工回归测试的工作量。若是一个短期项目或为一次性的项目，不建议使用自动化测试。因为这种项目得不到自动化测试应有的效果和价值体现。（按阶段划分，按照项目类型划分等多方面）二、选择恰当的测试用例实现自动化在实现自动化测试的前期有一点需要特别关注：选择恰当的用例来实现自动化测试。大部分自动化项目的失败的原因主要归根于被测试应用程序的快速变化、选择不恰当的测试用例、不完善的测试框架以及脚本的编写问题等。在做自动化测试时，需要分阶段逐步进行，不能局限在某一个阶段完成自动化测试，所以自动化测试应从选择重要的、恰当的测试用例开始，慢慢向其他方面扩展，这样会带来较低的维护成本，能实现更重要的业务价值。那么，我们选择什么样的测试用例才能叫做恰当呢？通常需要结合手工测试用例复杂度的评估以及功能重要性来设计自动化测试用例以及确定测试用例的个数。首先，我们参考手工测试用例优先级的划分把自动化测试用例分为：简单、中等、复杂三大类。然后，从这三大类的测试用例中选取一定的比例来选取需要的自动化测试用例。自动化测试用例的复杂度分组可通过综合分析测试用例包含的操作步骤，以及该测试用例包含的检查点个数来划分。分类方式可参考图2.1 图2.1 测试用例复杂度分类从表中可以看出：1）若用例中包含的操作步骤少于5，检查点个数也少于5，则判定为简单测试用例，对于此类用例，脚本的录制及调试相对于比较简单，可适当的多选择一些实现自动化。2）若用例中包含的操作步骤在5~15间，检查点格式也5~15个，则判定为中等测试用例，对于此类用例，脚本的录制及调试过程稍复杂，可少选择一些实现自动化。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（TestBasic）等这些制定某种语言的工具一般都是商业测试工具，也有一些测试工具使用标准语言：QTP（VBScript）、LoadRunner（C）等。所以我们在选择自动化测试工具的时候，最好选择标准语言，而且尽量与项目组的开发人员所使用的语言一致（项目使用VB开发，自动化测试工具建议使用QTP），这样的话可以充分利用现有的编程知识和语言知识，而且不需要花费大量的时间去了解开发商所制定的脚本语言（一些语言只有在该脚本上才能使用）。若脚本的语言与开发人员所使用语言一致的话，在遇到问题的时候可以请开发来协助我们完成脚本的编写和调试工作。并且一些商业测试工具不能良好的支持新型平台和第三方空间以及个性化控件。这样的话，会导致录制完成后对脚本的编写和调试有很大的难度。所以我们在选择测试工具的问题上需要慎重考虑。 总体来说，我们在选择自动化测试工具的问题上，需要考虑以下几个方面的因素来决定：
[*] 对不同类型的应用程序和平台的支持；
[*]对不同类型的操作系统的支持；
[*]对不同的测试类型的支持；
[*]脚本语言、编辑器和调试器；
[*] 录制测试脚本的能力；
[*] 应对变化的能力；
[*] 对控件和对象的支持；
[*] 支持不同渠道的测试数据；
[*] 运行测试与测试对象的同步；
[*] 检查点；测试结果记录和导出报告；
[*] 扩展性；
[*] 测试多语言应用程序的能力；
[*] 对团队协作和源代码的管理支持；
[*] 对命令行和OLE自动化的支持；
[*] 技术支持等
一般，我们用的比较多的还是QTP（HPQuickTestProfessionalsoftware）是HP公司的一款自动化测试工具。该工具支持多种平台，包括Windows、Web、.Net、VisualBasic、ActiveX、Java、SAP、Siebel、Oracle、PeopleSoft和终端模拟器等。QTP脚本语言为VisualBasicScript。 五、自动化测试脚本开发规范 在自动化测试的前期准备阶段，除了计划好时间、人员、工具外，还需要进一步确定自动化测试脚本的开发的相关规范。 1）测试工具使用规范。 在整个自动化测试范围内制定相应的规范，包括统一工具、统一工具的版本、统一脚本的开发语言、统一脚本注释方法等。 2）脚本注释规范。 高质量的测试脚本可以让测试脚本的后期维护工作量较少，让代码的可读性增加，从而有利于测试人员之间进行基于测试脚本的交流。测试脚本的规范编写有利于后期的维护。 一般，脚本的注释都应包含一下的成分：
[*] 脚本头信息；
[*]引用文件的信息；
[*] 变量和函数声明的部分；
[*] 脚本主体；
[*] 声明函数的实现部分；
3）测试对象命名原则。 使用过QTP的人都应该知道，QTP拥有强大的对象库，给我们的脚本调试工作带来了很多便利，但是对象库的对象命名是根据控件的属性随机命名的，这样在后期对代码进行维护的时候，不容易理解。所以我们要有一个对象命名的原则，把对象名描述成一个可读性强的词组。 在脚本开始的时候，放一个脚本头注释信息对于以后维护脚本会起到非常好的效果： 4）脚本编写原则。 使用一致的代码编写规范的目的是提供标准化的代码结构和代码风格，让所有参与代码编写的人员都能够很容易地阅读代码、理解代码。使用代码规范可以让代码保持清晰、严谨、可读、易懂。 “低耦合，高类聚”一个脚本（Action）建议只包含一个功能模块的测试脚本，不可把多个功能模块的脚本放倒一个脚本文件（Action）中，对于流程测试的脚本，可以从每个包含功能模块的测试脚本的文件中调用。 六、自动化测试计划文档 对于一个严谨的自动化测试项目而言，制定一份完整的自动化测试计划是必不可少的，尤其对于大型的自动化测试项目，下面给出一份自动化测试项目计划模版目录仅供参考：目录6.1 http://www.uml.org.cn/Test/images/2012040945.png
哦~还有此等操作
页:
[1]
