几乎所有面向服务架构(SOA)用户都在使用业务流程执行语言(BPEL)。作为编排粗粒度的业务流程流工具，BPEL实际上是行业的标准，但是无论是自身特性还是与它所编排的网络服务之间的连接都会引起测试问题。达到BPEL测试的最佳实践需要一种自顶向下的法，此方法结合了一套测试工具并且将BPEL完全整合到应用生命周期管理(ALM)之中。

第一步：建立一个模型

成功的BPEL测试始于建立一个全面逻辑的或者容许序列的业务流程模型，这个模型在BPEL维度和组件测试/ALM维度中对于促进测试至关重要。这个模型需要定义流程顺序以及在何种情况下这些顺序是有效或可预测的。

试着从业务逻辑角度建立模型并且避免以现有的BPEL或文档作为源文件，因为这会把之前的错误编码到本次测试中。这样做的目标是从业务角度验证或建立BPEL。随着这一步的完成，技术一致性会确保IT流程的业务整合。

执行BPEL测试

在达到业务流程一致之后就可以开始实际测试。通常的做法是把BPEL测试从在线网络服务的组件测试/集成测试中分离出来。让两个流程从本质上成为并行单元测试，之后合并到单一的ALM模型集成测试中。从BPEL角度看，测试目标是迅速验证业务流程顺序和性能，避免混合大量的实际网络服务使设置复杂化。

这非常重要，BPEL给那些从公司IT移出的工作流做出了指导。在支持大规模产品运动和即使制造组件上，集成数据交互就是这种跨公司工作流的例子。跨公司测试很难进行，因为几乎所有人都想在内部调试他们流程上的问题以避免与重要商业合作伙伴之间的冲突。

为了支持独立的BPEL测试，大部分公司将会确定一个BPEL测试框架或者一套工具，使BPEL不用在一整套的在线网络服务之中验证。如果你大部分的中间件来自于一个开放资源，SOA供应商的BPEL测试框架就更可能成为你的实际选择。除了像BPELUnit这样的开源工具，有些公司有自己的工具用于BPEL测试，比如IBM、微软和甲骨文。

使用框架的BPEL测试流程，包括带有将要调用的模拟网络服务的测试生成平台和一套测试BPEL编排流程的测试数据。在好的BPEL测试框架下，测试数据的生成是自动化的，是基于用户约束的。前述的初始业务流程评估是一种定义有效流程的好方法。。

测试数据应该通过有效路径测试，来保证数据不会强制编排进入不合逻辑的路径，或者生成与管理需求不符的工作流。与测试数据生成的一般案例一样，目标是要使测试所有可能的逻辑路径。如果工作流被测试流程记录下来，而它们又能对之前 识别的业务流程流验证，那将是很有价值的。

BPEL和服务/总线或工作流性能也可能成为一个问题，但至少有可能得出一个大致的思想：编排在BPEL测试层面上是如何影响性能的。你的业务流程流应该和总交易量链接，从而完成一个工作流编排所需的时间（忽略网络服务执行）就可以在BPEL测试中看到了。

发现复杂工作流（与很多组件相链接的工作流）的地方，或出现大量交易的地方（例如零售）或都两者都有的地方，BPEL每个交易支出的粗略估计就可以用来决定工作流的最小时间需求了。而这可以和商业响应时间需求核对。

集成业务BPEL测试到生命周期管理

由于使用框架的BPEL测试的目的是将网络服务测试从SOA组件中分离出来，所以把BPEL测试完全集成到ALM中，在大多数情况下并不是最佳选择。习惯做法是测试组件流来验证所谓的技术接口（预期数据和可用数据之间的关系，功能等），最后集成BPEL来验证总功能。

在这种情况下测试数据生成将会已成为BPEL驱动的生成数据（注重编排验证）和网络服务驱动的数据生成（注重功能验证）的混合体。如果BPEL测试数据生成可以用于产生两种测试数据，这将是很有用的。

当把BPEL测试集成到ALM时，大部分公司希望把他们合作伙伴的网络服务从测试中分离出来——除非双方有协定。这意味着要在ALM结构中使用一些模拟网络服务来代表外部合作伙伴的活动。

如果想要获得性能数据来验证ALM/BPEL测试的响应时间，必须确保模拟服务生成的时间能反映实际情况。测试这些网络服务的实际响应时间来获得正确值是很必要的。

业务流程、BPEL、SOA组件、应用和ALM之间的关系每天都变得更加弹性。BEPL测试结果通过存档业务流程流可以变得更加固定，这可以使SOA测试和BPEL测试保持一致，成为一个共同参考。随着常规元素重新部署，这又可以帮助减少成熟测试在BPEL和组件层面上的需求，同时还可以保持应用质量和功能。

关于作者：

Tom Nolle是CIMI公司总裁，CIMI成立于1982年，专注于电信和数据通信战略咨询。