当我定义我的测试用例（通常在 Team Foundation Server 中）时，我会将它们与需求进行交叉引用。然后，当他们通过或失败时，我用它来确定是否已经交付了需求。

一旦所有测试用例都通过了，将要求从“准备测试”设置为“已构建”的是测试人员，而不是开发人员。

这就是我如何获得您在问题中提到的两个关键措施。

我们将 UAT 遵循的需求设置为“已构建”并将其设置为“客户验证”的趋势表明它满足需求的程度。

测试结果随时间的变化趋势，提供了软件如何随时间保持该质量的长期、版本到版本的视图。

我不认为有一个单一的、神奇的指标可以给你这个。您可以测量一些常见的指标并以某种方式将它们组合起来以确定软件的质量。例如 - 上面提到的覆盖需求的数量（本身非常误导，因为我们不知道覆盖范围有多好），在这个版本中发现的低 - 中等 - 高严重性错误的数量以及它们是否全部关闭（不是确定如何解释结果）等。

这是一个很好的问题，也是每个产品公司都面临的问题。答案是非常主观的——它取决于您的产品、您的组织和您的客户群。尽管它是主观的，但在尝试评估产品是否满足其功能要求时，您应该牢记一些趋势。

随着时间的流逝，您的产品不仅在发展，而且您的客户群也在发展。您的第一批客户更有可能成为早期采用者。随着您的业务增长，您可能会接受更大、更规避风险的客户。您的功能需求将需要随着您的客户群而发展。对于您的早期采用者客户而言，优先级较低的错误和易用性功能可能对您的新客户而言是高优先级。

如果您托管自己的产品，您可能还会有不断发展的运营需求，例如可扩展性要求和诊断/故障排除功能。

那么这对 QA 指标意味着什么？您需要定期重新查看错误列表，以确保优先级随着客户需求的变化而变化。您还需要根据客户需求来判断您收集的任何产品指标，例如容量测量、响应能力或速度。

当然，您永远没有足够的信息来完全确定地了解功能需求是什么。有人会做出最好的猜测，当你错了，你的客户会告诉你。

底线：一切都在变化，包括功能需求。无论您决定在上一个版本中构成高质量的任何内容，都需要为此版本重新评估。

至于可用性，您可以衡量在给定场景上花费的时间或在用户中进行调查以评估易用性、可读性等。