软件测试员应如何处理发行版中遗漏的缺陷/错误[重复]

#1 楼

您将永远不会涵盖所有可能的测试用例。


在代码中发现了很多缺陷。他们大多数都已修复。


有任何与这些相关的错误。您是否指出了未解决的问题的可能后果？


我进行了分析，并向利益相关者提供了重要信息。


有人读过吗？您是否指出了您没有涵盖的内容？


现在，客户发现很多错误，客户对测试感到失望。


同一地区？有什么可以改变的吗？当被告知时，您是否意识到在测试方式方面可能会改变的其他事情？

您被分配了一些小产品。我猜可能是在生产中发现了一些错误，因为它们总是存在的。重要的部分是从中学到东西。不要为错过的事情而战，只是从中学到东西；不要再错过同一件事。继续做好。在您的经理和利益相关者眼中再次树立您的声誉。可能需要一些时间。他们也可能没有意识到测试的细微差别。难道他们不像对待开发人员一样对待开发人员，不是吗？

您说的是有经理和利益相关者。客户是另一家公司吗？他们是否进行用户验收测试。他们可以看看它，然后再上线吗？您是一个人，您还是整个团队，都会发现所有可能的错误。赶上那些可以学习，继续前进的人。

#2 楼

因此，我也可以举一个例子说明我们的情况。我们没有完全相同的问题，但是在生产中我们也发现了很多问题，过去我们遇到了一些麻烦。在某些情况下，我们如何提高质量

1。找到所有错误，并为其创建测试用例（至少对于测试用例而言）：对于我们创建的错误，我们为其创建了测试用例。基于带有标记为“高”，“非常高”或“严重”的错误的发布策略，我们创建了测试用例。但是，我们还使用已知的错误扩展了测试用例。例如：例如，不幸的是，购物卡不允许使用万事达卡通过信用卡付款（这是一个错误）。在这种情况下，我们使用万事达卡创建了测试用例，还使用了其他付款方式（签证，借记卡，预付款等）。此外，我们还检查了增值税（VAT），并以某种方式扩展了E2E测试用例中的测试用例（例如，使用浏览器firefox上的基于Web的应用程序进行了付款，用户再次使用了Safari来检查其移动应用程序版本中的购物卡） 。之后，您可以（尽可能）使这些方案自动化，并扩大您的测试方案。我们这样做了，并根据测试报告向我们展示了产品负责人。

2。用工具记录探索性测试：对我们来说，记录所有测试用例也很重要。我们使用的工具是HP ALM。但是我们想记录场景，因此我们使用了三角柏。 Tricentis能够捕获所有步骤。这非常有帮助，因为我们还遇到了一个暂时可用的国家/地区的问题（有一个选择框，必须显示30个国家/地区，但一个国家暂时在误导-这确实很奇怪）。使用此工具，我们捕获了所有测试场景，甚至创建了测试案例。这是一个很好的帮助，因为它节省了时间，并且以某种方式是“证据工具”（以防该国不再可用）。

3.让用户参与您的测试范围（或业务部门）：尝试邀请真实用户参与您的测试方案。这也可以是业务部门。因为有时测试团队只是热衷于执行已定义的测试用例（“测试盲目性”）。但是用户或业务部门做的工作完全不同，并且知道使用该应用程序的不同过程或步骤。例如，作为测试人员，我们在文本字段中手动输入值，业务部门很懒，只是在字段中复制了文本值，在此应用程序中，我们抛出了异常。如果没有业务部门的参与，我们将永远找不到错误/缺陷。

4。与开发人员交谈：有时，开发人员可以为您提供良好的示例，说明如何测试应用程序。我还将特别与他们讨论边界问题。例如，在文本字段中，仅允许使用char值。然后，您应该问自己作为测试人员，当您输入int值或仅输入特殊字符（例如@和％）时会发生什么。测试有很多技巧和事情要做。但是，开发人员可以提前解决一些问题！

5。与其他利益相关者讨论并制定测试策略：在我们的案例中，我们有两个测试部门。因此，IT部门主要只是测试所有者故事，因此将重点放在用户故事上。另一方面，业务部门正在做同样的事情（！）。只是再次重新测试相同的用户故事。嗯，可能很有用，但另一方面，我们没有考虑布局问题，语言问题，端到端功能不起作用...为什么？因为我们没有在测试策略/测试概念中定义它！因此，也许您应该再次检查您的测试概念，并与其他利益相关者讨论您的测试策略

6.产品在市场上有售吗？听您的用户：就您而言，我不确定您要测试哪个应用程序。在我们的情况下，它也是一个在市场上可用的应用程序。例如，在Apple Store中，您可以查看用户评论。一些用户抱怨并且对该产品非常不满意，其中一些甚至抱怨已知的错误。因此，我们在下一个测试会话中也考虑了这些评论。有时，用户的角度会对我们未涵盖测试范围的内容给出非常好的反馈。此外，您还可以为您的产品所有者找到好的建议：-)

因此，这里仅提供一些提示，但是对于我们来说，它有助于提高质量-当然，还有很多其他事情去做。您将永远不会停止测试，并且测试不会变得无聊:-)

但是，请您对正在测试的应用程序进行解释或提供更多信息。也许我可以给你更多的提示。

#3 楼

失败的最大问题就是不从中汲取教训
如果您
认识到失败并制定解决问题的计划和未来的事件，管理层将不胜感激

他们说所有这些特定的单词：

您粗心吗？
您不值得问？
您有风险吗？

或者这些单词是您的根据您-非常有效-的感觉而受到如此恶劣的对待？他们也许还说了些什么

您怎么错过了这些？
为什么您没有在客户面前检测到这些？

是什么，让我们面对现实，这是合理的问题！但是他们可能很粗鲁和讨厌，将其表述为“到底是什么，您怎么可能会错过这一点”，这将带给您那些非常人性化和非常正常的感觉。专注于产品质量。
与管理层讨论计划：

根据客户使用情况衡量质量
更快地从客户那里获得更多反馈
从反馈中学习什么大不了的地方
进行更多的测试
进行更适当的测试
复习单元测试以及UI测试

不要仅仅出于“意图下次再彻底”。如果没有解决已发现问题的具体计划，它们就会重新出现。如果他们这样做，下次您将遇到麻烦。错误可能是第一次被接受。重复一遍，您可能会被解雇。

#4 楼

这可能是一个棘手的情况，尤其是如果您与从未与测试人员合作过的人一起工作，或者通常没有太多软件开发经验。

我认为您和您有一些重要的观点同事需要认识到：


您将永远不会涵盖所有可能的测试用例。那甚至都不是工作，因为那样的话，您将非常无效，只专注于无关紧要的事情。找出最有风险的方法，然后主要进行测试。
您不是质量检查人员，没有决定团队中的成员，预算中没有发言权，也没有决定截止日期是什么时候。但是所有这些都会影响质量。您是在特定情况下尽力而为的测试人员。如果您没有时间讨论一些重要的测试案例，则应将此问题传达给团队，并让项目经理做出决定（并对结果负责）。
整个团队应对最终结果负责。如果您或其他任何人感觉到您是最后一位可以发现系统中隐藏的所有错误的人，那您是错的。您会错过一些东西，您会忘记测试一些东西。您和团队中其他成员越早意识到这一点，您就越早找到方法，当一个团队将bug投入生产时，团队如何将这种情况最小化。这可能意味着开发人员从单元测试开始，他们可能会引入代码审查，您可能会得到一个新同事，更多的测试时间等。无论采用哪种解决方案，这都可能是团队合作而不是个人的努力。
但是，前面的观点不应误导您以为您不能做更多的事情。有改善的方法。您提到客户端发现了其他一些错误。太棒了，看来客户知道他们想要从系统中得到什么。在系统投入生产之前，找到与客户交谈的方法。一起测试。让他们进行UAT测试。让他们在最终决定是否通过前一天使用您的测试环境。

可能还有更多，这些只是我现在想到的一些要点。总的来说，质量是团队的努力，而不是个人的努力，无论您对测试技能有多自信。找到其他方法可以进行更多测试的方法，并且所有人都会更成功地发现错误。

#5 楼

所有其他注释已经相当全面地解释了这种情况和解决方案，但是我只想添加一些想法：


，并在代码中发现了很多缺陷。它们中的大多数都已修复。


在这里您必须问自己一些问题，


这些错误本质上很重要吗？
识别这些错误是否需要付出很大的努力？

正如许多线程中所讨论的那样，缺陷编号不是衡量测试效率的KPI。很好，作为测试人员，您遇到了很多缺陷

，但是您应该认为，这是否掩盖了真正需要检查的区域？。

有一种叫做“缺少错误谬误”表示错误修复与产品本身不稳定或不值得使用无关紧要。

您可以做什么？

这种情况可能是或不可能是您的错误，您应该验证是否

1。您有足够的时间测试产品吗？

如果没有，您应该在批准QA通过之前将其明确告知管理层。您应该坚持有更多的时间，除非您有足够的时间来实现公平的测试范围，否则不要发布产品。

如果没有更多的时间不可行，则应在清楚记录之前或与利益相关者进行沟通。发布

如果您没有足够的时间进行完全回归，还应该尝试进行烟雾测试和健全性测试。

尝试自动化回归测试，这将减少您在下一个冲刺中的工作。您将有更多时间专注于新功能

2。您有足够的支持吗？

如果您是唯一的质量检查人员，并且测试任务超出了您的能力范围，请进行适当的交流并要求更多资源。

3 。您是否有适当的验收标准和文件？

无论问题如何正确沟通，都不要怪自己。如果用户故事缺乏适当的接受标准，则应进行回顾性讨论，并明确说明您缺少的内容。索取正确的产品文档

4。了解您的自我价值

质量检查的作用与业务密切相关，因此功能很强大。不要犹豫，索取更多详细信息，支持，讨论问题等。强大的质量保证不是及时完成任务的人，而是拥有高质量软件流程的人。

无论您做什么记录，在需要时准备说“不”。要求在需要时进行澄清，如有需要，建议对整个SDLC进行改进。不要退缩

摘要：


正确传达要求
在需要时寻求支持
准备对在没有足够的时间或文档的情况下进行测试
从错误中学习
使回归测试自动化并更加专注于关键区域
在开始适当的测试之前总是进行抽烟和健全性测试
进行回归并在发布产品之前进行跨浏览器测试
不要害怕问并拒绝
如果构建不够稳定，不要害怕拒绝构建

#6 楼

但是，不可能进行详尽的测试。我们作为一个团队考虑以下事实，这些事实可能会影响测试的范围：




与业务分析师的有效沟通：我相信测试人员应该对测试内容有适当的了解。应该向测试人员说明客户面临的问题以及可能的所有解决方案以及为什么选择此解决方案。测试人员应仔细阅读BRD。测试人员应具有与BA相同的领域知识。测试人员应与BA团队进行清楚的对话。他们还可以在此阶段提供有关范围未命中的信息。这样就可以尽可能减少需求收集阶段的泄漏。
尽管如此，测试人员还需要阅读FRD，FSD，并且应该了解我们作为一个团队如何为需求提供功能性解决方案以及该解决方案的可行性。

与开发人员的交流：测试人员不仅可以提供服务，还可以在开发部分提供输入，开发人员还必须扮演一定的角色，以提高产品质量。质量责任不仅是质量保证，而且是整个团队的责任。测试团队可以实现“预防错误”模型，而不是“查找错误”模型。例如，对于Web应用程序测试，我们作为测试团队构建了一些通用的组件清单和通用的验证清单，所有开发人员都将在开发时参考这些清单，并且很少有机会在任何构建中遗漏那些东西。当任何功能遭到破坏而团队需要支持时，测试人员和开发人员都有责任承担其工作的所有权，而不是玩非常规的游戏。在开发人员和测试人员之间应该清楚沟通错误，复制每个错误的步骤。如果任何错误造成的障碍太多，并且无法复制，那么测试人员应该与开发人员沟通该错误，因为开发人员是知道代码中写了什么以及导致该缺陷的代码部分的人。

理解从开发角度来看可能错过的一切：正如以上所述，开发人员大部分时间都知道他们的代码的哪些部分在某些情况下会引发异常。因此，如果测试人员可以判断系统将在何处发生故障，则最好具有测试人员的素质。 API测试应由测试团队执行。测试人员应具有构建产品平台的经验/知识。

了解系统的数据库体系结构：据说性能测试人员应该知道什么是“内幕”。数据是重要的公司资产。如果当前的方法还不够，测试人员可以测试数据库并提供他们的输入，那么对于任何产品来说都太好了。测试提供了早期发现缺陷所需的具体反馈。测试数据库还支持进化开发。

与产品负责人的沟通：重要的是，测试团队必须不断更新产品负责人的测试范围，没有。缺陷，这些缺陷是高度关键的，中等优先级的，低优先级的，如果我们提供解决方案而不解决缺陷会带来什么影响。发布说明不仅会被撰写，而且还应该向产品负责人解释发布说明，并且产品负责人应了解我们在此版本中提供的质量状况。

与Peer Testers进行通信：有时，由于测试团队之间的沟通含糊不清，因此缺少bug。团队目标应该明确，每个人都应该有清楚的理解，并且应该以相同的动机开展工作。每个团队成员都应该讨论他们在日常工作中面临的困难，他可以解决的问题以及团队可以添加到过程中的解决方案。如果团队成员之一正在休假或迟到，并且造成障碍，则团队应制定策略并明确责任转移和转移责任的所有权。

编写用例用例，测试方案，测试用例及其映射：这是任何QA的基础。但是会根据不同项目的要求而有所不同。但是我建议先写下用例，然后再编写测试方案。用需求映射用例。如果对用例不存在需求，则请咨询BA或产品所有者，并在范围内添加该需求，然后将需求与方案进行映射。用测试用例映射方案。这样可以使图片清晰明了，减少出错的机会。即使您错过了要求，也可以抓住它。如果您错过了任何功能检查，则可以在方案审查中将其捕获。如果您错过了任何特定的测试用例检查或任何特定的前提条件，则可以很容易地找到它。

执行和跟踪：测试仪是系统缺陷的所有者。将缺陷记录为测试用例的错误是测试人员的工作之一。如果缺少测试用例，则添加测试用例。如果找到任何测试用例，则捕获并添加所有相关的测试用例。及时从开发人员处解决错误。决定何时由哪个缺陷小组承担得起的费用，以及何时应完全解决该问题。

从过去的错误以及同行的错误中吸取教训：您工作的任何档案中始终需要这样做。
同行和领导的复审：
第二天或后天对自己任务的复审。（如果负担得起的话）：

#7 楼

在这里可以考虑一些事情：


创建某种覆盖率矩阵或文档，在其中确定您将在测试用例中涵盖的内容和将不会涵盖的内容。然后可以在测试之前与您的客户达成协议。这还可以防止/防止您错过任何（重要）功能，因为客户会突出显示他们希望您在此功能中包含的任何内容。
获取屏幕快照或测试视频的证据。这样，您可以证明自己确实进行了所有测试，并且在测试时它们还可以。
修复缺陷后，重新进行测试。您提到您发现了许多已解决的问题。这些修复程序可能会在以前很好的功能中引入新的问题。无需重新测试所有测试用例，但您应该重新测试相关功能，以前失败的功能，高风险/重要功能等。

如果您这样做并在某处进行了记录或报告，您应该能够（再）从客户那里获得对测试工作和价值的信心。

#8 楼

1）“测试”是一个主观术语。具有质量检查部门的视频游戏公司会对其游戏进行测试，以查看它们是否在指定参数内正常工作。同时，手忙脚乱的敬业玩家总是会发现一些漏洞利用或作弊手段可用于速跑或其他。这个人只是在花更多的时间来研究系统，而这对QA而言对公司而言不会节省成本。而且，有时他们以不想要的方式使用系统。 （例如，原本打算玩和玩的游戏突然变成了原本不适合的速度运行）。

因此，您必须首先让客户向您解释错误和他们发现的问题。如果他们发现除非有人真的在寻找麻烦（IE：在正常的用例场景之外），否则它们不会真正出现的东西，那么他们就是在“测试”的想法，而您的想法就是不在同一页面（不是苹果到橙子）。

2）“测试”应该以田口风格进行，即IE：您拥有系统应执行的理想参数，但还应对其进行半测试-晦涩难懂的使用方式，可能会导致他人（ab）将其使用。

Taguchi是日本的统计人员和流程优化师。他提倡制造能够在非常广泛的（ab）用例场景中运行的机械，然后对其进行微调以使其在最佳条件下工作。

EG：您可能拥有理想的电池在-20C至100C的环境中发挥功能。他会提倡设计可在-50C至150C之间工作的电池，以创建更广泛的（滥用）用例范围，以涵盖真正使事情变得不正确的客户，然后对其进行调整使其在-20C至100C之间更好地工作，然后对其进行进一步优化以达到在最常见的情况下，客户会使用它（如果大多数电池用户会在10C至50C之间使用它），则效果最佳。

您必须确定这对项目是否有用。通常，编程公司会因为过度设计产品而受到打击。 （例如：他们需要一个简单的日历小程序，但是负责使其成为超级鲁棒日历小程序的负责人却花了很多时间。）但是，然后，抓住22 ，您就可以按照规范（客户想要的）构建东西，然后发现他们正在使用超出他们给您的规范。

例如：他们忽略了告诉您他们想跟踪电子邮件地址针对客户的CSR应用。因此，他们的CSR开始使用地址输入中的第4行输入电子邮件。但是，某些地址确实确实需要全部4行（特别是如果它们具有“护理” / c / o标头行，或者需要自己的行的公寓编号系统）。然后，公司抱怨第四行是一个奇怪的电子邮件数据跟踪位置。好吧，是的，不要开玩笑..在设计的原始范围之外使用了它。

因此，您需要与抱怨该项目存在错误的人坐在一起，并弄清楚它们是否真正存在是由于不符合设计规范而导致的错误，或者是由于在未在范围内概述的情况下使用项目而导致的错误。

3）基于上述...拥有良好的业务分析师/项目经理将成败一个项目。 BA可能从一开始就只是对系统进行范围界定。您正在按照他们给您提供的示波器来组成测试方案，系统测试还不错。.但后来您发现，在为自行车进行测试时，客户实际上想要一辆摩托车，并抱怨为什么没有节气门而没有。

因此，我将回到您的系统规格，看看您是否真的创建了用例方案来满足所有预测的典型用例。

EG：如果有日期输入字段...，请设置一个测试以确保它仅接受日期。这很容易。您可以设置测试以输入字符串和数字以及所需要的功能。它的范围是一个可选字段。然后客户返回并抱怨该字段需要输入。.du，它没有被限定为必填字段，所以...

如果您按项目范围设置用例和测试，那么BA可能会从一开始就对项目进行范围界定，或者客户一开始就无法满足所需范围的问题，或者某个客户试图以一种不想要的方式使用（滥用）系统的问题。可能全部都是3。

因此，去与客户交谈，看看他们在抱怨什么，看看他们是否对保留该项目从未做过的奇怪事情有所保留。

写下他们遇到的所有问题，然后为每个问题分配某种“可能性”因素。这给出了某人进行该操作的可能性的想法。如果这是一个不太可能的动作，那么机会就更大，您可能也没有对其进行测试。.b / c成本效益来自测试80％的人使用的20％功能，而不是80％的人使用的功能具有20％的人使用的功能。

基本上，客户会期望完美。随着时间的流逝，这种情况可能会发生，尤其是在敏捷的编程环境中。 （即：每次迭代都会添加新功能并修复当前的错误，因此客户抱怨只需要提供反馈并等待下一次推出/更新。）

但是，没有人能做到完美。 QA测试人员需要付费才能涵盖最常见的情况，例如驾驶游戏，驾驶员可以在树上驾驶……哎呀，这是一个需要解决的错误。但是，有人发现了一些漏洞，他们可以同时踩刹车和踩油门，并同时在控制器上左右滑动（这不可能，但键盘允许他们踩踏），以便作弊并立即加速..赫克会在质量检查中发现这一点吗？

所以，与人们交谈，弄清楚它是否是有效的错误，或者是“你们手上有太多时间并提出了晦涩的漏洞利用方法”事物类型。

您的公司无法在质量检查上花费无限的时间/金钱，因此您无法找到所有情况。如果您对产品进行了测试以使其符合规格要求，那么您应该可以。如果他们在规范之外使用它，那么这是广管局需要解决的问题。

如果您没有在规范中进行良好的测试，那么您需要坐下来BA弄清楚他们如何帮助您更好地进行用例测试。 （有时，BA会写出晦涩难懂的规范，或者使用对程序员没有意义的高级术语，或者会从客户的角度编写规范，而不是去做他们的工作并转化为技术要求。）

基本上，不是要说您没有干活，而是要说他们也应该把您当做替罪羊。

当有人对我的工作提出疑问时，我会去找源头与他讨论。他们来看看我们是否要比较苹果和桔子，并经常发现他们做的事情完全超出了预定范围。