随着时间的流逝,随着应用程序的增长或更改,您的 回归测试 套件也将增长,可能会出现成百上千个回归测试用例。这就是为什么 自动化 将不可避免地成为您测试过程的一部分。
建立一个 自动回归套件 所需的精力比许多人想象的要少。回归套件实质上只是您已经构建的用于验证产品功能的现有测试用例的套件。这可以包括从单元测试到集成测试的所有内容。
但是,在设置自动化测试时,您可能需要进行一些春季大扫除,以确保仅转移那些可以真正了解产品质量的测试用例,并删除已经过时的测试。随着时间的推移,这将使您更轻松地维护自动回归套件。
为此,请问自己以下问题,以确定应包含在套件中/从套件中排除的测试用例(如果答案是肯定的,则很可能包括测试):
- 测试用例是否检查关键业务功能?
- 测试用例是否检查核心产品功能?
- 测试用例是否检查了对其用户高度可见的功能?
- 测试用例是否会产生错误?
- 测试用例是否检查已正确更改的功能?
- 测试用例是否检查一项新功能?
- 测试用例是否检查集成?
请记住,您始终可以调整测试套件。随着团队的发展和测试,您将不断学习和适应,因此测试套件也很自然。开始自动化时,您将可以腾出时间进行手动测试,让测试人员专注于提高测试质量。
不过,至关重要的是,您用于设置测试的工具必须提供良好的概述,并且可以由质量检查小组中的任何人进行调整,因为这将使维护变得更加容易,从而随着时间的推移改进测试。
如何在自动和手动回归测试之间找到平衡
建立自动回归测试时,通常会出现手动和自动应保留多少测试的问题。
要在手动和自动测试之间取得完美的平衡,首先需要了解自动化可以做什么和不能做什么。
自动化机器人旨在 究竟 您要求他们做什么,仅此而已。虽然在寻找问题时可能很容易找到问题,但要发现自己不知道要寻找的问题却要困难得多。
换句话说,自动回归测试将帮助您找到已知的未知数。它不会帮助您找到未知的未知数。
只有探索性,关键性,手动测试才能使您找到未知的未知数。
因此,随着软件系统的变化或增长,测试人员将继续履行监视,评估和更新他们设置的测试的关键任务。他们的任务也是跳出框框思考,寻找系统中潜在的陷阱。
自动化的伟大之处在于,它创造了一个良性循环–自动化的任务越繁琐,重复性越强,您和您的团队就可以释放出更多的能力,从而使您可以通过探索性测试发现现有功能中的这些陷阱。
此外,重要的是要了解,测试案例不一定是100%手动还是100%自动化。测试用例可以部分自动化,如果包含高度重复的任务(例如登录到应用程序或填写用户信息),则应该是自动化的。
总之,回归测试的理想方法包括持续关注通过自动化实现的效率和时间优化,以及批判性的思维方式和对新的和现有测试用例的仔细评估。
通过采用以自动化机会为核心的均衡回归测试策略方法,您可以确保项目按计划进行并按预算进行,确保团队成员以最佳方式利用其技能和能力,并且也许最重要的是,您的软件将保持无错误状态,从而为最终用户提供最佳的用户体验。
在有关该主题的下一篇博客文章中继续阅读: 您应该多久进行一次回归测试? 或下载我们的 白皮书:如何在敏捷团队中进行回归测试 了解您需要了解的有关敏捷团队中的回归测试的所有信息。