如何向只懂手工测试的团队解释测试自动化的概念？

#1 楼

测量它。


选择测试区域，测量手动测试需要多长时间，然后测量自动化测试需要多长时间，以及维护自动化需要花费多长时间。 （您也可以尝试测量其他事情，例如手动发现的错误与通过自动化发现的错误，但是很难量化。）


如果自动化更好，您将拥有数字来证明。

#2 楼

看来您的老板（正确）理解编写自动化测试所花费的时间会更长，而手动执行一次相同的测试会花费更长的时间，并且担心您将花费大量的时间进行自动化，而您将没有时间进行手动/探索性测试。测试也是代码，也需要维护，以使其适应应用程序中的更改。

自动化测试的价值不是第一次在应用程序中进行测试，而是在廉价的回归测试中进行。您不太可能拥有将100％的测试自动化的资源。但是，您可以自动化10％至20％的最常用功能，并保持其余部分的手动测试。如果您有资源，请添加更多。当然，即使在开发第一个可部署版本时，也必须多次测试某些功能，并专注于自动化。

测量花费多少时间来手动测试已经自动化的零件。这样可以节省时间。时间就是金钱。在继续开发应用程序的数周之内，您的自动化测试将节省大量资金。

进行自动化测试的另一个好处是，人们可以专注于更有趣的手动探索性测试。很难雇用一个星期又一个星期重复同样无聊的手动测试的人。而且这种令人麻木的脑力劳动不会是高质量的。

这枚硬币的另一面是：如果您要为其他人创建应用程序（您的公司不会获得长期维护该应用程序的报酬），并且您的合同不需要大量的自动化测试，则您仍然可以进行现有的测试（显示您的专业水平和能力），但是您的老板会不喜欢您花太多时间在客户不重视的事情上。允许将产品传递给客户的最少的自动化测试就足够了。然后，由客户来维护代码，以决定他们是否要在代码中进行更改以及如何处理回归测试（例如扩展测试）。一切都取决于合同中规定的可交付成果。

不要向老板提起它，但是自动化还有另一个好处：您正在学习新技能并提高自己的价值。

#3 楼

很难证明自动化测试的投资回报率。进行重构以保持代码精简和刻薄的团队确实对测试自动化有很高的要求。错误的代码甚至可以杀死公司。他的解决方案CleanCode！干净的代码是编写良好的代码，具有自动测试覆盖率。 （鲍勃叔叔有些怪异，但是花点时间习惯他的行为，我认为这是值得的。）

要成为一名测试工程师，最有效的方法是要么专注于自动化，要么专注于手动测试，不能同时使用。我已经尝试过并失败了……其他人也一样（Groupon的某个人在一次活动中承认了这一点）。在您的情况下，如果有9个开发人员和15个应用程序，您将永远无法跟上。

我将专注于教会开发人员如何进行自动化测试。对于他们来说，它只是更多的代码。 :)从长远来看，目标是更快。为此，您需要能够将代码重构为易于理解，可维护和可测试的代码。为了能够重构，您需要大量的自动化测试。这些测试中的大多数应该是单元测试，而不仅仅是您关注的功能测试。

运行Coding Dojo，向开发人员介绍其代码的自动化测试：


https://pragprog.com/book/ebdojo/the -coding-dojo-handbook
https://www.pluralsight.com/courses/the-coding-dojo

在自动测试工作的重点和重点之间找到平衡在硒测试上肯定会浪费时间。它们开发成本高，运行缓慢且经常损坏（维护成本高）。阅读有关测试金字塔的文章，而不仅仅是依靠端到端测试。

#4 楼

我感觉到您的老板没有参加编程，因此很难传递一个抽象的概念。

您可以从自己的情况中得出的一个重要论点是：



我替换了只进行手动测试的质量检查人员，不幸的是，没有测试用例留给我学习，也没有要求。总而言之，我不得不依靠探索性测试。测试人员离开时，他/她的所有知识也随之消失。让某人重新开始会消耗公司的金钱和时间。如果某人离开了自动化回归测试，那么知识转移会更加容易，并且可以节省时间和金钱。

有时，您无法将想法传递给他人。我记得有一次我向经理介绍了一个工具，他甚至在不看结果的情况下就把它刷掉了。如果您觉得自己已经尝试了一切，但老板仍然不听，那么您只能做很多事情。

#5 楼

首先，我是自动测试或BDD / FDD的忠实拥护者，这意味着编写测试是开发的一部分。因此，我感到您很痛苦。

您最好确保要实施的内容确实适合该特定公司。您说有15个应用程序要测试，还有其他应用程序正在测试中。您不会告诉我们旧应用程序有多少更改，它们有多复杂，有多关键以及所有这些。


我的问题是我该如何说服一个不了解自动化测试如何工作以及对组织有多帮助的人？


A务实/外交的方法：

通过暂时仅对新应用程序实施自动化测试，或者不对旧应用程序进行测试，也许您会更加成功。从业务的角度来看，很难将测试添加到现有应用程序中，因为这只是花钱（看似，我知道，但这就是您老板所相信的）。新应用程序的开发人员，并尝试引导他们进入BDD / FDD。这意味着他们要进行大量工作才能获得良好的测试。如果一切顺利，它们的开销将不会大大增加，这会让您摆脱手动测试的痛苦。如果您做对了，他们将来会希望通过这种方式来实现他们的应用程序，因为它有很多好处，尤其是心理上的好处（例如，消除重构中的恐惧因素）。

习惯了这一点，您可以在某个时候回到旧的应用程序，并在其中注入一些自动化测试。

#6 楼

不幸的是，这并不罕见。 （答案的底部是tl; dr版本）

我通常这样解释：假设您有一个做某事的应用程序。您添加第二个功能。现在，您有一个应用程序可以完成两件事，但是要对其进行测试，您必须至少通过四种方式对其进行测试：


仅功能1
仅功能2
功能1然后是功能2
功能2然后是功能1

现在添加功能3。您需要重复四个测试，然后至少添加以下新测试：


仅功能3
功能3再1
功能3再2
功能1再3
功能1再2
功能1，2 ，3
功能1，3，2
功能2，1，3
功能2，3，1
功能3，1，2
功能3，2 ，1

，这不包括重复功能（例如3、3、1、2）

发生的事情是进行彻底的手动回归所需的时间每增加一个新项，指数增长。每个新的配置标志都会发生相同的事情：一个开关配置标志需要2组测试。两个独立的开关标志需要4组测试。三个这样的标志，进行8组测试。等等。

如果每个配置标志需要花费一个小时来测试每个功能，那么您的手动测试时间将很快变得不可行。

现在，如果说每次手动应用需要2个小时，对每个版本进行回归分析，每个应用程序平均每月发布一次，对于16个应用程序来说，每月要进行32个小时的手动回归-几乎是您工作时间的四分之一-下个月除外，这将花费更长的时间，因为还有更多的测试内容。

如果您可以自动化回归-假设花费40个小时来构建一个合理的DRY工作框架，然后您可以在2个小时内为每个要素添加新的要素回归。假设测试需要一个小时才能运行，而维护大约每周需要一个小时。

如果您每晚运行该套件，那么您在一小时内要覆盖32个小时的手动工作。在一周的回归运行中，您已经花了超过创建测试框架所需的时间，而且在引入回归错误后的一天之内就可以捕获回归错误，这意味着向客户提供的问题更少。这样可以节省资金并建立客户信誉。它还使您有更多时间花在探索性测试上，这意味着新功能将得到更好的测试并且更加稳定。早点投资回报率是由更少的错误到达客户，对公司的更大客户信誉以及更好地利用您的测试时间所组成。

#7 楼

变量太多，无法正确回答您的问题。任何回答的人都只能提供建议和意见。为了给出正确的答案，我们需要了解一些其他事实：产品的复杂性软件开发生命周期产品的稳定性和可预测性变化

传统的自动化意识作为一种避免大量人工测试的工具，并不是一个很好的销售功能。手动和探索性类型测试总是会发现自动化不会发现的奇怪错误。在六个月内出现一次的极端情况下，自动化发现奇异回归的价值是不错的，但通常不值得进行自动化。当自动化是内部产品以及持续集成/连续交付类型环境中的开发工具和过程的一部分时，证明对经理，主管和开发团队有用。阅读此testops PDF，以更好地了解它如何工作以及如何向老板解释。


首先，单元和集成测试
应自动化，维护和开发团队将其集成到工具中。
其次，开发团队的系统测试


也已集成到构建工具中
QA / TestOps / Automation团队应成为开发团队的一部分，以
创建供开发团队用作系统测试框架的框架和工具，以测试单元测试和集成测试中无法涵盖的功能
在开发团队内部工作并与产品经理紧密联系，创建测试计划以自动最后测试主要功能和关键用例





最后，您将获得质量可靠的工件，并且不会因安装，配置和配置手动测试人员而浪费时间使用损坏的产品。
最终，一个好的目标是创建一个规则，使开发团队拥有自己的端到端质量。这将在软件开发生命周期的早期推动维护诸如硒页面对象，api调用等自动化框架项目，并增强整个公司对质量的信心。

#8 楼

测试自动化可以节省时间和金钱。原因如下：



开发周期更短


用户可以更早地访问新版本
公司仍然具有竞争力，因为它可以更快地实现必需的功能



回归


测试一遍又一遍地执行（在本地和由CI执行）。随着代码库的增长，现有功能仍在使用。您可以确定没有任何“副作用”。当然，这也取决于测试范围（尽管如此，请不要尝试达到100％的代码范围。这并不意味着没有错误。）。



发现错误的时间更早



发现错误的时间越早，修复越便宜。本文对软件质量进行了很好的概述。它比较老，但是恕我直言仍然有意义。看图5-4。降低检测错误和修复错误的成本（仅示例），您将看到测试自动化的重要性。

#9 楼

您需要退后一步，考虑更大的前景。

更大的图景称为DevOps。 DevOps不是一个人做的事情，而其他所有人都像以前那样进行。 DevOps是一种整体的文化变革，是思维方式的范式转变。那么如何赢得人心呢？您需要将利益出售给所有利益相关者。

企业需要看到对利润的影响。自动化测试的价值在于回归测试。开发人员倾向于只测试他们已经实现的东西。如果事物是​​新事物，那很好，但事物通常是旧事物，对它的任何更改都可能导致无法预料的后果。

自动回归测试意味着确保发布到生产中的东西与生产中的东西一样适合目的。以三星为例，说明发行错误时会发生什么。现在，提供管理的一种方法可以减少测试，而他们的下意识的反应是假设他们需要的人员更少。

不是。 DevOps是IT的精益专家。目的是减少交货时间，使人们自由追求附加值。管理层和开发人员都需要了解，自动化测试并不意味着人们会失业，而是他们现在可以自由地追求那些已经推迟的蓝天项目，这些产品增强功能可以为双方带来更多价值商业产品和开发人员的技能：无聊的测试v令人兴奋的开发，隐藏的工厂v的增值。您可能面临的最大障碍是，如果您正试图出售该经理，以将人工测试团队视为其工作存在的唯一原因。向该经理购买《凤凰计划》的副本。祝你好运。

#10 楼

主要问题是花费时间进行自动测试的合理性。而且听起来您的老板还没有进入质量检查流程的细节。这在技术人员和管理人员之间并不罕见。您的老板可能对测试结果更感兴趣，因此您应该以他理解的方式与他交谈。

经理通常将重点放在以下三个方面：


时间：项目的持续时间
预算：所花费的资金
全日制：从事该项目的人员

自动化部分可以提供很多帮助它可以减少持续时间和执行测试所需的人力。测试为开发人员提供了提高质量的工具。产品质量对您的老板来说应该是有趣的东西。

您的老板可能会问自动化将如何减少工期和人力。 ，因为它增加了您的范围，而这并不是老板想要听到的（随着您增加工期/成本）。谈论质量保证要求的保证基本质量水平的测试，如果他不做这些测试，那么项目就有风险（生气的客户，损坏，修复带来的额外工作）。

回归测试
回归测试是最适合自动化的测试之一。它们应涵盖产品的重要功能，以最大程度地降低交付不良产品的风险。这些测试是重复性的，因为它们通常在每次构建后进行，而执行的测试则是稳定的，因为它们仅作了一些调整。您可以使用单元测试，也可以使用硒中的集成/ e2e测试来做到这一点。这样，您可以轻松检测现有功能是否被破坏。当客户抱怨以前的功能无法正常使用时，老板可能会要求进行此测试。
如果客户抱怨这种情况，但老板不知道，请找出并通知他。自动化回归测试将有助于在发布之前发现这些问题。如果根本没有回归，则回归测试的成本可能会更高，然后它们将节省成本。在这种情况下，不需要手动测试，如果仍然需要将它们自动化，则可以进行自动化。

示例业务案例可以作为在项目中进行质量检查和自动化的理由
创建自动化业务案例想法，这将使您清楚自己处在正确的轨道上。考虑到测试的本质，那些将是具有高风险的项目。显示哪个测试将涵盖这些风险。现在，您有了可以自动化的测试列表。考虑到实际执行测试的时间，您可以使用它来显示自动化将为您的项目节省多少时间。

示例原因：您希望在一个测试中达到基本的质量水平项目，每天都要做一些简单的测试。您可以手动执行或自动执行。自动测试仅在多次执行后才有用，因此，如果始终手动进行测试，则在创建测试和节省时间之间是一个平衡。

例如，如果您必须手动进行测试测试3种浏览器；您必须为每个浏览器花费10分钟。如果要使其自动化，则需要花费1个小时使用脚本将其自动化，但是每次运行都可以节省28分钟。一个星期将是2.5小时。如果是自动化的，那么第一天您就会忙1个小时，而一周的其余时间几乎不会花费您大约1个小时。这样可以在一周内为您节省1.5个小时。
如果老板每小时为工作收取50美元的费用，您将在一个星期内为项目节省75美元。

质量检查：什至可以节省多少钱更多钱
测试只是QA的一部分，通常在代码已经编写时执行。那么，什么可以在编写代码之前更早地提高质量？
开发人员可能会说TDD / BDD。质量检查人员可能会说他应该对项目可交付成果进行更多的吸收/审查。两者都是好主意。

#11 楼

自动化或不自动化我的测试？是一个大问题。并且这是一个需要不断变化的新词的必要性。
在我提出这个问题之前，我们先从为什么要自动化测试开始。
我们之所以这样做，是因为软件开发和测试的方法已更改，并且专门针对敏捷。
当您说敏捷时，您会很快说说冲刺和周期。在这种情况下，无法进行手动测试。
同时，我们可以谈论通过所有类型的测试总体上提高质量的问题。自动化测试可以通过在单元测试中进行单元测试，然后在脚本中进行集成，然后在功能中进行。前两个通常由开发人员完成，而功能性则由手动测试人员完成。 />“每周进行十次相同的情况”。这很难又烦人。每次您为进行这些测试而付费时（特别是如果您要求外部公司这样做）。
通过自动化场景。您可以编写一个，然后每天启动十个。
因此，在预算方面，您最大的部分是测试的设置，然后执行是免费的。如果您使用最佳实践和设计模式以及专门分解代码以更改一行代码并更正所有测试，那么维护费用就不会那么昂贵。
直到现在，我们仅能获得频率上的收益。不，不仅如此。实际上，相同的测试可以对许多数据执行。因此它将由数据驱动。可以在许多浏览器中执行相同的测试，操作系统...
因此，每天10个可以*（4个浏览器）*（3 os）*（例如3个数据），并且这些组合不能人为完成。
希望我的回答对您有所帮助，对不起。

#12 楼

解释的概念是

投资


做一个足够好的案例，企业会要求您提供自动化

您使用短期资源（编写自动化而不是手动测试）会占用更多时间，因此从长远来看，您可以使用该自动化来帮助企业更快地移动，更快地响应市场，减少错误和停机等。

概念很简单。它是否实际适用于您这样的特定情况将取决于您。我建议您向自己和企业询问这些其他问题。考虑他们是您的老板要您提出的问题。使用您自己的答案向企业提出这些问题，并进一步探讨该主题：


当前的发布频率是多少？
自动化工程师要花多少钱？
公司是否有或计划使用CI / CD？
自动化工程师是否普遍可用？
产品现在有多少变化（搅动）？将来发布频率会增加吗？
该产品未来将发生多少变化？
该产品现在产生多少收入？
该产品将来将使用多长时间（如果知道）？
该产品将来有望获得多少收入？
我们能否聘请2名工程师来避免明显的总线问题？
是否使用了多个浏览器？操作系统？版本？设备？平板电脑？语言？

您需要很好地理解业务目标，然后根据自动化将如何帮助实现这些业务目标来进行介绍。您应该分析为什么长期需要自动化。确保您事先按人计算了数字。自动化是诱人的（因为它带来许多优势），但是要意识到需要创造一个需要每人支付10万美元的职位。提出案子时不要掩饰这笔费用！

还有一点（问题）：
9个开发人员团队是否很好地使用和理解了自动化的价值，例如他们的单元测试？