问题是，即使尝试了很多负面因素，测试场景和使用复杂的测试数据，除了一些次要的UI /外观错误之外，我仍然无法找到产品中的任何严重缺陷。
部分原因可能是由于应用程序本身非常古老且非常成熟，稳定。实际上，许多测试人员已经对此进行了研究，并且已经发现/解决了严重的问题。在工艺流程中发现关键缺陷确实具有挑战性且困难。
我只是继续编写测试用例/脚本并执行它们，但是那时我没有什么可向管理层展示的。有时，这使我认为我没有为产品所有者提供任何价值，因为他们雇用我来确定重要的重要问题。
我测试的产品是一种财务应用程序，并且对财务数据进行了大量的文件处理。
如果找不到这些情况下该怎么办即使在对产品进行足够长时间的测试后，也不会出现任何严重的问题。测试人员的工作价值与发现的缺陷数量成正比吗？
，如果您只是向管理层显示测试执行指标，但还没有发现任何实际漏洞，那么这会使您成为无效的测试人员吗？在产品中？
#1 楼
测试不再意味着测试
感到困惑吗？我们可以想象！以前测试的目的很明确-“测试是出于发现错误的目的而执行程序的过程”。当采用敏捷和精益开发时，这种情况会发生变化。
阅读更多...
我认为测试宣言在正确的一端。着重于防止缺陷而不是发现缺陷。如果缺陷确实达到了生产要求，则进行根本原因分析并防止将来发生类似的缺陷。
阅读：
https://less.works/less/technical-excellence/thinking-about-testing.html
https://moreagiletestingmanifesto.wordpress.com/2015/08/02/agile-testing-manifesto/
http://www.jamesshore.com/Agile-Book/root_cause_analysis.html
http://moderntesting.org
评论
那么，换句话说，可以确保软件的质量吗？我感觉合理。
–桑迪·查普曼
16年8月21日在0:48
#2 楼
我想解决问题的报告方面。您说...我只是继续编写出色的测试用例并执行它们，但是那时我没有什么可向管理层展示的。有时候，我觉得我没有为产品提供任何价值
即使在完美的世界中，该软件也使开发人员可以100％摆脱错误并拥有完整的功能（例如开发人员：“ HAHAHAHAHAHAHAHAHAHAHAHA”），这根本不是事实。是的，当您在第11小时发现关键任务错误时，那真是太棒了，而您就是英雄。但是，当您执行所有出色的测试用例并且没有发现任何缺陷时，您所产生的价值就相等或更大。这就是质量保证。
在我为“ Tester”工作的公司中，这是一个肮脏的词。相反，我们有“质量检查”小组。这是因为业务并没有真正从测试和修复错误中受益。拥有无错误代码的业务甚至没有真正受益。不，企业需要知道它具有无错误的代码。我曾在无法满足此需求的环境中工作，并且企业对其产品没有信心。在这些环境中，一切都崩溃了。
您无法自信地估计新功能所涉及的工作。因为错误可能隐藏在关键组件的表面之下。
您不能有效地测试变更集。因为没有可信度基准，每个测试都必须是完整的回归测试。
您不能将产品出售给认真的买家，因为当他们问“可以做XYZ吗？”您的工程师说“好吧，从理论上讲。”
我要说的是，在每个开发周期结束时您向管理层提供的任何报告的首页都不应与软件的位置有关。失败：
**Defects Found**
BUG-1: **Features Verified**
Can open a new account [PASSED]
Can close an existing account [PASSED]
Can issue a transaction [FAILED, BUG-1]
Can withdraw from a bank [PASSED]
Can withdraw from a ATM [FAILED, BUG-2]
.01 of every transaction is transferred to Joe A.'s offshore account.
BUG-2: Rounding error when withdrawing from an ATM on Tuesday.
相反，真正重要的交付物是您已经证明该软件可以完成的工作。并且可以正确地做。是的，未解决的缺陷是此报告的一部分。但是它们并不是真正重要的。真正重要的是：
**Features Verified**
Can open a new account [PASSED]
Can close an existing account [PASSED]
Can issue a transaction [PASSED]
Can withdraw from a bank [PASSED]
Can withdraw from a ATM [BACKLOGGED]
然后，在解决了这些错误之后。您发布的质量检查报告如下所示：
q4312078q
这就是管理层应该查看的文档。
评论
关闭BUG-1。按设计工作。真诚的，乔·A。
–戴尔·埃默里（Dale Emery）
16年8月20日在0:05
在硬件中工作：这是产品验证和验证的一部分。您必须证明，记录和报告设备的每个部分都可以正常工作并按照书面标准执行操作（甚至创建最终的性能规格编号），然后在产品上完成安全/合规性测试。其中一些数据甚至是要出售产品所需的合法测试证明。
–user2943160
16年8月20日在2:24
#3 楼
我的测试座右铭一直是这个。 “测试的目的是降低实施风险。”我总是发现，仅根据发现的错误数量对测试组织进行评分时，这是非常不准确的。如果您发现大量错误，那是因为您很棒，或者您的开发人员很糟糕。或者在您的情况下，如果测试没有发现错误，那是因为测试很差（不是您的情况）或您的开发人员就很好（听起来像您的情况）。当您需要担心时是指您在测试过程中没有发现任何问题，但是在生产中发现了问题。只要最终用户没有发现测试团队没有发现的缺陷，听起来就好像您做得很好。
此时您可以做的另一件事是增强您的测试。您是否尝试过寻找可以改进应用程序的地方？
#4 楼
除了其他答案外，对我来说，重要的是您要确定是否确实让漏洞通过。您编写此代码的方式将使该软件似乎已在生产环境中启动并运行，因此请确定是否会报告错误。然后，您可以检查是否应该能够找到它们。最终实现自动化，而其他人发现它将是一个时间问题。手动测试可以编写脚本的内容是低端工作。我知道您也是在自己设计测试，但是我认为您可以通过逐渐摆脱手动执行测试并使之自动化的过程，来改善并向公司展示您的价值。当然，这取决于公司，但是大多数公司都重视那些希望自己提高自己，使他们的工作更轻松（并且更便宜/更快）的人。#5 楼
您可以增强产品。除了所有答案之外，
您已经知道了两件事。在这种情况下告诉自己，
没有产品是没有错误的。
测试是一个永无止境的过程。
也许有一些您处于这种情况的原因。您正在开发的产品可能是一个成熟的，长期开发的项目。许多QA /测试人员可能已经测试过该产品。因此，您可能不会在产品中发现很多错误。不用担心，总有改进的余地。将自己视为“新客户”，并记录使用该应用程序时遇到的问题。也要了解工作流程并尝试进行优化，例如，尝试减少一些不必要的任务，而这些任务会不必要地消耗系统性能，诸如此类。这些任务可能非常适用于质量保证测试人员/工程师。
#6 楼
我的测试座右铭是，质量检查总是发现错误，而不是客户\用户发现错误总是更好。可能是您正在测试的产品\特定版本\特定功能没有错误。如果是这样，那就很好。
只要您在执行测试时继续获得“通过”，就可以继续为测试编写新方案，并尝试使测试包涵盖整个产品-我没看到任何问题。
#7 楼
您的编码员可能只是个好人。测试已经完成，以便在客户找到bug之前先找到bug，然后您必须先查找bug，创建补丁，分发补丁周期。如果客户不抱怨bug，那么测试场景是正确的。如果客户发现应该在“测试/质量检查”阶段中检测到的错误，则说明您的测试有问题。
如果没有错误，则找不到它们。您永远不能证明负面的。如果您没有发现任何错误，就不要灰心，这是您的工作。
您还在测试失败吗？
如果有人尝试将字符串输入整数，会发生什么？测试溢出？
#8 楼
两个建议：您可以将范围扩展到可用性测试吗？
您可以要求程序员进行Litmus测试，即在其中植入一个已知的bug，但可能有些微妙，因为他们知道其中存在错误。 （我一直在测试测试仪）。您甚至可以将其变成游戏，它们可能会引入更细微的错误（难以检测或难以表征）。这使您更有趣，并向管理层确认您正在寻找错误。
评论
测试人员唯一的危险是测试人员的错误有时会进入产品中-我已经看到产品中存在一些错误-假期中我也打过电话-因为该错误已解决我输入的内容还修复了一个错误，该错误被认为很难修复（大约10年前），并且用户无法理解所有“新”功能的来源。
–史蒂夫·巴恩斯（Steve Barnes）
16年8月24日在17:47
#9 楼
要直接回答这个问题，不。衡量指标并不是衡量测试仪价值的全部。我认为，识别规范中未定义的用户流比发现错误更重要。 （性能，自动化），只要您还履行预期的职责即可。表明您正在尝试提高自己的技能看起来不错，并且可以导致发现新的错误类别。#10 楼
好。我看不到任何问题，因为您已经提供了产品背景，并且没有经过许多不同的QA严格测试，因此没有发现任何严重的错误。这里要强调的是，如果您花了相当长的时间看这个应用程序，发现错误的机会也会下降，因为作为一个人，当您每天看到相同的事物时，您会逐渐停止变得兴奋和热情。 />
最好在一段时间内尝试围绕功能场景进行规划。
测试用例是否涵盖了测试的所有功能方面？
尝试看看RTM（需求跟踪能力矩阵），看看它是否涵盖了所有内容。如果RTM不存在，请尝试准备一个。
看，有一个痛苦的事实。如果您没有发现错误，那很好，只要在生产部署后没有（或只有几个）问题得到报告。因此，请尝试提出一些想法，以确保测试覆盖率，并增强您对应用程序质量的立场和信心。
#11 楼
问题应该是如何在产品中发现良好的缺陷，什么是最大程度地发现有效缺陷的最佳实践？
每个人都有他们自己的自己独特的测试风格，请阅读
，您会发现它非常有用，并且您可以从本文中学到很多东西。
#12 楼
从根本上说，测试是一种保险活动。
它的主要工作不是要发现越来越多的缺陷，而是要确保没有在以后的阶段中发现的关键缺陷。将影响业务，并且更正/修复的成本会更高。
评论
您应该祝贺开发人员，并且应该告诉老板您的测试正在使开发人员步入正轨。您还应该说，如果不让开发人员垂涎三尺，他们的标准就会下降，并且会开始出现错误。嘿，我们可以换工作吗？我很想在一个知道如何编码的团队中工作。您可以每月为我找到这100个错误。我什至不再报告外观错误。
问题是，您的客户会发现比您更多的错误吗？您的工作是确保质量，而不是发现错误。如果实际上编码人员的质量是那么好，那么他们似乎就很擅长-这是一件好事，不是一件坏事。如果您感到无聊，则可能要启动新的计划，例如自动化测试等，这将为每个人增加价值。
您说：“我的角色/职位没有太多的性能，安全性或自动化测试范围。”您能对此进行扩展吗？难道您不知道如何进行测试吗？是其他人将其视为自己的工作并且不想得到您的帮助吗？
没有雇用您来发现错误和缺陷。雇用您是为了防止错误和缺陷进入用户的手中。必须有人进行此验证。