前一段时间，我写
了一篇文章，介绍了我在组织质量保证工程师在一个项目上的工作经验。 现在，我想继续这个主题，但要从一个狭窄的方向进行-测试自动化。 它
大约是同一项目 ，很小，但是根据常规客户的要求进行开发。 也许我的方法不太适合拥有数十名员工的团队，每个团队都对自己负责（我认为，每个项目都应受到严格的监管，否则，尽管他们会找到健康的粮食，但管理这样的庞然大物根本是不可能的），但是对于像我一样刚找到新工作，站在十字路口如何在新的阳光下如何组织自己的位置的人来说，他肯定会很有趣。
准备学习
那么，如何组织项目的自动化测试呢？ 如果您的答案是采用出色的Selenium及其某种框架，那么从13年的测试经验的高度来看，我肯定不会这样做。 将不得不掌握新的视野。
“硒循环”的方法充满了什么？ 而且您已经阅读和听到了不止一次的事实。 这些测试是用户界面的事实，它们在编写和运行以及维护性能方面既昂贵又长。 每个人都知道这一点，但是只有当被忽略时，才会遇到这个真理的所有痛苦。 UI端到端自动测试应该是强制性的，除了它们，没有人可以让您有信心，客户端在下一次部署后
看到的内容不会令他感到失望。 但是，它们不应成为测试自动化的中心。
将“
测试金字塔原理”作为您的质量控制中心。 关于相同的问题，已经讲了很多，但是实际上，并非每个QA都了解如何应用此金字塔。
它是这样绘制的：
像这样：
每个人都会为他们的体系结构找到一个选择。
将测试金字塔原理纳入质量检查
首先，无论它多么懒惰和异常，都必须掌握白皮肤的测试并成为“部分开发者”。就像每个开发人员一样，在本地启动项目（当然，该项目包含有关如何执行此操作的文档，请查找它）。 您可能会停止诅咒该业务十次，这是第一次，您将遇到一百万个问题和问题，但是当您这样做时，您将已经了解很多：什么是体系结构构想，什么数据库，从哪里转发，什么是必要的配置，最重要的是，自动测试的存储位置以及运行方式。
其次，处理由开发人员自己编写的自动测试。在项目结构中找到它们的位置，使用什么类型的测试和工具，如何启动它们。 使用自动测试评估项目的覆盖范围，了解如何进行导航。 有许多用于自动覆盖率评估的工具，您可以使用，但我现在不在谈论。 我更多地是关于您的直觉的发展：掌握一项功能，看看自动测试如何涵盖它：好坏。 如果情况不错，您应该对此部分保持冷静；如果情况不好，您会发现自己在那些没有紧迫任务的日子里处于工作前沿。 同时，请记住，在每次运行期间，请记住，代码中的此位置容易受到攻击。
第三，鼓起勇气，检查开发商的要求。每次您开始开发新功能时，都要为其写下所有测试用例。 标记您必须自动执行的操作，以免返回对该功能的手动测试。 审查开发人员的请求请求，并合理要求实施他们错过的自动测试。 很多次，我遇到了非常出色的开发人员，他们编写了出色的测试，但是即使他们对理解最终客户最有可能使用该产品的精确度也产生了良好的质量保证。 因此，即使是经验丰富的专家，在编写自动测试时也有一些建议。
第四，更大胆，直接在产品代码中编写自动测试。是的，就像开发人员一样。 与他们同等。 每次遇到需要自动化的测试用例时，请不要急于使用仅在QA团队中使用的单独工具立即实施它。 首先，问自己一个问题：是否可以通过产品代码中的单元/集成自检将其自动化？ 如果是这样，那就这样做。 如果这很可怕，那么这只会是第一次，但是对于您的技能有什么提升，因为经验丰富的程序员会审查您的拉拔请求。 是的，起初，您所做的一切都会让铁匠铺遭受打击，但是发展总是会令人痛苦：)但是最终，您将获得丰厚的回报：
- 这样的测试将得到整个开发团队的支持
- 他们将持续，连续和快速地工作
- 它们将集成到CircleCi中，并在每次自动部署时运行（如果在项目中实现）
- 测试中将修补漏洞（您写了之前未写的内容）
- 如果没有时间，您可以帮助开发人员编写测试
第五，创建一组有限的UI端到端自动测试，以模拟最终用户在浏览器中的操作。这些将是仅由质量检查小组支持的测试。 它们可以体现
- 最受欢迎，最关键的客户场景
- 在主代码中的集成测试中，不可能完全实现例如与第三方服务一起使用的事实
是的，您现在可以访问该项目，并且无需更新项目的前端即可为Selenium提供方便，可靠的定位器。 无需等待并询问任何人-在主要产品代码中打开拉取请求。
它带来了什么
现在，我正在处理这种情况。 结果，在我的测试金字塔的顶部，只有9个端到端测试。 他们的支持是我的责任。 所有其他数十个和数百个测试与主要产品代码一起生活，在开发人员的本地计算机上开始工作，并得到整个工程师团队的支持。
我的端到端测试工作了一段时间，因为它们将视频文件上传到平台，然后使用不同的参数对其进行转换，将它们发送给第三方服务进行处理，等待答案等等，而没有任何存根。 因此，在自动测试中，有很多时间等待操作结束。 团队不喜欢在CircleCi中进行此类测试的前景，而且实际上并不需要。 因此，我在詹金斯（Jenkins）实施了他们的工作。
完成产品代码中的所有测试检查后，我们将已测试的早午餐部署到测试环境，并使用Jenkins在其上进行端到端测试。 另外还有一些手动功能测试可让质量检查人员更加保真，仅此而已，您就可以在主菜单中合并早午餐了。 今天，我并不是唯一一个在测试环境中驱动Jenkins进行自动测试的人，开发人员在需要生成新的测试数据并模拟用户活动时会不断启动它们。 它们很少，因此它们很稳定并且始终有效。 方便大家。
我将指出，质量保证工程师在测试金字塔的这种实现中具有另一个令人愉悦的优势。 事实证明，您已完全成为工程师团队的一部分。 您确实完成了一项工作的组成部分-与所有人一起编写代码，查看开发人员的代码，与他们交流，他们对您也是如此。 您会看到彼此的工作，更好的协作，更强大的团队建设。 您将不仅从外部而且从内部了解项目，值得尊重，不是吗？
最后的告别
我的文章并不声称是可以随时随地使用的通用药。 所有项目都非常不同，所有团队也都非常不同-每个人都应该自己建立自己的最佳路径，这通常是不同方法和工具的精髓所在。 即使是著名的Scrum，我看到了多少个项目，每个项目都有自己的职业：)我通常不相信严格的指示，我相信它们是指导原则，我需要根据实际情况采取行动。
但是，IT世界正在发展，并且有越来越多的人加入其中，因此，我确信在本材料的读者中肯定会有某人向我提供一些小小的指导，帮助我选择正确的道路。 如果有用的话，请在评论中对我微笑：)，反馈对我来说将是令人愉快的！