我知道这个问题可能有点广泛，所以我希望这个问题不会解决。但是，我觉得这是很多质量检查工程师和经理都在努力的话题，而且我认为没有什么办法可以做某事（就像我们领域中的许多其他话题一样）。
问题是这样的，您如何确定项目的质量随着时间的推移而提高？
您正在使用什么以及如何测量项目的质量？
我个人认为测试用例的数量不多在这种情况下，错误的数量是一个很好的指标，尤其是在敏捷（在我的情况下为Scrum和Kanban）的工作组织中。
我们在为期2周的冲刺中跨所有团队开发了X功能，并部署了它们测试完成后（而不是在sprint结束时）。尽管来自支持部门的错误可能作为一个起点，但理想的情况是不要在那里。
那么，您现在如何评估项目的质量？您如何知道您的项目是“好质量”状态还是“坏质量”状态？
您会做什么？主动或回溯，以便及时达到期望的水平？质量，也许可以避免业务损失？
#1 楼
一个好的起点是定义质量在您的上下文中意味着什么。然后找出测量方法。似乎您想要测量某些东西而不说什么是什么。话虽如此，我们在这里很难告诉您，但是也许我们可以给您一些起点，您可以在与团队和其他人的讨论中使用与您正在创建的产品有关的人。起点可能是这个金字塔：
（本书中提到）
产品应满足所有这些级别。在实践中，这意味着您应该根据自己的情况与团队，客户和客户定义。但是至少您有一些入门指南。
在这种情况下，我认为测试用例的数量和bug的数量不是一个好的指标。
一个数字并不能告诉您太多。尽管它们可能是某些行业，甚至连数字也很重要，但是即使那样，也应该给这些数字提供更多的背景信息，以更全面地了解我们正在处理的内容。
您正在采取主动或追溯的措施，以便及时达到所需的质量水平并可能避免业务损失？
着眼于高优先级功能，最大风险，广泛检查和探索测试。经常与客户/客户/团队中的其他成员进行交谈，让他们在生产前使用/测试新功能，对他们要说的内容感兴趣并采取后续行动。
#2 楼
对我而言，这是关于可衡量的更快交付有价值的功能，同时减少功能停机时间的问题。我认为优质的产品和团队会加班越来越快。这可能与大多数人所经历的有所不同，通常软件项目的加班时间越来越慢。我要说的是由于功能，结构和过程质量方面的“不良质量”。根据最近的一项研究，devops 2019年状态报告指出，衡量和改进以下关键指标会改善净结果（例如，金钱） ，利润）。
交货时间
部署频率
更改失败
恢复时间
可用性
< br
通过吞吐量和稳定性可以概括捕获
开发和交付过程有效性的前四个指标。我们使用从签入到发布
的代码更改的提前期以及部署频率来衡量软件交付过程的吞吐量。使用
恢复时间（从检测到影响用户的事件到修复事件所花费的时间）和更改失败率（衡量发布过程的质量的度量）来衡量稳定性。 br />
请参阅https://services.google.com/fh/files/misc/state-of-devops-2019.pdf中的第16页
测量站立的姿势现在尝试成为一名优秀表演者:)
#3 楼
这些是公司按优先级顺序使用的度量标准：每活跃用户数量的支持案例数量
我们的应用程序生成和记录的错误数量
此涵盖了软件开发的许多基本方面：
该产品的用户友好性如何？如果不是，那么您会收到更多的支持请求或更少的用户。
记录的错误越多，在开发/部署过程中遗漏的错误就越多。
我们的产品文档质量如何？如果不好，我们会收到更多的支持请求。这很难测试，但这是质量的一部分。我们的支持团队，文档编写者和测试人员之间存在反馈循环。
测试覆盖率是一个很好的指标，但是您可以拥有很好的测试覆盖率，但仍然有很多支持案例。在客户眼中，如果他们需要联系支持人员，那么您的产品就是不合格的，因此是我们的主要指标。
#4 楼
撇开通常的度量标准（例如，开放和关闭的缺陷的趋势以及我们为每个运行的内部构建或测试周期报告的问题数量），我想说交付时间和报告的部署后问题将是一个不错的起点。如果交付时间减少了，发布后的缺陷也减少了，那将最终意味着更少的补救措施，并且项目的总体绩效和健康状况将朝着良好的方向发展。但是，这也间接验证了我们现在以一种或另一种方式使用的指标。Niels，谢谢您的回答。这似乎很有趣。我们目前正在使用名为Kualitee的测试管理工具，并使用常规指标（例如问题趋势分析和测试周期比较）来审查项目运行状况。
评论
这里有什么“质量”的问题？软件就像热狗：它们可以尝起来不错，但是您不想知道它是如何制成的。从用户的角度来看，质量不同于可维护性或纯粹主义者所认为的“良好”等。您可以告诉项目更成熟，更稳定等，因为您需要的工程师越来越少，但这不是一般性的声明因为任何明确定义的问题都解决了一半；同样，我们需要先在上下文中明确定义“质量”，然后再进行追求。
您是说产品吗？衡量，提高质量通常应用于产品或过程。首先必须有一个测量的基线。