前段时间一直忙着测读写分离的项目，测试的过程是痛并快乐着的，收获颇多，感受也颇多。
（1）测试数据的准备
只是底层数据库的变动，与业务无关，按道理测试起来相对比较简单只要回归现有的测试脚本和新增一些读写分离的测试用例就可以，可是测试用例在持续回归的时候出现了一些状况，有些用例偶尔测试通过，偶尔又测试不通过。本着遇到问题刨根问底绝不放过一个bug的态度，查找出来了根本原因在于excel准备测试数据的随意性。所以在接口测试中，一旦用到excel准备数据的话，一定要留心准备的数据在别的excel中除了主键不一样外其他联合唯一约束是否有存在一样的，如果存在的话就尽量避免再使用这样的数据，以防有脏数据时很多用例都会受到影响。保证有效的和低耦合的测试数据，这样可以使我们的持续集成测试脚本更加的健壮，后期的维护成本也会降低。
（2）测试用例的设计与评审
与开发、功能测试人员多沟通，充分的理解测试的需求以及需要验证的点。在设计用例的时候，把握好测试用例的粒度，尽量避免过于简单或过于复杂，测试用例过于简单，只是记录一些功能点，而不去设计一些验证点，就失去了测试用例的意义，同时有可能正因为没有验证到某字段的状态而遗漏了bug。测试用例过于复杂会给后期维护成本变大，也许自已写的用例过段时间来看，自已都不知道是什么意思了，还必须看测试脚本才能知道测试用例的意思。设计好的测试用例也会提高测试用例评审时的效率。
（3）测试人员的心理素质
当现有用例数很多时，维护的成本相对来说也更大，在做读写分离接口测试时，cc经常挂而且一大批的用例都跑不通，刚开始每次 cc（cruisecontrol）跑完我都很沮丧，后来慢慢的把挂的用例分类好做一个简单的分析，心理就有数是什么问题会挂。让我明白cc不过肯定是有问题，不是测试数据问题，就会是开发代码有问题，不用惊慌，摆正心态去分析和解决问题。我们测试的目的不仅是测试结果是正确的，而是测试是不是有错误。
