敏捷测试

上一篇 / 下一篇  2010-04-07 23:43:53 / 个人分类:测试技术

她的看法出色地总结为下面这种索引卡片的形式:

为什么传统的、“录制-回放”式的、重量级的、商业化测试自动化解决方案做不到敏捷?被称为“测试狂人”的Elisabeth Hendrickson分析如下三个原因:

◆对于敏捷团队来说,类似工具所鼓励的“最后再测试”的工作流程是完全错误的。
◆类似工具创建的无法维护的脚本会成为敏捷所需的变更的障碍。
◆这样的特定工具会需要专门的自动化测试专家,因此会形成单打独斗的局面。

   在敏捷项目组中,界面几乎要到了后期才会稳定下来,这个时候自动化就不能尽早的介入,传统的录制回放模式必须要等模块基本稳定了才可以开始,那么这个时候做出来的自动化只能作为下次回归化测试的时候才能派上用场,一点也不敏捷。敏捷团队需要的测试工具要支持“首先测试”的方式,并可以马上开始进行自动化测试。 那么什么样的工具才是这样子的呢?Hendrickson讨论如下:

敏捷团队需要的自动化测试工具或框架要像这样:

◆要支持“首先测试”的方式,并可以马上开始进行自动化测试。
◆将要测试的业务实质内容与实现细节相分离。
◆在自动化测试需要编码的部分,支持并鼓励好的编程实践。
◆支持使用真正的开发语言、真正的IDE来编写自动化测试代码。
◆促进协作。
◆Fit、FitNesse以及相关工具可以达成上述要求。

   我认为selenium也可以做到上述这些,selenium rc 用真正的开发语言,与开发人员的代码一起集中管理,透明度高,版本控制清晰,并且可以与开发人员很多的协作,相比较传统的录制回放工具,它更加适合在测试早期就能介入,更适合敏捷团队使用。


TAG:

 

评分:0

我来说两句

Open Toolbar