重新测试整个系统或仅使用回归测试进行更改

#1 楼

“是”

如果您有自动回归套件，则一定要重新运行它。如果您的组织真的很负责任，那么它将作为持续集成过程的一部分与所有单元测试和其他测试一起自动进行。

如果您没有那么奢侈，那么如果如果没有重大风险，则仅在受该错误影响的区域进行测试是可以接受的。在那种情况下，您绝对应该记录您做过和没有做过的测试以及原因。

#2 楼

这取决于。有什么风险？

想到的风险之一就是代码依赖。一段代码中的修复程序可以在很多地方使用。不仅是原始缺陷所在的位置。在这种情况下，您应该分析代码并决定是否还需要重新测试所有相关的位置。

当应用程序可能危及生命时，可能会最好进行回归运行。

我个人希望将所有内容都包含在自动化测试中，以使完整回归快速，廉价且可在每次代码更改时运行。我认为您不希望浪费时间来平衡是否需要测试。

#3 楼

只说说测试方面：

显然，您应该只对存在错误修复的部分进行重新测试。

问题是要识别出这样的区域。
/>可以做到的：


向后：例如，不从服务X馈送的前端组件受X更改的影响较小。
向前：例如，如果更改服务X，则从X馈送的前端组件将受到更多的影响。

这是基于风险的分析：给定情况和某些目标，您将集思广益，进行失败和测试的可能风险相应地。此测试的范围可能是您的回归套件和一些新测试思路的一部分。

从项目管理的角度来讲：

但是，这种分析是否更昂贵而不是运行整个回归套件，并且您有信心完整回归套件足以*验证更改，因此“盲目”运行整个套件也是一个不错的选择。

*-即新测试思路可能不会发现新的隐藏的重要问题。

#4 楼

这是一个非常普遍的问题。这取决于一些因素。以下是一些需要考虑的问题：


您是否有测试自动化？
错误的功能/区域是否修复了关键区域，可能会造成更大的风险？
错误的范围，功能，测试范围是什么？这还有什么其他功能/区域？固定的代码是共享函数还是类？应用程序的其他哪些区域还依赖该代码？
修复了哪些错误？琐碎或复杂的东西？这是边缘情况吗？该功能获得多少用户流量？
您需要多少时间才能发布？
您对包含错误修复的功能有多熟悉？
这些错误仅发生在特定的浏览器，操作系统，设备上吗？

您越能亲自回答这些问题，就越能优化您的资源和风险/回报。您对产品的用途，功能范围越熟悉，就越能优化测试。

最终，测试/质量检查的过程是降低故障风险并增强对一切事物的信心。按预期工作。至少应始终检查已修复错误的部分。

让我们考虑一些一般性的答案：


如果您具有自动化功能，请运行自动化功能。
如果是更关键的区域，请运行更多测试。考虑进行更多的端到端测试，确认所有功能均按预期工作。
如果您了解错误/功能的范围，则可以针对性更具体。如果错误是独立功能的一部分，请测试该功能。如果与其他功能共享，请务必也进行测试。利用端到端的冒烟测试，集成测试。
错误或功能越复杂，您应该依靠更多的测试。如果它是该软件的常用部分，则需要进行更多测试。如果是边缘盒，请测试该边缘盒和一些烟雾测试。
如果您没有很多时间，请验证该错误是否已修复，然后运行一些冒烟测试。
您越熟悉此功能，可以帮助您确定在回归测试期间花费多少时间来验证错误修复。
如果该错误仅发生在特定的浏览器，操作系统，设备上，请始终确保测试该实现。根据时间和错误的性质，您可以考虑将其扩展到其他浏览器，操作系统和设备。请记住，某些错误是特定于浏览器，操作系统和设备的，因此您只需要测试这些选项即可。

此外，如果您愿意阅读/编写代码，请考虑查看源代码中的差异。代码以了解修复程序。这可以帮助缩小测试范围和软件测试范围。

如果您对代码不满意，并且与开发人员关系良好，请他们指导您进行代码更改。请他们提供有关风险的信息，并确认错误修复的范围和所测试的功能。

请记住，回归测试旨在确保代码更改不会对现有功能造成不利影响。通过修复错误，您可以发现新的错误。没有“一刀切”的解决方案来验证回归错误修复。

#5 楼

是的，至少应该这样做。

作为回归的一部分，我们要遵循的是：

手动：


作为任务（功能/错误）本身的一部分，测试所有受影响的区域。我们与各自的开发人员进行了交谈，以找出所有“受影响的区域”（受此任务中的更改影响）并将其包括在我们的测试中。
因此，在某种程度上，我们将快速回归作为测试任务本身的一部分。
为所有可能的案例创建一个测试案例表。
测试用例分为：冒烟，回归，不需要自动化。
烟雾测试-基本的添加/编辑/删除操作。
回归测试-深度测试，着重于在所有可能的情况下破坏应用程序。

自动化：


一旦完成第一轮手动测试并且构建稳定，我们便开始使该功能自动化。
首先，我们使烟雾测试自动化，以便在准备就绪后就可以在每个版本上运行这些测试，以确保该版本稳定并可以用于进一步的测试。我们维护的是单个烟雾测试文件，其中包含每个功能标记为“烟雾”的所有测试。
一旦烟雾测试自动化完成，我们就从测试用例表开始进行自动化“回归”测试。
一旦回归测试是自动化的，我们会将它们包含在每天运行的回归套件中（夜间模式）。

长话短说：
对我们而言，回归不仅仅在于检查副作用，还运行测试，尝试使用所有可能的组合/场景破坏应用程序。

#6 楼

这是软件测试公司所面临的一种常见情况，其中的缺陷修复是在回归测试之后进行的。在这种情况下，它完全取决于错误修复和提交的代码对应用程序其他区域的影响。

如果提交的代码对其他区域有影响，则需要进行回归测试。此外，如果您拥有自动回归套件，则可以从那些套件中寻求帮助，因为这将节省时间，并可以并行测试应用程序中非自动化的其他部分。

如果提交的代码没有很大的风险然后仅在受错误影响的区域进行测试是一个不错的选择。在这种情况下，您应该记录所做的和未进行的测试。

除此之外，如果您有足够的时间重新测试整个应用程序，则是有益的。