【问题标题】:Retesting vs Regression Testing重新测试与回归测试
【发布时间】:2016-12-17 16:59:42
【问题描述】:

我的问题如下: 有两个模块,如模块 A 和模块 B。在模块 A 中,我有 100 个测试用例,模块 B 也有 100 个测试用例。在测试过程中,模块 A 得到了 50 个失败的测试用例,模块 B 得到了 40 个失败的测试用例。

现在我的问题是,在 Modified Software Build.. 的模块 A 和模块 B 中要执行的重新测试和回归测试用例的数量是多少?

据我了解,在模块 A 中,重新测试用例 = 50 和回归测试用例 = 50,在模块 B 中,重新测试用例 = 40 和回归测试用例 = 60。

【问题讨论】:

  • 您的问题对我来说似乎不清楚。为什么这被标记为手动测试?
  • 我正在对具有两个模块(例如:模块 A 和模块 B)的软件进行手动测试,并提到了上述场景..
  • 首先检查模块A和模块B有多少测试用例,然后如果你想重新测试,你必须重新测试整个模块,而不仅仅是失败的测试用例。

标签: qa manual-testing


【解决方案1】:

重新测试是测试这个失败的案例,错误已解决。

回归测试是检查添加或更改的功能是否不会导致现有代码中的错误的测试。

在您的情况下,模块 A 中的重新测试为 50,模块 B 中为 40。

很难说您需要多少次回归测试,但在这种情况下(许多测试用例失败),您可能需要测试所有测试用例。通常,您不会在回归中测试所有内容。

您可以在 wikipedia (https://en.wikipedia.org/wiki/Regression_testing) 上阅读有关回归测试的更多信息

【讨论】:

    【解决方案2】:

    进行回归测试以确认最近的程序或代码更改是否没有对现有功能产生不利影响。 回归测试的目的是新代码更改不应对现有功能产生任何副作用 . . 修复缺陷后,进行重新测试以确认最终执行失败的测试用例是否通过。 在缺陷修复的基础上进行重新测试

    【讨论】:

      【解决方案3】:

      重新测试通常是为了测试报告的错误是否已经修复。

      回归测试基本上是为了检查修改对依赖模块的影响。它通常在重新测试完成后进行

      【讨论】:

        【解决方案4】:

        我同意金加的回答。为了识别回归测试用例,您可以创建一个可追溯性矩阵来帮助您识别可能受影响的区域,并且您可以在回归测试套件中包含这些区域的测试。
        你可以阅读更多关于traceability matrix

        【讨论】:

          【解决方案5】:

          您提到的重新测试的测试用例数量是对的。在重新测试时,我们会测试那些最初失败的测试用例,现在它们已被开发人员修复,因此可以重新测试。

          您在回归中测试的测试用例数量取决于您为回归测试套件选择的测试用例。有几个因素决定我们在回归测试中包含哪些测试用例或不包含哪些测试用例。这些因素可以是:

          1) 如果我们有足够的时间和资源,那么我们可以在回归测试中检查整个应用程序。关于您的问题,这意味着在回归中您可以检查模块 A 的 100 个测试用例和模块 B 的 100 个用例。

          2) 您提到模块 A 的回归测试为 50,模块 B 的回归测试为 60,但在回归测试中仅测试通过的测试用例不是必需的,通常也不遵循。

          通常在回归中,我们测试那些受到新功能影响的功能。这意味着受模块 A 和模块 B 影响的特性也应该包含在回归测试中。

          如果我们没有足够的时间,那么我们可以根据:

          a) 优先级:基于对客户具有高优先级的功能的测试用例。

          b) 变更:测试用例基于在不同版本之间频繁更改的功能。

          c)Experience:基于以前版本中出错最多且更容易出错的功能的测试用例。

          等等

          【讨论】:

            【解决方案6】:

            模块的 A 和 B 都有 100 个测试用例

            在测试过程中,模块 A 得到了 50 个失败的测试用例,模块 B 得到了 40 个失败的测试用例。

            据我了解,您第一次测试了这些模块,发现模块 A 的 100 个测试用例中有 50 个失败。

            那么模块 A 或模块 B 都没有在任何地方描述重新测试和回归测试。

            如果您再次对第一次失败的测试用例进行了测试,则称为重新测试

            并且在重新测试期间,如果您发现除了这 40 个错误之外的错误,则表示该错误是在修复 40 个错误期间出现的。在这里,该错误称为回归。

            【讨论】:

              【解决方案7】:

              在该版本中修复缺陷后,QA 团队会进行重新测试。

              对每个版本以及功能项进行回归测试,以便在部署代码时,代码不应影响现有功能。

              现在,在模块 A 中向您提出问题,重新测试用例为 50,回归测试用例为 50,在模块 B 中,重新测试用例为 40,回归测试用例为 60。

              【讨论】:

                【解决方案8】:

                回归与重新测试对于测试人员来说总是令人困惑的话题。

                在执行回归测试时我们需要注意以下主要事项

                • 受影响区域
                • 有哪些新变化
                • 错误修复

                如需了解更多信息,请查看:https://www.youtube.com/watch?v=i5DNiSEz464&t=174s

                【讨论】:

                  【解决方案9】:

                  回归测试:- 定义为验证软件更改不会影响现有功能的测试类型。

                  在回归时,我们确保新的更改和错误修复不会影响产品。在此,我们重新执行了之前的测试用例,以验证更改或错误修复对功能的影响。

                  重新测试:- 也称为对报告的错误的确认测试。重新测试是为了确保测试期间提出的缺陷得到修复并按要求工作。我们只重新执行失败的测试-从开发方面解决这些问题的情况。

                  如果您在模块 A 中获得了 100 个测试用例,并且在模块 A 的测试期间您获得了 50 个失败的测试用例。为此,当您重新开始后,开发人员将修复 50 个失败的测试用例执行失败的 50 个测试用例被定义为重新测试。

                  并且回归测试用例:-通过的 50 个测试用例的剩余重新执行被定义为回归测试。我们需要验证它应该影响其余通过的测试用例。

                  在模块 b 的测试期间,如果您在 100 个测试用例中获得了 40 个失败的测试用例。 修复错误后:- 重新测试测试用例:- 40 回归测试用例:- 60

                  【讨论】:

                    猜你喜欢
                    • 2017-01-17
                    • 2021-08-06
                    • 2011-12-02
                    • 1970-01-01
                    • 1970-01-01
                    • 1970-01-01
                    • 2010-11-06
                    • 1970-01-01
                    • 1970-01-01
                    相关资源
                    最近更新 更多