本文解释了一个完整的自动化测试策略，如果它是可行的，并且自动化 QA 保证质量。
事实上，软件测试非常耗费时间和资源。可以从不同的角度观察软件的测试。它可以根据我们正在测试的内容进行划分。例如，项目中的每个可交付成果，如需求、设计、代码、文档、用户界面等，都应该进行测试。此外，我们可以根据用户和功能需求或规范对代码进行测试，即黑盒测试。在这个级别，我们将代码作为黑盒进行测试，以确保程序预期的所有服务都存在，按预期工作并且没有问题。我们可能还需要测试代码的结构，即白盒测试。测试也可以根据测试中的子阶段或活动进行划分，例如，测试用例的生成和设计，测试用例执行和测试数据库的验证构建等。测试确保开发的软件最终无错误。但是，没有任何流程可以保证所开发的软件是 100% 无错误的。
尽管手动测试通常会导致遗漏的错误、次优的测试覆盖率和人为错误，但即使在大型项目中，也无法用自动化测试完全取代它。UX、可用性、探索性等测试需要人为因素，因为自动工具无法模仿用户行为。自动化测试也不适用于安全测试。自动漏洞扫描需要随后的手动检查，因为它会提供许多误报。
在当今的现实场景中，应用程序会根据用户反馈、Web 流量（性能/负载）、竞争、合规法律等频繁变化。因此，要保持竞争优势，就需要创新、升级和增强您的产品，使一切自动化变得具有挑战性。那么实施完整的自动化测试策略意味着什么呢？它甚至可行吗？全自动 QA 能保证质量吗？
观看此网络研讨会，了解企业范围内的可操作策略、自动化测试的注意事项以及有助于提高发布和测试速度的 DevOps 工具。
我们需要完整的自动化测试吗？
自动化测试不是精确测试；它正在检查事实。检查是机器可决定的；测试需要感知。测试是一项调查活动，我们旨在通过探索获得有关被测系统的新信息。测试（手动）需要人类对可用性做出合理的判断。结果，我们可以注意到我们没有预料到的违规行为。此外，在实施测试自动化解决方案时，除了编写测试用例脚本之外，还有其他相关的开发活动。
通常，企业开发一个框架来演示测试用例选择、报告等操作。框架的开发是一项艰巨的任务，需要熟练的开发人员，并且需要时间来构建。此外，即使有一个功能齐全的框架，编写脚本自动检查所花费的时间也比手动执行相同的测试要长。
但是，企业不应该对其中一种宽容，因为这两种方法都需要深入了解应用程序的质量。企业花费大量时间使用最佳工具和实践来开发完美的测试自动化解决方案，但如果自动化检查对团队没有帮助，那就无益了。我们不应该以取代人工 QA 为目标，而应该接受他们对团队的优势。例如，自动化测试有助于腾出 QA 的时间进行更多探索性测试，并会发现错误。
哪些测试应该自动化？
团队通常希望尽可能地自动化一切。但是当他们遇到各种问题时，这又会困扰他们。企业应该分析他们希望自动化的测试用例的类型以及不能自动化或不应该自动化的用例。团队不应该仅仅为了测试而自动化测试。例如，如果您将需要大量维护的一整套测试自动化，那么您正在投入额外的时间和金钱，而这些时间和金钱您可能没有。相反，如果您专注于采用基于风险的方法，这将有所帮助，这样您就可以只自动化最有价值的测试。
让我们看一下最可行的自动化测试场景：
- 回归测试：回归测试需要多次测试相同的变量，以确保新功能不会与旧功能混淆。回归测试非常适合自动化。
- 复杂的功能：企业可以自动化所有需要复杂计算的测试。
- 冒烟测试：可以通过运行自动化测试为企业验证重要功能的质量，这将快速分析功能是否需要更多测试。
- 数据驱动测试：使用大量数据集重复测试功能也是考虑自动化测试的好方案。
- 性能测试：在不同情况下监控软件性能的测试非常适合自动化测试。为手动测试团队进行性能测试将非常详细且耗时。
- 功能测试：每当开发人员需要执行快速执行以获得即时反馈的功能测试时，这是另一个有意义的自动化测试示例。如果没有自动化，就不可能实现这一目标，尤其是在快速发展的组织中。
自动化测试的问题
- 高期望
大多数商业人士相信新的技术解决方案将化险为夷。测试工具也不例外！我们不能否认，如今的工具几乎可以解决我们目前在测试自动化中面临的所有问题。然而，这种不切实际的乐观也导致了不切实际的期望。无论工具多么称职，如果管理层的期望不切实际，它就不会满足期望。 - 自动化不必要
的测试 不要仅仅为了测试而自动化测试。取而代之的是，在这个过程中投入一些想法。研究产品的高层和低层架构。问会出什么问题。分析集成点并寻找潜在的突破点。
在您的整体测试方法中采用基于风险的自动化方法。例如，某物发生故障的可能性有多大，故障的影响是什么？如果答案很高，那么这些场景应该在每次构建时自动化并执行。 - 有缺陷的安全
性 仅仅因为测试工具没有发现任何缺陷并不意味着软件中没有缺陷。至关重要的是要了解，如果测试包含缺陷，它们将带来不正确的结果。自动化测试将无限期地保留那些不满意的结果。 - 忽略重要场景
一个严重的问题经常会泄漏到生产环境中，因为没有人考虑过特定的场景。执行多少自动化测试并不重要。如果忽略了一个场景，那么根据 Sod 定律就会出现错误，即，如果某些事情可能会出错，它就会出错。
结论
大多数测试自动化工程师花时间与自动化代码作斗争，并使测试在现代软件开发中发挥作用。他们几乎不专注于适当的测试和探索系统。
没有足够的时间编写自动化代码和执行探索性测试。团队在冲刺后自动化冲刺，忘记大局。
通常企业最终会执行大量自动化测试，但探索性测试会发现大多数错误。相反，企业应该根据风险评估选择要自动化的内容。什么可能出问题，如果确实出问题会对业务产生什么影响？
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/te-auto/8083.html