我如何变得有点儿qa自动化：通过开发人员的眼光，我的感觉，幸存下来以及自动测试的出色架构和基础架构。
引言
正如他们所说，我不是妇科医生，我只是路过而决定看一下。 因此，对于初学者，我会说一下写作的原因。 在我看来，专家可以更快地解决该问题，并且在途中不会收集到太多耙子。 但是他不会像我那样感兴趣，您将一无所有。
导致我写书的另一个原因是：很长一段时间以来，我都不了解自动测试基础结构的特殊之处。 此外，许多PM或更高级别的经理还不完全理解那里的宇宙是什么，以及为什么开发人员自己为一两个进行单元测试，而对于phycestests，则采取了个人的方式，他们编写测试的速度较慢，不断修复某些东西，只要样本足够大，通过所有财务指标的机会就严格小于100％。
问题所在
第三天，铁路项目的发行规格下降。 一周前的某个地方，我们唯一的自动化工程师决定去芝加哥工作，但我们尚未找到新的专家。 因此，我不得不袖手旁观，假装自己是质量检查人员。 关于它的情况，并尝试告诉。
这个问题看起来很无害。 但是，对于初学者来说，需要一些环境背景和描述。 我们的平台中有许多地址选择器。 老实说，这是平台的主要实体之一。 选择器转到Google API获取数据。 在自动测试中，所有请求都将暂停以节省成本并加快测试速度。 另外，还添加了一些逻辑以提供几乎与所请求的地址线相同的地址线，而无需使用外部服务。
坏了：我们在地址栏中输入所需的地址，出现一个带有多个选项的下拉框，我们选择所需的地址，然后...将相邻元素的值插入到输入中。 总是
通往真相的路很长
最初的假设和幼稚的方法
事不宜迟，我接受了最近的跌落测试，找到了选择地址的那一行，并开始仔细检查它和邻居。 该行看起来是无害的： new_order_page.destination_address.select(baker_street) 。 但是我们知道，在漂亮的代码后面总会有一堆奇怪的小设计和令人讨厌的内脏。
我很快回想起，所有这些经济因素都可以在SitePrism上运行 。 这个东西可以将页面和页面上的元素分别包装在class和class方法中。 对于点击和其他操作， Capybara和RSpec负责。 但是毫无疑问，它们像整个民用舰队一样可靠。 如果是这样的话，第一个假设立即表明了这一点：要么有人为棱镜编写的选择器写得不好，要么有人扭曲了前面的布局。
假设的第一部分很快消失了，选择器被完美地编写了。 在那里没有找到可以选择第三个li xpath ，并且代码本身去年没有变化。
但是，在select方法的区域中，堆积了带有regexps的逻辑以从下拉列表中选择所需的选项。 当然，我对正则表达式很生气，然后去检查它们。 我花了半个小时，我知道一切正常。 正是选择了所需的行。 click就可以了。 一切都应该工作。 也就是说，布局假设的第二部分也消失了。 但是这种想法出现在js曲线上。 毕竟，我们页面上的元素是自定义的， js依序排列在该元素周围，此外，在此js最近一直在对其进行修改。
js是罪魁祸首
这是所有晦涩问题的标准原因。 诸如“去js ，因为他已经被震惊了”之类的东西。 而且，就我而言，似乎也离不开js 。 通常，我会三思而后行，奔向前端团队，将手指指向下降测试，并说“一切都对我们有利，请对您有利。”
但是，来自花花公子的家伙们不容错过，他们在那儿闲逛了几个小时，发现了几个与叙述无关的错误，并说不要怪js ！ 同时，他们抛出了一个有趣的信息，一个选择的请求是不够的，他提出了另一个选择，答案与输入的错误内容完全匹配。
我没想到会这样。 我们必须回过头来弄清楚模拟请求如何为我们工作。
综合方法
因此，没有其他地方可以等待帮助，莫斯科就在我们身后。
首先，我们看一下Moka向Google请求的方式。 更准确地说，首先我们寻找发生这种情况的地方。 这不是一件简单的任务。 事实证明，我们有一个完整的模块MockServices::Base ，它负责使用VCR模拟不同的请求。 他狡猾地跪在基本控制器上，仅由于负责外部请求的服务名称而找不到他。
好的，找到了moki。 现在我们来看一下它们的实现。 第一个请求很简单：从params中获取信息，并将其替换为答案的模板。 以防万一，我检查了params的内容，并且按预期的方式进行了准备。
下一个请求的moka方法更有趣。 某种mock_data出现在此处。 这些不是params ，我们需要弄清楚这个日期是哪里来的。 深入x_mock_data五次后，发现该数据是使用键x_mock_data从RequestStore中 x_mock_data 。 已经更有趣了。
我们返回到原始测试，并注意到有一个set_mock_header东西，在仔细检查后，会将一些数据添加到同一RequestStore 。 更有趣！
此时此刻，某个地方的大脑出现了认知失调：一方面，这可能是问题的原因，附带要求给我们的全局变量中断了。 但是有一个细微差别：财务规格服务器和财务规格本身是两个独立的流程（实际上，服务器至少是3个流程），因此，借方借方不能以任何方式收敛，因为流程之间的全局变量尚未带入这个世界。 而对于多线程的Web服务器来说，这将是一场激烈的比赛，实际上将无法正常工作。 意味着我掏空了一些东西，有必要进行搜索。
我们进一步查找并找到标头放到的特定bm 。 继续了解bm是BrowserMob 。 然后我有点费劲了，因为它是在Ruby封装中的Java代理。 只是灌木丛中的钢琴。
我们开始进行进一步的选择，并且了解到，对于具有rspec的客户端和具有应用程序的服务器（例如puma ）之间的“全局”变量，将使用请求中的X-Mock-Data标头。 问题在于应用程序对这些读者一无所知。 为此，您需要一个代理，所有请求都将通过该代理运行，并负责设置标头。 狡猾的你什么也不会说。
我们去测试，发现只是这个东西不起作用。 标头无处可见：无论是在请求中还是在响应中。 但是RequestStore在rspec端填充，在Web服务器端为空。 这肯定意味着-它在代理中。
然后，在两者之间，事实证明，我们不仅测试了set_mock_header地址，而且还测试了使用以上set_mock_header 。
太好了 有待了解如何解决此问题。
我们与代理打交道
我们忽略了启动jar文件的区域中的挖掘点，然后通过Ruby对其进行控制。 最好注意指定浏览器代理的方式。 我们使用Chrome，并在启动时在命令行的众多参数之一中传递代理信息。 代理功能是我们使用从模板生成的pac文件，以防止来自Web套接字的流量通过代理。
在这里的某个地方，人们渴望去使用代理配置在chrome上搜索谷歌。 事实证明，您不必走得太远，在72+版本中，这些家伙“完成”了他的工作。 在这种情况下，他们甚至带来了一个单独的错误 。 我最喜欢的评论：
“您能停止删除功能吗？”
令人遗憾的是，它被认为是一种功能，将来，它们在“保密性”方面承诺会提供更多锡。
简而言之，Chrome不再在proxy-pac-url参数中支持file:协议。 这些解决方案比另一种更好：
- 传入参数
js ，该参数将读取pac文件并将其转换为base64：-- --proxy-pac-url='data:application/x-javascript-config;base64,'$(base64 -w0 /path/to/pac/script) ； - 用python提升您的Web服务器，以便根据更“正确”的协议分发一个文件，这在
pac proxy的参数中受支持； - 关闭
NetworkService ，然后关闭file:协议，但他们保证将来也会对其进行“修复”。
前两个选项肯定没有启发我，而第三个选项很奇怪地帮助了我。
短暂的喜悦
很高兴在空闲的下拉列表和更新的chrome之间发现了一个棘手的连接，我很不高兴很久了。 事实证明，我们的CI不仅更新了chrome，还更新了所有相邻的软件包，现在由于未知错误Selenium::WebDriver::Error::NoSuchDriverError ，我们有更多的测试Selenium::WebDriver::Error::NoSuchDriverError了，奇怪的是，它与chromedriver不相关，但是相关带有chrome配置，库版本和并行规范执行。
但这是下一个工作日的任务...
展望未来： disable-dev-shm-usage参数在这里有所帮助。
结论
不要责骂自动化。 他似乎受与他无关的外部环境的影响最大。
最好让自动化工程师和开发人员成为朋友，以便他们组织自己的基础架构 有礼貌和礼貌 具有固定版本和受控的测试环境。 对我而言，这比遭受专有的CI更好，后者拥有各自非常复杂的拐杖和水下凳子，只有在将应用程序和测试与其他人的环境紧密集成后，您才能了解这些知识。