使用gtest也有很长一段时间了，这期间也积累了一些经验，所以分享一下。GTest为我们提供了便捷的测试框架，让我们只需要关注案例本身。如何在GTest框架下写出优美的测试案例，我觉得必须要做到：
　　案例的层次结构一定要清晰
　　案例的检查点一定要明确
　　案例失败时一定要能精确的定位问题
　　案例执行结果一定要稳定
　　案例执行的时间一定不能太长
　　案例一定不能对测试环境造成破坏
　　案例一定独立，不能与其他案例有先后关系的依赖
　　案例的命名一定清晰，容易理解
　　案例的可维护性也是非常重要，如果做到上面的8点，自然也做到了可维护性。下面来分享一下我对于上面8点的经验：
　　1. 案例的层次结构一定要清晰
　　所谓层次结构，至少要让人一眼能分辨出被测代码和测试代码。简单的说，是知道你在测什么。由于是进行接口测试，我已经习惯了如下的案例层次：

　　DataDefine
　　我会将测试案例所需要的数据，以及数据之间的联系全部在预先定义好。测试数据与案例逻辑的分离，有利于维护和扩展测试案例。同时，GTest先天支持测试数据参数化，为测试数据的分离提供了进一步的便捷。什么是测试数据参数化？是你可以预先定义好一批各种各样的数据，而你只需要编写一个测试案例的逻辑代码，gtest会将定义好的数据逐个套入测试案例中进行执行。具体的做法请见：玩转Google开源C++单元测试框架Google Test系列(gtest)之四 - 参数化
　　SUT
　　SUT，即system under test，表明你的测试对象是什么，它可以是一个类(CUT)，对象(OUT)，函数(MUT)，甚至可以是整个应用程序(AUT)。我单独将这个层次划分出来，主要有两个目的：
　　(1)明确的表示出你的测试对象是什么
　　(2)为复杂调用对象包装简单调用接口
　　明确表示测试对象是什么，便于之后对测试案例的维护和对测试案例的理解。同时，对于一些被测对象，你想要调用它需要经过一系列烦琐的过程，这时，需要将这一烦琐的调用过程隐藏起来，而只关注被测对象的输入和输出。
　　TestCase
　　测试工程中，必须非常明确的表示出哪些是测试案例，哪些是其他的辅助文件。通常，我们会在测试案例的文件名加上Test前缀(或者后缀)。我建议，将所有的测试案例文件或代码放在显眼的地方，让所有看到你的测试工程的人，第一眼看到的是测试案例，这很重要。