Joyine 2019-11-12
前面我们聊过《软件测试笔记(十七)回归测试的介绍和工具选择》,今天要分享的是缺陷的重新验证,这个回归测试的概念很相似,但又有所不同,下面会和大家详细聊聊缺陷的重新验证和它们之间的差异。
定义很明确:确保在早期版本中发现并发布的缺陷在当前版本中得到修复或不被修复。
更简单地说,重新测试就是在修复某个特定的错误之后对其进行测试。
例如,发布了版本1.0。在测试版本1.0时,测试发现了一些缺陷(例如,缺陷ID 1.0.1并提交到缺陷系统。测试团队测试Build1.1中的缺陷ID1.0.1,以确定缺陷是否已修复。
按照缺陷生命周期,一旦测试人员发现缺陷,就会将缺陷报告给开发团队。缺陷的状态应该是“提交”。开发团队可以接受或拒绝这个缺陷。如果开发团队接受这个缺陷,那么他们会修复它并在下一个或者几个版本中发布它(取决于缺陷的修复的难易程度)。缺陷的状态将是“准备好进行测试”。现在测试人员验证这个缺陷,以确定它是否被解决。这种测试称为重新验证测试。重新验证测试是一项计划性测试。我们使用的测试用例与我们在早期构建中使用的测试数据相同。如果没有发现缺陷,那么我们将缺陷的状态更改为“已修复”,否则我们将状态更改为“未修复”,并将缺陷重新发送给开发团队。
回归测试
当生产代码被修改时,我们都会进行软件回归测试。通常,我们在以下情况下执行回归测试:
下面以一个登陆界面作为我们比较两者的区别的案例。首先,我们假设两种情况:
案例1:登录页面-登录按钮不起作用(错误)
案例2:登录页面-添加了“保持登录”复选框(新功能)
在案例1中,登录按钮不起作用,所以测试人员报告一个缺陷。一旦修复了这个错误,测试人员就会测试它,以确保登录按钮是否按照预期的结果工作。
在前面,也有一篇关于《软件测试笔记(六)缺陷报告应该涵盖哪些内容》的文章,可以帮助更好的提交缺陷。
在案例2中,测试人员测试新特性以确保新特性(保持登录)是否按预期工作。
案例1正在缺陷的重新验证中。在这里,测试人员使用错误报告中提到的重现步骤,重新测试在早期构建中发现的错误。
同样在案例1中,测试人员测试与登陆按钮相关的其他功能,我们称之为回归测试。
在案例2中,测试人员测试新功能(保持登录状态)并测试相关功能。在测试新特性的同时测试相关的功能将进行回归测试。
另一个例子:
想象一下,一个正在测试的应用软件有三个模块,即管理、购买和财务。财务模块依赖于采购模块。如果测试人员在购买模块上发现一个缺陷并提交。缺陷修复后,测试人员需要重新测试,以验证与购买相关的缺陷是否修复,并且测试人员还需要进行回归测试,以测试依赖于购买模块的财务模块。
回归和复测之间的一些其他差异:
对失败的测试用例进行缺陷的重新验证,而对通过的测试用例进行回归测试。
缺陷的重新验证确保原始缺陷已被纠正,而回归测试确保没有意外的副作用。
这里大家可以了解了缺陷的重新验证的定义,以及什么时候我们需要执行缺陷的重新验证。同时也对比了非常会让人混淆的回归测试,以及其应用的场景,希望对大家有所帮助。如果大家关于缺陷的重新验证及同回归测试有什么想法,也请留言区回复。