概要：在短时间的市场化和短期冲刺的文化中，测试人员通过使用测试自动化实践和工具保持同步是至关重要的。本文跟踪从基于脚本的测试与硬编码数据到自动化框架的转变，探索测试自动化的开始和到今天的演变 - 并且可能的未来走向。
今天的软件市场完全以消费者为导向，为了保持相关性，产品必须处于不断的准备发版状态。面对不断变化的消费者品味，你如何确保这一点？
测试自动化发挥了重要作用，使测试人员更多地关注维护测试计划并确保测试覆盖全面。
当我回顾我在软件测试行业的经历时，标注测试自动化过程中的里程碑，从录制和回放的早期到当前的UI对象映射技术是非常有趣的。
记录和播放
录制和回放功能一直是大多数测试自动化工具的主要功能，今天仍然如此。该软件录制手动测试，包括每个鼠标移动，击键和屏幕截图，并方便你稍后回放。它减轻了手动测试的麻烦，特别是当你必须进行回归测试时，但它可能会受到限制。
在我作为测试人员的初期，在加利福尼亚州制药公司测试解决方案的同时，我正在使用一种录制回放工具，节省了时间，因为我能够录制UI操作并重播以便在需要时进行测试。录制和回放当时是一种新技术，我印象深刻。
但随着时间的推移，一些局限性开始浮现。因为测试运行是一个录制的脚本，所以如果遇到突然出现的页面加载失败，它不会被编程终止。所以，它会运行一个错误的UI对象 - 这是测试自动化计划开始失败的地方。
许多录制和播放工具确实提供了调整录制的测试脚本的能力，以便我可以根据以前的测试运行进行必要的更改。然而，可以理解的是，这对于较小的Web应用程序是有效的。当测试被录制时，测试脚本可能变得更长，难以维护，对于更大的应用程序而言更是如此。更不用说，将测试数据硬编码到测试脚本中的录制和回放相当不灵活。
当我转移到企业网络应用程序的项目时，我意识到需要一个可以重新使用自动化测试代码的工具，以便与UI更改保持同步。
数据驱动方法
由于硬编码的测试数据是使用记录和播放工具测试自动化刚性的主要因素，将该数据与代码分离，被认为是更大测试覆盖范围的可行解决方案。这可以通过在代码中使用占位符来实现。你可以添加或删除数据，并且你的测试脚本不会受到影响。这被称为数据驱动方法。
但是，这又不是那么简单。模拟用户操作的行为，同时从源文件中以正确的顺序挑选相关数据，仍然需要在测试脚本中进行定义。这使得代码应用程序特定，因此是刚性的。
更多关注行为和导航上，还需要人工拾取来以便正确顺序执行，它淡化了专注于测试应用程序的功能作为一个整体。测试脚本必须与应用无关。
测试自动化框架应该能够抽取测试代码中的大部分操作和导航。例如，登录页面将有用户操作，例如填写用户名和密码的文本框，导航到登录按钮，然后点击动作。对于大多数应用程序，这些操作非常常规。这些步骤的测试代码可以在自动化框架中维护，即从测试脚本中抽象出来，并在需要时重用。这使得测试代码灵活，轻便，易于维护。它应该允许错误处理，日志记录和系统恢复：即使在测试失败的情况下，也需要测试套件运行完成。
关键字驱动测试
为了开发普遍存在的测试代码，它在测试运行期间填充了可以“指向”相应脚本的关键字。测试数据将被传递到被测试应用程序（AUT），并且操作将按照脚本执行。这允许测试人员通过关键字来确定操作顺序，所以现在他们可以测试整个应用程序的功能。如果你还记得，这是简单的数据驱动方法的主要缺点之一。
尽管如此，测试脚本仍然存在某些不灵活性。测试代码与AUT密切相关。这意味着对AUT的任何更改将意味着对测试脚本的更改，使其维护成为一项繁琐的任务。
包装功能
需要的是另一个层，可以将测试代码从应用程序代码中抽出。这个添加层来自封装函数，它们以特定于AUT的所需顺序放入测试代码中。
包装函数与被替换的应用程序代码中的预先存在的函数不同，因为它们是测试者的工具：它们包括功能的错误检查代码。现在，代替重复调用的函数，每次都会调用它的包装函数，依次使用不同的参数来检查所有可能的路径。
例如，点击操作在不同的网页上使用不同，可能是单击“登录”按钮或“保存”按钮。因此，在常规click（）函数之上使用包装函数将使其可重用，具有不同的Login或Save参数依次传递。
至于可维护性，因为封装函数不是特定实现，它们可以在应用程序中重用。
UI对象映射框架
另一种并发控制包引入的方法是使用UI对象映射。UI元素（如登录页面）被视为对象类，此对象类的标识符存储在对象映射中。
测试脚本显示对象的逻辑名称。因此，当测试框架的自动化引擎读取测试数据（登录和密码）时，它会拾取对象的逻辑名称（例如登录页面），从对象映射中对类标识符进行置零，调用对象类“登录页面”的包装函数，并执行所需的操作。
唯一需要维护的是包装函数，使测试代码保持不变。
这种面向对象的方法允许测试专家定义动作序列，并使他们对测试计划有更多的控制。
展望未来
随着Web应用的出现，需求完全改变。Web应用有两个部分。第一个是使用Web服务的数据集成。有这么多的对象，库，数据源，浏览器，平台和设备 - 更不用说需要连接的互联网路径。另一方面是UI渲染。
在我经历的项目中，我用工具测试用户界面后面的对象，但不是UI的外观和感觉。我插入了几个java库，能让我拍摄屏幕特定区域的屏幕截图，以便我可以将其与相应的UI对象进行比较。
在我看来，就服务器而言，百分之百自动化似乎是一个有吸引力的命题，而且是可行的。但是，对于UI，没有任何东西可以代替人眼来测试它的外观和感觉。这是无法模仿的。手动测试，在这些情况下，是不可替代的。
本文由51ste软件测试部落 ruink 译自 Krishnan Govindarajan 的《The Evolution of Test Automation, from Record and Playback to Object Mapping》一文。