metrics - 跟踪和预测质量水平

Question

人们推荐哪些技术来跟踪新程序的质量水平？他们是否会采用定义不明确的术语（例如“质量水平”），对其进行量化然后进行预测？目前我使用错误率和 S 曲线，但我正在寻找其他方法来评估、估计和预测质量水平。

Answer 1

我不确定如果没有可以与之比较的东西，计算你的错误会做什么。如果你制作的软件非常难并且有很多边缘情况怎么办？你需要某种比较...

即使其他答案之一显然是一个笑话，代码审查也可能是一个好主意。如果你有太多错误，请雇用更好的工程师或让他们编写更少的代码。

编辑：在考虑评论后添加...

每个虫子都像一个独特的吸雪花（吸雪花？）。它们对您的客户和开发人员有不同程度的影响。我至少会考虑到这一点。也许增加严重性（衡量客户推动修复的措施）和修复它所花费的工程时间可能有助于提高准确性。我想我担心的是，在开发软件时，这仍然是对“质量”的过度简化。

可悲的是软件质量！=产品质量。最近发布的一款名为 Fallout 3 的游戏赢得了大量奖项并赚了很多钱（至少我认为），但至少在 PC 上也是一大堆垃圾。

只要确保您正在跟踪和优化正确的事情。跟踪 # 个错误与时间只是跟踪 # 个错误与时间。进一步阅读它需要某种程度的假设，无论是正确的还是不正确的。

你的目标是什么？错误只是软件质量的一部分。如果您想继续支持您的软件，可维护性是关键。很多时候，如果您的编码人员匆忙做某事，错误修复会使事情的可维护性降低。这反过来又使未来的修复和功能变得更加困难，并且修复可能会添加新的错误。

Answer 2

您在寻找这种措施吗？

更严重的是，对我而言，代码质量与可维护性有关：

• 修复错误，添加/删除/修改功能是多么容易，
• 重构有多容易：是否有可用的回归测试套件？
• 多少技术债？

请记住，您编写代码一次，但您阅读了多次。

Answer 3

你做单元测试吗？单元测试的代码覆盖率可以作为质量衡量标准。

Answer 4

这在很大程度上取决于您尝试进行什么样的比较。如果随着时间的推移您正在查看单个项目并且团队没有改变，那么错误率可能是有意义的。但是，如果你在比较不同的项目，不同的团队，真的没有办法比较 bug 率之类的东西，因为你实际上是在比较已知bug 的比率。一个团队可能比另一个团队更擅长识别错误，从而使他们的错误率看起来更高，但他们确实是软件质量更好的团队。