财新传媒
位置:博客 > 万战勇 > 我在谷歌弄啥咧之五:继续推广gtest

我在谷歌弄啥咧之五:继续推广gtest

测试小分队要解决的一大问题是很多测试的质量不高(比如运行不稳定、速度太慢、不好维护,等等),这和我想用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的用户说不。虽然这不是他们当时想要听到的答案,但是我相信这是对他们长远来看最有利的答案(从统计意义上说)。当然,我也会犯错,但是一个有眼光有原则的设计师偶尔犯犯错,远好过随波逐流的设计。 
 



推荐 23