如果在生产中发现缺陷但在质量保证阶段却没有发现该怎么办？

#1 楼

当报告生产中的缺陷时，我们遵循的工作流程可能会为您提供一些观点：



重现问题。如果可能，我们尝试在生产中进行复制。如果不成功，我们将使用过渡环境，该过渡环境是生产环境的镜像，除非在发布之前在此进行了新部署。

分析问题。首先，我们确定问题是否实际上是缺陷。在复杂的应用程序中，可能是误解或认为预期的行为不是应该发生的事情。

它有几岁了？如果是缺陷，我们将进行调查以确定该缺陷存在了多长时间。我们发现，在进行重大部署之后，我们的客户对应用程序更加敏感，因此可以解决已经存在多年的问题。

有什么影响？对于我们来说，很少有偶然的缺陷让通透的缺陷得以解决，但这确实发生了。

优先解决问题。优先级排序通常考虑到系统中已使用了多长时间，对受影响的客户有多严重影响以及达到的客户群比例。根据问题及其优先级的高低，这可以是一种快速的技巧，可以使事情按计划在以后进行更全面的修复，或者可以是对该问题的正确更正。 。同样，计划的时间表取决于问题的性质。我们的团队非常小（4个开发人员和1个测试人员支持并增强了数百万个LOC旧应用程序，并试图构建更现代的产品来同时替换它们），因此，对我们时间的需求意味着我们不能始终快速修复。

编码，测试和部署修复程序。

根本原因分析。根据调度的不同，此操​​作可能会在步骤8之前进行，但通常要等到我们至少对问题进行优先排序并向客户传达解决方法（如果存在）后，才会发生。

取决于严重性整个过程可以在一小时之内完成，也可以在缺陷修复之前数月内完成-或在极端情况之间进行。做


我们不怪。如果我觉得应该在发布前遇到问题，我会这么说，但是没人会责怪其他人。
我们列出了影响因素。这些可以而且确实包括诸如代码的复杂性，缺乏有关如何使用应用程序的知识，不合理的期限等等之类的事情。通常，这些都是使错误发生的可能性而不是直接原因的原因，因为有时候问题的解决是由于完美的贡献因素而不是直接原因而引起的。
我们尝试添加预防措施来防止这种情况反复出现的问题。

#2 楼

我认为有两件事需要发生，可能并行发生，可能相继发生，可能是由不同的人，也可能是由同一个人。猜测，面试官对B以下的B比A更感兴趣，因为A将严重依赖于所涉及的文化/公司。也就是说，在生产中发现的缺陷。上面的2、3和4部分中的第1步涵盖了这一点。

B）根本原因分析，可能会反馈给A。具体地说，您需要了解为什么在质量检查中未发现问题。如果这很简单，例如缺少一个测试用例，则添加该测试用例，验证该测试用例可以找到问题，然后在获得修复后重新运行回归并部署。 （您还需要首先了解为什么缺少测试用例，并解决由于相同原因而可能缺少的其他所有测试用例。）但是，也有可能找不到问题的原因这是因为出于规模，配置或其他原因，无法在测试环境中找到它。然后，您需要进行成本/收益分析：更新/复制/在任何测试环境中需要花费什么（时间，金钱，技能，长期维护等），才能找到问题所在，以及什么是原因好处？是否存在您现在找不到的各种问题？长期以来，您是否需要担心这些？例如，生产环境的增长速度是否比测试环境的增长速度快得多？

#3 楼

首先，当在生产中发现缺陷时停止责备游戏。
解决该问题，并尝试通过配置或如何应用变通办法解决它，与此同时触发具有所需日志和跟踪记录的研发。
让研发部门对他们的查询进行调查并提供支持。
分析其对生产的影响并提供修复日期。
在R＆D实验室
在实验室复制适合部署发行版补丁/软件
然后进行回顾，使RCA输出为动作点-如何确保不再出现类似问题
当然可以在Automation Suite中添加功能案例。

#4 楼

首先了解到，在生产环境中，这个世界上没有哪个软件的缺陷为零。
不要再担心自己或团队生产的缺陷了。在生产中完成的错误。
进行清晰的根本原因分析。
如果该错误影响很大，请检查是否需要将发行版角色恢复为先前的版本。
检查优先级和严重性错误。
与业务分析，开发团队讨论该错误。
从开发团队获得明确的修复程序，在您的UAT中运行它，然后将其发布到生产环境中。
检查该错误是否有任何新影响。
记录该过程，进行修复并将其制成文档。
通知客户并要求道歉。

#5 楼

这个答案的重点是“而不是在质量检查阶段”。想要怪别人的倾向。像质量检查一样。但是，就长期修复和提高质量而言，这无济于事。取而代之的是，它创造了或继续存在着一种有罪，指责和防御行为的有毒环境。几乎没有改善质量的方法。实际上，只是在开玩笑-除了命令和控制，而且很少关心未来的情况下，您几乎无法“使人们”做任何事情-您应该做的是成年后聚在一起并遵循此处其他出色答案所指示的步骤。同意所有人都希望改善未来，并同意任何一种责备游戏都会适得其反，应该公开呼吁（当然很好）。通常称为领导，可以由任何级别的任何人担任。

#6 楼

我很惊讶地看到每个人都在谈论缺少测试用例的测试人员/质量检查人员。大多数情况下，它是要求的问题。我已经进行了研究，甚至将数据备份了，大约有30％的时间，这要么是缺少的需求，要么是模棱两可的需求，而且很多时候，开发人员甚至在实施之前都不问问题。

请考虑进行质量检查，因为警察就像您不能为一名平民配备一名警察。这是相同的比喻。质量检查人员在那里进行检查，并确保组织中的每个人（从BA到开发人员）都必须正确完成工作。就责备游戏而言，它取决于组织的文化。如果这是一种不成熟的文化，那就一定会发生。

#7 楼

每个软件测试服务公司都在生产环境中发现缺陷时（而不是在QA阶段）时不时遇到此问题。以下是应牢记的几点。


在生产和测试环境中重现问题。
如果仅在生产环境中发生问题，则可能是由于配置问题所致。
另一方面，如果它在质量检查环境中发生，则检查该问题对应用程序的影响。
调查该问题，以找出该缺陷存在了多长时间。故障单修复程序，并列出可能产生更大影响的区域。
如果问题正在影响更多客户，则应用此修复程序并将其部署在QA环境中。
如果已应用的修补程序运行良好，则应将其部署到生产中，并应进行发布后的健全性检查，以免再次发生。
进行回顾会议。
应注意的事项：
1。优先工作，并尝试从过去已经发生的错误中学习。
2。分析导致问题发生的因素，例如可能是由于开发不佳，功能开发测试的紧迫期限，这样就不会再次发生。

#8 楼

在产品中始终发现错误。尤其是当上市时间成为竞赛并且测试的重点在于给定的很少时间而不是应用程序时。因此，作为测试人员，我们需要保持自我意识，并利​​用给出的工具和情况做到最好。

首先，要了解测试人员没有错误，所以不要它亲自。事实发生后，事情往往看起来很明显，所以不要对你有所了解，我不能太强调这一点，控制你的自我。许多人错过了该错误，并且许多因素导致了该错误。可以考虑的事情是，一切都保持稳定之后，您可以从发行版中吸取一些教训。

其次，获得有关错误的信息。修复程序完成后，它如何发生并与开发人员一起获取，以便您可以了解错误的发生方式以及修复程序的含义，从而可以围绕它进行测试设计？将测试添加到回归套件中，或者如果有一个旨在捕获该错误的测试，请对其进行重新访问并进行相应的修改。尽你所能。快速修复和发布是将错误引入产品的最常见方式。急于解决问题并将其付诸实践的努力有时会阻碍我们的思考。控制情绪并集中精力清晰思考。

这不是在指责别人。这是关于共同创造最好的软件。只要团队理解，一切都会好起来的。