业内专家认为，具有人工测试的企业文化是阻碍自动化测试进展的最大障碍。为了收集当前和未来自动化测试状态的见解，我们询问了来自 27 家公司的 31 位高管，“您认为阻碍自动化测试的最常见问题是什么？”
下面是他们告诉我们的：
企业文化
- 在开发进展和质量保证之间，公司仍然没有明确的期望。 需要编写脆弱的功能和单元测试，以便它们能够在不中断的情况下跟进变化。测试用例随着时间的推移持久耐用。了解为什么测试会中断，能够确定需要做些什么才能使测试更具弹性。
- 首先必须拥有与类似的测试基础架构，您可以在其中捕获问题并能够正确地通知开发人员。此时，需要明确的策略，以确定在检测到回归时执行的操作：分配给谁修复它们，解决它们与完成其他任务的速度有多快，模糊回归会发生什么（代码错误或测试错误））等，我们已经看到了一个经常性功能障碍类型中的几个组织：他们已经建立了一个自动化测试系统，但是从破碎测试的噪音淹没了从工作的测试信号，所以大家忽略的测试系统。 这比没有自动化测试基础设施更糟糕。必须积极维护测试和围绕它们的人员流程，否则您最终会遇到这种特殊的功能障碍。
- 传统软件和平台。 客户端尝试使用云原生但仍与大型机接口。工程文化：质量保证被视为次要的，这是一个落后的观念。培养开发团队的良好的心态。恰当使用正确的工具很重要，不会浪费开发人员的时间。
- 如果研发与自动化团队之间的沟通不良，那么这可能会对新的自动化流程产生不利影响。当我们全部同步时，技术（自动化）将成功。另一个问题是自动化基础设施，它必须足够灵活，能够接受产品开发方面的任何变更，从而将维护工作降至最低。
- 让公司内化并定义他们想要优化的业务指标。 更多关于结果而不是产出和与商业价值的关系。 多个独立的孤立方法，可在单个组织中进行测试。 Unicorns 具有高度分布的隔离组件。变化的影响是零，你没有筒仓问题。改变遗留系统的合规性和风险是一项挑战。
- 静态扫描不提供覆盖率。不保证质量范围。不要暴露实际的测试覆盖率。随着 DevOps 将人们聚集在一起，我们可以看到安全性和测试需要让他们一起工作所需的孤岛。
手动测试
- 在使用手动流程的情况下，人们需要接受再培训。就像 DevOps 一样。文化问题：需要再培训。把普通的手工测试工程师成编写测试程序的工程师。SDLC 中的许多其他流程已经自动化并加速，因此 QC 不会减慢流程。
- 从手动转为自动化。 学习如何编写测试，手动测试的未来会怎么样？培训和教育方面。然后进行测试并集成到 DevOps 管道中。公司进行测试但不看结果。时间或环境依赖的事情可能会有更多的问题。
- 旧式测试人员无法适应，拥抱，自动化测试和人工智能（AI）。技术覆盖需要跟上网站变得更加动态，UI 更加直观，面部识别和指纹。使用自动化完成测试的执行。
- 完全的手工测试 QA 测试工程师发展的一个瓶颈。
其他
- 曾经有一段时间人们不相信测试。现在不再是这种情况了，单纯地前端测试是很少人做的事情。现在可以做视觉差异了，自信地对 CSS 进行更改。整个系统看一下代码评论中的截图，以便测试整个堆栈。
- 向左转。用于进行手动测试，但转向 100％自动化。这其中需要更多技术技能。手动测试仪学习所需技能只需几天时间。Selenium 使用人们熟悉的通用 web 测试框架。接受和开发易于构建测试套件，同时构建应用程序以确保该功能没有错误。接入 CI / CD 管道进行部署。
- 一旦我们确定了价值驱动因素，那么我们就会遇到可以跨越两个或三个家庭的阻碍者：1.技能组合 - 完成这项工作（自动化和编程）很困难，调整期望和计划; 2.基础设施的稳定性 - DevOps，测试（20％漏报）; 3.对覆盖的理解在当今世界中测试真实用户环境意味着什么？不同的预期，帮助理解和自动化，以及无法克服结果产生的噪音量。测试的数量和生成的数据量，智能分析，快速放大，看看出了什么问题。
- 紧跟浏览器和平台的所有变化，以及如何管理和使用测试工具生成的所有数据。
- 影响自动安全测试的主要问题有两个：第一个主要问题是表现不准确的结果。如果证明这些结果非常困难，开发人员将忽略自动化测试结果。第二个主要问题是开发人员工具中缺乏有价值的集成测试。安全团队继续通过 GRC 系统记录，管理和分散其安全数据。开发人员不会说 GRC。他们说 JIRA，TFS，Trello 等。
- 这很难说。可能有更多用于编写可测试代码的设计模式或标准。令人不安的是，即使像 Salesforce 这样的现代软件工具提供商或像 Apple 这样的大品牌也没有考虑 “可测试性设计”，以便使测试自动化变得更容易。第二件事是关于大学和学院的软件测试的更多教育。大学倾向于专注于软件开发而不是教授测试技能。这使得培养可靠的软件测试人员面临挑战 - 特别是在自动化领域。
- 每天快速的技术进步。需要关注更新。转到新版本的测试和代码。不要将更新推迟到以后的阶段。1.具有新框架，技术，编写应用程序的方法的动态应用程序。由于底层应用程序发生变化，测试变得不稳定 我们构建了一个测试来解决这个问题。2.需要技术自动化。编写代码并不总是那么容易。我们通过无代码自动化解决问题，因此非技术团队成员可以自动启动和运行。3.通过 Web，移动和桌面应用程序实现高测试覆盖率。需要多种工具和工具才能协同工作。确定哪些环境很重要。
- 需要工具成为 DevOps 工具链的组成部分。使用许多工具进行交付过程（Jenkins，JIRA，Slack，GitHub）甚至希望将 AI 测试视为其中的一部分。想要一个全面，自动化，可见的交付流程来分享来自不同工具的反馈。另一个能够在整个组织内共享反馈的能力 - 单元，组件，集成，端到端测试到部署。没有办法分享他们分享的东西，协作非常重要。数字化转型高管也希望参与这一过程，所有人都看到并互相学习。
- 报告首先是最重要的。一堆自动化工具但没有超越 Jenkins 或 Bamboo 之外更好的环境查看分析测试结果，只知道报告。自动化缺乏 QA 参与，自动化缺乏智能，无法识别您需要的覆盖范围和需求可追溯性。需要端到端的单元测试 - 使用不同工具集的不同自动化集。
- 人们还没有完全理解失败的问题及其影响。从硬件世界到软件世界，具有深厚网络技能的人不了解事情的变化。第一波网络测试自动化有一些失败。
- 客户利用 CI / CD 中的 Selenium 必须让开发人员编写测试。自动化测试是产品开发背后的原因，因为开发人员无法编写测试。我们的平台使测试能够用英语而不是代码编写。它使客户能够利用他们的资源。
- 我认为我见过影响自动化测试的最常见问题是过度依赖它。所有关于未知数的自动化测试仍然是验证/测试您已识别的事物的有效且有用的方法。这可能是您所看到的问题，以及您正在尝试优化的工作流程。它无论如何都无法验证您的代码的实际用户交互或代码本身如何在您未预见的地方进行交互。所以，如果你不知道它，你就不能为它编写测试。过度依赖自动化测试，或静态使用自动化测试而不进行更新，可能是真正的挑战。你想让它成为你不断更新和评估的东西，“我是否正在测试正确的东西？” 而且您需要使用工具，例如功能管理。
技术类文章精选
非技术文章精选
↙↙↙阅读原文可查看相关链接，并与作者交流