下一代的功能测试工具应当提供怎样的功能？ 它们需要表现的像可以阅读的文档么？ 它们需要内嵌高级的测试编辑器，并通过这个编辑器来支持界面测试的自动完成功能以及测试代码的重构和分析么?

        又或者它需要象wireframes 和状态机那样支持多种表现方式么？  它需要将测试结果可视化么？ 或者以自学习的方式来生成测试用例？

        敏捷联盟在2007年10月11日和12日于俄勒冈州的波特兰市召开了专题讨论来展望下一代的功能测试工具。

        这个专题讨论通过描述功能测试工具过去的发展以及未来的方向为发起这一专题讨论给出了上下文：

        好消息是在最近几年，自动化功能测试的工具支持增加显著。目前有大量的商业或者开源的测试工具或者框架可以支持敏捷开发实践。FIT框架的出现在规范的语 法(使用表格的方式编写测试)，详细的测试执行结果(详尽到单元格)以及开发和执行环境(作为桌面工具存在而不是开发或者特定用途的工具)方面，对于自动 化功能测试是一个极大的提升， 
        但是，我相信目前是在功能测试方面进行另一重大提升的最佳时机。

        缺少整合的开发环境帮助我们：重构测试元素，自动完成命令，增量式的语法检验(基于测试领域特定语言)，快捷键支持，调试等等。

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

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

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

        我们还没有意识到的问题。

        这个大会只是敏捷联盟的功能测试计划的开始，由 Jeannitta Andrea 和Ron Jeffries 以及 Elisabeth Hendrickson发起。 Jeanitta之前一直在编写下一代功能测试工具，目前主要忙于下一代功能测试工具的展望。

        你对功能测试工具有怎样的需求？在研讨会中与会者会就什么问题进行讨论？ 你现在在使用什么工具，它们在哪些方面表现不错，在那些方面不能胜任？

        我们将继续跟踪报道这一计划，请继续关注。