近年来，越来越多的的 Web 端自动化测试都选择过渡到Selenium测试自动化的敏捷组织。毕竟，对于新功能的快速反馈，绝大部分人都不想错过 Web 端自动化测试的机会。虽然趋势如此，一些测试人员仍抱怨自动化测试不稳定且不可靠。造成这些问题的原因有很多，大多数时候，导致测试不稳定的原因是都是没有遵循适合的Selenium测试自动化的正确做法。
尽管编写Selenium测试自动化脚本没有权威的硬性规定，但是可以遵循一些技巧来编写更好的测试脚本。
在本文中将分享其中的Selenium测试自动化最佳实践技巧，这将帮助测试工程师从自动化测试工作中获得最大的价值。
尽早测试并经常测试
Selenium测试自动化的最佳实践之一是尽可能早且经常进行测试。随着组织远离瀑布模型，测试人员必须更多地参与开发过程，这与传统瀑布型开发模式中的软件测试形成对比，因为这对项目的发版周期和成本都具有重大影响。
这引起了左移测试的概念，这意味着从需求收集阶段开始就让测试人员参与其中。这样，他们可以通过了解最终用户的期望提前提出更加合理的测试用例。这里的主要思想是避免开发完成后遇到错误，这样的BUG修复起来代价会更高。测试人员可以提供宝贵的意见，并以改善用户体验的方式帮助开发人员开发更好的产品。另外，可以避免开发人员在软件的开发实中使用不推荐的功能实现以及选择存在风险的工具库。
这就是为什么敏捷测试应该尽快开始自动化测试，并根据需要进行频繁测试的原因。开始测试的时间越早，发现缺陷和发现的问题越早，可以帮助团队节省SDLC（软件开发生命周期）中的时间和资源。
使用 BDD 框架
BDD也就行为驱动开发，是执行Selenium Test Automation时流行的开发模式。BDD使测试人员可以用简单的工具或者语言编写Selenium测试自动化用例，可以使得更多具备基础知识的人都可以理解。这进一步有助于在业务团队和技术团队之间架起一座桥梁，以了解测试项目中实际发生的操作，从而团队协作层面上创造更好的价值。
通过使用BDD编写Selenium测试自动化脚本，测试团队还可以创建统一的规范，这将帮助测试团队以更好的方式理解测试和要求。这可以节省总的测试时间，因为减少向任何利益相关方不必要解释测试。
随着业务团队对测试有更多的了解，他们也能够基于业务功能在线上环境的实际使用情况提供一些宝贵意见。
使用 Selenium 等待 API 代替 Thread.sleep()
由于网络环境、服务器问题或其他各种原因，Web 应用程序经常需要花费一些时间来等待加载。为了解决这个问题，测试团队经常需要暂停脚本执行以等待所有元素加载完成。这是在对它们进行测试时确保所有Web 元素都在其中的好方法。
暂停脚本的一种方法是使用Thread.sleep()函数，它会在指定时间内暂停测试脚本执行。但是此功能存在一个主要缺陷，假设要打开网页，并且选择等待时间为 6 秒，如果网站实际加载得更快，脚本会浪费很多时间
在存在更多不确定的场景中，测试人员可能会浪费大量的额外时间运行Selenium测试自动化，而在较慢的场景中，可能会获得失败的结果。因此，为了避免此类情况，测试人员编写脚本时候需要使用Selenium隐式等待或显式等待替换掉原来的Thread.sleep()。
Selenium 测试自动化报告
Selenium测试自动化经常面临的另外一个问题就是：如何衡量测试结果？如果不跟踪测试的执行情况，就无法确保获得更好的Selenium测试自动化结果。自动化测试报告有助于提高测试结果的可读性，并有助于最小化维护测试数据，减少所花费的时间。在之前的文章中，介绍了Selenium报告的重要性，测试人员还可以了解更多有关如何使用pytest和Junit等工具生成Selenium测试自动化报告的信息。
Selenium测试自动化报告的生成可以为带来巨大的回报，它可以有组织地管理测试数据，从而节省了大量的时间。因此，测试人员可以更好地控制测试进展，因为使用这些数据可以分析测试脚本何时失败以及失败的原因。
使用 PageObject 模型
随着Web 应用程序的UI更改，与之关联的定位器设置也将会随之变化，所有相关测试都可能需要重新编写。针对这个问题有一个很好的解决方案，通过使用PageObject模型，无需一个个更改所有测试脚本。
大多数情况下，测试人员只需更改一次页面对象，因为所有定位器都位于一个中央存储库中。在测试用例中，每个网页都有一个单独的页面类，以在其上查找Web 元素以及这些Web 元素的页面方法。这使项目更加可靠稳定，因为框架开发人员无需扫描所有代码和测试脚本，只需针对变更的UI元素进行一次性修改即可。
自动截屏
运行Selenium测试自动化脚本必定会遇到一些报错、故障，甚至是偶现的问题。在这种情况下，建议通过Selenium Grid收集测试脚本执行的自动屏幕截图。
如果正在使用第三方提供的Selenium Grid运行Selenium测试自动化，则不用对此过多担心。完全可以采取第三方的图像和日志的手机功能来解决上述问题。
提前设计测试
在开始自动化测试之前，提前设计场景和测试方案是一个好习惯。如果没有适当的测试设计，直接进入自动化测试具有很大的风险。这就是为什么要成功完成Selenium测试自动化，必须将测试设计以及策略和计划结合在一起的原因。测试人员需要开发描述测试程序结构以及如何管理测试程序的测试体系结构和软件框架。
在没有适当设计的情况下，自动执行测试用例表明测试人员对于脚本的有效性过于看重。实际上测试用例和测试脚本的可维护性同样重要，对于长期的自动化项目和提高自动化测试质量显得更加重要。毕竟自动化测试通常是一个长期的项目，更加侧重远期的ROI，站在更长期的时间维度编写测试用例更有助于实现Selenium自动化的价值。
不依赖自动化工具
自动化工具是诸如自动化浏览器测试之类的不同测试活动的重要组成部分。但是测试人员应该知道他们并不能解决所有问题。选择合适且正确的工具是切换到自动化浏览器测试框架的重要组成部分，但这仅仅是一个开始。
但是通常情况下，有些管理者会误认为如果选择正确的工具，就可以实现自动化。实际上没有工具可以提供所需的一切。即使它们简化了整个过程，减少了时间，但是如果没有足够多的额外资源投入，仅仅依靠自动化工具是难以发挥Selenium自动化的价值的。
尝试在没有任何人工干预的情况下使用自动化工具时，在识别软件或应用程序上的复杂对象时，它们可能会出现停顿。如果团队又对特殊需求进行优化和改进，就可以使该工具克服复杂的情况，并为公司节省更多的隐性成本。
公众号FunTester首发，原创分享爱好者，腾讯云和掘金社区首页推荐，知乎七级原创作者，欢迎关注、交流，禁止第三方擅自转载。