qa建立质量指标与指标
您如何衡量软件工程的质量？ 我想这是一个永远都会辩论的问题。 解决这个问题的方法太多，以至于只找到一个答案是不可能的。 在本文中，我们将列出顶级工程团队一直在跟踪的与质量相关的指标，并查看何时以及如何使用它们。
但是，请注意，当您考虑它时，可能会怀疑质量本身是否是目标。 能够成长和改变行为而不会受到干扰的信心似乎更为重要。 在那种情况下，质量指标当然很重要，但是它们随时间的演变至少同样重要。
本文的目标是帮助工程团队更好地评估质量。 让我们进入工程质量指标列表。
本文实际上是软件工程指标高级指南的摘录。 无论您选择使用哪种指标，如果您想以无毒且有效的方式使用工程指标，都需要遵循一些规则。
有关该主题的更多信息，我建议阅读这篇文章 。
1.错误数量–可能按优先级或严重性
通常，错误的数量将在项目生命周期的中期开始增加。 在截止日期之前的几天或几周内（取决于项目的大小），团队将专注于减少bug的数量，直到bug的数量达到渐近线为止。 该渐近线最终代表了项目产品的整体质量。 因此，跟踪错误的总数（区分其优先级）是一个很好的指标。
但是，并非所有的bug都是一样的。 这就是为什么大多数团队将错误分配给优先级和/或严重性的原因。 例如，仅跟踪那些P1错误和P2错误可能会很有趣。 这取决于产品的成熟度。 对于新产品，您将希望专注于P1。 确实，具有很多P1的产品将被认为不起作用。
如果您不再有任何P1，但仍然没有P2，则用户仍然会遇到这些错误，并且可能会对他们对产品的认知产生负面影响。
如果您希望您的产品被认为是高质量的，例如在Apple的水平上，这实际上是在您解决了许多P3和P4错误的情况下发生的。 这是您需要达到的水平。 因此，现在只专注于跟踪对您重要的事情。
什么时候使用？
如果您的产品质量对您的业务很重要，则此指标非常有用。 如果是这样，您应该不断对其进行跟踪。 但是，如果您解决了所有P1和P2，则可能希望通过跟踪P3等来寻求更高质量的标准。
2.变更失败百分比
“加速”将失败定义为“导致降级的服务或随后需要补救（例如，导致服务受损或中断，需要修补程序，回滚，修复前瞻或补丁。）的更改”。 因此，此等级是导致部署总数失败的部署数。
请注意，此定义不包括部署失败的更改。 该信息很有用，但不是KPI的重点。
什么时候使用？
如果您专注于将频繁部署变成日常习惯，那么为了使它有价值，您需要将故障率保持在较低水平。 实际上，随着DevOps团队经验和能力的增加，该等级应随时间降低。 故障率的提高，或者说故障率很高，并且不会随时间推移而下降，这表明整个DevOps流程中存在问题。 它是整个过程中质量的良好代理指标。
3.拉取请求质量
拉取请求可以使您对代码库的整体复杂性有很好的了解。 代码库越复杂，以下度量标准变高的可能性就越高：
拉取请求中断构建或无法通过测试套件的时间百分比； 合并与拒绝拉取请求的百分比； 拉取请求的评论数–您不希望数字太低，但也不要数字太高。 此指标显示您的团队如何协作以及在拉动请求中是否吸引了足够的注意力。 它可以间接指示推送到生产中的代码的质量。
什么时候使用它们？
该指标并不是要衡量DevOps流程的质量（就 变更失败百分比而言） ，而是 要衡量 团队的工作和协作方式。 如何使用代码审查，这些审查有用吗？ 评估合并的请求与拒绝的请求请求的演变情况将帮助您了解您的团队是否随着时间的推移而有所改善。 您还可以按团队成员进行细化，以查看他们是否也在改进。
4.测试覆盖率
该指标只是您要测试的软件中的总代码行数与当前所有测试用例执行的代码行数之比。
以执行的代码行数衡量，通常公认的“足够的”测试覆盖率是多少？ 共识徘徊在80％左右-对于关键系统更高（关键的定义可能因行业，地理位置，用户群等而异）。
什么时候使用？
当然，您不需要100％的测试覆盖率。 但是，了解自己的位置并对其进行跟踪有助于查看您是否以速度为质量。 请记住，“ 建立在不良要求之上的高质量产品是劣质产品 ”，尤其是在测试覆盖率方面。
5.平均无故障时间（MTBF）和平均故障恢复/修复时间（MTTR）
这两个指标均衡量软件在生产环境中的性能。 由于软件故障几乎是不可避免的，因此这些软件指标试图量化软件恢复和保留数据的能力。
如果MTTR值随着时间的推移而变小，则意味着开发人员在理解问题（例如错误以及如何解决问题）方面变得越来越有效。
什么时候使用它们？
如果团队有一个特定的目标，这些指标将非常有趣：“我们需要在我们的产品上达到此MTBF或MTTR的水平。” 这将增强团队对客户提出的重要问题的响应能力，并有助于您为产品以及团队保持高标准。 为了提高这些指标的性能，团队可能会理解他们需要解决问题的真正原因，而不是简单的补丁。
6.服务水平协议（SLA）
每个团队都有自己的SLA定义。 但是，这是Airbnb使用的一种，您会发现非常有趣。 SLA是您的团队在特定时间内（例如，针对漏洞的24小时，对于严重漏洞的5天）修复并部署的拦截器错误的百分比。 您可能真正喜欢此指标的地方在于，它可以从用户的角度让您对产品质量有很好的了解。
什么时候使用？
该指标非常接近 MTTR ，但不仅限于软件故障。 它扩展到任何类型的错误。 同样，如果团队有一个特定目标使用此度量标准，则该度量标准将非常有趣：“我们需要在我们的产品上实现此SLA。” 该指标可提高团队的产品质量归属感和响应能力。 这就是Airbnb使用它的原因。
7.缺陷去除效率（DRE）
缺陷去除效率用于量化与产品交付之前发现的错误有关的最终用户在产品交付之后发现的缺陷数量（D）。 公式为：DRE = E /（E + D）
DRE越接近1，产品交付后发现的缺陷越少。 在整个测试程序中，平均DRE分数通常约为85％。 但是，由于有了全面而全面的要求和设计检查流程，预计这一比例将提高到95％左右。
什么时候使用？
该指标的用途类似于跟踪 错误数量 的演变 。 跟踪它们可能都是多余的。 我们对错误的数量有所偏爱，因为您可以区分现在对您而言重要的错误优先级，并且仍然对总体错误（不仅仅是趋势）有所了解。
8.应用程序崩溃率（ACR）
应用程序崩溃率的计算方法是将应用程序失败的次数（F）除以使用次数（U）。 但是实际上有几种计算方法。
每个用户的应用程序崩溃：此数字显示曾经遇到崩溃情况的用户数量。 该指标的可接受范围为<1％。 对于成熟的应用程序，此数字应该较低，因为功能会更稳定。 但是，在计算整个应用程序的实际数量时，可以忽略在回滚实例中导致的错误更新，从而获得准确的表示形式。 每个会话的应用程序崩溃：此数字显示与会话数相比，应用程序崩溃的次数。 该指标的可接受范围为<0.1％。 但是，可以将其分类为会话和应用程序流的类型，以更好地了解此问题。 每个屏幕视图的应用程序崩溃：此数字将应用程序收到的总屏幕视图与崩溃次数进行比较。 该指标的可接受范围为<0.01％。 必须对它进行分类，以了解崩溃对功能交付的影响。
什么时候使用？
当您有特定目标时，此指标很有趣。 例如，您可以努力 在软件最关键的用户流中 达到 小于0.25％ 的ACR 。
9.缺陷密度
有两种不同的方法来查看缺陷密度：
面向大小的度量标准着重于软件的大小，通常表示为千行代码（KLOC）。 一旦决定了什么构成代码行，这是一个非常容易收集的软件指标。 不幸的是，它对于比较用不同语言编写的软件项目没有用 。 一些示例包括每个KLOC的错误或每个KLOC的缺陷。
面向功能的指标侧重于软件提供的功能。 但是无法直接测量功能。 因此，面向功能的软件指标依赖于计算功能点（FP） ，这是一种量化产品提供的业务功能的度量单位。 功能点对于比较以不同语言编写的软件项目也很有用。 该指标将查看每个FP的错误或每个FP的缺陷
功能点不是一个容易掌握的概念，方法也各不相同。 这就是为什么许多软件开发经理和团队完全跳过功能点的原因。 他们认为功能点不值得花时间。
什么时候使用？
依赖于代码行的面向大小的指标本身就没有用。 因此，您不应将两个不同的软件项目与它们进行比较。 这就是为什么您可能不是忠实使用它的原因。 面向功能的指标很难计算和达成共识。 您可能想引入控制措施，但列表中可能会有更好的指示。
10.依赖年龄
技术债务的另一个指标是代码库中使用的依赖项过时的程度。 作为所有依赖项的平均值（可能带有变体）来跟踪它可能会很有趣，因此您可以确定何时一个很老并且应该引起您的注意。
什么时候使用？
该指标尤其应引起技术领导的关注。 这太可操作了，无法链接到经理使用的代码库。 如果您的项目有很多依赖项，则绝对应该考虑跟踪依赖项年龄。
请注意，某些指标可能未列入列表，因为它们不够流行，或者牵强到无法从中获取任何价值。 请记住，软件指标应该易于理解，并可能导致变更并具有业务价值。 否则，有什么意义呢？
您可能要记住的某些指标也可能是我在其他文章中谈到的与速度相关的指标和与过程相关的指标的一部分 。
如果我错过了任何事情，请告诉我您的想法。 最终目标是建立有关软件工程指标的最佳实践的全面列表，以帮助团队改进自己的流程。
最初于 2019年7月31日 发布在 https://anaxi.com 。本文是系列文章的第一部分。 阅读更多：
翻译自: https://hackernoon.com/software-quality-the-top-10-metrics-to-build-confidence-d28330b6
qa建立质量指标与指标
扫一扫
1146
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
