最近有关下代功能测试工具发展方向讨论热闹地开了锅不过还是众多组织仍然在努力让传统“录制-回放”测试工具跟上敏捷脚步被称为“测试狂人”Elisabeth Hendrickson告诉他们为什么不要再白费功夫了

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

　　为什么传统、“录制-回放”式、重量级、商业化测试自动化解决方案做不到敏捷？

　　 3个原因:

　　◆对于敏捷团队(Team)来说类似工具所鼓励“最后再测试”工作流程是完全

　　◆类似工具创建无法维护脚本会成为敏捷所需变更障碍

　　◆这样特定工具会需要专门自动化测试专家因此会形成单打独斗局面

　　Hendrickson首先讲述 “录制-回放”式工具“最后再测试”方式是如何难以取得成功而无关乎项目是否敏捷她解释了为什么这对敏捷项目来说尤其是个伤害在敏捷项目中“最后再测试”工作流程至少有下列问题:

　　浪费:同样信息在手工和自动化回归测试中会重复出现实际上它也在其他地方有所重复不过我们可以先将注意力放在手工和自动化测试的上

　　反馈延迟:这种工作流程中大量测试都是手工方式这就是说要花费几天甚至几周时间才能发现原先给出变更所产生效果如果我们Spr是 4周次那用 3至 4周时间等待回归测试结果就无法令人接受进步说“最后再测试”工具无法支持“验收测试驱动开发(Acceptance Test Driven Development)”敏捷团队(Team)需要测试工具要支持“首先测试”方式并可以马上开始进行自动化测试

　　Hendrickson解释了测试脚本如何成为这些“录制-回放”测试工具基础而且会无可避免地造成类似意大利面混乱局面将UI代码中有关业务上期待和具体实现细节混杂在起从而导致敏捷项目很容易变为场维护噩梦她简明地说:

　　敏捷团队(Team)需要可以将要测试业务实质内容和实现细节相分离工具这样分离是良好设计标志并可以增加可维护性

　　接下来在很大程度上出于考虑高昂成本和代码所有权需要典型“录制回放”工具会将大多织引向创建专有“自动化测试专家”小组的路并且他们会被授权负责监控自动化测试Hendrickson强调了这样方式是如何对有效敏捷所需协作方式形成阻碍

　　敏捷团队(Team)通过破除单干局面来提升工作效率这凭些所谓自动化测试“超级英雄”无法完成也就是说自动化测试成为需要协作完成工作ac业务利益相关者、分析师和黑盒测试人员他们都可以通过可自动化形式(比如Fit表格)来做出对测试贡献；而员则负责编写代码将测试和实现相关联

　　最后Hendrickson讨论了敏捷团队(Team)确实需要什么样自动化测试工具并以此作为结束:

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

　　◆要支持“首先测试”方式并可以马上开始进行自动化测试

　　◆将要测试业务实质内容和实现细节相分离

　　◆在自动化测试需要编码部分支持并鼓励好编程实战

　　◆支持使用真正开发语言、真正IDE来编写自动化测试代码

　　◆促进协作

　　◆Fit、FitNesse以及相关工具可以达成上述要求