"集成测试"真的是阴谋?

InfoQ China刊了J.B. Rainsberger的一篇文章题为

J.B. Rainsberger：“集成测试是个阴谋”

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.的阴谋论有些牵强。当然，集成测试必须建立在单元测试之上，这点毋庸置疑，集成测试的重点应该根据项目实情做出策略上调整，比如对集成目标、深度的制定上做修正。

 

 

评论

3 楼 seemoon 2009-05-12  

mock写的“传统的单元测试观念是根本无法支持敏捷开发的，充满了臭味”应该是“事后补测试”这种情况，通常发现一个功能做完后，某项目经理对开发人员说，“补上单元测试吧，这样以后好维护”，于是开发人员觉得象是被逼着去干一件“没有意义”的事。这种形式的测试失去了测试的最佳时机，也同时失去了“驱动”的价值，而且测试质量也不高，测试在这里成为了附加成本。

2 楼 daquan198163 2009-05-12  

mock1234 写道

这种“纠缠”之说的原因是 传统的测试观念把测试作为实现功能的代码开发之后才考虑的事情。

如果你使用XP或者其他敏捷开发，你就会发现，这根本没有懂什么是系统测试.测试用来驱动开发的，是架构设计和需求描述技术，是时时刻刻放在编码之前就开发好的，而不是编码之后才开始考虑的事。测试是用来协调开发的，是不纠缠那些细枝末节的。不要貌似很懂测试技术，结果只纠缠于细枝末节的技术。

当你把这个关系倒置过来，就会发现传统的单元测试观念是根本无法支持敏捷开发的，充满了臭味。

在审查任何貌似敏捷开发的人所谈论的测试方法之时，我们首先这样来看看它是真敏捷还是假敏捷，很重要。如果他是假敏捷，而还是在为传统的测试纠缠而烦恼，那么不论他对系统集成测试有什么样的担忧，我们也只是笑笑（同情他一下）就可以了。

所以首先不要纠缠于什么是系统集成测试，而要首先考察他是怎样的项目管理观念。

先写好测试程序，然后让测试程序发生异常（废话，现在连编译都过不去，因为被测试的接口还没有用代码来实现），然后写实现代码的目的就是让测试通过而已。这就是敏捷方法所说的系统测试！而不是传统测试理论中所说的任何一种测试。

所以，当我们站在敏捷开发的立场上来说系统测试时，只是引用其部分形式，而精神实质还是不一样的。

你越说我越糊涂了。
“传统的单元测试观念是根本无法支持敏捷开发的，充满了臭味”——能进一步解释一下么？
另外，我猜你有一个地方搞错了：
传统的测试观念把测试作为开发之后考虑的事情，但TDD并不是简单的把顺序掉过来——先写出完善的测试然后给出使其通过的实现，TDD就像走路，左右脚交替迈步，左脚是测试右脚是实现，测试代码和实现代码一起不断增长。
ps：也可能你本来就是这个意思，我的猜测是错的。

1 楼 seemoon 2009-05-09  

mock1234 写道

这种“纠缠”之说的原因是 传统的测试观念把测试作为实现功能的代码开发之后才考虑的事情。

如果你使用XP或者其他敏捷开发，你就会发现，这根本没有懂什么是系统测试.测试用来驱动开发的，是架构设计和需求描述技术，是时时刻刻放在编码之前就开发好的，而不是编码之后才开始考虑的事。测试是用来协调开发的，是不纠缠那些细枝末节的。不要貌似很懂测试技术，结果只纠缠于细枝末节的技术。

当你把这个关系倒置过来，就会发现传统的单元测试观念是根本无法支持敏捷开发的，充满了臭味。

在审查任何貌似敏捷开发的人所谈论的测试方法之时，我们首先这样来看看它是真敏捷还是假敏捷，很重要。如果他是假敏捷，而还是在为传统的测试纠缠而烦恼，那么不论他对系统集成测试有什么样的担忧，我们也只是笑笑（同情他一下）就可以了。

所以首先不要纠缠于什么是系统集成测试，而要首先考察他是怎样的项目管理观念。

先写好测试程序，然后让测试程序发生异常（废话，现在连编译都过不去，因为被测试的接口还没有用代码来实现），然后写实现代码的目的就是让测试通过而已。这就是敏捷方法所说的系统测试！而不是传统测试理论中所说的任何一种测试。

所以，当我们站在敏捷开发的立场上来说系统测试时，只是引用其部分形式，而精神实质还是不一样的。

说得对，测试是否起到driven是敏捷与否的“航标”。“纠结”在组织中引入测试（还不是敏捷所说的“测试”）必然存在，这也是国内敏捷推行的最大阻力，仿效scrum每天做15分钟的站立会议并不困难，难的是通过测试（不论传统或敏捷）步入真正的敏捷殿堂。