什么时候应该开始自动化？ [关闭]答案

【问题标题】：When should automation begin? [closed]什么时候应该开始自动化？ [关闭]
【发布时间】：2010-04-27 23:24:03
【问题描述】：

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

即使您有手动测试人员，您能告诉我您何时会自动化的理由吗？

【问题讨论】：

听起来您正在尝试提出一个测试框架，以自动化您的 QA 测试人员所做的事情（GUI 测试）。您是否已经进行了较低级别的测试（单元/集成）？在你拥有 GUI 自动化之前拥有这些是很重要的。
感谢大家的回复。他们都非常有帮助。现在我正在研究 Selenium 和 Ruby。我相信你很快就会看到我发布更多问题。
看了我最后一个问题后，我搞砸了。它应该是“何时”而不是为什么。再次感谢您。
@onesith，应该是“你能告诉我什么时候应该自动化”。 “reasons when”没有意义，最接近的短语是“reasons why”。这就是为什么你有这么多答案告诉你为什么要自动化。

【解决方案1】：

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

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

【讨论】：

【解决方案2】：

您实现自动化是因为按下“开始”并等待 10 分钟等待结果意味着您的测试人员可以在这 10 分钟内做其他有用的工作，而不是照看应用程序。

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

最大的原因是，当您在交付前不久更改了一些小东西时，使用自动化测试您会毫不犹豫地运行测试，即使“更改很简单，不应该破坏任何东西”——然后你就松了口气当自动化测试发现您引入并即将发布的错误时，松了一口气。

【讨论】：

【解决方案3】：

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

我更喜欢自动化，因为时间很长（已经提到过），而且在大多数情况下，您知道自己会得到什么。

你应该两者都有，但是随着产品的增长，如果没有自动化和测试将变得非常困难。

【讨论】：

他在我应该自动化时回答。其他人都给了我使用自动化的充分理由。

【解决方案4】：

我使用自动化测试的原因是，这意味着我可以获得一致、可重复和及时的反馈，表明我刚刚所做的事情是正确的。

手动测试也有它的位置，但很难确信它正确地涵盖了所有内容，而且肯定没有自动化测试那么快。

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

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

要确保对结果的任何“肉眼”检查都与以前一样好也非常困难，因此结果检查必须自动化。但如果你要自动化，你也可以自动化整个事情。不难。

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

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

【讨论】：

【解决方案5】：

即使您有手动测试人员，您能告诉我您何时会自动化的理由吗？

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

【讨论】：

【解决方案6】：

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

【讨论】：

【解决方案7】：

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

【讨论】：

【解决方案8】：

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

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

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

【讨论】：

【解决方案9】：

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

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

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

【讨论】：

【解决方案10】：

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

以下链接可能也有帮助：

Pre-requisites to start automation testing

How to plan test automation

【讨论】：

【解决方案11】：

每个公司都应该自动化他们的测试用例。
自动化回归测试用例。
遵循 BDD 和 POM 方法。
代码应该是可重用的。
代码应始终独立于机器。
报告方法应该足够简单，以便项目所有者轻松了解它。
通过 JENKINS/cron 集成 CI。
自动化需要硬件成本和自动化时间。

【讨论】：