“集成测试”真的是阴谋?

     “集成测试”真的是阴谋?   集成测试工具

　　J.B.对集成测试作了定义，认为集成测试是：

　　在我的理解中，集成测试表示那些测试结果(成功或失败)依赖于超过一个重要行为的实现正确性的测试。

　　简单可以理解为集成测试是依赖于其他(多于一个)测试的测试。

　　J.B.为什么认为集成测试是一个因为，他的观点是：

　　1、开发人员认为某一缺陷只能通过集成测试发现，因此认为应该integrate everywhere，要写大量集成测试。

　　2、J.B.列举一个中型web app的集成测试大概包含至少1000个集成测试，开发人员容易产生抵触情绪。

　　3、J.B.以两个测试进行对比，一个是对象测试(我的理解是单元测试)，另一个则是集成测试，对象测试花费6秒，集成测试花费1分钟，而开发人员保持1分钟屏幕关注时间是不可能的，一分钟当中开发人员的注意力分散从而导致过多开销和低效，J.B.称之为集成测试的“隐含成本”。

　　关于观点1，根据我的测试经历，集成测试的目标应该关注于“集成可运行”上，比如一个集成涉及BO1, BO2,那么集成测试关注的应该是BO1+BO2得到的测试结果是可信的，而且测试结果通常不涉及太多可能性测试，比如通过不同的入口来测试集成结果的准确性，这样成本的确很高，而且会跟BO1，BO2的单元测试产生重叠，这也是一些集成测试采用MOCK测试的原因。

　　关于观点2，如果集成测试采用我说的那种“通过不同的入口来测试集成结果的准确性”的话，的确会发生抵触情况，因为集成测试的测试周期相对较长，内聚性不强，需要耗费很多精力，比如有可能涉及很多条件分支。

　　关于观点3，J.B.这里是拿集成测试和单元测试做比较，固然这是一个视角，但是这个视角是否全面我认为有失偏颇，拿一个JavaWebApp作例，对Service类做测试比较容易，如果把Action看作集成测试的话，Action测试的难度要较前者高，因而往往Action的测试有可能会被忽略掉，但是问题的发生在手工调试Action这一环节，比如出现Service中出现空指针，如果对Action做测试的话，问题有可能会在测试中发现并解决，而不是在对整个app进行编译和启动、运行、打开浏览器、输入用户名、密码，手工集成测试之后才发现问题，而这一系列过程所花的时间完全不止1分钟这么短，有可能是5分钟——完全可以来JavaEye灌水了!

　　如果把集成测试都累积做完之后，整个app会形成一个很完整的测试体系，再通过持续化集成工具来辅助实现集成自动化，专门拉到一台测试服务器做集成，J.B.说的那个1分钟问题其实可以完全避免，因此我认为J.B.的阴谋论有些牵强。当然，集成测试必须建立在单元测试之上，这点毋庸置疑，集成测试的重点应该根据项目实情做出策略上调整，比如对集成目标、深度的制定上做修正。

原文转自：http://www.ltesting.net