这可行吗？这是一个公平的指标，还是我担心会导致功能障碍？还有其他可以/应该使用的指标吗？与我有关的一些问题包括定义错误是什么，由谁找到错误（仅在客户找到错误时才计数？），在旧版本中发现的错误如何计数，由需求差距引起的错误是否计数，当其他不受薪金标准影响的人（例如开发人员）在大版本发布之前提供帮助时会发生什么情况，查找所有错误与交付产品之间的冲突等等？
换句话说，是否有可以使用的合理性能指标？
#1 楼
将现金奖励与错误计数之类的指标捆绑在一起始终是一项非常冒险的业务，几乎可以肯定会引入功能障碍。希望他们做正确的事。假设您是一名测试人员，正与一个开发人员（恰好是您最好的朋友）一起工作，该项目计划在财年结束前发布（奖金期结束时）。开发人员的奖金与按时完成此发布有关。您可以确保发行版在发行后没有任何错误。
在发行前一天，您会发现一个不太严重的错误。你是做什么？您可以保持沉默，释放代码，以便您的朋友获得红利，并希望未发现该错误，从而使您获得红利。您可能会立即写出错误报告，导致您的朋友争吵并试图使您被否决，或者失去奖金。
这种情况总是在将错误报告用作指标和指标时发生。应用于奖金。
您已经指出了使用错误计数指标的一些缺陷。这是一个观点：
http://www.allthingsquality.com/2010/04/misuse-and-abuse-of-bug-counts.html
发布决策是业务决策。有时，发布代码以满足紧急的业务需求（即使其中包含错误）更为重要，然后再修复这些错误。您不应该为此受到惩罚。
不幸的是，对于个人奖金，没有好的系统必须与“指标”联系在一起。这种想法是：“如果我们将他的奖金与“指标”联系起来，它将正确地激励他，并且将是客观，公正地衡量他的方式。这种想法是错误的。然而，公司知道这一点，并且仍然继续迫使经理创建这样的奖金计划，每个人都会受苦。相信我-经理也没有意思。
如果还没有，请阅读Robert D. Austin撰写的“组织绩效的测量和管理”。他谈到了由度量/度量系统引起的功能失调。
我希望我的团队有权在所有情况下简单地“做正确的事”，而不必担心这会花费他们额外的金钱和
我强烈希望所有奖金都是根据公司目标（例如销售和利润）获得的，而不是基于较低级别或个人的收入目标。对我来说，这是激励个人并奖励他们的正确方法。不幸的是，我曾在很多公司工作过，否则我不得不这样做。
在您接受工作邀请后，您将无法说出这对您的效果如何，并且已经在那里工作了一年多了。
祝你好运！
#2 楼
除了其他人都说过的以外，用于提高性能的指标在软件界也是一个严重的坏主意。指标作为描述性工具很有用，但是我认为就是这样。
以下是其中的一些原因：
每个软件项目都是不同的。这意味着即使所有
相同的事物都经过测量，比较也将无效。项目A可能会按时发布，但几乎没有错误，但这是因为项目
很小，经过仔细的范围划分，并且是未开发的项目，其中项目B已经过时了，而且非常糟糕是那些资源不断变化的死亡项目之一
，没有人知道应该发生什么
，并且它严重依赖现有代码，并且有很多已知（和未知）内容错误。您根本无法比较错误计数，
延迟或其他任何指标-如果您正在测试的人
项目B，如果将这样的指标用于
，您将一头雾水您的效果评价。
每个指标都可以而且都会被采用。我知道在性能审查中相对于开发人员代码提出错误的地方
。为了避免伤害开发人员，所有小问题都将完全从系统中处理掉-除非测试人员不喜欢开发人员，否则所有赌注都被取消。什么是软件质量检查的良好KPI？ -总结了我对绩效评估指标的所有异议。我还建议与这个潜在的雇主讨论指标问题，并指出当您指出使用错误计数或其他此类指标来评估您的工作状况如何时，他们会如何回应。 （根据我的经验，领导和团队成员知道谁是杰出人士，谁是负重人士。如果他们认为管理层信任他们无需微观管理就能完成工作，那么他们会让管理层知道任何问题。） br />
#3 楼
您可以阻止带有已知错误的代码发布吗？如果您实际上无法控制要测量的事物，那么这是一个糟糕的指标。如果对企业来说正确的事情是发布带有错误的代码，以便更快地发布代码，以便用户开始受益，该怎么办？有时拥有某些软件总比没有好（但并非总是如此！）。如果该度量标准可以合理地反对为企业做正确的事情，那将是一个糟糕的度量标准。
我猜想，告知产品质量而不是控制它是您的职责。除非您被允许，授权和中止发行，直到所有已知的错误得到修复而没有影响，否则该指标将无法衡量您的工作状况。
看一下关于SMART目标（具体，可测量，可实现，相关和有时限的目标）的Wikipedia页面。为测试人员建议的许多指标无法实现，因为它们反映了不受测试人员控制的因素。测试是上下文相关的角色。负载和性能测试工作通常需要相对较少的bug进行大量工作-但是这些bug往往是真正重要的bug。测试具有明确要求的平稳运行项目以及编写出色代码的高级开发人员可能意味着很少提交错误，并且可能需要非常快速的测试工作。测试要求不明确的越野车项目可能意味着需要花很多时间提交许多错误的冗长的测试工作，尽管进行了出色的测试工作，仍然可能会漏掉错误。
Cem Kaner是一个受人尊敬的名字，他与他人合着了一篇有关软件工程度量的文章，重点关注测试人员。他提出了一种涉及定性分析的方法，考虑测试人员预期执行的每个任务，并定义对完成该任务意味着什么，然后对其进行评估。本文以以下告诫结尾：
我们还没有看到这种评估完全实施，也不知道有人完全实施了这种评估。一组测试经理已在开发使用这种方法的方法，并且其中许多人正在尝试
，以使其可以在工作中使用。
我们的直觉是，存在一些具有挑战性的权衡。这种方法的目标不是微管理测试人员的工作细节，而是帮助测试经理和测试人员了解测试人员能够完成哪些任务以及哪些任务做不到。通常，有很多
方法可以很好地完成任务。如果计分结构不允许这种多样性，那么我们将预测由于测量导致的功能障碍。
评论
好答案。尽管“博弈”一词具有消极含义，但这并不意味着该人故意在做任何坏事。如果您奖励某种特定的行为，则基本上是在告诉个人“多做（或少做）该行为”。因此，个人寻求最大化其奖金所基于的指标也就不足为奇了。如果生产中没有错误，请给我更多钱？太好了-我会确保生产中没有错误-也许我不帮助别人，也许我试图推迟发布，也许我会尽一切可能成为障碍。
–乔·斯特拉泽（Joe Strazzere）
13年7月25日在13:51
@JoeStrazzere-完全是。人们做的是有回报的事情，而不是管理层说的有回报的事情。而且他们避免了惩罚，而不是管理层所说的惩罚。
–凯特·保罗（Kate Paulk）
13年7月25日在15:34