我的问题如下: 有两个模块,如模块A和模块B.在模块A中,我有100个测试用例,模块B也有100个测试用例。在测试期间,模块A得到50个失败的测试用例,而模块B得到40个失败的测试用例。
现在我的问题是,在修改后的软件构建中,模块A和模块B中要执行的重测和回归测试用例的数量是多少??
根据我的理解,在模块A中,重新测试测试用例= 50,回归测试用例= 50,在模块B中,重新测试测试用例= 40,回归测试用例= 60.
答案 0 :(得分:6)
重新测试正在测试失败的错误案例并解决了错误。
回归测试是测试,检查添加或更改的功能是否不会导致现有代码出现故障。
在您的情况下,模块A中的重新测试将为50,模块B中的重新测试将为40。
很难说您需要多少回归测试,但在这种情况下(许多测试用例失败)可能您需要测试所有测试用例。通常,您不会在回归中测试所有内容。
上阅读有关回归测试的更多信息答案 1 :(得分:2)
我同意Kinga的回答。为了识别回归测试用例,您可以创建可跟踪性矩阵,以帮助您识别可能受影响的区域,并且可以在回归测试套件中包含这些区域的测试。
您可以阅读有关traceability matrix
答案 2 :(得分:1)
执行回归测试以确认最近的程序或代码更改是否对现有功能没有产生负面影响。 回归测试的目的是新代码更改不应对现有功能产生任何副作用 。 。 进行重新测试以确认在缺陷修复后最终执行失败的测试用例正在通过。 重新测试是基于缺陷修复
完成的答案 3 :(得分:1)
重新测试通常用于测试报告的错误是否已修复。
回归测试基本上是为了检查修改对依赖模块的影响。 >完成重新测试后,通常会执行。
答案 4 :(得分:0)
您提到的重新测试的测试用例数是正确的。在重新测试中,我们测试那些最初失败的测试用例,现在它们已由开发人员修复,因此他们会被重新测试。
您在回归中测试的测试用例数取决于您为回归测试套件选择的测试用例。在几个因素的基础上,我们决定在回归测试中包含哪些测试用例,或者不做什么。这些因素可以是:
1)如果我们有足够的时间和资源,那么我们可以在回归测试中检查整个应用程序。关于你的问题,这意味着在回归中你可以检查模块A的100个测试用例和模块B的100个测试用例。
2)您提到模块A的回归测试为50,模块B的回归测试为60,但没有必要,通常不会遵循您只测试回归测试中传递的测试用例。
通常在回归中,我们测试那些受新功能影响的功能。这意味着受模块A和模块B影响的功能也应包含在回归测试中。
如果我们没有足够的时间,我们可以根据以下内容做出决定:
a)优先级:基于对客户具有高优先级的功能的测试用例。
b)更改:基于在版本之间经常发生变化的功能的测试用例。
c)经验:基于以前版本中出现大量错误并且更容易出错的功能的测试用例。
等
答案 5 :(得分:0)
您在模块的A和B中都有100个测试用例
在测试期间,模块A得到50个测试用例失败,而模块B得到40个失败的测试用例。
根据我的理解,您已经第一次测试了这些模块,并且在模块A中的100个测试用例中找到了50个失败。
然后,模块A或模块B都没有描述任何地方的重新测试和回归测试。
如果您再次对第一次失败的测试用例进行了测试,则称为重新测试
并且在重新测试期间如果你发现了一个除了那40个bug之外的bug,那么这意味着在修复40个bug时会出现bug。这个错误称为回归。
答案 6 :(得分:0)
在该版本中修复缺陷后,由质量检查小组进行重新测试。
针对每个发行版以及功能项进行回归测试,因此只要部署了代码,代码就不会影响现有功能。
现在,在模块A中出现问题,重新测试用例为50,回归测试用例为50,在模块B中,重新测试用例为40,回归测试用例为60。