专业的咨询师不仅需要对新兴的技术和趋势有足够的好奇心去探索，也要能够对过气的技术工具有自己的评价，这样当客户咨询师为什么做这样的技术抉择，而必须放弃手头已经的技术投资时，才能有足够的说服力。
这次要介绍的是2013年12月版ThoughtWorks Tech Radar中的Heavyweight Test Tool条目，状态是Hold。Hold就是建议停止使用。
建议停止使用重量级测试工具，有很多角度和因素的考量，不管是从工具本身使用体验上，还是工具对敏捷迭代开始带来的消极影响：
l 昂贵的许可证费用。一般重量级测试工具都是商业产品（小公司也难以开发出如此重量级别的工具产品来），购买使用和寻求长期的技术支持，意味着庞大的技术投资和费用，每台机器或者每个IP都可能是成百上千美元的费用。我见识过商业公司为了防止盗版使用，创造了专门的许可证验证服务器，每次工具启动都会联网验证是否通过合法渠道获取了软件的使用，启动过程缓慢低效，等待启动是个消磨耐心的过程，而长时间不关闭工具对于机器的性能又是一种折杀。
l 更为陡峭的学习曲线。这点是针对轻量级测试工具而言的。在一个新人加入团队的时候，他不得不花费更多的时间，来熟悉甚至掌握笨重的的测试工具，不同功能的菜单按钮在哪里，如何调试，如何查看测试报告，如何寻求技术支持。在熟悉了基本的界面和功能之后，在日常的测试开发过程中，新人还不得不逐渐习惯整个团队对于这个测试工具的自定义开发部分，比如依赖于工具的测试框架，测试开发的流程，而且会发现，笨重的测试工具下面，其实到处是陷阱，为了满足再正常不过的技术要求和功能，却需要实现大小不一的work around，步履蹒跚，成果微弱。而这一切噩梦的开端，只是因为这个工具的笨重。
l 限定在固定的语言平台。这也是遗留问题，经年累月的开发和维护造就了笨重的测试工具，它们一般会限定在Java或者C#平台，并以此语言平台来支持不同类型的待测应用，很显然无法满足现如今千变万化的应用类型，以不变应万变，固定的语言平台，而且多数是过时的臃肿的语言，带来的只能是开发效率低下，或者根本就是用错了工具。而新类型的轻量级测试工具，可以同时支持多个不同的语言平台，比如Java、Ruby等，可以让团队面对各种不同类型的待测应用，去选择从技术上最适合，对团队能力自身也最匹配的语言平台。
l 脆弱的难以维护的测试生成脚本。重量级测试工具在诞生之初，最为人津津乐道的就是它的录制回放机制，点击录制按钮，测试工具就可以把任何的用户界面交互录制下来，添加进自己的验证点，就是一个可以反复回放，可以重用的测试脚本。看，是不是很简单，即使是最白痴的测试人员也可以掌握这种用法。可实践的经验证明，这种录制回放的机制强烈依赖不能变化的用户界面，任何用户界面的调整都会造成录制好的测试脚本运行失败，而能做的只能是重新录制，而这在需求功能频繁变化的日常开发中，这简直就是噩梦，再有经验的测试人员也只是在不停的重复点击录制和回放按钮而已。更有剑走偏锋者，比如有专家会发明出屏幕截图对比的高深技术，用来对比代码变化前后，用户界面的截图变化，来验证功能是否如期正确。同时，自动录制和回放的机制，所自动生成的测试代码，对于测试开发人员来说，可以读但层次太低，带来的问题就是难以维护和可重用性低。而所有这些都是效率低下，打击测试耐心和信心的症结所在。
l 测试落后，延长反馈周期。重量级测试工具，多产生于传统瀑布式软件开发过程，在那时测试是软件开发周期中处于开发后端的一个过程，“专业”的自动化测试团队，并因为测试工具足够重量级而产生的自动化测试专家，手中掌握着重量级测试工具这张“王牌”，本以为可以高枕无忧自动化测试待测的应用，解放人工测试，未曾想不仅受制于笨重的测试工具开发效率，还受制于开发人员因需求频繁变化而对待测应用的频繁改动。测试又失败了，仅仅是以为开发人员又调整了用户界面上的一个元素的标识符。错误的开发测试过程，经过笨重测试工具的推波助澜，从软件问题的暴露到修复，反馈周期被延长，交付日期退后，软件质量变低。
但是，无法忽略重量级测试工具也有它具有优势的一面：
l 可管理性。重量级测试工具，多会提供统一的工作界面，在同一个窗口里面，可以进行测试脚本的编写、调试，可以跟版本控制系统交互，可以查看测试的结果，可以生成浏览测试报告。测试开发人员在不离开工具界面的情况下，可以完成自动化测试开发所需要的所有工作，他可以尽可能少因为切换上下文而丢失对问题的聚焦。
l 稳定性。重量级测试工具相比较轻量级或者开源测试工具来说，较少地更迭版本，从而减少版本变化所带来对已有功能和支持的消极影响。商业化的开发也会给重量级测试工具良好的技术支持，保持已完成测试脚本的稳定性，确保测试的失败不是因为工具本身的问题，而是待测应用的确出了问题，对于测试开发人员尽快定位问题，修复问题，甚至缩短开发测试反馈周期，都有积极的作用。
