自动化测试框架

自动化测试框架

 

 

# 翻译: will

# 2010-1-14

# 水平有限，见谅

 

“在构建测试策略时，必须将被测应用的变化和测试工具的变化所造成的影响降低到最小。”    --Carl J. Nagle

1.1 思考过去的“项目”

在当今项目周期急剧下降的环境下，自动化测试变得日益重要和关键。假设在过去，测试水平是足够的（这是很少见的），我们怎么能够跟上这一新的网络爆炸性的步伐，使其能够部署，同时降低风险并能保持令人满意的测试覆盖率？答案或者是更多的人参与手工测试，或者是更高水平的自动化测试。毕竟，项目周期的减少会关联到测试时间的减少。

随着快速开发和部署的需要，web客户端的自动化测试变的更加重要。除此之外，更严峻的现实是我们经常会同时面对多个项目。比如说，也许某个团队正在结束Version 1.0的开发，同时为Version 1.1添加必须的新特性，同时正在为Version 2.0准备新技术的原型设计。

更好的是，也许我们的测试团队实际上是测试人员的资源池，支持许多不同的、互不关联的应用程序。如果每一个项目采用唯一的测试策略，那么测试人员在不同项目中的变动，更可能地成为障碍，而不是帮助。在这个新环境中，测试人员成为生产力所需的时间未必存在。并且，使测试人员熟悉新环境直至能够测试，这一过程势必会减损整个团队的测试效率。

为避免混乱，我们必须思考过去的项目。我们不能为每一个和所有的新应用程序设计或重新设计自动化测试框架，这不是我们所负担得起的。我们必须努力开发一个能够根据不同的应用程序或项目而扩展和持续改进的单一框架。在后面的1.2节，将会看到这些不同方法的优缺点。

1.1.1 自动化测试的问题

历史上，自动化测试带来的成功并不符合预期。一次又一次的自动化测试的努力，出生、蹒跚前行、死亡。大多数情况下，“努力和财力必然能够实现一个成功的、持久的自动化测试框架”，这一错误观念导致了以上结果。这是为什么，我们可能会问？那么，有几个原因。

首要原因就是自动化测试工具供应商在展示其工具的”简单性“时，并未提供完全直截了当的演示。我们看到的供应商的示例应用程序，测试工具在这些应用程序上使用的很好。我们试着在我们的应用程序上同样流畅地使用该测试工具。 固有地，一个项目接着一个项目，我们并没有达到同样的成功。

这通常归结为事实，我们的应用程序大多包含与测试工具不兼容的元素。因此，我们必须经常策划技术上的创造性的解决方案，使得测试工具可以用于我们的应用程序。不过，这很少在文献或商品宣传中提及。

商业自动化测试工具已经被主要销售为应用程序的测试方案。他们应当作为企业级自动化测试框架的基石。并且，事实上

1.1.2 测试策略准则

1.1.3 自动化测试是全职工作而非兼职

1.1.4 测试设计和测试框架是完全不同的

1.1.5 测试框架是独立于应用程序的

1.1.6 测试框架必须易于扩展、维护和可持续

1.1.7 测试策略/设计的词汇表是独立于框架的

1.1.8 测试人员易于掌握和使用测试框架

1.2 数据驱动的自动化测试

1.2.1 数据驱动的脚本

1.2.2 关键字或表格驱动的自动化测试

1.2.3 以上结合的自动化测试

1.2.4 商业的关键字驱动的测试框架

1.3 关键字驱动的自动化测试框架模型

1.3.1 项目准则

1.3.2 code and documentation standards

1.3.3 我们的自动化测试框架

1.3.4 The application map

1.3.5 模块功能

1.3.6 Test Tables

1.3.7 the core data driven engine

1.3.8 the surpport libraries

1.4 自动化测试框架的工作流程

1.4.1 High-Level Test Cycle Tables

1.4.2 Intermediate-Level Test Suite Tables

1.4.3 Application Mapping

1.4.4 Low-Level Test Step Tables

1.5 摘要

参考资料