这几天产品线这里要搞LLT(Low level Test)重点工作，保障版本的高质量发布。工作当然包括一系列的规范、培训、编码、检视，不过具体看下来主要还是提取了下面的一些度量要点:

保证LLT运行不挂(废话)
清零无效LLT代码
保证LLT对代码的覆盖率
保证LLT对需求的覆盖率
清零无效LLT代码，意思是指通过一些检查工具，检查出LLT代码中没有使用断言的测试，或者是那种假装使用了断言的测试代码(“assert(true);”)。显然，这两种情况下写的LLT代码永远无法告警，因此是没有任何意义的。
保证LLT对代码的覆盖率很简单，就是通过测量测试代码对业务代码的覆盖率，保证软件的质量。虽然代码覆盖率并不能够绝对代表测试的充分程度，但是在排除恶意提高覆盖率的情况下，也可以作为度量LLT代码质量的一个参考。
保证LLT对需求的覆盖率这一点是一个比较小众的概念，这主要是对BDD(Behaviour Driven Development)实践执行效果的一个辅助度量方式。我们知道BDD的要点在于将功能需求作为测试的方案，测试代码围绕着需求展开(而不是函数)。这样一方面写完测试代码就相当于写完了测试文档，任何人都可以非常清晰的理解LLT代码的实际目的是什么；另一方面也可以很好的从需求的层面保障新需求经过了完备的LLT测试。那么为了度量LLT对需求的保障程度，就需要将需求进行编号，然后与LLT对应，以度量需求的覆盖率以及需求的平均用例数。