对Service Component Architecture模块的可靠和可重复的单元测试 第3部分 测试使用人工任务的业务流程

本系列教程的第 3 部分将讨论有效而可靠的单元测试，学习如何将测试框架用于需要人工交互的测试流程。能够包括人工任务意味着您可以真正地执行对 Business Process Execution Language (BPEL) 流程和人员查询的完整测试。

<!--START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- include java script once we verify teams wants to use this and it will work on dbcs and cyrillic characters --> <!--END RESERVED FOR FUTURE USE INCLUDE FILES-->

摘自 IBM WebSphere 开发者技术期刊。

引言

在本系列教程的前两篇文章中，我们介绍了对 Service Component Architecture (SCA) 组件执行重复测试的方法，其中包括使用 Business Process Execution Language (BPEL) 实现业务流程的组件。 我们的方法利用了 JUnit 开放源代码框架和 Cactus（其服务器端扩展）。在本部分中，我们将介绍测试使用人工任务的业务流程的方法。首先介绍包含内联人工任务的简单业务流程，然后在测试此流程 时列出前两篇文章中介绍的适用技术。所有这些需要设置一种场景来演示如何处理人工任务，我们的方法是先前技术的扩展。

查看系列所有文章。

回页首

测试组件

本文与前两篇文章一个重要相同点是通过把有效负载和预期结果外化到 XML 文件来简化测试的创建。我们将通过分析图 1 所示的简单流程来说明此情况。

图 1. 带有内联人工任务的 BPEL 流程

此流程表示一个简化的档案检索流程，该流程在收到检索请求并得到确认后开始，并通过调用通知服务完成。实际的检索工作需要人工干预，这表示为 Retrieve 人工任务；我们可以设想此人工任务可能需要在长期存储库中对纸质文件进行物理检索，或需要从磁带库中装入磁带。如何处理此人工任务是本文的重点内容——但是，在了解这些人工任务之前，让我们先总体了解一下测试此流程的方法。

我们的测试需要使用各种不同的输入值启动流程，然后根据验证和人工任务的结果确认使用适当的值完成了通知。我们的测试计划包括表 1 所示的项。

表 1. 示例测试计划
测试 ID 输入请求 任务 通知结果

1	有效请求	人工任务成功	成功的通知
2	有效请求	人工任务报告检索不可能	失败的通知和原因
3	无效请求	无人工任务	验证失败的通知

前两篇文章介绍了定义输入请求数据和验证预期通知请求的一些技术。让我们对这些技术简单地总结一下。

指定服务调用

图 2 显示了启动 Archive Retrieval 流程的测试规范；使用 InitiationRequest.xml 有效负载文件中定义的有效负载调用 initiateRetrieval 方法。

图 2. 示例测试规范

我们可以创建此请求的变体来执行测试计划中定义的每个测试。

模拟对象

BPEL 流程将通过调用外部服务 notifyCustomer 完成。此流程成功的一个主要条件是将预期值提交到此服务；对于某些测试，我们希望看到有效负载指示成功的检索，而对于其他测试，我们希望看到有效负载指示 特定的失败条件。模拟对象用于验证预期值正在生成。我们将创建提供 notifyCustomer 方法的 Customer Communication 组件实现。模拟对象的一个额外功能是控制器接口，它使测试框架能够查询是否使用预期数据值调用了模拟对象。在图 3 显示的测试模块的组装关系图中，您可以看到，模拟控制器和档案检索接口是作为独立引用提供的，以供我们测试使用。然后我们可以创建测试规范，如图 4 所示。

图 3. JUnit 模块组装


图 4. 模拟服务调用确认

该测试包含模拟对象从业务流程接收的预期通知数据的有效负载；仅当业务流程生成此预期数据时，整个测试才能成功。

测试规范摘要

图 5 显示了我们介绍的测试规范、流程和模拟对象之间的关系。还突出显示了其余的问题：人工任务。

图 5. 测试和模拟对象

若要运行测试，则需要启动业务流程，人工任务将在 Retrieve 步骤生成，并且不再需要执行其他步骤。我们需要声明和完成 人工任务，以便流程继续到 notifyCustomer，因此，需要为 CheckNotification 步骤准备 MockCustomerCommunication 对象。在本文接下来的部分中，我们将介绍声明和完成人工任务的技术。

本文提供的下载文件中包括 Project Interchange 文件中的一组项目。此文件包括以下项目：

表 2. 要导入的项目
项目 类型 内容

L_Archive	SCA 库	档案应用程序组件的接口。作为应用程序的一部分提供，用于 JUnit 测试。
MP_ArchiveRetrieval	SCA 模块	档案应用程序流程模块。包含我们要测试的 BPEL 流程。
J_ScaUtilities	Java 库	应用程序和测试都需要使用的工具。
LT_ScaTest	SCA 库	单元测试和模拟对象使用的接口，不用于应用程序。
LT_ScaJunitTest	SCA 库	JUnit SCA 测试执行代码。仅供 JUnit 测试使用。
MT_TestArchiveRetrieval	SCA 模块	提供 JUnit 测试的模块
MT_TestArchiveRetrievalJUnitWeb	J2EE Web 项目	JUnit 测试代码、测试定义和有效负载数据，MT_TestArchiveRetrieval 的一部分。
MT_MockCustomerCommunication	SCA 模块	模拟服务的实现，该服务将发送到检索请求结果的客户通知。

将这些项目导入到 WebSphere® Integration Developer，并在本文的后续内容中继续对它们进行检查（假设您运行该测试并使用 Business Process Explorer 探索其效果）。

使用人工任务需要您启用 WebSphere 安全性，这样 WebSphere Process Server 可以标识不同的人工任务，从而使人工任务能够正确分配。如果您还没有启用 WebSphere 安全性，并希望完成这些示例，那么请按照下面在测试环境中启用安全性部分中的描述启用安全性。如果已启用了安全性，那么您需要为测试执行提供合适的用户；该部分中还描述了一组适当的用户，本文提供的下载资料中包括示例 Custom Registry 文件、archiveUsers.props 和 archiveGroups.props。

启动 WebSphere Integration Developer 测试服务器，并将以下三个 SCA 模块添加到服务器：

• MP_ArchiveRetrieval
• MT_TestArchiveRetrieval
• MT_MockCustomerCommunication。

当按照本文进行操作时，您将发现我们提供的测试框架可使测试创建变得相当简单。如果您要亲自创建类似的测试，则需要创建类似于 MT_TestArchiveRetrievalJUnitWeb 和 MT_TestArchiveRetrieval 的 JUnit 测试项目。本系列的以前文章阐述了如何实现这一点。

回页首

声明和完成人工任务

这里，我们将了解一下示例测试场景，并完成图 5 中突出显示的缺少步骤：通过声明和完成检索人工任务模拟人工干预。我们将对此场景使用自顶向下的方法，即先执行测试，然后分析发生的处理，最后详细了解测试步骤的规范。

运行测试

将列出的项目导入到合适的工作区后，请切换到 Web 透视图。展开 Dynamic Web Projects，然后展开 MT_TestArchiveRetrievalJUnitWeb 项目，以查看 JUnit 测试类及其相关的测试数据（图 6）。

图 6. 示例人工任务测试

让我们检查一下测试类 HumanTaskExampleTest 和 HumanTaskExample-Data 目录中的数据文件。当打开 HumanTaskExampleTest.java 时，您将看到以下熟悉的测试代码：

public class HumanTaskExampleTest extends ServletTestCase {
	public void testHumanTask() {
		ScaTestExecutor executor = new ScaTestExecutor(getClass(), getName());
		executor.executeServiceTest();
	}

我们将仅考虑一种名为 testHumanTask 的测试方法，此方法的测试步骤位于同一名称的子目录中，如图 6 所示。您会注意到此目录中有五个数据文件，其扩展名为 .tspec。这些文件定义以下五个测试步骤：

1. 010-HouseKeepArchiveProcesses.tspec——清理先前测试中的任何失败流程。（将稍后讨论）
2. 020-InitialiseNotification.tspec——初始化 Mock Customer Notification 对象。（有关详细信息，请参见以前的文章）
3. 040-InitiateRetrieval.tspec——使用有效数据初始化 Archive 流程。（这是图 5 所示的第一个步骤）
4. 050-CompleteRetrieval.tspec——此步骤模拟人的行为来声明和完成检索任务。这是我们要详细分析的步骤。
5. 060-CheckNotification.tspec——验证 Mock Customer Notification 对象是否从流程收到了预期的数据。

通过启动 JUnit 测试执行这些步骤，该测试的说明可在第 1 部分中找到。总的来说：

1. 在 Web 透视图的 Project Explorer 视图中，选择 HumanTaskTest.java。
2. 运行 Menu => Run...，以显示 Run 对话框。
3. 单击 New，使用 HumanTaskTest 类及其包来填充 Test 选项卡。
4. 选择 Arguments 选项卡，并输入 Cactus URL 作为 VM 参数（如果需要，请调整端口，以反映服务器的设置）：

   -Dcactus.contextURL=http://localhost:9080/MT_TestArchiveRetrievalJunitWeb
   

   
   
5. 单击 Run 启动测试。JUnit 视图中将显示进度（图 7）。

图 7. 执行示例测试

现在，让我们验证在执行此测试的过程中，在业务流程中实际发生了什么情况。

在控制台中发生了什么情况

测试进度的有用信息将报告到控制台。（下一部分将介绍 BPC Explorer 如何用更友好的方式提供此类信息。）您可以使用控制台视图检查服务器的 SystemOut 日志（图 8）。

图 8. 服务器的 SystemOut 日志

您可能会发现此输出内容相当详细；您可以修改测试框架，使之更简洁，以供日常使用。与一般情况相比，此示例中提供了更多的信息，而这些信息可能对了解测试活动很有帮助。

在控制台中，我们可以看到测试的五个步骤：

1. 010-HouseKeepArchiveProcesses.tspec

   此步骤将删除先前执行时保留的 Archive 流程的任何实例。（稍后讨论如何执行此操作。）

   HumanTaskExam I   Test: HumanTaskExampleTest/testHumanTask/tidy up archive 
   processes - zap everything
   ProcessTestEx I   Complete task
   ProcessTestEx I   Terminate process instance MP_ArchiveRetrievalProcess state 3
   ProcessTestEx I   deleted :_PI:9003010f.5331a825.3d725bf6.47190000

   
   

2. 020-InitialiseNotification.tspec

   此步骤将初始化 Mock Communication 对象。

   HumanTaskExam I   Test: HumanTaskExampleTest/testHumanTask/Reset Mock Communication

   
   

3. 040-InitiateRetrieval.tspec

   下一步将初始化检索流程。将显示用于初始化流程的数据。

   HumanTaskExam I   Test: HumanTaskExampleTest/testHumanTask/Initiate retrieval 
   process
   initateRetrie I   Initiating with <?xml version="1.0" 
   encoding="UTF-8"?>
   <_:datadump xsi:type="l:RetrievalRequest"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xmlns:l="http://L_Archive" 
   xmlns:_="http://scatest/issw/ibm/com">
     <customerId>1</customerId>
     <requestId>11</requestId>
     <dateOfRecord>2006-05-12T10:04:17.714Z</dateOfRecord>
     <region>111</region>
     <duration>1111</duration>
   </_:datadump>

   
   

4. 050-CompleteRetrieval.tspec

   此步骤是重点查看的内容：检索任务的声明和完成。

   HumanTaskExam I   Test: HumanTaskExampleTest/testHumanTask/Archive retrieval completes
   HumanTaskTest I   Complete task
   HumanTaskTest I   task query TASK.STATE = TASK.STATE.STATE_READY AND
   (TASK.KIND = TASK.KIND.KIND_PARTICIPATING OR TASK.KIND = TASK.KIND.KIND_HUMAN)
   AND WORK_ITEM.REASON = WORK_ITEM.REASON.REASON_POTENTIAL_OWNER
   AND TASK.NAME = 'MP_ArchiveRetrievalProcess$MP_ArchiveRetrievalProcessTask1'
   
   HumanTaskTest I   claimed com.ibm.task.api.ClientObjectWrapper@3b198581
   HumanTaskTest I   completion data <?xml version="1.0"
   encoding="UTF-8"?>
   <_:datadump xsi:type="l:RetrievalResponse"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:l="http://L_Archive"
   xmlns:_="http://scatest/issw/ibm/com">
     <status>7</status>
     <explanation>Retrieved</explanation>
   </_:datadump> 

   
   

   查询字符串

   上面第一个粗体部分显示了用于声明任务的任务查询。当创建此测试步骤时，您需要指定标识要声明和完成任务的查询。这里使用的查询选择可对其进行声明 的特定类型的人工任务。在此简单的流程中，仅使用单个任务的单个实例，不需要对查询进行更精确的控制。更复杂的情形可能需要更复杂的查询；信息中心的 Interface HumanTaskManagerService 文章是了解查询语法的很好的入门文章。

   完成数据

   您可以根据任务的接口并通过提供适当的完成数据来完成任务，如上面的第二个粗体部分所示。在本例中，状态代码“7”指示成功的检索。这可以满足示例测试计划（表 1）中的第一项。第二次测试将提供指示失败检索的状态代码。

5. 060-CheckNotification.tspec

   在最后一步中，模拟对象将报告它收到的检索通知。

   MockCustomerC I   sendRetrievalResult<?xml version="1.0" 
   encoding="UTF-8"?>
   <_:datadump xsi:type="l:RetrievalNotification"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xmlns:l="http://L_Archive" 
   xmlns:_="http://scatest/issw/ibm/com">
     <specification>
       <dateOfRecord>2006-05-12T10:04:17.714Z</dateOfRecord>
       <region>111</region>
       <accessDuration>1111</accessDuration>
       <requestId>11</requestId>
     </specification>
   <result>7</result>
     <resultNotes>Retrieved</resultNotes>
   </_:datadump>

   
   

   粗体数据显示业务流程成功获取人工任务的结果，并创建了通知。最后，您可以看到测试步骤正在检查模拟对象是否收到正确的数据。

   
   

在 BPC Explorer 中发生了什么情况

在 Business Integration 透视图（图 9）中，选择 Properties 视图。

图 9. 流程删除

在开发和测试过程中，最好取消选中 Automatically delete the process after completion 选项，因为这样可以简化故障事件中的问题诊断。不过，这意味我们需要对旧的流程实例执行一些常规操作，像在测试步骤 010-HouseKeepArchiveProcesses 中执行操作一样。

1. 由于尚没有删除最近执行的测试的流程实例，所以您可以使用 Business Process Choreographer (BPC) Explorer 来验证测试执行情况：选择 Servers 视图，然后选择测试服务器，再右键单击，并选择 Launch => BPC Explorer（图 10）。

   
   
   图 10. 启动 BPC Explorer
   
   
   

2. 选择 Process Instances Administered By Me（图 11）。您将看到完成的流程实例，其状态为“Finished”。

   
   
   图 11. 流程实例
   
   
   

3. 单击流程实例（图 11），以显示该实例的详细信息，然后选择 Activities... 选项卡。

   
   
   图 12. 流程活动
   
   
   

4. 图 12 显示了流程实例执行的三个活动，并按相反顺序显示。按预期的时间顺序它们应为 initiateRetrieval、Retrieve 和 notifyCustomer。BPC Explorer 允许您检查活动的有效负载。例如，如果单击 notifyCustomer，您会看到由流程创建的数据（图 13）。

   
   
   图 13. 通知消息
   
   
   

5. 我们这里主要关注“检索”人工任务。在活动列表中单击 Retrieve 任务（图 12），并选择 Activity Input Message 和 Activity Output Message 选项卡，分别如图 14 和15 所示。

   
   
   图 14. 检索任务输入
   
   
   
   
   图 15. 检索任务结果
   
   
   

6. 如果您选择 Staff 链接，则还会注意到目前人工任务的潜在所有者是“所有人”。更实际的业务流程将需要身份验证，并且人工任务要分配到特定的用户或用户组。稍后我们将返回到人员查询这一问题。

接下来，我们将检查人工任务测试步骤的详细信息。您需要了解任务的声明规范和检索响应的规范；在上面的示例中，响应是状态值“7”和解释值“Retrieved”。

指定人工任务

声明和完成人工任务的每个测试步骤由测试数据目录中的三个 xml 文件定义。在 Web 透视图的 Project Explorer 视图中，展开 MT_TestArchiveRetrievalJUnitWeb 项目，并找到以下三个文件：

1. 050-CompleteRetrieval.tspec

   tspec 文件是一个测试规范文件，类似于以前文章中描述的那些文件。这里它包含一种新功能，即服务引用一种完全限定的 Java™ 类，而不是 SCA 组件。

   <service>com.ibm.swservices.sca.test.junit.HumanTaskTestExecutor</service>
   <method>completeHumanTask</method> 
   <payloadFile>CompleteRetrievalHtSpec.xml</payloadFile>
   <description>Archive retrieval completes</description> 
   <pause>10</pause>

   
   

   指定 Java 类的能力使您能够扩展测试，以添加所需的功能，在本例中，此功能为调用人工任务 API。指定的类必须位于 Web 模块的类路径中。HumanTaskTestExecutor 类提交到 L_ScaJUnitTest 测试框架库中，这样它可以作为 MT_TestArchiveRetrievalJUnit 应用程序的一部分与 Web 模块一起部署。

   在 Web 透视图的Project Explorer 视图中，找到位于 Other Projects 下的 HumanTaskTestExecutor.java 代码，如图 16 所示。打开该文件并检查提供的方法。您将看到有两个方法可供测试使用：deleteHumanTasks 和 completeHumanTask。我们认为，大型项目可能还需要其他方法；如果是这样，完全可以将它们添加到此类中。

   
   
   图 16. HumanTaskTestExecutor 类
   
   
   

   在我们的示例中，我们使用的方法是 completeHumanTask。测试规范使用 payloadFile 元素来引用第二个数据文件：CompleteRetrievalHtSpec.xml。

2. CompleteRetrievalHtSpec.xml

   此文件包含要声明的 HumanTask 的规范。在我们的示例中，该规范为：

   <taskName>MP_ArchiveRetrievalProcess$MP_ArchiveRetrievalProcessTask1</taskName>
   <taskCompletionFile>CompleteRetrieval.xml</taskCompletionFile>
   <minTaskCount>1</minTaskCount>
   <maxTaskCount>1</maxTaskCount>

   
   

   此文件的三个重要组成部分为：

   • 要声明的任务规范。
   • 第三个数据文件的引用，它包含用于完成任务的数据。
   • 预计声明多少个任务的规范。

   可以按以下两种形式提供规范：作为完整的查询字符串，或仅作为任务的名称。在我们的示例中，任务名称由 WebSphere Integration Developer 生成。您可以在 BPC Explorer 中的流程实例的 Task 选项卡中看到任务名称，如图 17 所示。

   
   
   图 17. BPC Explorer 中的任务名称
   
   
   

   更复杂的测试场景（其中可能包含多个未完成任务，每个任务需要使用不同的数据完成）将需要使用查询字符串。您可以使用查询字符串（而不是仅使用任务名称）来指定测试。

   <queryString>
   TASK.STATE = TASK.STATE.STATE_READY
   AND (TASK.KIND = TASK.KIND.KIND_PARTICIPATING 
   OR TASK.KIND = TASK.KIND.KIND_HUMAN) 
   AND WORK_ITEM.REASON = WORK_ITEM.REASON.REASON_POTENTIAL_OWNER 
   	AND TASK.NAME = ' 
   MP_ArchiveRetrievalProcess$MP_ArchiveRetrievalProcessTask1 '
   </queryString>
   

   
   

3. CompleteRetrieval.xml

   第三个文件包含用于完成任务的有效负载。在我们的示例中，有效负载为：

   <status>7</status>
   <explanation>Retrieved</explanation>
   

   
   

常规操作和扩展

我们用于指定人工任务测试的技术是可扩展的。我们已提供了第二个类 ProcessTestExecutor，它包含常规操作功能。检查 010-HouseKeepArchiveProcesses.tspec 及其相关的有效负载文件，如图 18 所示。

图 18. 常规操作规范

您会看到我们指定使用 deleteProcesses 方法，并将其应用到与 MP_ArchiveRetrievalProcess 模板对应的所有流程中。您可以按此方式添加自己的功能，以支持自己的测试要求。

这些执行常规操作流程和人工任务的简单测试步骤示例，主要供在开发模式中专门从事工作站开发的单个开发人员使用。他们不打算与其他人同时共存测试。 从理论上讲，此类共存是可能的，但是必须将查询编写为可选择。我们不打算将此类测试用于实际的生产环境中，如果您这样做，则很可能会导致严重后果，如删除 有价值的流程实例，或意外执行人工任务。

回页首

身份验证和人员查询

还有一个测试功能需要说明：即使用指定的身份验证凭据执行测试的能力。此测试使您能够验证人工任务规范的某些重要方面。

打开 Retrieve 人工任务的详细信息（图 19）。在 Business Integration 视图中，选择 BPEL 编辑器中的任务，然后在 Properties 视图的 Details 选项卡中单击任务名称。

图 19. 显示人工任务详细信息

当 Human Task 编辑器显示（图 20）时，在 Receiver settings 中单击 Potential Owner，以显示 Everybody 可以声明此任务。

图 20. 供所有人使用的人工任务

在实际的业务流程中，查询谓词可能更为复杂，因此，确实为此任务自定义开发了查询谓词。查询可用于实现业务需求，如“4 只眼”注销；这需要两级审批，并且审批人员为两种不同的技术人员。此类查询的状态与您开发的任何其他代码相同，并且在您的测试中应使用它们。

全面测试需要您指定执行每个测试步骤的用户身份。测试框架允许您为每个测试步骤指定用户 ID 和密码。

图 21. 为测试指定身份验证

此工具假定您在测试环境中启用了安全性。我们假定您将与其身份验证详细信息不敏感的用户一起使用测试注册中心，因此，可以接受纯文本密码。通过进行 其他编码工作，可以实现更安全的身份验证方案。如果您在测试中使用纯文本密码，则应考虑许多其他开发人员很可能共享您的测试（可能通过源代码管理系统）。 您应该对专门用于测试的用户（无 WebSphere 管理权限）进行设置，并在测试脚本中只引用这些用户。我们的下一个示例将向您演示如何完成此操作。

在测试环境中启用安全性

在 测试服务器上启用安全性的过程因您选择使用的特定用户注册中心而异。执行单元测试的优先选择是使用基于文件的自定义注册中心。使用此类注册中心可省去对外 部服务（如 LDAP）的任何依赖。这里描述的自定义注册中心配置可以满足桌面计算机上的桌面单元测试，但是它不能用于生产系统。

1. 创建两个文本文件，一个用于用户，一个用于组。本文的下载文件包含适用的示例：archiveUsers.props 和 archiveGroups.props。信息中心中对这些文件的格式进行了阐释。将文件放置到一个方便的目录中。稍后在配置注册中心时，您需要知道它们的位置。

2. 我们定义了五个组：

   • administrators——具有 WebSphere 管理权限的员工。
   • operators——具有 WebSphere 操作权限的员工
   • workers——可以实现检索流程的员工
   • approvers——高级员工
   • users——使用检索流程的员工。

   在这些测试中，您仅能指定用户、工作人员和审批人员组的成员。

3. 我们定义了以下用户（在以下特定的组中）：

   • wps-server（管理员）
   • administrator（管理员）
   • operator（操作员）
   • archivist（用户和工作人员）
   • seniorArchivist（用户、工作人员和审批人员）
   • retriever（用户和工作人员）
   • librarian（用户、工作人员和审批人员）
   • joe（用户）

   请注意，WebSphere Application Server 本身将以 wps-server 身份运行，我们将此身份用于所有内部服务器的身份验证。

4. 要配置自定义注册中心，请启动测试服务器，并调出管理控制台。导航到 Security => Global Security，并单击用户注册中心下的 Custom（图 22）。将显示自定义用户注册中心窗格（图 23）。

   
   
   图 22. 自定义注册中心
   
   
   
   
   图 23. 服务器 ID
   
   
   

5. 输入服务器要使用的用户名和密码；我们的示例使用的是 wps-server。单击 Apply，然后单击 Custom Properties（图 23）。将用户和组文件的位置指定为自定义属性（图 24）。

   
   
   图 24. 自定义注册中心文件位置
   
   
   

6. 创建两个新的属性 groupsFile 和 usersFile，并指定属性文件的绝对路径。

7. 保存更改。

8. 您将使用 LTPA 身份验证，这需要预配置步骤。返回到 Global security 窗格（图 22），通过选择 Authentication 下的 LTPA 执行第二个配置步骤。指定一个任意密码，并确认它，然后单击 OK。

9. 最后的预配置步骤是指定 JCA 身份验证值，以便访问 JMS 资源。再次返回到 Global security 窗格（图 22），在 Authentication 下展开 JAAS configuration，并选择 J2C Authentication data。

   
   
   图 25. JAAS 别名
   
   
   

10. 依次选择 SCA 别名和两个 JMS 别名，然后为每个别名指定 wps-server 和密码。保存更改。

11. 您现在可以启用全局安全性了。返回到 Global security 窗格（图 26）。

    
    
    图 26. 启用安全性
    
    
    

12. 进行以下更改：

    • 对于 Active authentication mechanism，请选择 LTPA。
    • 对于 Active user registry，请选择 Custom user registry。
    • 选中 Enable global security。
    • 取消选中 Enforce Java 2 security。

    单击 OK 并保存更改。

13. 此 时，在不使用 WebSphere Integration Developer 的情况下，最好测试一下您的服务器配置是否正确。在 WebSphere Integration Developer 中停止服务器，然后从命令行启动它。您需要打开命令窗口，并将目录更改为概要的 bin 目录；在我们的示例中为：C:\IBM\WID-6.0.1\pf\wps\bin。

    C:\IBM\WID-6.0.1\pf\wps\bin>startserver server1
    ADMU0116I: Tool information is being logged in file
               C:\IBM\WID-6.0.1\pf\wps\logs\server1\startServer.log
    ADMU0128I: Starting tool with the wps profile
    ADMU3100I: Reading configuration for server: server1
    ADMU3200I: Server launched. Waiting for initialization status.
    ADMU3000I: Server server1 open for e-business; process id is 4448

    
    

14. 现在选中记录错误消息的服务器日志。由于先前错误键入了 JAAS 别名数据而报告错误这种情况相当常见。这些错误不会阻止服务器启动，但是会阻止服务器的正常运行。

15. 您可以通过手动调出管理控制台来修复任何错误。在服务器日志中搜索管理端口：

    [11/12/06 13:52:05:375 GMT] 0000000a TCPChannel    A   TCPC0001I: TCP Channel TCP_3 
    is listening on host *  (IPv4) port 9043.
    [11/12/06 13:52:05:391 GMT] 0000000a WSChannelFram A   CHFW0019I: The Transport 
    Channel Service has started chain WCInboundAdminSecure.
    

    
    

    并在浏览器中使用相应的 URL：https://localhost:9043/admin。请使用下面的服务器标识进行身份验证：wps-server。

16. 服务器正确启动后，您可以调整 WebSphere Integration Developer 配置，以便与之通信。在 Server 视图中，双击服务器，调出 Server Overview 窗口（图 27）。确保使用了 SOAP 连接。

    
    
    图 27. 服务器的 WebSphere Integration Developer 身份验证
    
    
    

17. 展开 Security，指定 Security is enabled on this server，并为 WebSphere Integration Developer 指定用户 ID 和密码，以便向服务器进行身份验证。最初将 wps-server 用作身份标识；随后可以对它进行改更。

18. 保存更改。您应看到 WebSphere Integration Developer 成功地检测到服务器正在运行；不过，您可能看到在服务器日志中出现一些身份验证失败信息。重新启动 WebSphere Integration Developer，这些故障信息应消失。

19. 配置的最后部分是允许 WebSphere Integration Developer 作为服务器本身的独立用户进行身份验证。启动管理控制台，并选择 System administration => Console users => Console Groups（图 28）。

    
    
    图 28. 管理组
    
    
    

20. 添加 admins 组作为管理员。保存更改，并重新启动服务器。您现在可以调整 WebSphere Integration Developer 身份验证，以便使用管理员用户，从而使 wps-server ID 仅供服务器流程使用。

回页首

运行经过身份验证的测试

您现在可以为每个测试步骤指定适当的用户，方法是将 userId 和 userPassword 元素添加到每个 tspec 文件：

表 3. 测试用户
步骤 用户 组

010-HouseKeepArchiveProcesses.tspec	seniorArchivist	审批人员——只有高级员工可以执行常规操作
040-InitiateRetrieval.tspec	joe	用户——所有员工都可以请求检索
050-CompleteRetrieval.tspec	librarian	工作人员——所有工作人员都可以完成检索请求

然后可以设计其他测试，以验证是否正确地指定了员工查询。例如，您可以指定一个测试，其中仅用户组的某个成员尝试完成检索；此尝试将由于缺少权限而失败，并且该测试将检查检索是否完成。

为测试指定了身份验证数据后，您可以重新运行它们，并使用 BPC Explorer 来验证流程和任务是否有预期的所有者。

图 29. 仅限于审批人员的流程管理

在图 29 中，您可以看到流程由用户 joe 启动。管理任务只能由管理员执行，即用户 seniorArchivist 和 librarian。通过选择检索任务，您可以看到成为任务所有者的用户。

图 30. 由工作人员完成的任务

图 30 显示用户 librarian（工作人员组的成员之一）执行了检索任务。

回页首

结束语

本文介绍了如何将测试框架与人工任务结合使用，从而支持 BPEL 流程和人员查询的完整测试。用于启用人工任务操作的技术对扩展其他测试技术是开放的。本文通过另一个示例显示了常规操作流程。