测试自动化为企业节省了大量时间——除非您选择了错误的测试用例。这篇文章指出了您应该注意的事项。
根据2021年测试自动化报告，超过40%的公司正在寻求扩展和投资于测试自动化的资源。虽然这并不意味着手动测试会消失，但从ROI的角度来看，人们对自动化的兴趣越来越大——无论是在金钱还是时间方面。
毕竟，我们可以同意编写和运行这些单元测试用例很无聊。一个好的自动化策略可以腾出测试人员的时间来解决一些更复杂的问题，并有助于及早发现错误。
然而，团队经常在没有适当测试策略的情况下急于自动化测试，这会导致在进行大修时出现问题。通过选择正确的自动化测试，最大限度地提高您的精力和投资回报。
在自动化任何测试用例之前应该考虑什么?
1.测试频率
为边缘情况组件编写一个手动测试通常更有效。事实上，测试新功能可以让您快速了解有关应用程序的更多信息。但是，随着功能数量的增加，这并不有效。
将您的测试场景分为两部分：重复部分和一次性或非常复杂的部分。
自动化重复次数最多的那些。您甚至可以设置测试频率的阈值，高于该阈值您将考虑自动化。
例如，应用程序登录或警报系统测试是测试自动化的理想候选者，因为它们需要在每次应用程序构建后运行。
这个规则也有几个例外——比如，单个测试需要执行的数据输入量非常大。在这种情况下，自动化该特定测试是有意义的，因为它会节省大量时间。
这里唯一的警告是自动化一系列相互依赖的重复测试。如果出现故障，可能很难确定是主要罪魁祸首的确切测试。这就是日志派上用场的地方，它可以帮助您有效地检测这些长期模式故障。
2.测试覆盖率
测试覆盖率对于软件质量和确保软件构建的稳定性至关重要。自动化正确类型的测试可以帮助您以几乎相同的时间投入实现高测试覆盖率的目标。
例如，如果您的应用程序有很多组件，那么运行自动化测试是个好主意。这绕过了错过特定测试的手动错误的可能性，并确保应用程序中最关键的部分顺利运行。您还可以在无人看管的情况下运行那些冗长的夜间测试，并在醒来时查看测试失败(或成功!)原因的详细日志。
3.结果
结果的可预测性如何?自动化需要预先定义的输入和输出来产生通过和失败条件，否则它们可能会导致错误的结果。
如果您处于测试的探索阶段，并且您的测试是临时的或需要非常具体的领域知识，那么将它们自动化并不是最好的主意。
4.特征重要性
如果一个项目是一个重要的功能，如果失败可能会导致用户体验中断，你应该编写一个自动化测试套件。这样，您就可以防止任何人为错误扰乱您的发布。
理想情况下，测试应该连续运行，以便尽快通知相关团队。
5.时间回报比
虽然自动化可以腾出测试人员的时间，但组织和个人经常忽略测试的一个关键方面——维护自动化测试所需的成本和时间。如果您的应用程序的后端发生重大变化，通常为自动化测试编写和重写代码就像手动测试一样麻烦。
解决这个问题的一种有趣方法是让测试工程师自动化，以了解程序的哪一部分失败。您可以通过自动化更广泛的应用程序测试来做到这一点，这样如果出现问题，您就可以确切地知道去哪里寻找。智能测试执行是测试自动化领域的主要趋势之一，它通过识别需要执行的特定测试来做到这一点。
6.人的参与
您尝试自动化的测试套件有多复杂?如果需要用人眼重新检查测试结果或需要进行实际的用户交互，那么自动化可能不会有太大帮助。
例如，用户体验测试最好不要自动化，因为测试软件在使用产品时永远无法模仿人类的情绪。但是，如果您需要对测试输出进行视觉确认，则可以运行自动截屏测试，然后进行手动验证。
7.优先权
什么时候需要测试结果?如果自动化测试有助于您更快地将产品推向市场，那么您应该继续使用它。但是，当您需要立即获得结果时，不要让编写和运行自动化测试成为瓶颈。
此外，您应该记住，“测试”并不是唯一可以自动化以提高应用程序效率的东西。手动数据收集或设置数据输入等任务也非常适合自动化。因此，如果有一个大型数据集但您的时间不够用，那么自动化它可能是您的救星!
经常自动化的测试用例
1.性能测试(负载、压力测试)
负载测试几乎因“隔夜”测试而臭名昭著。根据定义，负载测试需要大量资源，因为它们可以识别公司扩展时出现的系统滞后和性能问题。
这就是为什么进行自动化测试的工具很有意义的原因——因为它们可以以很少的成本有效地模拟用户和资源。我的意思是，尝试找1000名用户对尚未发布的产品进行错误测试-哎呀!
虽然您绝对不能聘请1000名QA专家来进行自动化测试，但测试自动化框架可以设置虚拟用户并让他们像真实用户一样与您的产品进行交互。这将使您能够通过在流程早期识别它们来扩展和避免中断。然后，您的团队可以查看性能指标并确定速度下降或中断的确切原因。
同样，如果您需要进行跨浏览器测试，自动化测试可以帮助您通过几个步骤收集应用程序跨多个配置的性能。
自动化您的性能测试以查看哪里出现问题，以及您的应用程序是否可以处理这些问题。
2.单元测试
如果您正在开发大型应用程序的代码库，自动化单元测试将节省您的时间。单元测试的自动化测试将帮助您实时发现错误，让您持续了解各个组件是否正常工作。
自动化在重构代码时特别有用，因为只要单元测试是绿色的，您就可以放心地假设单个代码单元的行为没有改变。此外，这些测试的报告可以立即提供给整个团队。
3.回归测试(烟雾、健全性测试)
回归测试可确保即使进行了大量更改，应用程序也能顺利运行。这意味着需要反复重新测试多个应用程序组件。由于这种重复，回归测试是测试自动化的理想候选者。
自动化回归测试将帮助您节省手动资源和时间，并更快地扩展。虽然回归测试通常在软件发布结束时执行，但自动化它们也为您提供了一个迭代和连续运行它们的选项。这有助于更快地识别程序中的错误并创建快速反馈循环，从而更快地解决问题。
4.功能测试
功能测试本质上是验证应用程序是否在前端以应有的方式运行。虽然功能测试的某些方面是手动的，但很多方面应该是自动化的，以确保无错误的产品交付。
例如，端到端测试自动化可确保关键的预定义用户体验流程对于每日发布的产品顺利运行。
使用selenium自动化功能测试是一种流行的选择。您甚至可以使用稍微不同的数据集或用户行为来调整测试，以涵盖多个用例。
哪些测试绝对不应该自动化?
1.探索性测试
探索性测试包括更广泛的非脚本测试，这些测试必不可少，但都是即时完成的。通常，这些测试需要一些领域知识和对应用程序的熟悉才能找出意外行为。由于它们没有很好地定义，它们不能被自动化。
但是，一旦测试人员通过探索性测试发现缺陷，这些测试操作就可以记录下来并自动化以供将来构建。
2.可用性测试
如前所述，可用性测试不应该自动化，因为很难预测人类行为。这可能包括错误的字体、颜色或使人们感到困惑的UI。只有在执行Beta或QA测试时，您才会知道这些。尽管有一些工具可以尝试自动执行此操作，但让人工查看它更有效(且成本更低)。
自动化还是不自动化?
测试自动化对于高效的CI/CD管道至关重要。测试自动化领域正在进行许多创新，例如并行测试执行、DevTestOps、物联网测试自动化等。这些自动化框架帮助大大缩短了产品的上市时间并提高了构建质量。
选择正确的自动化测试只是为您的组织实现这一目标的第一步，因此更快地测试、更快地失败和更快地修复!
