一、说明

　　该文档详细的介绍了有效地执行一个自动化测试指南。自动化测试是公认的增强应用程序可靠性的有效成本方式，同时减少了时间和软件质量计划的成本。 在过去，大部分软件测试都是使用手工方式来执行测试的。由于今天先进应用软件的规模和复杂性，在众多测试情况中，手工测试不再是一种可行选择。
         而进行自动化测试的通常原因有： 节省测试时间 由于测试是一个重复性很强的工作，自动化测试过程则是用机器来完成这单调乏味的重复性操作，而人们就可以去执行其它的工作。一个自动化测试以机器的速度在测试等级中执行着下一个操作，以比最快的个人还要快的速度来多次重复地完成测试。并 且很多测试类型，比如负载/压力测试，手工执行实际上是不可能的。

 节省测试成本
    当与自动化测试方法比较，执行手工测试的成本是过高的，但是负载/压力测试则有必要比较一下，因为自动化测试是唯一的解决方法，比较起需要被安排n个测试人员和n台计算机的手工测试，自动化测试能简单的做到用单台电脑同时模拟n个用户，想象一下，如果是负载的手工测试，则不得不由1000人来执行阿! 跨平台的移植测试 自动化允许测试组织来执行一致的和重复性的测试，当应用程序需要配置在不同的软硬件环境中的时候，标准化或基准测试就能被创建并重复在目标平台上来执行，保证在新平台上操作的一致性。 重复性和控制` 通过使用自动化测试技术，测试员有了更高程度的控制：哪些测试类型正在被执行，和这些测试将被怎么执行。使用自动化测试增强了过程的一致性，允许开发人员对各种应用程序修改影响的评审如同不同用户行为的影响一样。

　　例如，自动化测试能建立在从外部文件或者应用程序中提取的有效数据然后作为一个输入数据运行测试。最重要的，自动化测试能执行多次必要的测试而不须要求用户每次都重新创建测试脚本来运行。 更大的应用覆盖面 提高生产力的自动化测试允许和鼓励更经常和更彻底地组织测试。更广泛的应用测试覆盖率也能减少暴露在用户面前的故障和不符合规定软件的风险。在一些行业领域如医疗和药品，严格遵从质量规则的要求来组织和证明他们的系统所有部分的质量保证工作。
 
    结果报告 全功能自动化测试系统还有方便的测试报告和分析。这些报告证明了测试状态和结果的标准化措施，因此允许更准确的测试结果解释。而手工测试方法则要求测试人员自我归档测试过程和测试结果。

三、任务
1．什么需要选择自动化
大部分，不是所有的，测试类型都能自动化。像用户所理解的测试的某些测试类型，这些测试只须运行一遍，并且这些测试要求人们不断的介入，因此通常不值得投资自动化。下面举例说明了能被用来识别使用基本的候选自动化测试的标准。
 
    高频率路径 – 自动化测试能被用来查证当一个软件正在全面投产运行时使用高频率程度的应用程序路径的执行。例子有：创建客户记录，货品计价和其它软件故障发生频率比较高的高容量活动。

    关键业务流程 – 许多情况中，软件应用能正确的定义或者控制公司的核心业务。如果程序应用失败，整个公司将面临在关键操作上的极端混乱。

关键任务
       流程是自动化测试的主要候选者。比如包括：月底的财政结束核算，生产计划，销售订单输入和其它的核心业务。任何联系着的高程度风险失效的程序应用都是测试自动化的非常好的候选者。

       重复性测试 – 如果一段测试指令能被重复使用多次，那么它也是自动化的一个基本的候选者。例如，共同的概要文件能被创建来建立测试会话，关闭测试会话并应用测试值。这些自动化模块能一次又一次的使用而不需要重新建立脚本。当比较那些每个测试每次都创建一个新的端到端的脚本时，这种模块化的方法节省了时间和金钱。

长时间的持续应用 – 如果一个应用程序被计划在一个生产周期中很长一段时间，更大的受益的是来自自动化。

2．测试工具的评价
    选择一个软件测试的自动化工具是一个很重要的步骤，而这往往造成了整个企业的影响。当选择一个应用测试解决方案的时候，有几个关键问题应该被定位。
 
    测试计划和管理 一个强健的测试工具应该有能力来管理测试过程，提供为测试组件组织，还有创建有意义的终端用户和管理报告。它还应该允许用户包含在自动化测试计划和测试结果中的非自动化测试过程。一个强健的工具是会允许用户来集成已存在的测试结果到一个自动化测试计划中的。最后，一个自动化测试应该能将业务需求链接到测试结果中，基于应用程序支持业务需求的能力，用户可以随时申请评估应用程序。
 
    测试产品整合 测试工具应该提供紧密的集成模块以用来支持测试组件的复用性。为功能测试执行建立的测试组件应该也能支持其它类型的测试，包括回归测试和负载/压力测试。在测试产品环境中的所有产品应该基于在一个通用，易于理解的语言上。用户培训和在执行一个测试任务去中取得的经验应该也可以转换到其他测试任务上。并且，测试工具环境的结构应该支持与其它技术的交互开放，比如缺陷或者错误跟踪软件包。


    国际互连网/局域网测试 一个好的工具是有能力对web浏览器测试范围的支持的。为以国际互连网和局域网为基础的应用程序创建的测试应该是可移动在跨浏览器上的，应能为不同的加载时间和性能水平来自动调整。
 
    易用性 测试工具应该要设计成能被非编程人士和应用终端用户使用。从开发人员转移到部门的大部分测试责任，一个要求编程技能的测试工具是不会被大部分组织使用的。即使程序员也负责测试，测试工具本身应该有一个短期的学习曲线。
 
    界面和C/S测试 一个强壮的测试工具应该支持不同的用户接口、创建简单的管理、易于修改的测试。测试组件的复用应该是产品结构的基石。 负载测试和性能测试 选定的测试解决方案应该让用户执行有意义的负载测试和性能测试以精确的衡量测试性能。它也应该用一个易于理解的报告格式来提供测试结果。
 
    方法和服务 对于那些需要外部专业技术的情况，测试工具供应商应该提供广泛的咨询、实现、培训和评估服务。测试工具应该也支持结构化的测试方法。 注意：对于评估各种工具的共同参数，参见“测试工具评估和选择报告”模板。

3．脚本计划和设计
     认真的计划是任何过程成功的关键。对测试自动化的评价应该考虑到基本的计划步骤，才能从一个自动化测试过程中保证非常好的可能的结果。将时间投资到有意义的详细计划上能增进测试自动化所带来的好处。 业务需求的评估 通过在终端用户的实际业务活动的条件下精确定义你的应用软件应该完成的任务，再来开始自动化测试过程。这些任务的定义，或者业务需求，界定了高级别，软件系统的功能需求问题。这些业务需求应该要定义的足够清楚以致软件系统能正确的（或者错误的）执行必需的业务功能。比如，企业要求的薪金应用程序可能要能计算工资或者打印工资支票。

脚本计划和设计
     这是自动化周期里最重要的阶段。脚本计划基本上确定了测试结构。在这个阶段所有的模块都被确立。各模块用来导航、操作控制、数据输入、数据验证、错误识别、并进行书面记录。由命令、逻辑、数据组成的复用性模块。通用模块使用贯穿测试系统，比如初始化和功能设置，一般在文件中分组并命名来反映他们的主要功能，如“初始化”和“设置”，另一些具体的应用，如在客户窗口上设计的服务控制，分组在一起并命名相似。所有确定的功能/模块/库/脚本都按照标准命名规定来命名。测试数据计划也是在这个阶段做。

4．测试环境设置
    测试环境设置由访问自动化测试连接的建立、测试自动化工具、测试库、配置管理工具的建立、机器的识别来创建和运行测试、浏览器的安装、缺陷管理工具的配置等组成。 开发库 所有通用功能都能被开发和测试来促进可重复性和可维护性。

5．脚本的开发
    事实上脚本是要开发和测试的。 开发测试套件 集成的脚本和库所形成测试套件能以最少的用户介入独立运行。
6．部署/测试套件
    不同的机器配置上运行不同的测试套件。用缺陷跟踪工具来报告和跟踪缺陷。如果回归测试需要的话这些套件还要再次的运行。
7．测试套件的维护
    如果应用程序后面的发布有变更的话，功能上的这些变更要验证并且相似的分析测试套件同样也要做得达到所要求的变更。在变更影响后，测试脚本基线和适当版本的脚本也要得到相应的修改。

8．测试自动化方法
    



 

四、附加指南
1．自动化之前的考虑重要因素
    范围 －将所有的东西都自动化是不切实际的，通常也没有可利用的时间。要非常仔细的检查应用程序的功能和区域才能运用自动化。
    时间框架的准备 －准备自动化测试脚本的时间是必须要考虑到的。通常，自动化测试脚本的准备时间是手动测试的2/3倍。事实上，碰巧是最初的工具实际上会增加测试的范围。这就是因此管理期望的重要性。一个自动化工具不能代替手工测试，也不能代替测试工程师。开始的时候，测试工作将增加，但是当自动化使用正确得当的话，它是会大大的减少后面的发布时间的。

投资回报率 －因为自动化测试的准备时间过长，我听说测试自动化的受益仅只有在第三次测试开始运行的时候才产生。

什么时候开始受益？明智地选择你的对象，并且认真思考关于什么时候及在哪个阶段才开始受益。如果你的应用程序定期的有着较大的变化，放弃自动化测试－因为你将花费大把的时间来更新你的脚本而你将不会得到多的受益。【然而，如果只有应用程序的不通用部分改变了，或者这个改变较小－或者有一个具体的部分是不会改变的，那么你还是可以成功地利用自动化测试】记住，你可能只有在应用程序将要发布的时候才能做一个完整的自动化测试运行。－比如，接近完全的测试！！如果你的应用程序是非常错误的，然后这个可能性还是你还不能完全的运行一个完整的自动化测试套件－归咎于遇到了失败的功能。

变更的程度 －自动化测试非常好的的使用地方就是做回归测试，那样你使用自动化测试能确保之前存在的功能（例如：版本1.0里面的功能－即这个发布中没有新的功能）不受在版本1.1引入的某些改变的影响。并且，因为适当的自动化测试计划要求设计好的测试脚本要对于一个简单的GUI改变不会完全的无效。（比如重命名或者删除一个特定的控制），你需要考虑到更新脚本的时间和工作量。举个例子，如果你的应用程序有了意义上的改变，版本1.0的脚本在版本1.1中可能就要完全重新编写，并且这些涉及的工作可能就是成本过高的，至少没有被考虑进去！然而，如果只有无联系的应用程序部分改变了，或者改变很小，你才能成功的利用自动化测试来回归这些区域。

测试的完整性 －你怎么衡量一个测试是否测试成功或失败？仅是因为工具返回一个“Pass”是不能决定测试本身就是“Passed”。例如，仅是因为没有错误信息的出现是不能代表脚本下一步是能成功完成的。这需要考虑到具体测试脚本的fail/pass标准。

    测试独立性 －必须建立测试的独立性可以避免在第一个测试用例中的错误而导致该测试组件中余下的测试脚本产生多米诺骨牌效应或者被阻止，或引起失败。然而，事实上，这是很难达到的。

    实际测试脚本本身的调试或“测试”－时间必须允许这一点，并且要证明测试本身的完整性。
    录制和回放 －不要依赖录制和回放作为生成脚本的唯一方式。这种想法是伟大的。你手动的执行测试而测试工具是位于后台记住你所操作的，然后生成你能运行重复执行测试的脚本。不依赖录制和回放是一个伟大的想法－却很少能有效（并且证明也非常有限）。

    脚本的维护 －最终，对于自动化测试脚本的维护有着高昂的维护费用－它们不得不不断的更新，因为一个应用程序有了太多的变更需要对测试脚本进行修改，否则你将最终放弃数百小时的工作。结果，测试脚本的文档的更新也是很重要的。

2．推荐的测试工具
    

五、常见陷阱
? 各种工具在整个开发生命周期的使用并不容易整合。
? 更多的时间都是花在自动化的测试脚本而不是实际的测试。首先决定哪些测试应该被自动化哪些不适合自动化是非常重要的。
? 测试团队里的每个人都尝试自动化脚本。最好是分配测试脚本的生成给那些有开发背景的人，这样手工测试人员能集中在其它的测试方面。
? 详尽的测试脚本正在开发，重复着开发的工作。
? 测试工具的 培训在过程的后期才给予，而导致测试工程师缺乏工具方面的知识。
? 测试人员抵制工具。有个工具使用高手是很重要的，这样他能在早期阶段提倡利用工具的特点来测试而避免抵制。
? 自动化测试的预期投资回报是很高的。当一个测试工具被引入，但如果自动化使用正确时测试范围的初始化会变得很大，而它将在后期的发布中慢慢减少。
? 要意识到第三方的控件工具是有问题的。
? 缺乏测试开发指南。
? 随着所需的数据产生的报告绝不要积累在工具里，这些由工具生成积累的报告对后面的数据是没有用的。
? 工具的选择和购买之前系统工程环境需要得到定义。
? 不同工具版本在使用时，会导致在一个工具中创建的脚本不能在另一个版本里运行。阻止这个发生的一个办法是确保工具升级是由配置管理团队集中管理的。
? 新工具的升级不兼容现有的系统工程环境。所以要在该项目上在新工具推出之前首先做一个beta 测试。
? 工具的数据库不支持扩展性。所以最好选择工具之前要确定它有一个能扩展的强健的数据库。同时，恢复测试数据是非常重要的。
? 不正确的使用测试工具的管理功能只会导致浪费时间。

六、参考文献
? Test Strategy Guidelines