为什么大中型公司不采用测试自动化？

#1 楼

我认为公司不进行自动化测试的主要原因是因为“投资回报率”难以证明。同样，很难证明由于这些测试，您将在生产中减少缺陷，因为它们将捕获明显的问题，而不是实际用户可能会遇到的复杂依赖关系问题。测试者或沮丧的开发人员通常会更加自以为是。除非您已经进行了非常严格的手动测试，否则将自动测试添加到您的流程工作流程中肯定会减慢开发周期，但这也是很多公司都不会做的事情。

自动化测试的想法是，从长远来看，您将保持稳定的步伐。无需长时间的手动测试。但是，当您从长远来看永远都没有关系时，因为您将在一开始就变慢。大多数新软件产品都是从概念证明开始的，它成为生产系统，当产品成功时，并不是在考虑自动化测试的情况下进行构建的。现在使遗留系统可测试是非常困难且非常耗时的。

因此最终是一个平衡。我注意到的是，在中型/大型公司中，自从第一个主要产品停产后，自动化测试就变得更加重要，因为它是无法维护的，任何小的改动都可能在某处损坏某处。

那么您如何解决此问题并引入自动化测试？
进行连续部署。当任何代码签入自动进入生产环境时，它使得连续的自动化测试非常重要，并且可能是强制性的。像Etsy，LinkedIn，Spotify等其他一些相当大的公司正在做得非常成功。

#2 楼

公司选择不投资测试自动化的原因有很多。我遇到的一些问题包括：




软件的状态使测试自动化不可行。当组织的旗舰软件是用较旧的代码和技术构建的，并且图形用户界面和逻辑高度交织时（在这里想到经典的ASP），这尤其常见。如果旗舰软件相对稳定并且开发团队也相对稳定（因此熟悉应用程序代码），那么将其保留在原处并在必要时添加功能比将其重构为更干净，可单元测试的价格仍然便宜

组织环境不允许更多的时间来开发。这很普遍，尤其是对于那些并非以测试优先的哲学为开端的开发人员而言，发现所有级别的抵制都是“花费额外的时间”构建单元测试。如果没有单元测试，那么更高级别的自动化将是一场失败的游戏，因为与通过与应用程序GUI进行自动交互来测试业务逻辑相比，效率低下的唯一事情是手动执行这些测试。如果您不花时间去做正确的事情，那么您将不得不花时间去做它的想法并不会取得太大进展，这也许是因为这些组织往往需要经常发布和升级。 br />
组织/开发人员赞成“可以通过任何温暖的身体进行测试”的谬论。这是软件开发所特有的：手动测试可以由能够使用该软件的任何人进行的想法。

组织/开发人员认为他们已经充分测试了他们的工作。他们也可能。我的经验是，专用测试资源往往落后于开发资源约十年。花费大量时间来抵制构建高质量测试自动化框架所需的成本和精力。

组织更喜欢使用开发资源来编写代码，而不是编写测试自动化。这是另一种非常普遍的情况-经常伴随着让开发人员有时间设计更好的解决方案或提高其技能的阻力。

该组织没有“看到”无形资产的投资回报率。这是另一种常见的现象：会计师往往更关注有形的收入和支出。与新销售相比，失去，不满意或失去联系的客户不容易衡量，因此，他们的重要性往往降低。在这种情况发生的地方，这表明决策者是种豆算账的会计师。如果您无法量化，他们将无法评估，如果无法评估，则将不允许。如果您曾经试图说服这样的会计师说没有发生错误的正ROI，那么您就会知道问题所在。再次，很常见。中小型和中大型组织的利润通常很窄。不发布新功能意味着落后于竞争对手，这反过来又意味着可能倒闭。他们没有能力花费额外的时间来启动测试自动化工作。提供了引入测试自动化所需的时间和精力，但是它们持续的时间越长，就越需要测试自动化。通常，只有在组织文化发生变化或聘请了足够强大和/或富有魅力的测试自动化布道者之后，该周期才会改变。

#3 楼

分析的缺陷在于您像工程师一样思考。您声称成本效益分析表明自动化软件测试是出色的。但是您忘记指定要优化的目标。仅当您查看最终产品的质量，使用该软件的开发人员的效率或他们的工作满意度之类的东西时，自动测试才是优越的。

然而，公司的目标是盈利。期。当另一个目标，例如“制造优质产品”与目标“利润”保持一致时，公司就制造出了优质产品。如果不是，则有些人会偏爱目标“利润”，有些人会偏爱目标“质量”，而第二个人通常不管理大中型公司。也许他们会尝试，但是利害攸关。

因此，原因可以用一句话来概括：


CEO（或类似的高层决策者）并不认为这会增加利润和投资其他东西一样多。


CEO误会了吗？您的问题和其他答案都断言他是。实际上，他有时是，有时不是。想象一下在高进入成本的市场中的垄断。对于他们来说，投资金钱来提高产品质量将是一个错误，除非他们有一些自由现金需要投资想法。在现实生活中还有很多其他星座，在这些星座中，其他投资具有更高的优先级。

最后，我们无法告诉您为什么给定公司没有测试自动化。原因因个案而异。但是要注意的更重要的一点是，无论工程师对此有何看法，都必须根据具体情况回答“是对是错”的问题。

#4 楼

一些大型组织不回避功能测试，是因为它们“不会被它们打扰”或“不了解”，而是因为他们将它们视为战略责任。我在《卫报》上任职，我们既不依靠自动化也不是依靠人工进行回归测试。

为什么？ 。任何在大型项目中维护过回归套件的人都会遭受这样的困扰：脆弱的端到端测试需要持续维护，复杂的数据库设置和笨拙的配置。自动化测试是与任何其他软件一样的软件，并且受其自身的错误和意外行为的影响。我曾在每个CI构建启动一个功能套件的环境中工作，该套件将运行一个小时以上。我什至看到自动回归套件需要十二个小时！对于任何致力于连续部署的组织来说，这都不可能太长。

连续部署可以减轻错误的影响。大多数组织在能够快速响应业务需求的前提下采用CD，但是其真正的承诺之一就是将质量问题的影响降至最低。如果更改引起问题，那么我们的CD管道可以使我们在7分钟的周期内进行生产修复。我们所有的文章回复都保存在CDN缓存中，因此我们有可能破坏整个网站，并仍然在全球范围内提供内容，而不会造成延迟。而且由于我们的应用程序包含隔离的微服务，所以即使是-就像评论这样的关键问题，也不能也永远不会破坏文章或成员资格功能，因为这些功能是在完全不同的服务器上运行的完全不同的应用程序上实现的。

单元测试通常比功能测试更可取。它们更易于编写，运行更快，更不易碎，消除了他们的顾虑，几乎没有自己的错误并为代码本身提供了出色的文档。在少量受众群体上尝试一下。我们可以在当前需求较低的时区中，对10％的读者测试一项新功能。我们可以使用功能开关立即打开和关闭代码，而无需重新部署。

RUM为我们提供了外包服务。 Real-User-Metrics使我们能够实时捕获与真实用户的实时错误，性能和人为交互错误。阅读了此博客文章，并观看了我的一位同事，《卫报》质量负责人Sally Goble的最近演讲（在这里甲板）。