通过使用单元测试超时来衡量方法的性能是一个好主意吗？
在有非功能性需求的项目中，该非功能性需求指定了特定操作的最长时间执行时间，QA必须在精确负载下使用精密硬件检查专用设备上此动作的性能，硬件和负载均在需求中指定。 另一方面，对源代码的一些错误更改可能会严重影响性能。在源代码到达源代码控制并由QA部门验证之前尽早注意到这种负面影响，这可能会因为QA部门报告问题而浪费时间，而开发人员稍后再修复它会造成损失。 为此，这是一个好主意： 要使用单元测试有花了执行相同action²时间的想法ñ倍， 要在C＃中通过属性使用每次测试超时[TestMethod, Timeout(200)]？ 我期望这种方法会出现几个问题： 从概念上讲，单元测试并非真正做到这一点：它们应仅测试代码的一小部分，仅此而已：既不检查功能需求，也不进行集成测试，也不进行性能测试。 考虑到这些测试不存在初始化和清除功能，或者它们太短而无法影响结果，Visual Studio中的单元测试超时是否真的可以衡量预期的结果？ 用这种方法衡量性能很难看。在独立于硬件，负载等因素的任何计算机上运行基准测试，就像进行基准测试一样，表明一种数据库产品总是比另一种数据库产品更快。另一方面，我不希望这些单元测试是确定的结果，也不希望质量检查部门使用这些东西。这些单元测试将仅用于提供有关预期性能的一般概念，并且实质上是在提醒开发人员，他的最后修改破坏了某些内容，从而严重影响了性能。 对于这些测试，无法进行测试驱动开发（TDD）。首先，在开始实施代码之前它将如何失败？ 性能测试太多将影响运行测试所需的时间，因此此方法仅限于短期操作。 考虑到这些问题，如果将此类单元测试与质量保证部门的实际性能指标结合使用，我仍然觉得很有趣。 我错了吗？还有其他问题使其完全不能使用单元测试吗？ 如果我错了，那么在源代码到达源代码控制并由质量检查部门验证之前，警告开发人员该源代码的更改严重影响性能的正确方法是什么？ ¹实际上，单元测试只能在具有相当硬件性能的开发人员PC上运行，从而缩小了永远无法通过性能测试的最快计算机与永远无法通过性能测试的最慢计算机之间的差距。 ²实际上，我的意思是一段相当短的代码，需要花费几毫秒来运行。