您使用什么措施来评估软件质量？

#1 楼

我在计算缺陷时可以看到的问题是，所有缺陷都不相等。当您发现一个bug时-您可能会改变发布截止日期，因为showtopper会导致客户完全丢失数据，但是即使是几十个外观错误也不太可能这样做。

另一方面-您也不能只打折扣化妆虫。如果该装饰性错误是您公司名称的拼写错误，或者是使句子无意中出丑的错字在首页中间爆炸了？突然之间，所有外观缺陷也不相同。

同样，您可能已经“完成了95％”-但是剩下的5％是关键业务功能，并且在过去五个月中，一个又一个bug阻止了它，现在不得不向高级管理层解释，仅仅因为百分比看起来不错，并不意味着项目状况良好，您确实需要更多时间。您不仅需要考虑错误的数量，还应该考虑它们的位置以及尚未进行测试的位置。如果由于少数漏洞导致无法访问大多数应用程序，或者该特定项目需要冗长冗长的数据设置，则每个测试人员小时的缺陷率也可能非常低。要基于这些措施发布（或更确切地说，不发布）决策，您需要确保所使用的措施真实地反映出您想要度量的内容-正如我们所看到的，仅缺陷计数并不能很好地做到这一点。

现在该发布我最喜欢的论文了：Kaner和Bond的“软件工程指标：他们衡量什么以及我们如何知道？”阅读本文并运用其中的建议将帮助您评估选择的措施。度量标准很差是非常危险的-它们将成为吊住您的绳索。我曾在一个团队中工作，该团队因无法反映风险的度量报告而遭受多年损失-尽管我们有时有时会使测试和产品变得更糟，但我们仍面临着使数字更好的压力。 :(不过，要反对既定措施确实很难。

那么，还有什么其他选择呢？好吧，Gojko Adzic列出了一些有用的建议。我真的很喜欢热图的想法-无论是衡量哪些文件与大多数缺陷相关（我刚刚想到，我们可以通过收集关于JIRA的信息来在工作中实现此目的-我们将Subversion签入与每个问题相关联，因此，如果我们可以将问题归为bug，我们可能会有一些有趣的数据。不知道会有多少工作！），也没有功能性的指标来表明您在应用程序区域中进行了多少测试，而感觉却需要多少。组件能力矩阵也很有趣-能够确定对于业务关键的区域存在阻塞性错误是一个令人信服的论点。我见过的一些方法：


确定通过应用程序的关键端到端路径。创建一组精心选择的验收测试，涵盖通过应用程序的关键路径-对于一个电子商务网站，一个测试可能是客户可以订购和结帐。在开始测试之前，所有测试都必须通过。 （如果仔细选择的话，这可能是一个很小的集合-一个小的集合更容易达成协议。）如果您经常遇到阻碍大范围功能的集成错误，则值得使用。在测试的前几天内，严重性为Y的错误的数量。这个没有用，我再也没有看到过构建版本的返回，这导致无休止的时间浪费在一个漏洞的严重程度上。
超过X％的计划测试用例被阻止。这是一个看起来很客观的项目，但实际上却很主观-也许一个项目的测试负责人编写许多简短的简单测试，而另一个项目的测试负责人倾向于编写较长的复杂测试。

我希望上述一些想法对您有用。我觉得这是一个非常有趣的领域，但是不幸的是，我有很多问题要比答案多。 （我认为测试人员应该以与测试系统一样多的怀疑态度来对待软件工程指标。

#2 楼

对我来说很容易。

满意的客户（即生产支持低）=高软件质量

不满意的客户（即大量生产支持）=低软件质量

还与团队交谈。正如其他帖子之一所述，并非所有错误的数量都是相等的。鼓励测试人员在质量下降时大声疾呼。他们应该比任何人或任何指标都要了解。

#3 楼

“如果要建造一艘船，请不要鼓动这些人来收集木头，分工并下达命令。相反，要教他们向往茫茫大海。 -Antoine de Saint-Exupery


警惕测量的内容。通过衡量并报告有关内容，您将激励人们进行善恶之举。很少有坏演员会（可能在不知不觉中）烹饪书籍，并给试图按规则行事的人们带来道德问题。当单元测试尽早发现开发人员时，他们不会报告该问题，而只是修复错误。通过（隐式地）奖励测试人员发现错误，您可能会无意中增加周期时间。

这里是您应该测量的内容。时间（从发现缺陷到签入并签收）
平均功能周期时间
敏捷性

您交付良好软件的能力取决于组织的健康状况。

#4 楼

这些是很好的基础，但是如果您专注于单元测试，则应该监视：


代码覆盖率（来自单元测试）

问题通过代码覆盖，很难从单元测试中选择能给您真正价值的百分比。 100％的覆盖率通常意味着您正在测试几乎没有失败风险的代码区域。通常，大约70％是一个很好的数字，它将发现大多数价值缺陷。但是，随着时间的推移，您可以自己计算出这个数字，如果覆盖范围下降并且发现更多缺陷，则可以要求进行更多的单元测试。但是，如果这个数字很高，而您又找不到更多的缺陷，那么您可能会想让它下降一点。根据我的经验，这实际上是一个错误过程的试用。

#5 楼

对于小型项目，我可以观察传入的错误率和已知缺陷的严重性/数量。