最近，我与微软的高级软件工程师KlausHemstitch进行了交谈。过去7年里，Klaus Hemstitch一直在微软的Office 365团队工作。每天他的团队要确保所有的网络组件能在每个主流浏览器上正常工作。我很想知道在构建可扩展且有益的自动化测试时，他们如何解决那些困难的任务。文末分享自动化测试学习笔记
· 您在微软工作多久了？以前在哪里工作？
我从2013年开始在微软工作，之前在奥多比（Adobe）工作了3年。
· 您目前的工作职责是什么？
我们的团队负责Office365中大部分网络组件的功能自动化测试。
· 在这些工作任务中最大的挑战是什么？
最大的挑战无疑是跨浏览器测试。我们要确保一切都是完美无缺的，能在Chrome, Firefox, Safari, Opera, Internet Explorer, Edge和移动浏览器上正常工作。
· 你们为什么还支持IE浏览器？它和原来一样吗？
我们将于2021年8月17日正式停止支持IE浏览器。但这并不意味着我们将停止对它的测试，因为我们应该最先知道它哪里出了问题。很多企业仍在使用IE浏览器，并且会继续使用很多年。许多遗留系统依赖IE浏览器，甚至有些企业不允许员工使用其他浏览器。
· 您如何看待测试用的无头浏览器？
使用无头浏览器无疑是一种糟糕的做法，因为与常规浏览器相比，它在某些情况下的运行往往略有不同。我们一直在安装Windows和Mac的机器和移动设备上使用真正的浏览器。
当收到一份关于产品缺陷的报告时，如果回复说“等等，我先手动检查一下，因为我们的脚本使用的是无头版本的Chrome。”那是很尴尬的。
· 您会使用Selenium还是Playwright？
都不使用。我们会采取不一样的解决方法。如果你在5年前问我，我可能会选择Selenium，但事物总在不断变化。使用Selenium来构建内部测试框架意味着要重造wheel文件，这会使ROI很糟糕。
· 可以告诉我们这个解决方法是什么吗？这是机密吗？
不是机密，我们会使用Endtest。
· 为什么使用Endtest？
一年前我们做了一个全面的分析，内容涵盖了易用性、灵活性、协调性、跨浏览器功能、ROI、可靠性等方面。完成POCs并计算完数据之后，我们就很明确应该使用什么。到目前为止一切都很好。这似乎是目前唯一的解决方案，可以自然地进行跨浏览器测试。
我们可以直接创建测试并在所有浏览器上运行，无需像Selenium一样加入额外的调整。我喜欢它的另一个原因是它可以用来测试电子邮件，短信，PDF文件以及API请求。
· Endtest是无代码工具，这不会降低灵活性吗？
并不会。这可能是21世纪初的旧测试记录仪导致的错误观念。自动化测试需要变量，if语句，循环以及可重用组件等。这些Endtest都有，它和许多脚本语言一样灵活。选择语言或工具时，灵活性固然很重要，但并不是最重要的。如果这是最重要的，那我们现在可能还在写机器代码。
· 你们每天进行多少次测试？
这里我只算功能性测试。它取决于多个因素以及我们有多少个提交，每天至少几千次吧。
· 我们往回聊一聊。你们为什么不使用Playwright呢？
我知道你为什么问我这个问题，因为Playwright是微软开发的。有几个原因。
Playwright相当于一个网络程序库，好比它可以给我们提供砖头，但我们仍然要自己建房子。所有这些“创建”都需要时间和资源。我们认为开发人员应该把时间花在开发公司销售的产品上，而不是花在开发内部工具上。而且它的内部测试框架会使ROI非常糟糕。
· 为什么ROI对自动化测试非常重要？
投资回报率（ROI）对任何事物来说都很重要。几年前团队自动化测试所使用的工具或网络程序库是由一小部分人决定的。他们不会去计算执行成本之类的东西，只会说“噢，这个看起来很酷，我们就用它吧。”
这是一个可怕的趋势，它催生了大量科学怪人般的自动化工程师，构建了过于复杂和不可靠的内部测试框架。这些框架总是处于“差不多”的状态，没有太大的价值。有些工程师在工作上戒心很重，他们会扭曲所有的逻辑只为防止项目被抛弃。
如今这样的情况已经改变了，越来越多的人参与到这些决策中，最佳实践和真正的项目管理已经应用到这些自动化工作中。
如果这个概念难以理解，那我们来看一个例子：哪种选择更有意义？使用像Zoom这样的视频会议工具，或者使用WebRTC从头开始构建一个内部视频会议工具。
WebRTC是开源且免费的，但是构建内部视频会议工具需要数月，这会给雇主带来巨额支出。就像我前面说的，重造wheel文件会带来糟糕的ROI。
· 无障碍可访问性有多重要？
我们一直觉得它很重要，但我感觉很多公司并没有认真对待它。不久的将来这种情况应该会发生改变，我希望与GDRP类似的无障碍立法能得到广泛的应用。开发人员需要了解它的含义。在元素中添加标题属性可使网站与屏幕阅读器兼容，但如果没有在所有主流浏览器上进行测试，网站的可访问性得分就会被破坏。
虽然有视觉障碍的用户可以使用该网站，但由于只在Chrome进行测试，使用Firefox、 Safari 或 Edge的用户就无法访问了。准确的定义如下：无障碍可访问性是指让尽可能多的人能够使用你的网站。
· 你们会围绕更新进行测试吗？
万幸我们有足够的资源，不需要使用这种方法。我们每时每刻都在测试所有的内容。但对于没有资源可以支持时刻完全复原的团队来说，围绕更新进行测试是一个可以接受的技巧。
· 您如何看待测试趋势？
这取决于是什么趋势。我曾见过营销预算推动下的糟糕趋势，将缺陷伪装成良好的实践，这简直是噩梦般的东西。
我脑海中最先想到的一个例子是，有一家公司创建了一个用于自动化测试的产品，它的架构非常糟糕，甚至不能同时打开多个浏览器标签。这主要是因为它过于依赖JavaScript。我们都知道，当JavaScript想要打开另一个浏览器标签时，原本的浏览器会产生抵触。
他们掩盖了这个缺陷，说我们不需要测试一个链接是否真的能在一个新的浏览器标签打开一个页面，因为这实际上是在测试浏览器而不是网站。他们说只需要检测target=”_blank”的属性。按照这个扭曲的逻辑，测试时只需要检测鼠标点击这个动作能否完成，不需要进行任何点击操作。
我还见过另一个工具，它通过在Chrome上测试网站，在每个步骤获得DOM，并将这些DOM转储粘贴到其他浏览器中来实施跨浏览器测试的想法。我不明白为什么会有人想出这么可怕的主意。我希望在不久的将来无障碍可访问性可以成为趋势。
· 对于希望改进功能自动化测试的团队，您有什么建议吗？
跨浏览器测试很重要，不是每个人都会在苹果笔记本电脑上使用Chrome。浏览器不仅仅是JavaScript的解释器。无头浏览器的运行可能与常规浏览器不同。
Chrome在Linux系统和Windows系统上的运行也可能不同。测试整个工作流程。如果您的网站在执行某个操作时正在发送电子邮件，请检验该电子邮件是否正常发送。如果那封邮件有按钮，点击并查看所跳转的页面是什么。
用最新的工具，傻瓜才会去重造wheel文件。
