代码覆盖率达到100%,真的代码就没有问题了吗？

Posted 2023-05-03

参考技术A 在软件测试中，有一个重要的概念叫做代码覆盖率，一般在单元测试中作为测试充分性的重要衡量指标，那么代码覆盖率达到100%是否就算覆盖全了？答案显然是否定的。

那么，100%的代码覆盖率还值得追求吗?

这是当然，这也应该是每个程序员追求的目标之一，但是如果从项目角度考虑ROI(投入产出比)，对于需要快速上线的短期项目，需要注重的是让测试覆盖核心功能代码。如果你的项目是一个长期项目，那么高覆盖率是非常有必要的，它意味着高可维护性，以及更少的bug。

那么对于一个项目来说，覆盖率应该达到多少？

其实没有适用于所有项目的数值，每个项目都应有自己的阈值，但共性是，测试必须覆盖主要业务场景，代码的逻辑分支也必须尽可能的覆盖。

如何改进你的项目代码覆盖率？

首先我们要阅读和理解项目代码，找出其中需要测试并且与业务强相关的代码，结合sonar等代码质量管理平台，从代码编写规范、复杂度、重复代码等方面进行代码重构，进一步提高项目的可维护性与可读性。

这也意味着重构，重构的同时，你需要更多的测试来保证你重构代码的正确性。

代码覆盖率的意义

阅读分析之前项目中未覆盖部分的代码，进而反推在前期QA以及相关测试人员在进行黑盒测试设计时是否考虑充分，没有覆盖到的代码是否是测试设计的盲点，为什么没有考虑到？是需求或者UX设计不够清晰，还是测试设计的理解有误。

检测出程序中的废代码，可以逆向反推代码设计中不合理的地方，提醒设计/开发人员理清代码逻辑关系，提升代码质量。

代码覆盖率高不能说明代码质量高，但是反过来看，代码覆盖率低，代码质量绝对不会高到哪里去，可以作为测试自我审视的重要工具之一。

单元测试的覆盖率并不只是为了取悦客户或者管理层的数据，它能够实实在在反应项目中代码的 健康 程度，帮助我们更好的改善了代码的质量，增加了我们对所编写代码的信心。

你真的搞清楚k8s的subpath了吗？

参考技术A 我们经常会使用subpath，当我们直接挂载一个存储或者configmap到一个目录后，目录下面原有的内容将会被覆盖。比如，我们只想替换nginx容器里面的 /etc/default.conf 这个文件，但如果通过configmap 直接挂载到 /etc 目录是不行的，会直接覆盖整个目录，导致原有的文件被覆盖了。此时，就需要借助subpath了。

通过subpath我们可以只挂载一个文件到/etc 目录下，从而避免全目录覆盖，但这里也要一个小瑕疵，就是这个文件后续的变化不会更新到容器里面了，这点需要注意。

回到主题，那么这个subpath是如何实现的？ 我们先看这样一个例子。

当我们登录到容器里面后，可以看到 /mnt/aaa/bbb 和 /mnt/ccc/ddd 这两个目录，在宿主机上可以看到 /srv/aaa/bbb 和 /srv/aaa/eee目录。这个subpath 其实是我们存储的subpath，k8s 会在存储的目录下找寻这个文件或者目录，如果不存在，则会创建。我们看一下k8s代码实现。

如果存储里面已经包含了subpath路径，比如 NAS存储子目录已经存在，或者configmap 某个key 已经存在，此时就不会创建这个文件或者目录，反之，如果不存在，则会首先创建这个目录。

后续只是将这个subpath路径 bind mount 到容器里面的路径，和其他存储挂载没啥差别。