软件质量传道士——Anand Bagmar是一名具有丰富实际经验并以结果为导向的软件质量传道士，他在IT领域拥有超过17年的经验，其中有超过14年专注于测试领域。他热衷于交付一个高质量的产品，同时致力于自动化测试工具、架构和框架。Anand撰写测试相关的博客文章并开发了软件测试相关的开源工具——WAAT (Web Analytics Automation Testing Framework), TaaS (for automating the integration testing in disparate systems) 和 TTA(Test Trend Analyzer).

起源

敏捷方法论始于2001年。随着越来越多的团队开始理解到更多敏捷宣言之外的内容，他们也开始识别出真正敏捷所必需的不同实践。

测试自动化是团队在工作中做好敏捷的一个必要的实践。测试自动化看似简单，但实际上为了让它真正地具有实效，团队不仅需要在流程中遵守很多规则，而且需要选择既能提供快速反馈又能满足测试自动化扩展的合适工具和技术。

必须要说的是，即使到现在，在同一个迭代中，伴随开发工作完成全面的自动化测试，对很多团队来说都是一个巨大的挑战。如果测试自动化采用了那些难以适应被测产品快速改变的工具和技术，这种无力感就更强烈了。

2004年Jason Huggins在ThoughtWorks测试一个内部应用时，创建了一个JavaScript的测试工具；而这个工具改变了浏览器（基于浏览器的测试）自动化测试的方法。这个工具后来慢慢进化成开源的“Selenium”。如果感兴趣，可以参考“Selenium历史”了解更多的演变历史。

不光以前，现在依然有很多非开源的、商业的测试工具和产品，而这些工具的卖点都是在难以说明的复杂过程中自动地做自动化测试。很遗憾，想要使用这些工具和产品都需要付出非常高的授权使用费。

这样导致的结果就是，各种机构和团队为了控制成本，只允许一小部分人来使用，来限制这些产品的大规模使用。而这就进一步导致了团队间的隔离。

开源的Selenium挑战了这种工作方式，并且打破了团队间的藩篱。

所有知道如何编程的团队成员（QA，开发人员以及其他成员）现在都能为搭建和运行自动化测试贡献自己的力量，而不需要考虑授权的费用。

更重要的是，开发人员和QA现在能对测试实现有同样的认知，从而减少了做出错误假设的可能。

现在距离Selenium推出已经有十年了，这十年之间发生了很多事。在技术领域中，基于测试的工具和技术发生的变化更多。而Selenium不仅仅存活下来，，而且随着时间变大变强，这实属不易。

如果把Selenium比作一瓶酒，十年时间足够让它变成一瓶陈年佳酿吗？

Selenium目前在业界的声誉：

• 现如今，对于做基于浏览器的测试的人来说，不了解或者说没听说过Selenium是相当罕见的了。
• 目前有许多其他用不同语言实现的框架都是基于Selenium的，这为测试自动化提供了更多的可能。
• 有许多具有创新力的公司都基于Selenium开发了不同的产品，为它们的客户提供了更多的价值，比如说SauceLabs和BrowserStack等。
• 全球的服务型组织都会对潜在客户的进行管理层面的对话或者提供基于Selenium的服务。
• 近年来涌现出大量组织来销售基于Selenium自动化的测试服务。
• Selenium是求职的热门搜素技能之一（关于测试自动化）
• Selenium团队也在努力快速地推出更多的功能，并且尽量标准化对浏览器和移动浏览器的自动化支持。

为什么Selenium如此流行呢？

所以，到底为什么Selenium已经存在了10年但还能越来越强大和流行呢？其实，原因很多，最重要的原因是——它就是简单有效，它能够实现API所宣称的能力。

它是开源的——所以你可以深入了解它的工作原理，如果有需要的话，社区的每个人都能力去改进它。而你不需要成为同类产品“白金级”用户，就可以接触到它的核心工作原理。

社区支持很强大。如果Selenium核心贡献者不能及时回答提问，社区里还有大量的专家可以提供支持。

很可能有人也遇到过类似的问题，所以思路／建议／变通的方法就有很多。除此之外，功能修复一般都很快。

它是免费的——所以只需要拥有良好的编程语言专业知识，不需要在工具上破费。

由于敏捷的广泛发展，基于Selenium的自动化满足了大多数团队对于测试自动化的需求。

Selenium是测试自动化的银弹吗？

和其他工具和技术一样，你需要在正确的场景下使用Selenium。要不然，你不仅会渐渐失去工作的价值，而且会面对更多的挑战。

随着敏捷方法论不断成为主流，对更好更快的测试自动化的需求也变得很明显。

其他原因之中有一条，Selenium IDE可以更好地让不了解Selenium具体如何工作的人，通过使用录制得到脚本和浏览器进行交互。可是，和其他录制的工具一样，你得保证录制的脚本在所有情况下都工作，而且你要能够智能地使用不同类型的数据（有需要的话），处理等待和超时。

遗憾的是，不少使用Selenium IDE来录制脚本的人开始自称Selenium专家。

基于Selenium的自动化看似是所有自动化测试问题的正确的解决方案。它开始成为自动化的银弹。可是，世界上并没有这样的银弹。我们忽略了测试金字塔有多层，每层代表的一种类型的测试都是待测产品有必要的。

这是理想的测试金字塔看起来的样子：

对于基于Selenium（也包括其他UI自动化测试工具）的测试，要聚焦于金字塔的顶部，而不是试图覆盖整个金字塔的各个层级。这也正是这类测试的真正价值所在。

通常，那些对于测试自动化框架应该如何构建完全没有概念，或者只有有限概念的人，成为了测试自动化的主管和测试架构师。更加糟糕的是，层层传递的压力和数量导向的测试以及测试自动化，导致只是快速地添加自动化测试，而并没有审慎地思考和规范的实践。

所以很快地，理想化测试金字塔变成了下述的反模式之一：

结果就是这颗银弹变成了一颗致命的子弹，导致团队对于自动化、自动化的结果和团队的成员都丧失了信心。

很多团队的情况都是：虽然有无数的基于Selenium的自动化测试，并且团队的绝大多数时间都耗费在维护和修复测试上，而且还会有专门的团队针对产品执行手动的回归测试。这无疑是一种双输的局面，但是却是非常真实和常见的现象。从而导致了团队中成员的相互指责。

至为重要的一点是，我们要构建鲜活的、并能随着被测产品用户案例不断进化的自动化测试框架 。自动化测试框架必须要可维护和可扩展，这是作为测试企业级产品的不言而喻的需求之一。同时，识别那些可以通过浏览器实现自动化的测试也是非常重要的。

那么，接下来会发生什么？对你来说意味着什么呢？

测试的未来非常有前景。每一分钟，我们都面临着设备过剩和技术发展；而对于那些没有走上学习和适应科学和技术趋势之路的人来说，这是非常可怕。

以下是一些可以让你沿着这种趋势前行的想法：

• QA的职责变得更加复杂，并且需要思维和技术纪律的转换
• 参与和理解产品架构，并且对其作出贡献；这有助于理解需要测试什么，需要在测试金字塔的哪一层级实现自动化以及为什么要这么做。
• 了解测试自动化是软件开发的一种形式。精通开发实践的同时，应用测试技巧会帮助你做好测试自动化。
• 网页测试主导了过去十年测试的发展，现在的QA不仅必须了解如何自动化地测试网页，还必须了解如何自动化地测试移动和交互性的应用。
• 行为驱动测试（Behavior-Driven Testing，BDT）作为一种可以识别并构建有效的回归测试用例集的方法，可以帮助规避我们之前提到的那些反模式