应该何时开始自动化？

Question

我想开始实施自动化。我只是不知道这是否会很好地利用资源。应用程序正以指数速度增长，但我不知道自动化在什么时候有利于测试。

即使您有手动测试人员，您能否自动提供原因？

Answer 1

自动化几乎总是一种很好的测试方法。手动测试仍然很重要，但它更容易出错，如果您的手动测试过程开始需要数天或数周才能完成，则很难快速推出更新。在项目开始时通常更容易设置自动化，因为您将自动化更少的东西，并且一旦您获得自动化框架，随着项目的增长，它应该很容易扩展。

尝试在已经完全实施的项目上自动化测试可能需要比从一开始就自动化更多的工作，所以我建议尽快潜水。

Answer 2

你自动化，因为按“go”并等待10分钟结果意味着你的测试人员可以在10分钟内做其他有用的工作，而不是让孩子坐在应用程序上。

请记住，您可以在睡觉时每晚进行自动化测试。然后，您的测试人员可以使用他们的工作时间编写新的有用测试，而不是一遍又一遍地运行相同的旧测试。

最大的原因是，当您在发货前不久更换了一些小东西时，使用自动化测试即使“变化很简单且不应该破坏任何东西”，您也会毫不犹豫地进行测试 - 然后您呼吸当自动化测试捕获您引入并即将发布的错误时，我们松了一口气。

Answer 3

我自动化测试的原因在于，这意味着我可以获得一致，可重复且及时的反馈，即我刚才所做的是正确的。

手动测试也有它的位置，但很难确信它能够正确地覆盖所有内容，当然也不会像自动化测试那样快速地进行测试。

例如，我的一个项目的一部分是一个优化算法，它使用一些启发法在搜索空间中走动以寻找好的解决方案。现在有大约40种不同的启发式方法可以单独使用或以各种组合使用，并且每次与客户的会议似乎都涉及添加新的启发式或扩展现有的启发式方法。我需要绝对肯定的是，对于一个客户而言，这一切都不会导致另一个客户的回归，这包括在几百个不同的情况下运行算法并检查输出是否（不比以前更糟）。 / p>

要求手动测试人员通过加载GUI，打开输入文件和单击“运行”来运行所有这些测试用例是不切实际的，至少不足以成为有用的反馈机制。对于短测试，测试通常每天运行数十次，对于更重量级的测试，每晚测试。通过手动过程，完整的反馈可能需要几天时间，修复几天前引入的错误要比修复过去半小时内引入的错误要困难得多。

确保对结果的任何“眼睛”检查都与以前一样好，也很难确保结果检查必须自动化。但是如果你要自动化它，你也可以自动化整个事情。这并不难。

根据使用没有项目的项目的经验，自动化测试的另一个优点是，如果您手动测试没有广泛记录，那么当项目处于休眠状态时（显然处于“维护模式”）一年然后重新开始积极开发没有人能够完全记住如何进行测试或预期的结果是什么，并且最终会引入一堆愚蠢的回归，需要花费很长时间才能确定。另一方面，如果您要详细记录测试结果，可以在一年之后获取它们，那么您基本上已经将它们自动化了：您只需要使文档可执行。

根据我的经验，您需要在您突然意识到应该在2小时前开始测试之前大约2小时开始测试：）

Answer 4

我认为这取决于在公司工作的人。有些人喜欢自动化，有些人不喜欢自动化。如果你的公司现在没有它试图实施它可能很困难。

我更喜欢自动化，因为工作时间（已经提到过），因为大部分时间你都知道你会得到什么。

你应该同时拥有这两者，但是如果没有自动化，测试将变得非常困难，因为产品的增长。

Answer 5

  

即使您有手动测试人员，您能否自动提供原因？

我会自动化所有可以自动化的东西。使用人类大脑可以通过机器以可重复的方式完成某些事情的附加价值是什么？个人发展呢？我更喜欢用人脑来做一些比机器更好的事情：想想。

Answer 6

通过手动测试重复测试很痛苦且容易出错，如果要更改应用程序，则需要重复测试。

Answer 7

使测试更有效 - 即使您有手动测试人员，如果他们（或您）可以实施自动化测试，那么可以探索更多案例。编写自己的自动化测试也可以让您深入了解自己的代码。

Answer 8

自动测试还可以对UI进行基准测试和识别问题... 人工甚至无法快速点击它：）

Answer 9

想象一下，程序的大小和测试的数量随时间线性增加，并且您希望进行连续（每日）集成和回归测试。在这种情况下，第一天你会测试一件事，第二天你会测试两件，第三天你会测试三件，等等。

手动测试的总测试工作量将随着程序大小的平方而增加：因为重新测试和重新测试。

如果您没有自动化，那么您将不会定期进行完整的回归测试。

Answer 10

您应该尽快自动化。许多研究表明，在开发周期中发现的缺陷越晚，修复的成本就越高。自动化通常可以在尽可能早的时间内找到缺陷（假设您实际上尽快运行了这些自动化测试）。

您越早开始编写自动化测试，您的开发人员就可以越早开始运行这些自动化测试和/或它们可以在持续集成环境中运行。一旦发生这种情况，您就会发现缺陷，从而节省公司资金并使开发人员满意，因为它使他们能够发布更高质量的代码。它还使他们有信心进行更改，因为他们可以快速查看是否会导致回归。

另外，它使您的质量工程师更多地成为整个过程的一部分，而不是觉得他们的努力是在大部分工作已经完成之后最终得到的。

Answer 11

在开始自动化之前有一些经验法则，例如确保您的应用程序足够稳定，其次尝试使用例如自动启动自动化。创建一个烟雾测试脚本，它最初只涉及主要部分（功能的唯一关键部分）。例如，如果它是银行应用程序，最初只是自动化，如果用户能够登录并检查他/她的帐户余额等，或多或少。这样尝试增加脚本存储库，因为应用程序随着时间变得更加稳定。但最重要的是要问问自己，您希望通过自动化解决的目的究竟是什么。

以下链接也可能有所帮助：

Pre-requisites to start automation testing

How to plan test automation

Answer 12

1. 每家公司都应该自动化他们的测试用例。
2. 自动化回归测试用例。
3. 遵循BDD和POM方法。
4. 代码应该是可重复使用的。
5. 代码应始终与机器无关。
6. 报告方法应该足够简单，以便项目所有者能够轻松了解它。
7. 通过JENKINS / cron整合CI。
8. 自动化需要硬件成本和自动化时间。