原文地址：http://gigix.thoughtworkers.org/2010/5/29/how-to-create-a-test-tool-which-sucks/
你是一家大公司里不得志的程序员。和你同年进公司的那些人在核心业务上拼命工作，被客户骂，加班，交付，开庆功会，拿奖金。而你，不知道怎么的被放到一个叫做“测试工具开发”的边角部门里，干着一些不疼不痒不影响公司业绩的工作。你恨。你要报复。你要拿回本该属于自己的一切。
现在我教你怎么做。
首先，你要启动一个自主开发自动化测试工具的项目。让老板们相信自动化测试的重要性并不困难，世界上有无数的文章和书籍在讲这件事，你们公司请的咨询顾问一定也会说到这件事，这些都是你的帮手。真正难的部分是“自主开发”。你用得上一个百试百灵的招数。告诉老板们，一个自主开发的工具可以由自己来维护和支持，只有这样才能把核心技术的命脉掌握在自己手里，而不用向别人支付维护支持的费用──小心，千万不要提到那些开源的工具，因为老板们万一真的弄懂了“开源”这两个字的含义，你的整个大计划就泡汤了。拿IBM的RFT当靶子。除了后面我会说到的各种好处之外，IBM的咨询价格足以帮你吓到老板从而启动这个项目。
然后，你要精心选择一个自动化测试执行引擎。你需要这么一个引擎，因为你不能自己去做一个──工作量还在其次，要是连这都能做，你也就不在这个边角部门里郁闷了。同时这个引擎又不能太稳定，更不能太开放，这都是你大计划中不可或缺的要素。所以，你看，我说过了，RFT就是最好的靶子：它的开放程度确保了你要花好几个月时间才能把它嵌在自己的工具里而且以后再也不会有别人尝试干这件事。而且，想想吧，当你跟老板们报告说你hack了IBM的软件从而省下了licence费用时，他们该有多开心。
接下来，你要发明一套自己的测试脚本语法。沿用RFT的语法当然轻松，但这样使用它的人就会发现自己使用的其实是RFT，然后在该死的互联网上找到相关的资料。不能让这样的事发生。始终记住，你的目标是让自己变得重要。你发明的语法应该基于XML。不仅因为实现简单，而且因为它能确保测试脚本无法被阅读和重构，从而让使用这工具的人跪在你脚边求你支持。关于使用XML的好处，稍后我还会说到。
当然你不希望向领导演示时用记事本编辑XML。所以你得同时实现一个支持拖拽的测试用例编辑界面。把一个测试步骤表示为一个图标，把几个图标往测试用例里一拖，一个测试用例就好了。别忘了，执行用例的功能也得在这个界面里实现。千万别为了偷懒而实现一个命令行来执行用例，这很重要。好了，现在你可以去演示了，领导一定会喜欢的。“鼠标拖拽其实比键盘输入慢多了！”旁边一个傻逼顾问叫喊着。领导们不会听懂他的话。不用理会他，更不要尝试跟他争论，那只会给你自己带来麻烦。
现在这个工具可以小范围试用了。那些麻烦的用户会抱怨：“我每次都要重复这几个同样的操作！我想把它们合并成一个步骤！”镇静。不要骂他们（尽管你一直就想骂他们）。记得吗？让测试用例不可被重构是你大计划中的一部分。现在你要笑容可掬说。我们早就考虑到了这个问题，我们的工具可以把几个步骤封装成一个更大的、具有业务含义的东西……嗯，姑且把它叫做“操作词汇”吧。现在我就来帮助你们做这个抽象和封装。当然了，操作也要用XML来承载，并且在提供给用户时要先做一次编译或者打包或者加密，总之是不能让他们看到源文件。这样他们才能永远依赖你。
小范围试用很重要。你必须努力工作，帮用户写测试用例，帮他们封装操作，找你能找到的一切资源来帮他们，然后把投入二十个人月干出来的成果全都描述成你的工具带来的神奇变化。放心，你只需要这么干一次（或者两次）。为了把这些愚蠢的家伙踩在脚下，有时你就得先纡尊降贵。这是策略。
试用结束，你回到自己的办公室，这些愚蠢的用户还会不停地找你帮忙更新被封装的操作。这是设计中的一环。现在你应该做一个*服务器，把他们的测试用例和操作全都保存在上面，让他们每次执行测试都从服务器上取用例脚本。然后告诉他们，这叫云计算，这叫测试工厂。当然这些傻瓜不会懂得云计算是什么玩意，但他们会发现你帮他们更新操作的速度变快了，然后他们就会认为这就是云计算带来的效果。把他们感谢你的话搜集起来，很快你就会用得上。
现在万事俱备，可以向老板汇报了。这次汇报的重点是两个关键词。这也是今后宣传这个工具时的常用语。一定要背熟。
关键词1：“第四代自动化测试工具”。你要告诉老板，用Java啦Ruby啦C#啦这些编程语言来编写测试用例，那是第三代（前两代是什么就随便你编吧）。第四代的特征就是“基于操作词汇”──也就是图形界面上可以拖的那个玩意，尽管你知道它背后就是一坨不能读、不能改、连SVN合并都困难的XML。
关键词2：“测试工厂”。这时候把界面打开，连上*服务器，让老板看试点项目的测试用例。“坐在办公室就能知道所有项目的测试进展情况。”这句话是杀手锏。老板们一定会喜欢，而且会帮你推广这个工具。
只要被推广到更多的项目组，你就会变成红人。现在前面那些设计决策的重要性就逐渐体现了。因为测试用例不可重构，任何一个项目想要正经用你的工具都得找你帮忙做操作词汇，为此你就可以成立一个部门，拉更多的人来给你打这份苦工，自己当领导。但你又怕别人真的用得太多太频繁，那样的话你就得疲于支撑了。放心，因为RFT不稳定，因为每次执行都要连到*服务器来取用例，因为不能通过命令行或者Ant之类的办法把它放进持续集成，还因为用鼠标拖拽就是比用键盘慢得多，自动化测试的进展会非常缓慢，你大可以安心享受自己的新办公室。
先别急着享受，好事才刚开始呢。那些深思远虑的设计决策确保了很多项目不会认真用你的工具。这时候作为推行先进自动化测试理念的红人，你正好可以在老板耳边吹吹风，让他们强迫所有项目使用。强迫的方式有很多，但你必须记住的手段是给测试人员做职业技能鉴定考试：必须学会用你的工具才能评级加薪。这招的关键在于一箭双雕：不仅可以强迫他们使用，而且确保了他们没时间没动力去了解别的测试工具──你当然不想这些傻瓜突然冒出来说“这个开源的工具比我们自己的好用多了，而且还有那么多社区高手在维护和支持，为什么不用它”，对吧？
强行推广之后，你接到的支撑需求肯定会剧增。这时你得好好培训一下客服的小弟。要让他们分清用户的来头。如果是老板重视的项目，如果办公室离你或者离老板很近，就得大力支持。如果来自什么边远山区的支撑需求，那就把它撂到一边凉快去吧。这些边远山区经常会提些奇怪的需求，例如“能不能不连*服务器执行用例？我们这里无法连通公司内网”。让小弟们直接回复“不行”就可以了。无法连通公司内网的人同样无法有效地跟领导告状，不用担心他们。
好了。现在你已经从一个边缘程序员成功晋升为公司的红人。不仅有一帮小弟鞍前马后，而且一大帮项目头头们都得求着你优先支撑。这快感，又岂是交付一两个项目、开一两次庆功会所能比拟的？恭喜你。你不仅改变了自己的命运，还很有可能改变整个公司的命运呢。
噢，差点忘了最重要的……千万别用你们的测试工具来给自己的项目做自动化测试。微软那帮傻逼把这种行为叫做“吃自己的狗食”，可你做的是毒药，吃下去会害死自己的。切记，切记。