自动化实用模型(上)

    接触自动化，总觉得无法推行，归根结底是自己站的位置太低了，总是一个脚本的编写者去看待问题，无法站在更高的位置上去考虑很多东西，所以做了一些翻译，觉得这篇文章写的不错，只是自己水平有限，不知能否翻译出原文的精髓

原文地址http://www.automated-testing.com/PATfinal.htm

译文：

                    自动化测试的实用模型

摘要

这篇文章的目的就是去探索自动化工具的实用和阐述自动化成功的必要条件，要取得成功，必须记住，有四个相互关联的组成部分，必须共同工作和相互支持1）自动化测试基于一点维护和重用的模块2）测试基本组成的事件，任务和进程，立即支持自动化，以及手工软件测试3）软件测试的生命周期是由许多确定时间点和确定需要取得的成果的阶段构成的4）公司支持可重用的流程，这个部分是作者作为一个资深的测试工程师和测试架构师经过多次的不同的软件开发过程下讨论确定下的

简介

这篇文章的目的是解释怎样成功的实施自动化测试，想要使自动化测试成功，大家必须明白必须很多相关的环节一起正确的工作，每个环节必须互相支持。

这篇文章会阐述锁包含的关键的环节和他们的关系，在这里强调的是哪些是重要的，哪些是有用的，和一些作者在工作中的经验

自动化不是一个孤立的个体，他需要坚实的测试基础设施和全面的软件测试生命周期的支持和重视的企业文化

首先，一个自动化测试系统必须是在支持模块重复利用和一点维护，他必须非常的灵活而且易于更新

测试的一些基础设施包含精细的测试实验，好的bug管理系统，测试用例格式的标准和全面的测试计划

测试的生命周期是当任务和自动化联系是

一个公司可以通过运用自动化测试工具有很大的提升，这些益处主要包括，更高的测试覆盖率，更高的可靠性，缩短测试周期，在没有其他的资源损失下去做更多的多用户测试，重要的是提高完成软件的信心

好消息是，自动化测试所需要的各个组件并不是都需要，这个要根据习惯去决定，哪些是重要的取决于自动化测试和在公司推行自动化测试的理解

自动化的成功是个实用的业务。在这片文章中剩下的问题就是去解决在自动化测试中两个经常遇到的问题

1、怎样才能用快速应用开发环境（Rapid Application Development environment）设计完成一个高效的自动化测试体系接口不停的变换、数据和内容不停地修改和变化

2、为什么很多公司的自动化测试最终都失败了

事件1

第一个问题的解决是利用一个自动化测试系统使用架构原则基于架构的方式创建1）重用的模块和2）一点维护

一个重要的成果就是让自动化测试系统像被测软件一样迅速的，容易的进行改变，从一个公司的角度，这是一个使自动化成功的重要条件

为了简洁这个目标，自动化测试的设计是基于架构原则建立的，这个可以称为PATS

PATS是如何工作的

这一节关注自动化测试系统本身，怎么样去建立一个简单，易用，支持重用模块和一点维护，换句话说，就是PATS

工具的选择

首先需要做工具评估。必须让一个人去使用这个被评估的工具。我的建议是使用两个到三个工具，一个一个的使用，用他们创建简单的和复杂的脚本。基于衡量每个工具的易用性和使用工具重用模块的能力。值得注意的是，每个工具都有他们创建脚本的特性。最重要的一点是不要让工具告诉你怎么去测试。自动化测试策略是独立于工具的，工具是为了支撑和实现测试策略的

一个马匹会带领你去找到水源，如果你让他去，如果你想围着湖转转这当然非常好，如果你想穿越草甸你就不会认为这是个好主意了。这个类似自动化测试工具。利用捕捉-回放手段，你可以找到野生树林-不是你想去的地方。你的自动化测试系统会最终和一个巨大的混乱交织在一起以至难以持续。这是为什么最重要的是测试方法的架构会与测试工具有关。测试工具是客人而不是主人

自动化测试方法

可重用模块

模块的重用用来导航，操纵控制，数据验证，错误识别（软件，硬件），和输出日志。可重用模块基本组成是命令、逻辑，数据，这些必须以归并的方式呈现才有意义。在测试系统中使用通用的模块，比如初始化和安装部分，封装起来命名为体现他主要功能的名字，像“初始化”或者“安装”。其他的更具体的应用，在客户窗口对服务的控制，例如，也封装在一起，并且命名类似

系统架构就是重用的内容被组织起来，经验表明完整的架构是组织主要的重用模块在一个应用窗口，所有的模块被客户窗口调用被组织在一个文件里或者一个library（qtp有这个library）。这样的话，就是客户界面因为任何原因被修改，更新文件只要更新一个地方。这就使在一个地方更新维护成为现实的原则

这个争论的中心是，如果一个控制语句，例如在客户窗口的列表框，非常类似于清单屏幕，为什么不用一个适合两种情况的重用模块？这个应该比想象的要麻烦，而且复杂程度没有办法保证模块的正确。当一个模块越来越复杂，他将越来越难保持，而且会有很大的可能带来一些bug

测试用例

下面一个步骤是把我们的方法从模块转化成自动化测试的用例，在这里，自动化测试工程师有一个架构较好的手工测试用例，去把他变为脚本，创建重用模块。目标是有条不紊的创建一个可重用的模块，行动-响应的测试用例演化为可重用模块的脚本。测试用例一般决定可重用模块的粒度，这个模块包含一个行动-响应。这个对于判定自动化项目的范围和成本来说是比较重要的。一个单独的可重用模块需要一到三个小时去做成脚本和做一些单元测试，自动化测试一般需要二三十个可重用模块

在这种模式下创建的自动化测试用例是一个可预测的结构，一个优点是可以在提早在测试生命周期中开始创建自动化系统

结构化的测试用例格式

结构化的测试用例是一种动态的自动化测试用例，包含了一系列的行动-响应

测试用例举例

测试用例id：客户01

功能：新加一个用户

数据假设：客户数据库已经恢复

概述：

增加一个新的用户通过用户的屏幕，需要确定这个新增加的用户在所有的用户屏幕上显示的都是正确的

优点

1、 易于自动化-所有的都有一样的框架

2、 数据都需要明确的定义

3、 精确的导航

4、 每一步骤的期望结果都很明确-没有需要猜测的结果

可预测的架构

下一步，我们举例说明什么是可预测的架构，所有测试用例的屏幕名字都指向一个包含可重用模块的文件。例如：如果这个应用程序有三十个不同的屏幕，那么测试系统就会有三十个文件名字相同的可重用模块对应于每一个屏幕。通过执行命令去显示特定的屏幕，第一个测试用例的操作是确定屏幕是否通过桌面打开，（屏幕启用和焦点-取决于正在测试的具体内容），这个是通过索引文件调用重用模块，那么，这个确定的新的屏幕就是我们文件的第一个模块。这个可重用模块知道怎样去1）利用多级动态验证方法动态的确定屏幕的文件名，2）如果验证失败指定一个错误级别3）向日志文件里面写错误信息。注：我建议创建两个日志文件，一个详细日志，另一个日志只记录通过/失败信息

下面是一个例子一个索引的客户文件调用可重用文件去判断customer screen是不是正确显示的，这个索引是“VALIDATE”

下面是一个可重用模块的例子1）多级验证动态验证客户屏幕2）包含逻辑制定的错误级别3）向详细日志里面写入两条信息

把文本字符串中的变量存储在constants.cust_txt，支持一点维护的原则，这是一个切合实际的方式存储文本验证字符串所以他们很容易找到并更新

这增强和深化了一点维护的原则，允许很多跨平台测试，增加了可移植性，通过使用通用的屏幕和应用程序变量的方式，这种技术使得自动化测试系统动态的变化界面，这些界面通常需要RAD环境，这使得系统比较灵活而且减少了维护的时间。

这种利用重用模块的框架思想继续在测试用例中使用，结果是可预知的，结构是实用并且好用的自动化测试系统，像一个人用砖去建造房子，建立一个有条不紊表示可重复使用的模块测试功能。在最后的分析阶段，这就是构成了实用的自动测试系统（PATS）

多级验证

多级数据验证增加了测试系统的有用性和灵活性，更多层次的数据验证和评价，则测试系统更加灵活，多级的验证和评价使得测试系统拥有这样的能力1）动态的数据验证在不同的级别和2）从系统消息中收集信息，这样其他人可以在将来评估数据

依照自动化测试工具的动态的数据验证，在控制下取数据，把数据和预期结果进行比较，然后把结果写进日志文件中。测试工具也可以按照输出做出分支的判断。测试工具可以在一个命中混合GET（取数据）和COMPARE（比较），类似LOOK（看）功能，去简化编程

验证涉及到动态的检查数据，评估涉及到系统的消息，在看到结果后才进行评估

在PATS中，动态的数据验证和消息评估可以被分成七种不同的级别和两种比较场景，包含和不包含

在精确的指出自动化测试系统不是一个独立的过程，我们下面将列出自动化测试为什么总是失败的原因