透明思考

如何做一个能害死人的自动化测试工具

你是一家大公司里不得志的程序员。和你同年进公司的那些人在核心业务上拼命工作，被客户骂，加班，交付，开庆功会，拿奖金。而你，不知道怎么的被放到一个叫做“测试工具开发”的边角部门里，干着一些不疼不痒不影响公司业绩的工作。你恨。你要报复。你要拿回本该属于自己的一切。

现在我教你怎么做。

首先，你要启动一个自主开发自动化测试工具的项目。让老板们相信自动化测试的重要性并不困难，世界上有无数的文章和书籍在讲这件事，你们公司请的咨询顾问一定也会说到这件事，这些都是你的帮手。真正难的部分是“自主开发”。你用得上一个百试百灵的招数。告诉老板们，一个自主开发的工具可以由自己来维护和支持，只有这样才能把核心技术的命脉掌握在自己手里，而不用向别人支付维护支持的费用──小心，千万不要提到那些开源的工具，因为老板们万一真的弄懂了“开源”这两个字的含义，你的整个大计划就泡汤了。拿IBM的RFT当靶子。除了后面我会说到的各种好处之外，IBM的咨询价格足以帮你吓到老板从而启动这个项目。

然后，你要精心选择一个自动化测试执行引擎。你需要这么一个引擎，因为你不能自己去做一个──工作量还在其次，要是连这都能做，你也就不在这个边角部门里郁闷了。同时这个引擎又不能太稳定，更不能太开放，这都是你大计划中不可或缺的要素。所以，你看，我说过了，RFT就是最好的靶子：它的开放程度确保了你要花好几个月时间才能把它嵌在自己的工具里而且以后再也不会有别人尝试干这件事。而且，想想吧，当你跟老板们报告说你hack了IBM的软件从而省下了licence费用时，他们该有多开心。

接下来，你要发明一套自己的测试脚本语法。沿用RFT的语法当然轻松，但这样使用它的人就会发现自己使用的其实是RFT，然后在该死的互联网上找到相关的资料。不能让这样的事发生。始终记住，你的目标是让自己变得重要。你发明的语法应该基于XML。不仅因为实现简单，而且因为它能确保测试脚本无法被阅读和重构，从而让使用这工具的人跪在你脚边求你支持。关于使用XML的好处，稍后我还会说到。

当然你不希望向领导演示时用记事本编辑XML。所以你得同时实现一个支持拖拽的测试用例编辑界面。把一个测试步骤表示为一个图标，把几个图标往测试用例里一拖，一个测试用例就好了。别忘了，执行用例的功能也得在这个界面里实现。千万别为了偷懒而实现一个命令行来执行用例，这很重要。好了，现在你可以去演示了，领导一定会喜欢的。“鼠标拖拽其实比键盘输入慢多了！”旁边一个傻逼顾问叫喊着。领导们不会听懂他的话。不用理会他，更不要尝试跟他争论，那只会给你自己带来麻烦。

现在这个工具可以小范围试用了。那些麻烦的用户会抱怨：“我每次都要重复这几个同样的操作！我想把它们合并成一个步骤！”镇静。不要骂他们（尽管你一直就想骂他们）。记得吗？让测试用例不可被重构是你大计划中的一部分。现在你要笑容可掬说。我们早就考虑到了这个问题，我们的工具可以把几个步骤封装成一个更大的、具有业务含义的东西……嗯，姑且把它叫做“操作词汇”吧。现在我就来帮助你们做这个抽象和封装。当然了，操作也要用XML来承载，并且在提供给用户时要先做一次编译或者打包或者加密，总之是不能让他们看到源文件。这样他们才能永远依赖你。

小范围试用很重要。你必须努力工作，帮用户写测试用例，帮他们封装操作，找你能找到的一切资源来帮他们，然后把投入二十个人月干出来的成果全都描述成你的工具带来的神奇变化。放心，你只需要这么干一次（或者两次）。为了把这些愚蠢的家伙踩在脚下，有时你就得先纡尊降贵。这是策略。

试用结束，你回到自己的办公室，这些愚蠢的用户还会不停地找你帮忙更新被封装的操作。这是设计中的一环。现在你应该做一个中央服务器，把他们的测试用例和操作全都保存在上面，让他们每次执行测试都从服务器上取用例脚本。然后告诉他们，这叫云计算，这叫测试工厂。当然这些傻瓜不会懂得云计算是什么玩意，但他们会发现你帮他们更新操作的速度变快了，然后他们就会认为这就是云计算带来的效果。把他们感谢你的话搜集起来，很快你就会用得上。

现在万事俱备，可以向老板汇报了。这次汇报的重点是两个关键词。这也是今后宣传这个工具时的常用语。一定要背熟。

关键词1：“第四代自动化测试工具”。你要告诉老板，用Java啦Ruby啦C#啦这些编程语言来编写测试用例，那是第三代（前两代是什么就随便你编吧）。第四代的特征就是“基于操作词汇”──也就是图形界面上可以拖的那个玩意，尽管你知道它背后就是一坨不能读、不能改、连SVN合并都困难的XML。

关键词2：“测试工厂”。这时候把界面打开，连上中央服务器，让老板看试点项目的测试用例。“坐在办公室就能知道所有项目的测试进展情况。”这句话是杀手锏。老板们一定会喜欢，而且会帮你推广这个工具。

只要被推广到更多的项目组，你就会变成红人。现在前面那些设计决策的重要性就逐渐体现了。因为测试用例不可重构，任何一个项目想要正经用你的工具都得找你帮忙做操作词汇，为此你就可以成立一个部门，拉更多的人来给你打这份苦工，自己当领导。但你又怕别人真的用得太多太频繁，那样的话你就得疲于支撑了。放心，因为RFT不稳定，因为每次执行都要连到中央服务器来取用例，因为不能通过命令行或者Ant之类的办法把它放进持续集成，还因为用鼠标拖拽就是比用键盘慢得多，自动化测试的进展会非常缓慢，你大可以安心享受自己的新办公室。

先别急着享受，好事才刚开始呢。那些深思远虑的设计决策确保了很多项目不会认真用你的工具。这时候作为推行先进自动化测试理念的红人，你正好可以在老板耳边吹吹风，让他们强迫所有项目使用。强迫的方式有很多，但你必须记住的手段是给测试人员做职业技能鉴定考试：必须学会用你的工具才能评级加薪。这招的关键在于一箭双雕：不仅可以强迫他们使用，而且确保了他们没时间没动力去了解别的测试工具──你当然不想这些傻瓜突然冒出来说“这个开源的工具比我们自己的好用多了，而且还有那么多社区高手在维护和支持，为什么不用它”，对吧？

强行推广之后，你接到的支撑需求肯定会剧增。这时你得好好培训一下客服的小弟。要让他们分清用户的来头。如果是老板重视的项目，如果办公室离你或者离老板很近，就得大力支持。如果来自什么边远山区的支撑需求，那就把它撂到一边凉快去吧。这些边远山区经常会提些奇怪的需求，例如“能不能不连中央服务器执行用例？我们这里无法连通公司内网”。让小弟们直接回复“不行”就可以了。无法连通公司内网的人同样无法有效地跟领导告状，不用担心他们。

好了。现在你已经从一个边缘程序员成功晋升为公司的红人。不仅有一帮小弟鞍前马后，而且一大帮项目头头们都得求着你优先支撑。这快感，又岂是交付一两个项目、开一两次庆功会所能比拟的？恭喜你。你不仅改变了自己的命运，还很有可能改变整个公司的命运呢。

噢，差点忘了最重要的……千万别用你们的测试工具来给自己的项目做自动化测试。微软那帮傻逼把这种行为叫做“吃自己的狗食”，可你做的是毒药，吃下去会害死自己的。切记，切记。

界，越界，以及自制轮子的邪恶本质

做工具需要知道界限。一个好的工具，应该只做一件事并把它做好，是为高内聚；应该以最容易、信息量最少的方式与其他工具集成，是为低耦合。这些道理，Eric Raymond早就说过了，不应该再重复。

（跑题：GUI迷恋者的盲点在于，他们没有意识到鼠标点击是一个蕴含了多大信息量的操作。在1024×768的屏幕上找到一个48×48的图元然后向右拖拽530像素。啧啧。不懂得文本和命令行的重要性的人不配做工具。）

持续集成工具应该做的事就是让集成能够被“持续”起来。“集成什么”和“怎么集成”是软件开发者自己的事。测试工具应该做的事就是帮助编写和运行测试用例。“测试什么”和“怎么测试”是软件开发者自己的事。这就是一个明确并且信息量最小化的边界。

而坏的工具则总是尝试越界。通过把软件的集成过程本身纳入持续集成工具会让软件被集成得更好吗？不会。只会让软件开发者更加不了解自己的集成。通过把软件的测试过程本身纳入测试工具会让软件被测试得更好吗？不会。只会让软件开发者更加不了解自己的测试。其结果是，拥有现场信息和能力、应该关注这些事情的人不去关注，只管盲目堆代码而不管得到什么软件；没有能力关注这些事情的人被不断求助──他们也没有真正去关注，因为他们没有能力。

简而言之，试图用越界的工具大包大揽软件的质量保证，其结果是没人关注软件的质量。

推论是，自制轮子的工具本质是邪恶的。自制轮子的人没有办法像开源社区那样拒绝越界的非法要求。他们只能迫于上下两方面的压力把不该自己做的事纳入自己的产品中，并因此陷入不断为别人的事提供支撑而没有时间做好该做的事的泥沼。这种邪恶本质是内生的：不仅因为这些工具一定会越界，而且因为这些工具会被强加于人。因此自制轮子的工具永远不如开源工具。

（我知道我的客户会有一些人看我的博客。对了，这就是写给你们看的。你们知道我在说什么。）

知识·欲望·绑架

掌控了那么多知识，而又不愿意提供给其他人使用，又有什么意义呢？但正是因此，我谈到了欲望。罗杰·培根对知识的渴求不是一种欲望，他是想用科学给上帝的子民造福，因此他不是为了知识而寻求知识。而本诺那种欲望仅出于无法满足的好奇心，以及拥有才智的自傲。对一个僧侣来说，那不过是一种转化和抑制自身肉欲的手段。

书本的益处就在于让人阅读。一本书是由论及其他符号的符号构成的，而这些符号又论及别的事物。如果书本不被人通过眼睛阅读，那书上面的符号就不能产生概念，书就成了哑谜。这座藏书馆的诞生也许是为了拯救这些书籍，而如今藏书馆却是为了埋葬这些书而存在，因此它成了叛逆的诱因。

──翁贝托·艾柯，《玫瑰之名》

可是，我们的DNA在哪里？

子曰：不得中行而与之，必也狂狷乎，狂者进取，狷者有所不为也。

一开始，我们只是想教他们写程序。因为我们相信，如果程序员不会写程序，那么不管用什么组织结构什么流程方法，也不可能把软件做好。就这么简单，而已。

于是一切就开始了。他们的测试一团糟，所以我们教他们做测试。他们的构建脚本不自动化，所以我们教他们做一键式构建。他们的持续集成没有规矩，所以我们帮他们建立持续集成纪律。他们角色之间沟通成本很高，所以我们帮他们建设一体化团队。他们做个培训叫人昏昏欲睡，所以我们帮他们培养敏捷教练……

我们还想得更多。他们的考核方式重个人目标多于团队目标，虽然我们不是绩效考核的专家，但我们给了他们建议，于是他们开始改变了。他们和客户打交道的方式让他们难受得要死，虽然我们不是搞客户的专家，但我们给了他们建议，于是他们想改变了。他们的项目监理让他们束手束脚，虽然我们不是监理的专家，但我们也想给他们建议，让他们改变。“如果有天让我做这件事……”我们经常这样的想着。

因为我们都是进取的狂者。某人说，就像丰田方法之于其他所有人讲的精益一样，我们能得到区别于其他所有人讲的敏捷的ThoughtWorks方法。他们需要的，我们能做的，远不止现在这些。那些我们还没有做、想要去做的事，才是对他们最有价值的。

然后伊涅什说，是的，我们当然可以做这些事，我们都是进取的狂者，然则当我们一次又一次地改变自己，我们最初的DNA在哪里？我们是不是会很容易地劝服自己，没关系，如果我们能做好这些最有价值的、最关键的事，程序员们自然会找到方法学会写程序的──我几乎就把自己劝服了。

两周前我和YH说，我很喜欢豆瓣上的某个小组。那天下午，YH就改了他的签名档。于是我问自己，我会给自己找一条有所不为的线吗？

YH的签名档说：最终我们都会变成自己讨厌的那种人。

被高手们震撼到了

宁宇，中国移动业务支撑系统部规划建设处副总经理。今天临时抱佛脚，看他的博客和别的一些文章，被震撼了。

我们现在先把全省集中的计费系统做好，积累经验和技术，然后再将计费和营帐一起做全省集中；当这些都实现后，再将客服系统纳进来。这个时候，我们就可以做企业级的数据仓库，以及电子商务了，等到这两个部分都做好，企业信息化就能够实现

移动的BOSS走到今天，得益于众多SI的支持和帮助，即使有的SI已经不在了，但是他们对于技术的积累和贡献仍然至今还服务于业务支撑。这也客观造成了移动BOSS的SI门槛越来越高，如果不是HP和华为这样的实力派厂商，恐怕很难进入这个圈子。

还有姜涛的博客，也看得受益良多。

在 3G时代，运营商的系统越来越像是一个运营的平台，大量的增值业务诸如视频点播等等在上面跑，如果运营商没有良好的欠费控制，用户看了一段视频，内容提供商是得从电信运营商那里收钱的，即使是电信运营商自己购买的版权，这笔花费依然不少，所以在线计费势在必行。

Before about 1970, manyOSSactivities were performed by manual administrative processes. However, it became obvious that muchof thisactivity could be replaced by computers. In the next 5 years or so, the telephone companies createda number ofcomputer systems (or software applications) which automated much of this activity. This was one ofthe drivingfactors for the development of the Unix operating system and the C programming language.

每个行业的核心都是那么的有趣啊^_

禅意的对谈

领导：大师你看，我们公司多久能达到敏捷的状态呢？

大师：五年。

领导：大师有所不知，我们公司执行力很强，只要我一句话下去，所有人都会照办。

大师：哦，那么十年吧。

（如有雷同，纯属巧合。请勿对号入座，谢绝跨省追捕。）

去了QCon，又回来了

去QCon做了个演讲，把演说之禅里学到的东西试用了一把。据说，效果还不错。

每次讲真实的故事，就会觉得，讲得有劲，似乎别人听得也有劲。

问我，在研究什么呢？没有在研究什么。研究人算是研究吗？Fearless Change是个挺好的典范。

与人斗其乐无穷，也有术与道之分。一件件实践着的时候，常常归纳模式，确保原则没有变。那就不会误入歧途了吧。

又回到实践的战场了。进取中的常自反省，很好。

《持续集成》第二版译出

《持续集成》第二版的中译本。感谢雷镇的奉献。

一开始，我将已集成的源代码复制一份到本地计算机。这可以通过从源码管理系统的 mainline 上 check out 一份源代码做到。

现在我拿到了工作拷贝，接下来需要做一些事情来完成任务。这包括修改产品代码和添加修改自动化测试。

一旦完成了修改，我就会在自己的计算机上启动一个自动化 build。

当我 build 成功后，我就可以考虑将改动提交到源码仓库。但麻烦的情况在于别人可能已经在我之前修改过 mainline。这时我需要首先把别人的修改更新到我的工作拷贝中，再重新做build。如果别人的代码和我的有冲突，就会在编译或测试的过程中引起错误。我有责任改正这些问题，并重复这一过程，直到我的工作拷贝能通过 build 并和 mainline的代码同步。

一旦我本地的代码能通过 build，并和 mainline 同步，我就可以把我的修改提交到源码仓库。

然而，提交完代码不表示就完事大吉了。我们还要做一遍集成 build，这次在集成计算机上并要基于 mainline 的代码。只有这次 build成功了，我的修改才算告一段落。

无畏·勇气

做360度评价。发现别人对我的认知和我的自我认知之间，差别最大的是“fearless”这项。

原来那么多人认为我”always fearless”，还有”like challenge”。 天知道我有多胆小。风险只会让我焦虑并加重颈椎病症状。

风说，要勇敢，至少装作勇敢的样子，很少有人能看出两者的差别。（知人论世就是，你不仅要知道大家都认为他很勇敢，还要知道他其实只是装作勇敢的样子。）

Deliberative和Context的特质，使你面对风险时思考它的前因后果。对它认识得更多，也就更容易去承受它。所以让你看起来无畏。可能这不是无畏（不害怕），而是勇气（害怕也敢于去做）。郭晓如是说。

也许知道自己胆子小，就会认真去计算一个uncertainty的成本和收益；反而成天嘴上喊着“敢于尝新”的某些人，面对风险总以“要想清楚”做借口。这么一来，岂不是比我更胆小了么。

原来勇气是一种与知识、与经验、与计算有关的东西。嗯，符合敏捷价值观。

持续集成不是敏捷的基础

它就是敏捷本身。或者说得更大一点，持续集成就是软件交付本身。

持续集成反映交付形态。这句话实际上是肖鹏说的。实际上是肖鹏很久前说过然后李丰用了很长时间理解了然后再说出来然后我听了一耳朵然后又用了很长时间理解然后再说出来的。持续集成是什么样，不是由持续集成负责人设计的，而是由软件交付形态决定的。

所以持续集成反映交付团队的一切现状和问题。分层分级的持续集成，说明团队与团队之间的沟通成本高。层级之间以二进制还是源代码集成，代表团队之间的依赖层面和交付形式。测试用例失败时构建不失败，说明交付团队没有可依赖的质量标准。构建的频率，代表团队关注质量的频率。每日构建，说明质量没有内建在生产流程中，全靠“守门人”把关。

没有持续集成，说明交付流程是混乱不清晰随机的。

（推论：关于“敏捷是不是必须有持续集成”的讨论再也不想听到，因为持续集成不是敏捷的组成部分，它就是敏捷本身。连交付流程都没有还提什么敏不敏捷的，没有意思。）