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

#1 楼

好问题。在这里，我将根据经验解释一些步骤。

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

2）在这里，我只想澄清一下“执行所有测试案例/套房”一词。我们需要在四个象限中对测试用例进行优先级排序，如下所示。



3）进行大量的探索性测试，而不是完全采用脚本方法。

4）首先尝试覆盖所有关键业务流程。

5）尝试测试所有先前的生产缺陷并覆盖当前的回归周期。

6）给在采用顺序方法之前，您需要一些时间进行适当的计划。您可以首先消除和删除哪种类型的模块和测试用例，因此现在您有了所有重要任务的列表。再次使用Priority Quadrant [Step-2]

6）最后但并非最不重要的一点。同样，我们需要步骤1 ：）

始终开放以征求反馈和建议。

#2 楼

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

那么您该怎么办？优先排序。常见的启发式方法是RCRCRC：

最近：新功能

核心：产品的基本功能

风险：风险定义为风险的概率发生（发生的可能性）乘以影响（损失，损失的金钱小时数或任何相关的损失）的多少，风险隐藏在其下很多，可以从模块到系统再到环境的不同级别进行计算。 >
配置敏感：这表示内部配置和环境设置，例如设备或操作系统的类型

已修复：最近修复的错误代表未经测试的区域

慢性：已知某些地区容易受到伤害。这可能是由于复杂性，开发人员的级别或介于职责之间的领域而造成的。

为您列出测试用例列表并为每个项目评分，例如1-5（不要请使用零，因为它会干扰下一步），然后将六位数相乘并按结果排序。这将使您对应该首先测试什么以及为什么要进行初步估计。

#3 楼

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

1。优先考虑测试用例

在我过去的项目中，我们优先考虑测试用例。我们使用了HP ALM，并且那里也有几个测试用例，不可能全部执行。因此，我们所做的只是确定测试用例的优先级，例如严重，极高，高，中，低-与缺陷处理相同。所有创建的测试用例均基于我们也创建的发布策略。这只是专注于最重要的测试用例

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

让测试团队中的另一个人参与进来。测试并不意味着您仅与测试对象一起进行测试。这意味着您还可以让其他团队成员参与其中。因此，在我们的项目中，我们还邀请产品负责人进行测试。而且不只是在最后（例如，部署完成后，应通过业务部门和产品负责人完成UAT）。在《 Janets》一书中，我发现UAT通常是在部署后完成的提示。但这并不意味着必须将其留给最终游戏（Janet Gregory的“更多敏捷测试”第202页）。因此，当然，在测试产品时，您可以让其他利益相关者参与测试产品。在我们的案例中，我们的产品负责人帮助测试了一些测试用例！顺便说一句，您也可以要求UX部门来支持您。我们还要求UX部门支持我们执行一些测试用例，我们也从中得到了宝贵的反馈。

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

您也可以尝试进行Mob测试。只需给他们一些测试用例（易于理解）和一些说明（并准备例如测试数据），然后让他们运行测试用例即可！当我们邀请其他部门的利益相关者来支持我们时，我们就是这样做的！这项工作奏效了，输入的信息对我们很有帮助（因为我们还收到了有关新变更请求的反馈）。好消息是，我们只从那里的测试人员那里发送了一个，负责两个人的四五个小组。不知何故，这就像处理测试用例的加速器。

向业务部门寻求支持

我们还向业务部门寻求支持。通常，业务部门仅在应执行UAT时才采取措施。但是我们要求他们支持我们，并给出了这样的理由，即该帮助对于交付（测试）稳定的产品将非常有价值。

使用日志记录工具进行探索性测试

当我们决定使用捕获-重放工具时，我们还减少了创建测试用例的时间。在我们的情况下，这是三角龙/ quamphmphony。在测试执行期间，此工具创建测试用例，在此期间，我们以某种方式进行了探索性测试。表示执行和创建测试用例。因此，这减少了创建具体测试用例的时间。

你知道，有很多想法。但是最重​​要的是，测试是整个团队的方法！因此，您可以邀请所有相关的利益相关者支持您-基于我们的经验，大多数人都愿意支持我们。

#4 楼

首先分析有关变更的影响。这样您就知道要覆盖的范围。

在大量测试用例中，您必须能够确定测试用例的优先级，因为并非所有测试用例都具有相同的优先级。您可能最终会获得高优先级，中优先级和低优先级的测试用例集。

您可能希望执行所有测试用例，但是在这种情况下，如果有时间和精力的话，这是不可能的。资源约束。

估算执行每组测试用例所需的时间和精力。然后将出现以下几种情况：


如果您有时间讨论高优先级和中优先级。这是个好消息。
如果您有时间只讲“高优先级”。还可以
如果您甚至没有时间解决“高优先级”问题，就需要与您的经理或需要做出发布决定的人员进行讨论，以传达您确实需要时间来完成测试。高优先级测试用例的执行。否则，存在主要功能无法正常运行并在部署时影响生产环境的风险。

如果他们坚持要按时完成任务，那么您已经做好了提供信息的工作，提供了什么信息

如果您没有太多的测试经验，那么一切都是非常重要的，需要对其进行测试以确保其正常工作。

如果您有多年的测试经验，您将知道我们将没有足够的时间来进行这项工作。挑战将是，如何在给定的时间和资源范围内按时交付最佳结果？


关键是要了解目标。它将引导我们完成并确保我们不会迷路。

#5 楼

在这种情况下，最重要的是确定测试的优先级。基于风险的测试是确定测试优先级的好方法。查看您预见的风险，并根据测试的缓解计划来确定测试的依据。对于每种风险，分析影响和发生的可能性，并为相应的测试分配优先级。首先运行高优先级测试，如果时间允许，请进行其他测试。

另一种方法可能是使用数据组合技术进行测试设计，例如“分类树方法，决策表或成对测试，等等。”帮助您将测试分组在一起。但是，为了评估优先级，请查看风险并根据需求及其业务影响和优先级确定优先级。诸如Hexawise，Testona和Razorcat等工具实际上可以帮助您进行数据组合测试。


底线，应该对功能进行优先级测试。它应确保尽可能对所有通用流程进行测试。

#6 楼

找到一些度量然后进行排名。

假设您的度量是线覆盖率；或扩展覆盖率，或者...


为该单个测试运行每个测试收集覆盖率度量。
对测试进行排名。 （我将在之后的排名中进行扩展。）
下一次只运行排名的测试+先前发现了错误的测试+随机选择其他测试来填充您在此“回合”中拥有的测试资源。 br />重复执行要测试的程序的下一个增量更新。

排名：

我提到了一种算法，该算法用于选择总覆盖范围相同的那些测试子集，但是使用较少的测试，因为许多测试将覆盖相似的区域。

注意：

这是芯片设计中使用的方法，其中创建要执行的测试比实际容易得多在模拟硬件上运行测试。它允许您通过设计（在您的情况下，在程序中）来监控覆盖范围，通过使测试保持已知进展来提高覆盖范围，同时还允许添加新的测试以填补覆盖范围的空白/随机地探索测试空间。

#7 楼

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


例如每个模块有500个测试用例或测试用例，作为测试人员，我们首先必须决定在该模块中哪个功能比在特定功能测试场景中要重要。（对于手动测试）
当您有大量场景时，您必须忽略那些测试用例，这些功能不那么重要。
例如每个模块有500个测试场景或测试用例，作为测试人员的最佳选择是自动化测试，在自动化中，我们将使用TestNG一次执行大量测试用例，从而减少了您的工作时间。 （用于自动化测试）

#8 楼

答案取决于您要进行手动还是自动测试
对于所有测试，请确保遵循以下准则：

敏捷测试金字塔
敏捷测试象限

您最重要的是确保您
与产品所有者进行对话并听从他们的建议
如果您要进行手动测试，我的建议是：

使用基于风险的评估
使用探索性章程
让更多的人来从事工作
聘请有经验的人来帮助和指导从事这项工作的人

如果您正在做自动测试我的建议是：

使用并行化
使用浏览器测试服务，例如Br​​owserstack，Sauce Labs等。
对质量充满热情的自动化工程师
做不要使用专注于性能和效率的开发人员访谈*

*主要重点应该是可读性和可维护性。在选择自动化工程师时，（测试代码本身的）性能不是主要考虑因素。不幸的是，我遇到表演面试的大多数应用程序开发人员还没有学到这一点。这是根据我的经验得出的意见。

#9 楼

通常，大量的测试用例意味着其中一些是可忽略的，或者其中的很多取决于您的测试用例的制作以及功能对测试系统的影响程度。

首先，您将寻找如果回归中的主要情况是否通过，则您将尝试在运行主要情况时检查情况是否未爆炸。这可能占您测试的20％到30％。然后，您将研究可能对系统效率产生直接或间接影响的半主要情况。因此，您可以执行50–60％的测试并进行测试。

主要测试用例指的是系统的主要功能

半主要指的是取决于主要功能或对客户端或系统效率有多重要。

这就是我的建议。但这完全取决于情况。

#10 楼

对于大多数测试用例，取决于您的选择，您必须先执行哪个然后再执行。对于大型测试用例，大多数情况下需要确定其优先级。
首先：确定测试用例的优先级。
其次：检查哪些案例/问题影响了模块的大部分。
第三：进行新的修复模块问题。

#11 楼

优先处理关键测试用例和耗时的测试用例。将这些测试用例分享给执行迅速且正确的测试人员。
然后将中等测试用例提供给对项目/产品有充分了解的其他人。
然后汇总低优先级测试用例并给出其余的测试人员执行。