什么是衡量测试/测试人员效率的好方法？

我即将参加与管理层的讨论，以衡量我们作为质量保证组织的测试效率。这背后的主要原因是我们的团队有一半被外包出去了，我们的业务想提供一些关于我们效率/效率的指标，以便我们有基础数据可用来与承包商的服务协议进行合同参数谈判。

我已经提出了一些建议，并且我在该主题上发现的大多数意见都围绕着开发人员的效率：代码行，交付的故事点，引入的缺陷等。

但是测试人员呢？我们的测试主要是基于需求的，并且混合了手动，半自动和自动测试（不是因为我们还没有自动完成所有工作，而是因为某些事情在我们的测试系统中无法实现自动化）。

编写的测试数量是没有用的，发现的大量bug可以衡量开发不良，而不是有效的QA。

自动化措施（代码覆盖率，功能覆盖率...）可能很好，但是我认为它们比客户（我想这样做，对开发人员（作为开发人员，是否会意外破坏某些东西，我是否会知道）更有帮助），它不起作用）。

由于如果客户没有遇到问题，质量是好的，所以衡量QA团队和流程的有效性（而不是效率）的一个好方法就是衡量QA尚未发现的客户发现的错误。

该指标的主要问题是，在完成工作与开始拥有有意义的数字之间可能会有相当大的延迟。

在上一份工作中，我们使用了一些指标来评估质量检查：

• 发现的错误数量。我讨厌这个 对于开发人员来说，这就像“编写的代码行数”。
• 产生的自动化测试用例的数量。
• 功能测试中涵盖的总应用程序百分比。
• 登台与生产中发现的错误数量。

最后，您的质量检查小组的工作是在发现错误之前将其找出来。他们的指标应基于实际实现该目标的基础。如果测试用例的覆盖率低，自动化测试的数量最少以及生产中的错误率很高，则说明它们做得不好。但是，如果他们在找到产品之前很早就发现了错误，那么他们的指标应该很高。

质量检查应通过两个主要指标来衡量：通过质量检查可以在现场发现多少个错误？他们的严重程度是多少？

您也许可以对质量检查进行质量检查，以查找比dev-complete更接近发行版的严重错误。您可能可以在未完成测试的估计完成日期之前（针对每个功能）向质量检查提出要求。

虽然最后，我担心您会花更多的钱来衡量合同工的效率，而不是使用合同工节省的钱...

我工作的公司使用许多质量检查指标。

我觉得最相关的一个是代码覆盖率。像EMMA这样的工具非常有用，因为它们除了手动测试外还编写了全面的自动化测试。

无论您做什么，都不要专注于测试数量。这和每天的LOC 一样有用。

在项目执行期间，有许多方法可以衡量开发和测试阶段的性能。我们在项目中使用了以下措施。开发性能由4种流行的Code指标（可维护性指标，循环复杂度，继承深度，类耦合）衡量。对于C＃，它将在Microsoft Visual Studio中获得。对于测试覆盖率，Ncover / Ndepend非常有用。测试性能，无任何开发错误-由最后4个冲刺所产生。系统测试错误由过去4个冲刺所产生。在特定版本/交付的功能中未通过自动化测试。