如果该软件有太多bug，根本无法进行测试该怎么办？

#1 楼

在这种情况下继续进行测试会适得其反，并可能导致“僵局”，因为所报告的问题将相互递归地相互依赖。情况
与开发团队一起坐下-确定最关键和最有问题的区域，并逐步进行测试以摆脱测试“僵局”

跟随改进/固定的区域以“广度优先”的方式对软件进行分析-从最关键到不太关键
进行根本原因分析-导致这种情况的原因是什么，可以改进以免再次发生这种情况-是吗设计/架构问题，文档记录不佳，缺乏不同类型的测试，通讯问题等。

#2 楼

理想情况下，暂停测试。现在是时候参考“测试计划”文档了。
这是时候应该查看“测试计划”文档中的“测试暂停和恢复标准”部分了。
我可以参考以下三点：通常在测试暂停条件下提到，这种情况看起来像属于第1点和/或2点：



发现了一个错误，需要进行修复才能进行进一步的测试，或者


开发的软件不能很好地发挥作用，使测试变得有意义。


测试出现问题环境或访问和/或设置不完整且不可用。



如上所述，由于严重的错误，该软件不能真正进行测试。因此，测试团队应随数据（到目前为止已找到的组织良好的错误的列表）一起发出危险信号，以展示其案例。
一旦满足恢复标准的条件，则应恢复测试：
恢复标准-只有在暂停测试的情况有所改善并且可以继续进行测试活动的情况下，才能恢复测试。

#3 楼

如果该软件存在问题，我们作为质量检查人员还必须采取哪些其他步骤？在一次软件安全面试中，一名候选人被问到：“您将如何修复零日安全漏洞？”这位候选人回答说：“我将从修复100天错误开始。”

与零天错误相比，100天错误是对较旧的安全错误的补充。

当某个软件累积了太多的错误时，几乎可以肯定，某些​​错误比其他错误更根本。有些错误是其他错误的结果。换句话说，以前犯的错误会导致以后再犯更多的错误。

除了Aalok和alecxe所说的，您是否可以对错误进行分类，以便从最有可能的错误开始有复利作用吗？

先修复它们，您可能会发现其他错误也会在此过程中得到修复。

#4 楼

如果您是开发人员...


每次触摸代码时都要重构代码。
在重构之前就知道应用程序的行为。单元测试（如果您知道如何编写可测试的代码）。
包括估计，进行变更影响分析，并让您的经理知道。

如果您是测试员...


如果可以批量修复错误，请与开发人员联系。
了解应用程序的行为并准备测试用例。新修复。耐心一点。

如果您是技术主管...


如果不尽快处理，这可能是一场噩梦。
与开发人员有关估计的信息。
在必须更改代码以修复缺陷时激励开发人员。将代码更改为可通过自动测试进行测试。
赞赏自动测试，即使它增加了开发时间。

最终，你们所有人都对工作或不工作的软件负责。因此，请耐心等待，并在每次更改它以解决问题时不断改善它。

无论如何，我正在做类似的事情，以便分享经验。

#5 楼

通常情况下，这种情况与管理人员要求推出产品的巨大压力相结合，他们可能不愿接受质量保证，告诉他们这是不容错过的。 ，找到并遵循最令用户烦恼的错误的修补程序非常有用。如果在公司内部或某些紧密合作伙伴公司内部使用该软件，则更容易，但人们可以尝试在任何地方寻找一些示例用户。越野车软件时，他们别无选择。即使是在一个糟糕的软件中，仅修复了一些错误就可以显着改善。

#6 楼

答案是验收测试。您的软件应满足基准功能集（通常由采购订单确定，但可以是dev / QA组合），才能被视为“完成”，从而可以进行质量检查。

#7 楼

在这种情况下，我要做的第一件事就是报告观察到的错误，并以某种方式将其标记为阻止进一步的测试。

标记的确切执行方式取决于工具和环境，但是我这样做确保阻止进一步测试的每个错误均已明确标记为阻止进一步测试。例如，一个无法保存数据的错误明显阻止了对该数据的进一步操作。他们需要知道，由于无法控制的情况，我无法进一步前进。那时，他们有责任确保已修复阻塞性错误，以便我可以重新使用该软件。问题已解决。从来没有短缺的事情要做，所以有什么事情要做是没有问题的。

我认为最重要的步骤是确保您的主管和项目经理知道您无法继续测试以及原因。

#8 楼

自动化测试也是一种具有一系列要求，设计和交付日期的应用程序。
明智地利用时间继续开发测试应用程序，因为如果SW团队在前一天确实修复了错误交付，仍然可以预期您可以运行测试并确定。让每个人定期评估测试结果的状态-不仅要通过x％的测试，还要把测试中的应用细分为子组件。尽管SW团队在运行依赖于其他代码的测试时几乎没有价值，但它可能有助于您改进测试应用程序。

#9 楼

处理此类情况的最佳方法是拒绝包含所有阻止程序和关键问题列表的构建。除此之外，还包括项目的所有高级质量检查人员，向开发人员发送电子邮件，以便每个人都应了解情况。为了以良好的方式处理事情，请与开发人员和业务团队开会，以便可以更好地讨论越野车软件的漏洞。几乎每个质量检查公司都遵循这些类型的流程来处理错误的软件。

#10 楼

当严重性为1和2的缺陷更多时，就会发生这种情况。
据我所知，至少有三个项目我遇到了相同的问题，并且遵循以下系统方法：基本前提：

您是否列出了所有测试方案？

-如果您的回答是“是”，那么工作就很简单（按照步骤1）。如果不是，请集中精力使用成对测试（正交阵列）之类的工具获得清晰的测试场景列表。

步骤1：
在下一个测试周期内是否有可能？

-对这个问题的肯定回答将有助于发现至少Sev 1和2缺陷的完整列表（不是完整的缺陷，因为可能无法进行完整的回归测试可行）
尝试实现诸如CypressIO之类的工具以使这些测试自动化，因此您可以将相同的框架扩展到单元测试（在左侧）和回归测试/ UAT（在右侧）测试周期）
步骤2：

知道何时停止测试至关重要。在“测试计划”的“休养标准”部分中找出答案-您是否通过了
测试计划并在其中提到的合格率百分比？此百分比已经提供了，非常好，否则必须进行修改，以使其至少90％的测试应该通过才能发布该软件（例如）
如果您没有测试计划，最好按照以下IEEE模板编写一个：
https://jmpovedar.files.wordpress.com/2014/03/ieee-829.pdf