如何有效管理LLT用例，避免重复和遗漏

低层级测试一般来说包括单元测试，功能集成测试和子系统之间的测试。

单元测试是针对函数这一层级的测试，一个文件中会存放多个函数，我们在创建测试文件的时候呢，我们会对应这个源代码的文件。比方说我们现在有个文件叫source1.xx，那我们在创建测试文件的时候，我们可以定名为source1Test.xx，接下来，我们会把对应的测试放到这个测试文件当中。 

针对一个函数，我们有时候会有多个测试案例，我们要做的就是把这一些针对一个函数的测试案例放在一起。比如说我们现在有个函数function1, 还有多个输入参数，有一个返回值。我们可以创建如下的测试案例: function1InputXYReturnZ。其中XYZ代表你测试的输入和输出, XYZ的值可以是泛化的，也可以是具体的，以测试的输入和输出来指定你的测试案例的名字来避免出现重复的测试案例。

一个测试文件下面可以包含很多个测试用例, 我们可以把这个文件归类为一个用户故事。

我们也可以把多个用户故事归类为一个测试套件。

一个工程下面可以包含多个测试的套件。

通过以上的管理，我们可以让其他的开发者快速的了解我们已经创建的测试案例, 当然也可以避免单元测试的重复创建问题。

这里要说一下单元测试代码重复的问题。

一个很有意思的现象，比如对于针对同一个函数的测试案例，可能有很多相似的地方，那么有的人，就喜欢把这些相似的地方抽取出来，作为公共函数。

从我的经验来看，如果能够保证整个程序代码的复杂度不变是可以的。

首先测试代码部分保持重复，主要是为了保证整个逻辑的线性化。我们力求每个测试案例的复杂度为O(1)。杜绝这一点，除非非常有必要, 我们不想使用一些条件判断。

其次，如果公用代码可以放到测试初始化函数里面的话是最好的。这样同时也减少了测试案例内部的代码。

再次，虽然我们把测试代码当作产品代码来看，但是在实际的产品发布程序包中，我们是不会包含测试代码进去的。当然，这里有个例外，除非我们的产品本身就是开源的。即便如此，我们也不应该用实际产品代码的眼光去评判测试代码，因为测试代码的存在依据就是产品代码，也就是说测试代码并不是独立存在的。所以没有必要在测试代码中使用非常绚丽的编程技巧，平铺直叙，返璞归真才是正确的做法。

集成测试跟单元测试类似，区别在于它关心的是组件之间的测试。集成测试又称为功能集成测试。一般是基于业务需求而进行的针对跨组件的测试。

这部分的代码量一般来说要比单元测试要少。

子系统间测试是广泛意义上的功能集成测试，它针对的目标是子系统之间。一个比较常见的例子是通过调用多个微服务系统的接口，实现某项功能。再比如调用多个模块的接口，实现某项业务需求。

这部分的代码量一般来说比集成测试要少。