测试顺序包括烟度、健康度、功能和回归

Question

让我们假设我们在应用程序中有5个模块。模块1与模块2交互。我们在Sprint 15中。在Sprint 15中，模块1中增加了新功能。当sprint 15的构建部署到QA中时，测试的顺序必须是什么-

1. 我们应该吸烟->理智->功能性->回归吗？考虑到以上问题的答案是肯定的，
2. 烟雾是检查的建设稳定性，我们将检查所有5个模块的关键功能。假设我们在每个模块中有三个关键特性，所以我们将在烟雾测试周期中执行15个测试用例。对吗？
3. 我们不会对这15个特性进行深入的测试。对吗？
4. 既然它是按脚本编写的，那么我们可以为每个sprint提供一个标准的烟测试套件吗？当然，如果在一个sprint中需求或新特性有任何变化，那么我们将添加/更新这个套件。那么，我们能为每个冲刺提供一个标准的烟测试套件吗？
5. 一般来说，烟雾测试周期应该是多长时间？应该像3-4小时那样短吗？
6. 根据第1点，我们将从吸烟后的健康测试开始。理智不是脚本化的，而是在测试应用程序的特定领域。所以在这个Sprint 15的例子中，我们将测试模块1和模块2的主要区域，对吗？
7. 因此，当我们进行理智测试时，我们将对模块1和模块2的主要区域进行深入测试。对吗？
8. 一些人说，心智测试是在重新测试之后进行的。如果这是正确的，那么在错误修复之后，我们必须对模块1和2的区域进行快速的健全性测试。对吗？
9. 或者，如果我们有足够的时间，我们会做回归，所以测试周期将是烟->理智->功能->回归。如果我们没有足够的时间，我们就会保持清醒。因此，测试周期将是吸烟->理智->功能性->理智。

请让我知道答案是明智的，并让我知道以上各点是否正确。

Answer 1

好的，这个问题非常广泛，但是基本的目标似乎是一致的，在一个sprint周期内的测试顺序。我将努力解决这个问题，因为我理解测试的深度完全取决于分析，以及应用程序是什么，以及修改了什么。

开始点:一旦Dev完成了某些功能(希望通过单元测试，并以sprint方式发布-伟大的scrum意味着QA已经参与其中，dev/QA已经同步)

1. Build created -安装后开始冒烟测试，这将确定安装是否成功，以及应用程序是否正常工作。这应该只需要30分钟，除非应用程序是巨大的，然后我希望一个团队是烟雾测试或并行自动化，以验证和得到验证到30分钟或更少。
2. 对新的预期功能进行功能测试。这是为了确保构建实际上正在进行预期的改进。如果构建没有做任何应该改进的工作，那么做一大堆其他测试就没有意义了。
3. 下一个是回归/理智测试。回归是针对受影响区域的详细测试，这些测试可能会以某种方式被修改，从而导致错误。健全性测试是这一领域之外的领域，是一种粗略的探索性测试，以验证应用程序中本应未被触及的其余部分确实是“未接触”的，并且功能相同。

注意:所有测试都需要分析，因为它真正和真实地取决于修改了什么代码、团队对特性的信任程度、特性的复杂性和交互性、可用性、性能、安全性、用户视角(特别是如果您有挑剔的客户)、预算限制、团队规模和技能集、自动化、测试#、测试规模等等。这是有原因的，它是“工程”，应用简单的1，2，3步骤并不适用于所有的应用程序。

为了将上面的内容与您的sprint示例相匹配，模块1应该进行功能/回归测试，在涉及到与模块1的代码连接时，应该对其他模块进行回归测试，并在其他地方测试是否正确。如果您有时间，更多的回归不会伤害，因为它可能会发现挥之不去的错误工作。