昨天是周五,按照工作计划,上午和组内同事做个人阶段性目标沟通。在与一位曾经在国外公司里做过项目的同事沟通时,他给我讲了这么一个故事:某一年的圣诞节前夕(圣诞节在西方人眼里是地位最高的节日了吧)他所在的那家公司的经理预感到圣诞节那天他们公司的网站的访问量激增的可能性会很大,为了保证网站在那圣诞节那天能"挺住",他要求手下的人对网站进行一次压力测试,并决定让手下用jmeter来做这件事情。手下人没有异议,由于没有用过jmeter,遂大家都忙碌起来,预研的、准备测试环境的等等。一切就绪后,正准备开始测试了,这时那位经理突然召集手下人说jmeter不能满足他们的压力测试要求,大家都惊愕之,并马上提出了反驳,因为jmeter工具是这位领导提出要使用的,现在又不用了,圣诞节已经迫在眉睫,更换压力测试工具肯定不能完成这个任务了。这位经理无奈妥协,结果是:通过jmeter压力测试后优化的网站顺利了通过了”圣诞节的考验“,不过大家都觉得这个过程很别扭。

上面的那位经理显然是犯错误了,我看到的起码有二:第一,没有经过对jmeter细致的评估,就断言要使用jmeter做为压力测试工具;第二,其领导意志的不坚定,险些使任务失败,并最终造成了公司成员的不满情绪,影响了整个团队,得不偿失。

这个故事也让我触动很大。记得在上一个项目的准备布局阶段,我当时很想在项目组内推行自动化页面测试,提高开发人员和测试人员的测试效率,到目前为止我也觉得当初我的想法是没有错的,但是问题就在于执行过程出了问题。我对web页面开发是外行,WEB页面开发过程会遇到哪些问题,我基本没有太多概念。当时部门内部正巧有一个服务于外国公司的项目使用了Watir-一款用Ruby实现的轻量级开源Web 自动化测试框架,很袖珍,上手简单。我就安排了一位同事专门花时间去研究了一下如何使用这个工具,并在组内做了一个Share。大家对这个工具提出了一些自己的意见和建议,并基本上认同了它。由于是试点,所以先安排放到测试组做自动化页面回归测试,由专门的测试人员负责编写测试脚本。就这样完成两轮测试后,收到一份文档-关于Watir在自动化回归测试过程的问题报告,里面列出了诸多问题,比如:自动测试过程中如遇到弹出对话框的情况,自动化过程被中断,需人为干预;测试对数据依赖很大,当数据量很大,需要多页显示时,没有找到很好的办法;页面元素变动较为频繁,用例脚本需不断更新,工作量较大;Watir只支持IE,对其他浏览器支持不好;Watir录制功能不甚完善等等。这些问题是我始料未及的,恰逢那个时候,我又发现了一个更为强大的页面自动化测试工具-Selenium,我个人也就渐渐的对Watir失去了早先的热情,Watir在我的不坚定的意志下没有收获很好的结果。现在看来,如果当时我持续关注、持续推进Watir的使用,积极解决发现的问题,也许Watir就会成为大家日常不可缺少的一个工具而存活下来,显然我没有这么做,我想和上面的故事一样,或多或少这也给组内的同事带来了一些负面的影响。

与此类似的是部门曾经多次考虑过使用C++来重新设计和实现我们的产品,众所周知C++开发效率高,性能也不逊于C,如果真的改成了C++,我们的思维也可以和这个世界接轨了(很多人认为:太多的新思想似乎和古老的C搭不上边),大家认可,关键是领导也认可并鼓励一些有能力的开发人员抽时间研究学习C++,但是每每总是不了了之,领导始终没有坚定的意志做这次变革,开发人员也逐渐消磨的热情,回归到了C的世界。

打破既有规则,拥抱新事物,似乎一直就是一件很困难的事,而领导意志在一个组织内部目前来看还是起着决定性的作用的,否则再好的东西也会变成局部的个人兴趣,没有用武之地。如果一个领导坚定的推行大家都不认同的新事物(很可能是领导的个人喜好或者上级的命令),那么这样带来的后果将更加严重。

所以作为领导的,确需三思而后行啊,用此文自勉共勉吧。

© 2008, bigwhite. 版权所有.

Related posts:

  1. 推进项目改进,难!
  2. Boost_1_32_0版源代码编译
  3. 看完“程序员”2005-04期一些想法
  4. 开发人员之维护他人项目有感
  5. APR源代码分析-进程同步篇