测试小分队要解决的一大问题是很多测试的质量不高（比如运行不稳定、速度太慢、不好维护，等等），这和我想用gTest解决的问题是一致的。所以，经过几个月的实战、打磨，gTest渐渐稳定之后，小分队决定在全司推广gTest。大家讨论后决定，把工程师入职时的技术培训做为一个重要的着手点：按照谷歌发展的速度，大部分员工都是入职三年以内的新员工，所以把新同事发展成测试能手，对提高公司的测试质量至关重要。抓住了新人，就抓住了未来。这时小分队的Mike Bland同学挺身而出，挑起了把“如何写C++测试”培训改写成使用gTest的重担。Mike不光测试经验丰富，热心公益，还风趣幽默，写得一手好文。他来牵头改培训材料，实在是gTest之幸。此外，他还热爱音乐，几年后为了追梦从谷歌离职，到美国最顶尖（没有之一）的流行音乐学府，波士顿的伯克利音乐学院学习音乐，成了王力宏的校友。

 

说到Mike和音乐，还有段小八卦：有一年我司系统升级，所有C++代码要从32位模式改成64位模式编译，这样可以利用更多的内存。为了解决升级过程中的问题，测试小分队组织了一次全司范围的“64位修好它（64-bit fix-it）”草根活动。作为鼓励大家参与的手段，Mike建议我们买了一批Beatles乐队的“佩珀军士孤独心灵俱乐部乐队”CD做为奖品。我来说明一下：这张专辑Mike不是随便选的。除了在2003年被“滚石”杂志评为史上500张最佳专辑第一名外，它还暗含了一个紧扣这次活动的哏：其中有一首歌叫“当我六十四（When I'm 64）”。后来我想，其实改用郎朗的CD应该也不错，因为在我们用的gcc编译器里，long long数据类型就是64位啊！而且，不管能不能弄到郎朗的签名（signed or unsigned），都是64位，哈哈。

 

回过来再说gTest。通过换位思考，我意识到必须要有一套清楚易读的用户文档，才能降低使用gTest的门槛。俄罗斯文学大师托尔斯泰山说得好：人性都是懒惰的，在有选择的情况下，大多数人都会选一条相对容易的路。如果一个系统很难学，别指望大家会选择它。就算你酒再好，巷子深了也会造成用户流失，至少是拖延发展用户的进度。所以，一开始我就花了不少时间编写和打磨用户手册。过了一段时间，我从一些老工程师那里得到反馈：看完一遍使用说明时间太长了，很多人没有那么多工夫；如果把手册拆成初阶和进阶两部，让人可以快速上手就好了。我觉得这是很好的建议，马上就照办了。

仔细想想，这其实是一个用户需求细分的问题。不同的用户，甚至同样的用户在不同的情况下，会有不同的需求。如果用同样的服务来应对不同的需求，用户体验不会好。把gTest文档拆分后，新手可以花15分钟看入门指南，然后基本用法就有数了；老用户想提高自己的技巧可以看高阶指南；使用过程中碰到问题可以看“常见问题解答”；如果还是搞不懂可以上邮件表提问。这样各个层次的需求基本上都照顾到了。两年多后，我做gTest的姊妹项目gMock（另一个C++测试工具）时，采用了类似的做法，把文档分成了傻瓜书（介绍最基本的概念和用法）、作弊页（把最重要内容简单地归纳在一张纸上，便于快速查找）、菜谱（针对一个个具体的应用案例，给出解决方案）和常见问题解答几个部分，大家反映效果不错。

 

在gTest的发展过程中，我犯过一些错误。这里讲讲印象比较深刻的一个：为了让测试写得更精炼一些，我定义了一个叫TEST_FIXTURE的宏。这个出发点是好的，万万（就是我）没想到，它把Emacs（一个很多程序员用来编辑代码的工具）的自动缩进功能搞糊涂了。结果，凡是用到TEST_FIXTURE的地方，Emacs都会对不齐。虽然不影响功能，但是把代码搞得不好看。等我收到用户投诉的时候，已经不少人在用这个宏了。怎么办？我先试了试能不能改造Emacs绕开这个问题，结果发现太难搞。那么剩下两条路：要么硬着头皮一条道跑到黑我就是不改了大家凑合吧，要么把这个功能去掉，但是这会把很多人已经写好的测试搞坏。经过反复内心交战，我最终决定长痛不如短痛，长吸一口气，把这个宏删了。然后，我就开始不断接到用户电邮、即时信息、和电话报告某某某项目的测试又坏了（那时我们还没有很好的内部工具提前找到所有会受影响的测试，只能等用户报告），我再忙不迭地道歉、修理。那天夜里，我抱个笔记本，靠墙坐在地上（不要问我为什么这种姿势，我也不记得了）一直干到凌晨四点，终于把全部问题解决了。深刻的教训啊：做系统不是做研究，不能光想到技术的优劣，一定还要把重要的非技术因素考虑进去，一切以用户体验为检验标准。

做gTest，我最大的感触是做好一个系统只是冰山一角，增长用户服务用户完善系统才是工作的大头。后者是一个日复一日不断迭代的过程，短时间内不显功但是绝对不可缺少。说到为用户服务，可能有的朋友会认为就是把用户当上帝，用户提个需求我们就照他的意思去做。我觉得这样做是搞不出真正杰出的产品的。苹果创始人乔布斯老爷讲，如果150年前你要去问小朋友他们做作业想要什么，他们会告诉你想要100页的活页本，不会说要iPad。这观点我太赞同啦！你想想，如果用户能取代你做设计，你领这么多工资不有愧吗？

 

大多数时候，用户并不真正知道自己想要的是什么，他们只是按自己的本能提要求，基本不会有全局思维。如果让用户牵着鼻子走，就会朝令夕改前后矛盾左右互搏一团乱麻。一定要在倾听用户反馈的基础上加以提炼，问一问：他们到底最终要解决什么问题？有没有类似问题是其他用户会碰到的？这类问题的本质是什么？有没有一个通用优美的解决方案？这个方案会不会和其它需求冲突？把这些问题想清楚了再下结论。基于这一原则，我在很多时候会礼貌但是坚定地对gTest的用户说不。虽然这不是他们当时想要听到的答案，但是我相信这是对他们长远来看最有利的答案（从统计意义上说）。当然，我也会犯错，但是一个有眼光有原则的设计师偶尔犯犯错，远好过随波逐流的设计。 

 

上一篇，系列目录，下一篇