我们部门以C# Web应用开发占大多数，几乎所有人都未听说过单元测试，更别说写测试了。
最近，领导开始要求每个人为新功能或bug修复编写单元测试，当我们决定监控所谓的“单元测试实施率”时，我们有了以下讨论：
－ 将代码行覆盖率作为指标之一，并且覆盖率不应在将代码推送到git remote 时降低。
－ 将测试用例的数量作为指标之一，并且要求当代码推送到 git remote 时，测试用例数不应下降。这个指标不会受到新CRUD代码的影响，但我认为这样要求的活就没有人会在推送代码时写新的测试了（因为如果不使用编写新测试的话，该指标也不会下降）。
目前我们就如何监控导入情况的具体作法僵持不下，想请教这些情况下如何衡量单元测试的实施率？不知道还有哪些指标或是您的经验可以分享？
谢谢。
其实你的描述核心问题是“自己给自己打分”，你在担心自己给自己打分，会不会有问题
那么我说，那就别自己给自己打分呗。
需求是人提的，提需求的来打分就好，啥测试用例。你提需求的不给测试用例，要程序员们给啥测试用例，程序员说都解决了，都是绿灯，你提需求的相信不？你提需求的说“管你绿灯不绿灯，反正我的要求你没实现就是红灯”
在C# Web应用开发中，单元测试是非常重要的一环，可以帮助开发人员及时发现和解决代码缺陷和错误，提高代码质量和稳定性。以下是一些建议来衡量单元测试实施率：
代码覆盖率：代码覆盖率是衡量单元测试质量的一种方式。它能够衡量测试用例对代码的覆盖程度，即测试用例是否覆盖了代码中的所有分支和语句。可以使用工具来计算代码覆盖率，并将其作为指标之一来衡量单元测试实施率。但是，如你所提到的，代码行覆盖率并不适合于所有类型的代码，所以可以使用更细粒度的指标来衡量单元测试实施率。
测试用例数量：测试用例数量也是一个重要的指标。它可以反映测试人员对代码的测试程度和测试质量。可以通过监控测试用例数量，并在将代码推送到Git远程仓库之前执行所有测试用例来衡量单元测试实施率。如果测试用例数量不增加，可能意味着新的代码缺乏测试，这将有助于开发人员意识到需要增加新的测试用例。
代码质量：单元测试实施率的另一个指标是代码质量。编写单元测试的主要目的是确保代码的质量，如果代码中存在许多缺陷和错误，这意味着单元测试的质量不够高。可以使用代码质量工具（例如CodeClimate）来监控代码质量，并将其作为指标之一来衡量单元测试实施率。
Bug修复速度：在单元测试实施率高的团队中，通常能够更快地发现和解决问题。如果团队能够快速修复bug，并在短时间内重新运行测试用例，这将有助于提高单元测试实施率。答案来自 https://www.wodianping.com/