如何在有限的时间和资源范围内执行/测试大量的测试用例？

Question

我们有大量的测试用例，但是执行/测试它们的时间和资源有限。我们认为，但不可能执行/测试所有的东西。

我想知道在上述情况下哪些策略是有益的，以便在有限的时间和资源范围内进行更多的测试。

有人能提出解决上述情况的策略或方法吗？

Answer 1

问得好。在这里，我将从我的经验中解释一些步骤。

1)为此我们需要良好的团队合作。

2)在这里，我只想澄清“执行所有测试用例/套件”术语。我们需要在下面的四个象限中对测试用例进行排序。

3)进行大量的探索性测试，而不是完全按脚本编写的方法。

4)首先要包括所有的关键业务流程。

( 5)试着在当前的回归周期中测试所有以前的生产缺陷和覆盖。

6)先给自己一些时间进行适当的规划，然后再按顺序行事。您可以先消除哪些类型的模块和测试用例，然后先删除它，所以现在您有了所有重要任务的列表。再次使用优先级象限第二步

( 6)最后但并非最不重要。再一次，我们需要第一步:)

随时听取反馈和建议。

Answer 2

基本上，您从来没有足够的时间和资源来测试所有的东西，您的测试用例已经是无限“一切”的一个子集。

那你该怎么办？优先次序。一个常见的启发是RCRCRC：

最近:新特性

核心:产品的基本功能

风险:风险的定义是，风险发生的概率(发生的可能性)乘以影响(损失是什么，损失的时间或任何相关的时间)，风险隐藏在它下面，可以在从模块到系统到环境的不同级别上进行计算。

配置敏感:这表示内部配置和环境设置，例如设备或操作系统的类型。

修复:最近修复的bug代表未经测试的区域。

慢性:已知有些地区易受伤害。这可能是由于开发人员的复杂性、开发人员的水平或职责之间的某个区域造成的。

拿出测试用例的列表，对每一项进行打分，比如1-5(不要使用0，因为它会干扰下一步)，然后乘以六个数字，然后根据结果排序。这将给你一个初步的评估，什么应该首先测试和为什么。

Answer 3

我从项目中学到的东西也来自我的反馈。

1.优先考虑测试用例

在我过去的项目中，我们对测试用例进行了排序。我们使用了HP ALM，在那里我们也有几个测试用例，不可能执行all。因此，我们所做的只是对测试用例进行优先排序，例如临界、非常高、高、中等、低的测试用例--就像对缺陷的处理一样。所有创建的测试用例都基于我们也创建的发布策略。这有助于将重点放在最重要的测试用例上。

2.让其他人参与测试范围，例如产品负责人，并将一些测试用例转移给他们--

让测试团队中的其他人参与进来。测试并不意味着你只是和你的测试伙伴单独测试。这意味着您还可以让其他团队成员参与进来。因此，在我们的项目中，我们还邀请了产品负责人进行测试。而不仅仅是在最后(例如，当部署完成时，UAT应该通过业务部门和产品负责人来完成)。在Janets的书中，我发现了一个提示: UAT主要是在部署后完成的。而这并不意味着它必须留在游戏结束(珍妮特格雷戈里“更敏捷测试”第202页)。因此，当然，在测试产品时，您可以让其他涉众参与测试产品。在我们的例子中，我们的产品负责人帮助测试了一些测试用例！顺便说一句，你也可以要求UX部门支持你。我们还要求我们的UX部门支持我们执行一些测试用例，我们也从他们那里得到了宝贵的反馈。

以某种方式组织了Mob测试，并充当了测试协调者，向他们抛出测试用例！

您也可以尝试做一个Mob测试会话。只需给他们一些测试用例(这是容易理解的)和一些指令(并准备测试数据)，然后让他们运行测试用例！当我们邀请其他部门的一些利益相关者来支持我们时，我们就这样做了！这是有效的，输入对我们非常有帮助(因为我们也收到了新的变更请求的反馈)。好消息是，我们只派了一位来自那里的测试分析员，他负责四到五组两人。不知何故，这就像一个加速器，用于继续测试用例。

要求业务部门支持

我们还要求商务启程提供支持。通常，业务部门只在应该执行UAT时才采取行动。但是我们要求他们支持我们，我们给出了这样的理由:为了提供一个(测试)稳定的产品，这种帮助是有价值的。

使用日志工具对

进行探索性测试

当我们决定使用捕获-重放工具时，我们还减少了创建测试用例的时间。在我们的例子中，它是三位一体/不对称的。在测试执行过程中，这个工具创建了测试用例，在此期间我们做了一些探索性测试。意味着测试用例的执行和创建。因此，这以某种方式减少了创建具体测试用例的时间。

你看，有很多想法。但最重要的是，测试是一个完整的团队方法！因此，你可以邀请所有相关的利益相关者来支持你--根据我们的经验，大多数人都愿意支持我们。