回归测试范围

Question

有一个关于其他人做回归测试的问题。让我阐述一下我们目前的情况以及我认为应该是什么：

1. 我们有烟雾测试，这只是一些最低限度的测试，用于构建验证。
2. 我们对特性进行了功能测试，这些功能可以用来验证进入sprint的各个特性。这将测试单独的特性，而不是从系统的角度。
3. 我们有一个QA类型的测试套件来测试产品，无论失败与否。更多的顾客喜欢，如果你愿意的话。

我的困惑是，回归应该包括什么？

我在想以下几点：

• 从(2)和(3)的特性测试集合中创建组件套件。
• 初始回归将根据更改的内容选择组件测试，并为特性和QA套件运行它。
• 每周一次，运行全套(2)和(3)套，所有组件。也可以使用这些套间进行日常构建？不确定在日常jenkins构建上运行的测试与QA自动回归测试( QA )之间有什么区别。

你们在这种情况下做什么？

Answer 1

为一个快速/简单的答案事先道歉-现在是关键时刻！

我目前的客户端已经自动化了大约80%的回归测试，其余的都是由一个离岸团队手工完成的，基本的经验法则是：

“如果您更改B，测试A和C"

也就是说，您的回归团队(或自动回归包)没有必要重复您已经执行的功能测试，因为它没有增加价值，只是在重复工作。

听起来你已经走上了正确的道路--尽管我对b点有点困惑。就我个人而言，我会为每个版本运行整个回归套件(除非运行时间太长)，因为目标是检测回归问题，而不是单元测试问题。

希望这有意义吗？

Answer 2

当需要完成一个推出时，我们执行以下操作。重要的是要注意这个阶段是在没有以前数据的以前版本测试模板上运行的。我们还在将回归套件的一部分拉到自动化的过程中。

• 浅浅的探索性。测试每个页面的基本导航和控制功能。
• 深度探索。类似于肤浅，但背后有更多的逻辑，但不具体。这包括搜索结果、显示问题、排序等。
• 一旦解决了本节中的bug，我们将继续进行实际的回归。
• 我们目前有一个谷歌文档与系统的每一个领域。每个区域都有一个优先的标记，以指定我们应该寻找的细齿梳子的数量。首先，我们验证pass测试，以确定是否一切都正常工作。然后尝试打破任何我们能在页面上花费更多的时间在高优先级的项目。对我们来说，这将构成我们计划的计费部分。-Once焦点部分回归已经完成，我们继续讨论存储在Test上的回归套件用例。它们基本上是具体的用例，有一步一步的描述和先决条件来模拟实际的标准用例，有时还包括系统的多个部分。这些都是非常有益的，因为它将有助于覆盖标准案例，无论是在Beta中还是在版本中，这都是有帮助的。

Answer 3

不久前我也问了一个类似的问题。也许在这里找到的答案也可能有帮助，因为您评估什么是最适合您的组织。基于我从stackexchange收到的反馈，我在每次发布时都将我们的流程修改为一个迷你回归套件。它只测试显示停止级别的功能。如果我没有发现bug，我可以在两个不同的平台(操作系统级和互联网)上同时完成大约4个小时的测试，包括我们的移动应用程序和设备通信(如时钟)。我是唯一的测试人员，我们的迷你回归套件没有自动化。如果我发现错误，自然需要更长的时间来完成迷你回归。

这是链接。如果你有任何问题，请告诉我。内部验收测试(非自动化)：需要多长时间？