我想开始实施自动化。我只是不知道这是否会很好地利用资源。该应用程序正在以指数速度增长，但我不知道自动化在什么时候有益于测试。
即使您有手动测试人员，您能否给我一些自动化的理由？
问问题
3054 次
11 回答
6
自动化几乎总是进行测试的好方法。手动测试仍然很重要，但它更容易出错，而且如果您的手动测试过程开始需要数天或数周才能完成，那么快速推出更新就会变得困难。在项目开始时设置自动化通常更容易，因为您需要自动化的东西更少，并且一旦您的自动化框架到位，随着项目的增长，它应该很容易扩展。
尝试对已经完全实现的项目进行自动化测试可能比从一开始就自动化需要更多的工作，所以我建议尽快投入。
于 2010-04-27T23:38:55.557 回答
4
您实现自动化是因为按下“开始”并等待 10 分钟等待结果意味着您的测试人员可以在这 10 分钟内做其他有用的工作，而不是照看应用程序。
请记住，自动化测试可以在您每晚睡觉时运行。然后，您的测试人员可以利用他们的工作时间编写新的有用测试，而不是一遍又一遍地运行相同的旧测试。
最大的原因是，当您在交付前不久更改了一些小东西时，使用自动化测试您会毫不犹豫地运行测试，即使“更改很简单并且不应该破坏任何东西”——然后您会叹息当自动化测试发现您引入的错误并即将发布时，您会感到宽慰。
于 2010-04-27T23:35:04.037 回答
3
我认为这取决于在公司工作的人。有些人喜欢自动化，有些人不太喜欢它。如果您的公司现在还没有它，尝试实施它可能会很困难。
我更喜欢自动化，因为时间很长（已经提到过），而且在大多数情况下你知道你会得到什么。
你应该两者都有，但是随着产品的增长，如果没有自动化和测试将变得非常困难。
于 2010-04-27T23:53:40.420 回答
2
我使用自动化测试的原因是，这意味着我可以获得一致、可重复和及时的反馈，表明我刚刚所做的事情是正确的。
手动测试也有它的位置，但很难确信它正确地涵盖了所有内容，而且肯定没有自动化测试那么快。
例如，我的一个项目的一部分是一种优化算法，它使用一些启发式方法在搜索空间中四处走动，寻找好的解决方案。现在大约有 40 种不同的启发式方法可以单独使用或以各种组合使用，每次与客户会面似乎都涉及添加新的启发式方法或扩展现有的启发式方法。我需要绝对确定对于一个客户的这些工作都不会导致另一个客户的回归，这涉及在数百个不同的情况下运行算法并检查输出是否（不比以前更差）。
要求手动测试人员通过加载 GUI、打开输入文件并单击“运行”来运行所有这些测试用例是不切实际的，至少不足以成为有用的反馈机制。对于短期测试，测试通常每天运行数十次，对于重量级测试，每天晚上运行数十次。使用手动过程，完整的反馈可能需要几天时间，而修复几天前引入的错误比修复最后半小时内引入的错误要困难得多。
确保对结果的任何“肉眼”检查都与以前一样好也非常困难，因此结果检查必须自动化。但如果你要自动化，你也可以自动化整个事情。这并不难。
自动化测试的另一个优势是，从处理没有的项目的经验来看，如果您有没有广泛记录的手动测试，那么当项目处于休眠状态（显然处于“维护模式”）一年时，然后重新开始积极的开发，没有人能完全记得如何进行测试或预期的结果是什么，你最终会引入一大堆愚蠢的回归，这些回归需要很长时间才能确定。另一方面，如果您要对测试进行足够详细的记录，以便在一年后进行测试，那么您基本上已经将它们自动化：您只需要使文档可执行。
根据我的经验，您需要在突然意识到应该在 2 小时前开始测试之前大约 2 小时开始测试 :)
于 2010-04-27T23:48:24.870 回答
2
即使您有手动测试人员，您能否给我一些自动化的理由？
我会自动化所有可以自动化的东西。将人脑用于机器可以以可重复方式完成的事情的附加价值是什么？那么个人发展呢？我更喜欢用人脑来做比机器做得更好的事情：思考。
于 2010-04-28T21:16:12.213 回答
1
手动测试重复测试很痛苦且容易出错，如果应用程序正在更改，则需要重复测试。
于 2010-04-27T23:39:33.333 回答
0
提高测试效率——即使您有手动测试人员，如果他们（或您）可以实施自动化测试，那么可以探索更多案例。编写自己的自动化测试也可以让您深入了解自己的代码。
于 2010-04-27T23:34:03.770 回答
0
想象一下，程序的大小和测试的数量随时间线性增加，并且您想要进行连续（每天）的集成和回归测试。在这种情况下，第一天你会测试一个东西，第二天你会测试两个，第三天你会测试三个，等等。
手动测试的总测试工作量将随着程序大小的平方而增加：因为重新测试和重新测试。
如果你不自动化，那么你就不会进行常规的、完整的回归测试。
于 2010-04-27T23:47:01.500 回答
0
您应该尽快实现自动化。许多研究表明，在开发周期中发现缺陷越晚，修复的成本就越高。自动化通常可以尽早发现缺陷（假设您实际上尽快运行这些自动化测试）。
您越早开始编写自动化测试，您的开发人员就可以越早开始运行这些自动化测试和/或它们可以在持续集成环境中运行。一旦发生这种情况，您可以更快地发现缺陷，从而为公司节省资金并使开发人员感到高兴，因为这使他们能够发布更高质量的代码。这也让他们有信心做出改变，因为他们可以快速查看它是否会导致回归。
此外，它使您的质量工程师更多地成为整个过程的一部分，而不是在大部分工作已经完成之后，感觉他们的努力是一种坚持到底的东西。
于 2010-04-28T22:30:14.247 回答
0
在开始自动化之前有一些经验法则，例如确保您的应用程序足够稳定，其次尝试通过例如创建烟雾测试脚本来启动自动化，该脚本最初仅涉及主要（仅功能的关键部分）部分。例如，如果它是一个银行应用程序，最初只是自动化，如果用户能够登录并检查他/她的帐户余额等，仅此而已。随着应用程序随着时间的推移变得更加稳定，这种方式尝试增加脚本存储库。但最重要的是问问自己，您想通过自动化解决的具体目的是什么。
下面的链接可能也有帮助：
于 2014-12-25T06:18:01.023 回答
0
- 每个公司都应该自动化他们的测试用例。
- 自动化回归测试用例。
- 遵循 BDD 和 POM 方法。
- 代码应该是可重用的。
- 代码应始终与机器无关。
- 报告方法应该足够简单，以便项目所有者轻松了解它。
- 通过 JENKINS/cron 集成 CI。
- 自动化需要硬件成本和自动化时间。
于 2017-02-14T16:37:56.277 回答