谈功能测试之美

　　谈功能测试之美  软件测试

　　功能测试之乐:

　　功能测试定义了产品的业务需求，通过它业务人员可以了解系统是否能在各个业务场景下正常工作。功能测试通常使用某种自动化测试框架编写，这样开发者可以从自动化的功能测试中获得快速反馈，为下阶段新功能的开发或软件内部实现的重构提供帮助。另一方面，它大大减少了手动环节可能引入的错误，而将枯燥的回归测试交给机器完成，在加快测试速度的同时，将质量保证人员解放出来，从而使他们可以更多地关注于创造性的探索测试。通过从用户角度进行的功能测试，团队对系统在真实条件下的可用性充满信心，而自动化的功能测试也大大提高了工作效率。这样一来，产品能以更高的质量，更快的速度进入市场。

　　功能测试之苦:

　　* 保持验收条件及其技术实现的同步

　　在任何开展自动化功能测试的敏捷开发团队中通常会存在两套系统、 一套是BA(业务分析师)\QA(质量保证人员)所编写、维护的验收条件，可能以纸卡、Wiki等形式记录下来。另一套是验收条件的技术实现。以源代码的形式记录，由开发者维护。两套系统的并行发展，带来了同步的问题。如何快速将验收条件转变为技术实现?当验收条件变化时如何使源代码部分同步变化?可不可以将验收条件与测试关联起来，利用Rspec的思路消除这个并行的系统?

　　* 无法系统化的划分测试

　　速度是阻碍频繁运行功能测试的主要原因。进行功能测试的团队常常花费数十分钟甚至数小时来运行完整的功能测试套件，加快测试几乎总以失败而告终，从用户角度进行业务场景的测试决定了功能测试的速度天生就是缓慢的。随着软件功能的日益完善，更多的测试被添加到套件中，庞大的套件也使得测试运行的时间越来越长。无法快速得到反馈使团队没有安全感，同时大大减缓开发的脚步，烦躁的开发者甚至开始逃避运行测试，将不安全的代码集成到产品中。

　　只运行相关的测试，听起来这似乎是一个解决方案。当开发者修改了登录模块的实现后，为什么他们非得花费1个小时等待其他模块的测试结果呢?如果可以仅仅运行登录模块相关的测试，将其余的测试留给持续集成工具运行，开发的效率将大大提高。但遗憾的是在XUnit的世界中，系统化的划分测试并不是件容易的事情。不论是利用文件名和目录来区分，还是手工维护测试套件，最终总会变成难以维护的大泥球。

　　* 阅读测试花费的大量时间

　　大量测试代码总是难以阅读。随着项目的进行， 各种不同习惯的缩写出现在代码中、测试代码中出现的大量的方法、设置数据越来越复杂等都给阅读测试带来了极大的麻烦。面对失败的测试，试图修复它的开发者总是需要在复杂的代码中挣扎着找出测试的意图，过滤掉准备数据的过程，抽丝剥茧地找到这个测试所覆盖的业务流程，分析究竟是哪个产品模块出了问题。出现这样问题的根源是没有对测试的目的 (业务价值)和技术实现做出合理的抽象。

　　能否有这样一个视图，过滤掉所有让人分散注意力的方法(私有方法，准备数据、清理数据的方法等)让开发者可以清楚地看到测试的目的和步骤，甚至让测试以一种自然语言的形式展现出来，让非技术人员也可以轻易地阅读修改测试呢?

　　* 启动功能测试的花费

　　在任何一个团队开始功能测试的第一步，总是耗时和痛苦的。下载各种依赖的库文件，在脚本中进行配置， 保证功能测试可以在命令行执行， 同时还要对IDE进行配置，让开发者可以从IDE中方便地运行单个测试。

　　能不能缩短这个过程，减轻开发者的痛苦?

　　功能测试工具的趋势:

　　敏捷联盟在2007年10月召开了专题讨论来展望下一代的功能测试工具。在这次讨论中, 功能测试领域的专家们提出了对下一代功能测试工具的展望：

　　* 需要一个整合的开发环境帮助团队：重构测试元素、自动完成命令、增量式的语法检验(基于测试领域特定语言)、快捷键支持、调试等等

　　* 需要更具描述性的测试领域语言，如将可执行文件、文字、表格、图片、颜色整合到一个测试用例中

　　* 需要特定的测试领域语言使测试更具阅读性并容易维护

　　* 需要具备可以使用多种方式查看/导航测试的能力，来帮助我们了解某个部分与整个领域或者特性之间的联系;将测试按照领域上下文来组织;按照用户定义的关键字进行搜索(跨横切关注点)

　　Twist

　　经历过很多的功能测试之苦，我们团队尝试了使用Twist来编写、管理功能测试，并得到了很好的效果。它是ThoughtWorks Studio为软件团队设计开发的下一代协作功能测试平台，提供了一个编写、执行以及维护测试的丰富环境。Twist以Eclipse插件的形式设计并开发，充分利用了Eclipse强大的编辑功能，支持测试专家们通过DSL来表达测试意图。通过自动完成功能，开发人员可以利用Eclipse中广为人知的CTRL + 1 (帮助完成)来快速地将验收条件转换为相应的技术实现(测试类和方法)。由于Twist中的Driver是以Spring Bean的形式注入到测试中，开发者可以以Twist作为平台，使用任何熟悉的DRIVER(如Selenium、Watir、fraiksen)来编写测试。

原文转自：http://www.ltesting.net