醉里乾坤大,壶中日月长

自动化测试与敏捷开发

上一篇 / 下一篇  2010-07-27 14:12:49 / 个人分类:闲言碎语

周六参加了Baidu技术交流会,会上的两个主题《web automation test》和《TDD》都是当前非常感兴趣的话题,因为:目前采用敏捷的方式开发我们的自动化测试框架和脚本。

敏捷这种模式或多或少大家都有些了解,虽然挺久之前对此就有所了解,但一直没有深入,只是草草看些书籍,了解些梗概,也还相当混淆。

但这次为了采用这种开发模式,和头认真的学习《敏捷软件开发原则、模式与实践》这本业界的经典书籍,也根据书中的模式进行结对编程,测试驱动开发等极限编程的典型实践进行演练,对于敏捷这种开发模式有了客观的了解,当然,还不深入。

看看振奋人心的敏捷宣言吧:

我们正在通过亲身实践以及帮助他人实践,揭示更好的软件开发方法。通过这项工作,我们认为:

个体与交互       胜过    过程和工具

可以工作的软件   胜过    面面俱到的文档

客户写作         胜过    合同谈判

响应变化         胜过    遵循计划

虽然右项也具有价值,

但我们认为左项具有更大的价值。

2001年的宣言,发展至今,已经指导很多公司进行了相关的实践。当然,我们这里也没有机会在发布的软件产品中进行敏捷的尝试,在产品层面,我们的影响还不够,但,在我们自己的自动化测试框架和脚本开发中,已经开始遵循敏捷中的典型方法极限编程来指导我们日常的开发工作了。

在日常的工作中应用敏捷,激动的让人无以复加。看看如下的一些敏捷原则,你是否感觉到同样的激动?

在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈:我们越来越多的交互方式使用文档,使用电话,却没有发现我们的座位其实只有几步之遥,相比于那些交流方式,我更喜欢面对面和我的团队伙伴进行交流,这样我可以通过他(她)们的语言之外的表情,动作,了解他们更多的需求,也能让我产出的方案更贴近他们的需求;

工作的软件是首要的进度度量标准:放弃那些所谓的MPP吧,思维导图吧,大家真正需要的是可以工作的软件。有多少项目的产生周期是和MPP中涉及的一致的?

最好的架构、需求和设计出自于自组织的团队:相信你的团队伙伴,同时,让你的团队处在积极,乐观,进取的氛围下,大家彼此快乐的工作,自愿为团队奉献更多的应用和方法,而不是用所谓的高压去推进。

。。。。。。

当然,这些只是原则的一部分,其实我更激动的是一种心态上的契合。

我一直相信,流程和方法能够辅助项目的成功,但真正引导项目成功的决定因素,还是人。在敏捷这里,我找到了理论的依据:“过程和方法对于项目的结果只有次要的影响,首要的影响是人“;”人是获得项目成功的关键因素“;”项目的成功不是以稳定可靠的产品作为唯一输出,还要有不断进步的工程师“。。。

当现代项目,不断要求人去差异化,让大家成为零件的时候,这样的一种方法,能够让我们自身认识到自己的价值,并且在项目的发展中完善自己,我认为非常重要。

有时候,扪心自问,我们是否真的随着产品的成熟而进步?历经了一两年甚至几年的测试工作,是否在技术,视野等方面有了显著的提升?客观的说,我曾经的一些同事,负责某个产品已经数年,却连产品基本的一些业界通用的方法都不了解,不能自己实现,这样的结果让我感到非常悲哀。或许,每个人都应该从内心就明确的认识到,自我的发展也是项目的产出之一,优秀的测试工程师同样能够提高效率,提高产出,制造更多的价值。

再看看这条:可以工作的软件胜过面面俱到的文档。公司在进行流程的梳理与制定,以往很多的文档缺失,现在在弥补一些以往的稳定缺失,当是否需要很多文档呢?

在敏捷里面给出了一些指导的意见:没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档,来对系统及其设计决策的依据进行描述。然后,过多的文档比过少的文档更糟!编制众多的文档需要花费大量的时间,并且要使这些文档和代码保持同步,就要花费更多的时间。如果文档和代码之间失去同步,那么文档就会变成庞大的、复杂的谎言,会造成重大的误导。

在文档方面,我从来不是文档排斥者,我只是排斥过多的文档,你有没有发现你的团队用大量的时间做一些没有意义的文档?我有过这样的经历,在调查部门其它同事的工作,发现他们大量的时间用来做文档,真正的测试工作相比于文档反而少很多。这样的文档的受众有多少?不过是部门的寥寥几个人。。。

也许有人会认为,文档是知识传承的良好媒介,有了详细的文档就可以抵御人的流失。我不得不说,太多的文档正是人的流失的原因之一。同时,还要指出:最好的知识传承的媒介是人!一个系统,如果能够保持耐心的给予新人足够的指导,我相信他们对于系统的理解要远远超越于枯燥的文档,当然,如果你能把文档写得像老舍的小说那样精彩,我也会认同你写文档的方式。

还有就是,对于很多功能,为什么非要采用文档的方式来保存细节?我一直不明白,为什么不直接去看代码?类似我们的产品,每个人都有权限看代码,可以还是很多人愿意电话去问研发怎么回事,怎么回事,我有的时候很不理解。代码是最真实的文档,也一定比编写人员的描述更准确,更多的时候,我们应该查阅代码,相信代码,而不是别人的描述或者某些早已过时的文档。

 

其实模式没有好坏之分,还是要根据应用的场景来选择开发模式。到目前来说,我认为在我们的自动化测试框架和脚本开发工作中,敏捷的模式可能更适用。

比如我们可以无障碍的保持和客户的交流,甚至把客户作为我们开发团队的一员;

比如我们可以并不关注文档,而已可工作的代码作为交付;

比如我们可以测试驱动开发,让我们测试人员编写的代码同样经过测试,让代码健壮,而不是总是问一些,为什么代码会报错,难道是wait不够吗等等问题;

比如我们可以在功能实现后进行不断的重构,让我们的代码更清晰,结构更合理;

。。。。。

有太多的比如让我们选择敏捷作为我们的开发模式。

 

当然,正如前面所说,模式本无好坏,而是看场景。敏捷本身也有他自身的弊端,但至少当前,是满足我们的需求的,也激励我们更多的使用和尝试,现在还浅薄,希望伴随着使用,能够对这种开发模式有更深入的理解。


TAG:

逍遥客 引用 删除 xiaoyaoke   /   2010-07-28 21:28:59
原帖由ermine于2010-07-28 20:22:06发表


感谢支持啊~
逍遥客 引用 删除 xiaoyaoke   /   2010-07-28 21:27:32
原帖由liangshi于2010-07-28 11:12:57发表


感谢前辈的肯定
ermine的个人空间 引用 删除 ermine   /   2010-07-28 20:22:06
5
Smart Testing 引用 删除 liangshi   /   2010-07-28 11:12:57
5
 

评分:0

我来说两句

日历

« 2024-03-23  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 72621
  • 日志数: 106
  • 建立时间: 2009-06-05
  • 更新时间: 2011-09-09

RSS订阅

Open Toolbar