为了保证代码质量，一般会要求提交的源码要有测试用例覆盖，并对测试覆盖率有一定的要求，在实践中不仅会考核存量代码覆盖率(总体覆盖率)还会考核增量代码的覆盖率。
或者说增量覆盖率更有实际意义，测试用例要随源码一并提交，实时保证源码的质量，而不是代码先行，测试用例后补，这有些应付的意思。
对于存量代码覆盖率主流的测试工具(框架)都是默认支持的，配置reporter相关参数，执行完测试用例就会生成测试报告。
对于增量测试覆盖率主流的测试工具一般没有支持，我想计算增量代码貌似不是测试工具该干的事，所以主流测试工具并没有提供这一功能。
那么如果计算增量覆盖率呢？
计算增量测试覆盖率，总共需要3步：
·计算出增量代码的所有行号
·计算出测试未覆盖的代码的所有行号
·对比计算增量代码被测试覆盖的比例，得出增量覆盖率
是不是很简单，有没有一种 “道理我都懂，就是过不好这一生的赶脚”
一、计算增量代码的所有行号
代码管理一般都会用到 GIT 这个工具，GIT提供了非常强大的管理增量代码的能力，因此，可以利用GIT这一特性，通过git diff(参考文献1) 这个命令获取增量代码。
git diff命令可以使用如下格式，用来对比不同commit(或分支)间的增量代码
git diff []
其中可以是分支名，对比分支间的差异，则是 git diff [] targetBranchName sourceBranchName。可以简写为 git diff targetBranchName 表示对比当前分支与目标分支间的代码增量差异。
例如 git diff master 生成当前分支与master分支的增量信息，当有多个文件变化时，会有多个这样的信息块。
·第1部分是发生变化的文件名。---表示文件发生了删除行 +++表示文件发生了新增的行，当---和+++后面是文件路径(相对代码根目录的相对路径)。
·如果某个文件是新增文件，则---后面是/dev/nul
·如果某个文件被删除了，则+++后面是/dev/nul
·如果文件发生修改，则---和+++后面都有文件名
·先介绍第3部分，因为第2部分的解读需要用第3部分辅助。第3部分是详细的含有上下文的增量信息(
