“没有测试数据”——尤其在需要多系统/进程之间协调数据时。

　　工具问题可以通过各种方式解决。向他们说明使用如JUnit或NUnit等标准测试工具的好处，指出用脚本进行整合的好处，并具有可持续的、可重复的方式进行测试的能力。在大型企业中，不太可能所有的人都使用同一工具。更现实的做法是，同一部门的开发团队至少有一套标准的工具集。我所做的是，提供标准的自动化测试脚本——这些脚本用于对JUnit测试用例进行编译、执行，生成报告并通过email发送报告——这些脚本是每个开发人员开发环境的一部分。当开发人员从源代码控制系统中下载工作副本时，测试脚本已经位，并且他们会继续加入自己的测试用例。我们团队有一个标准的测试目录结构，其中放置着测试用例和测试套件，脚本会从中选取并执行测试用例。另外，在代码复查期间，我会确保不但要复查代码，同时也要复查测试代码。对未包含在自动化测试中的测试用例进行重构也是复查工作的一部分。这同样适用于包含了硬编码数据的测试代码，把硬编码数据改为从配置文件或者数据库中读取。例如，一个测试方法指定用户角色为BRANCH_SUPERVISOR，而不是从配置文件中去获得。复查时，把这一属性保存在一个由名称-值数据对组成的文件中，重构该测试方法，使之从属性文件获取用户角色。这样一来，这一属性也可以被其他测试使用了。

　　对SOA项目来说，服务中整合了应用程序服务器、遗留系统、数据源或应用程序包，一系列的系统测试也是必不可少的。初，这些测试可以使用暂时代替后端整合点的mock对象执行。但终你会希望在真实的整合点上运行这些测试。在这种情况下，测试数据以及与多系统相关的数据极为重要。缺少良好的测试数据，特别是需要跨系统的数据，是导致无效自动化测试的一个重要原因。对需要依靠数据复杂性和系统运行时依赖较多系统的情况，可以分阶段解决这一问题。可以从数据的本地副本开始，开发人员查询多种数据源并填充到本地存储。这听起来非常像是手工操作，但如果数据是新的并且ETL作业/批处理过程对数据存储的填充还未完成，这也许是启动测试更为简单的方式。随着时间的推移，你可以建立起一套类，封装了来自多种数据存储的测试数据，确保数据的有效性和质量，并把填充测试数据作为持续集成脚本的一部分。无论如何，如果把测试用例代码和获取测试数据的细节解耦，更易于改变数据源策略而不影响测试代码。我的团队初用配置文件来提供测试数据，随后把数据迁移到一组数据访问类中，并通过这些类获取所需测试数据。例如，我们用DataAccessObject设计模式创建了一组java类，这些类封装了对客户数据和账户数据项的操作。这些类提供了一个简单的有增删查改方法的接口，JUnit的测试方法可以通过它访问这些类。如果一个测试方法需要获取客户数据，它会导入DAO工厂和特定的DAO类并调用getCustomer()方法。在提取特定客户对象时，测试可以继续执行其余的逻辑。测试不需要了解如何查询数据并将其打包至一个对象中的，而且这些接口能被其他测试重用。

　　定义什么是完成

　　在企业中，为完成指定一个标准是非常棘手的。在开发环境中执行地非常好的代码在测试环境下也许根本无法工作。这也许是由于安全令牌/安全政策、网络/连接问题、系统不稳定或是由于质量保证（QA）团队或终端用户更严格的质量测试。为了尽量减少迁移代码时的意外，完成标准中应当包括：

　　建立一套全面的测试套件，这些测试套件是可复用的，并大限度的减少（如果没法消除的话）硬编码的数据值。

　　在持续集成的过程中加入测试套件。例如，在我的团队中，这意味着在特定目录中加入JUnit测试套件，apacheant脚本可以从这一目录中提取并执行那些测试。

　　自动化测试用例不但要覆盖功能测试还要覆盖性能测试（例如，使用像JUnitPerf这样的工具，通过使用性能阈值实现测试场景自动化）。

　　获得广泛的测试数据。如果测试需要整合遗留系统，让开发遗留系统的团队同你们一起创建测试并定义测试标准。开发人员未必总能了解在遗留系统上工作需要注意的细微差别。开发环境下测试良好的一些场景，并不能反映生产环境中的实际数据。

　　代码复查不仅要在内部团队中进行，而且也要在基础团队中进行（例如，DBA、系统管理员）。

　　总结

　　本文谈到了在企业中应用敏捷方法面临的一些挑战，并提出了一些应对的策略。使用自动化脚本和检查清单以一致的方式建立开发环境，使用标准的工具和透明的测试数据有助于自动化测试和持续集成，并确保对完成有一个更严格的标准。这些方法并非无所不包，但它们会帮助团队在企业环境中获得更高的生产效率。