进行Struts应用程序单元测试开发

一 引言

测试驱动开发在减少开发努力的同时也改进了软件的开发质量 单元测试 作为一整套测试策略的基础 必须是全面的 且要求易于建立和执行迅速 然而 对执行环境和被测试类外部代码的依赖性使我们实现这些目标变得更为复杂 例如 把应用程序发布到容器将显著地延长代码和测试的周期 而对其它类的依赖性通常也会导致测试的建立更加复杂和测试运行速度更为缓慢

集成两个流行的测试框架（StrutsTestCase和EasyMock）来单元测试Struts应用程序将会更为容易地建立测试并加快测试速度 然而 这两个框架之间尚存在一些 隔阂 从而很难把它们理想地集成到一起 在本文中 我将通过分析两种方案（一个面向对象的方案和一个面向方面的方案）来探讨这个问题 同时 我还将展示面向方面编程(AOP)是如何通过简化一些看起来很困难的问题的解决方案而进一步补充面向对象编程(OOP)的

二 集成需要

一个典型的Struts应用程序既能够展示也其所使用的执行环境也会体现出类之间的依赖性问题 这是因为Struts行为（Action）是在一个servlet容器内执行的 并且典型情况下会调用其它的类来处理请求 模拟对象测试方法有助于消除其中不必要的依赖性 借助于继承自基本JUnit测试集的MockStrutsTestCase类 StrutsTestCase测试框架提供了对servlet容器的一种模拟实现 这显然方便了容器外测试 因而也相应地加快了单元测试周期 另一方面 另一个测试框架—EasyMock—进一步便利了对协作类的动态模拟（Mock） 这个框架中所提供的模拟能够用更简单的实现来代替真正的类 并且添加了校验逻辑以支持单元测试

非常清楚 把这两个框架结合在一起是非常有益的—Struts应用程序便可以在非常真实的隔离环境下进行测试 理想情况下 你需要使用下列步骤来实现这样的一个单元测试

建立MockStrutsTestCase以便模拟servlet容器

借助于EasyMock来模拟行为所依赖的类

设置模拟的期望值

把模拟注入到当前测试的行为中

继续进行测试和校验

注意 上面步骤 中所执行的依赖性注入使被测试的Struts行为远离了其真实的协作者而与一个模拟的行为进行交互 为了把通过EasyMock生成的模拟注入到行为中 你需要从测试类内部存取这些行为相应的实例 遗憾的是 这里出现了一种障碍 因为我们无法轻易地从MockStrutsTestCase中实现这样的存取

三 OOP方案

那么 你该如何从MockStrutsTestCase中存取行为实例呢？首先 让我们来分析一下MockStrutsTestCase和Struts的控制器组件之间的关系

图 中展示的关键关系有可能潜在地导致一种解决上面问题的方案

图 此处展示的关系能够建立一种OOP方案

MockStrutsTestCase中提供了一个public类型的getter方法用于检索ActionServlet

ActionServlet有一个protected类型的getter方法用于实现RequestProcessor

RequestProcessor把行为实例存储为一个protected类型的成员

你是否可以子类化ActionServlet和RequestProcessor从而使MockStrutsTestCase能够存取行为呢？相应的结果调用链看上去应该如下所示

注意 在你分析完把MockStrutsTestCase链接到Struts行为的调用序列图之后 你就会发现此方法是行不通的

图 展示了存在于MockStrutsTestCase和Struts组件之间的关键 互

   

图 存在于MockStrutsTestCase和Struts组件之间的交互

图 展示的问题涉及到Struts行为创建的时序问题 到行为内部的模拟注入必须在调用MockStrutsTestCase actionPerform()之前发生 然而 此时这些行为还不可用 因为只有在调用actionPerform()后 Requ

estProcessor才能够创建这些行为实例

既然你不能很容易地把行为实例传播到MockStrutsTestCase中 那么 为什么不子类化RequestProcessor并重载processActionCreate()方法呢？在这个重载方法中 你可以存取所有的行为实例 这样以来 创建 配置和设置对相应行为实例的一个模拟一下子变得非常直接 因为应该在执行完actionPerform()之后调用MockControl verify()方法 所以 你还需要重载processActionPerform()以进行此校验调用

这种方案对于测试正规的Struts应用程序是不太适合的 因为即使所有的行为仅与单个模拟进行交互 测试一个行为也有可能要求多个测试方法—每个方法都具有不同的模拟期望 为此 我们建议的方案是 创建不同的RequestProcessor子类 相应于每个子类设置不同的模拟期望 另外 还需要多个Struts配置文件来指定不同的RequestProcessor子类 最终 管理大量的测试将成为一件令人头疼的事情

四 AOP方案

因此 我们非常希望 在执行某行为之前能够通过某种方式实现在MockStrutsTestCase中使用该行为的实例 如果你熟悉AOP 那么 你会立即意识到它所提供的简单方案即能直接满足这一要求 注意 这里的关键是定义一个切点 由它负责捕获行为执行连接点 然后通过一个before advice把模拟注入到相应的行为中

在此 我选择使用AspectJ框架来实现这一方案 当然 其它的例如Spring AOP这样的AOP实现也应该能够良好工作 不过 Spring AOP还需要一个额外的步骤—通过Spring框架中的DelegatingActionProxy类把对Struts行为的管理委托给Spring

图 展示了基于AOP方案的单元测试示例静态模型

图 基于AOP方案的单元测试示例静态模型

SimpleAction是一个Struts行为的子类 同时与ActionService进行协作 其中 SimpleActionTest派生于MockStrutsTestCase 用来测试SimpleAction

SimpleActionTest使用EasyMock创建和建立一个模拟ActionService SimpleActionTest还实现StrutsActionPreExecuteListener接口以便在即将运行        SimpleAction的execute方法时接收通知 作为通知的一部分 SimpleActionTest接收SimpleAction实例以便注入ActionService模拟 由方面类StrutsActionPreExecuteNotifier负责通知任何实现监听器接口的测试类 并且使相应的行为实例可用

下面的步骤描述了实现StrutsActionPreExecuteNotifier的过程

◆首先 由一个切点选择相应的测试方法执行连接点 另一方面 这个测试方法驻留于负责监听该行为的预执行事件的测试类中 另外 这个切点还会暴露当前执行的测试类对象 pointcut mockStrutsTest(StrutsActionPreExecuteListener actionTest):

◆然后 由第二个切点负责捕获上面的行为执行连接点 通过结合第一个切点 匹配范围被限制到该行为相应的测试方法的调用流程的内部 这种进一步缩小的范围对行为执行（并非通过测试方法激活）起到过滤作用 最终 方面根本不会影响到最后生成的代码 该行为及其相应的测试类实例都是经由切点参数加以暴露的 pointcut strutsActionExecute(Action action StrutsActionPreExecuteListener actionTest):

◆最后 由一个与前一个切点相关联的before advice负责通知测试类（它们担任行为事件的监听器）并且传递相应于模拟注入的行为实例

图 展示了这些类之间的动态交互情形

图 类之间的动态交互

注意 图中从行为到方面的虚线描述了对行为执行连接点的捕获情况 此时序图与第一个时序图比较 其重要区别正在于行为执行之前发生的三个步骤

一个切点捕获行为执行连接点（由从SimpleAction指向StrutsActionPreExecuteNotifier的虚线箭头指出）

方面的before advice负责通知测试类并且把相应的行为实例传递给它

测试类把模拟对象注入到即将要开始执行的行为实例中

现在 你可以基于前面概括的五个步骤继续编写行为测试 下面的代码展示了相应于SimpleActionTest的部分代码 步骤已在注释中标出

使用MockStrutsTestCase和EasyMock进行行为测试的部分代码

在行动及其依赖的服务之间存在四种可能的复合关系

每个行为依赖于一个服务

每个行为依赖于多个服务

多个行为依赖于一个服务

多个行为依赖于多个服务

我在此展示的方案能够比较灵活而且相对容易地支持上面所有这四种情形 因为模拟创建 期望值建立以及模拟注入都能够在单个的测试类内实现

你能够不借助于监听器接口就可以在StrutsActionPreExecuteNotifier内部模拟注入吗？这看起来似乎使得测试类实现更简单一些 然而 实践证明 类似早些时候讨论的OOP方案 编写多个方面以创建不同的模拟对象并建立相应的不同的模拟期望是非常必要的 另外 在单个测试类内本地化模拟的创建与安装（借助于监听技术 这是可能的）将变得更为方便

五 总结

对于我们在本文中所讨论的集成问题 有人可能会创造出一套相当不错的OOP方案 然而 构造这种方案很可能需要对Struts和StrutsTestCase有深入的理解才行 并且要付出相当的努力 影响本文中所讨论的两个测试框架（StrutsTestCase和EasyMock）紧密集成的主要障碍在于 在Struts行为实例执行之前很难实现对它的访问 在认识了导致这种障碍的基本原因之后 AOP方案自然地出现在我们面前 不必再强求于基于传统型OOP的那种更复杂的方案 AOP允许我们把我们的方案更为紧密地映射到问题空间

lishixinzhi/Article/program/Java/ky/201311/28045

不同的程序不同的测试工具

程序大都开发完成后 生成编译一般都提示第几行编写的程序错误。解决后再看做出来的效果。如果有bug问题，在进行源代码的修改，反复进行直到满意为止。当然还有其他环境下提供的测试及自己累积的经验进行测试。

黑盒测试

黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否

都能正常使用，在测试时，把程序看作一个不能打开的黑盆子，在完全不考虑程序内部结构和内部特性的

情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序

是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。“黑盒”

法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输

入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测

试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。

白盒测试

白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是

否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按

预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证

。 “白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在

使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的

独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序

违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错

。第三，穷举路径测试可能发现不了一些与数据相关的错误。

还有一个灰盒测试

灰盒测试

灰盒测试，确实是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内

部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运

行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来 ***

作，效率会很低，因此需要采取这样的一种灰盒的方法。 灰盒测试结合了白盒测试盒黑盒测试的要素它

考虑了用户端、特定的系统知识和 *** 作环境。它在系统组件的协同性环境中评价应用软件的设计。灰盒测

试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试

以增强测试效率、错误发现和错误分析的效率。 灰盒测试涉及输入和输出，但使用关于代码和程序 *** 作

等通常在测试人员视野之外的信息设计测试。

本文介绍如何开发和测试 Windows CE 50 设备驱动程序。本文循序渐进地介绍如何创建流驱动程序，如何创建自定义 Windows CE Test Kit

(CETK) 测试，以及如何编写应用程序来测试驱动程序。这要花费大约 60 分钟来完成。

本页内容

第一部分：建立设备驱动程序

第二部分：测试流驱动程序测试代码

第三部分：检验驱动程序

第四部分：使用

Windows CE Test Kit

第五部分：创建自定义

CETK 测试

第六部分：确定谁拥有流驱动程序

小结

第一部分：建立设备驱动程序

在本练习中，您将使用 Platform Builder 来添加作为设备驱动程序的项目。

在 开始编写驱动程序之前，您应该了解设备驱动程序的用途。驱动程序将基础硬件从 *** 作系统中抽象出来，使之更好地面对应用程序开发人员。应用程序开发人员无需

知道显示硬件或串行硬件的详细信息 — 例如，串行设备是用 Universal Asynchronous Receiver/Transmitter (UART)

实现的还是用 field-programmable gate array (FPGA)

实现的。在大多数情况下，应用程序开发人员根本不需要知道硬件是如何实现的。

Microsoft Windows 为开发人员公开了调用硬件的应用程序编程接口

(API)，他们不需要知道物理硬件的情况。例如，为了向串行端口写入数据，应用程序开发人员只需调用 COMx 上的 CreateFile( )（其中 x

表示您要打开的串行端口编号，例如 COM1 代表串行端口 1），再调用 WriteFile( ) 以将一些字节数据写入串行端口，然后调用

CloseHandle( ) 以关闭串行端口。不管基础串行硬件是什么（也不管您运行的是哪个 Windows *** 作系统），API 都会以同样的顺序执行。

相同的情况也适用于其他 API：如果您希望在显示表面画一条线，那么您只需调用 PolyLine( )、MoveToEx( ) 或 LineTo(

)。作为应用程序开发人员，大多数情况下您都不需要知道显示硬件的情况。此处调用的 API 将返回显示表面的维数、颜色深度等等。

好 消息是开发人员可以调用一个一致的、众所周知的 API 集。这些 API

将他们的应用程序从基础硬件中抽象出来。这至关重要，因为应用程序开发人员无法知道应用程序是运行在便携式计算机上，还是运行在 Tablet PC

上，抑或运行在桌面计算机上。无论电脑以 1024×768 还是 1600×1200

的分辨率运行，应用程序开发人员都可以在运行时查询屏幕分辨率和颜色深度，因此不需要构建只在特定硬件上运行的应用程序。

驱动程序只是一 个动态链接库(DLL)。将 DLL 加载到父进程地址空间；然后父进程就可以调用从该 DLL 公开的任何接口。通常，父进程通过调用

LoadLibrary( ) 或 LoadDriver( ) 来加载驱动程序。LoadDriver 不仅将 DLL 加载到父进程地址空间中，而且还要确保 DLL

没有“paged out”。

调用进程如何知道从您的 DLL 或驱动程序公开了哪些 API 或函数呢？父进程调用 GetProcAddress( )，后者可以获取函数名称和所加载的

DLL 的 hInstance。如果函数存在，调用返回该函数指针；如果没有从 DLL 公开该函数，则返回 NULL。

流驱动程序也公开了一个众所周知的函数集。对于流驱动程序，您会希望能够将字节流写入设备中，或者从设备中读取字节流。因此，在前面使用的串行端口示例中，您可能希望从您的驱动程序公开如下函数集：Open、Close、Read

和

Write。流驱动程序还公开一些其他函数：PowerUp、PowerDown、IOControl、Init

和 DeInit。

您可以将现有的 *** 作系统映像用于模拟器平台（Basic Lab MyPlatform 平台最理想）。然后，您就可以将

DLL/驱动程序项目添加到该平台了。

在构建并下载了该平台之后（这表明 *** 作系统启动并运行良好），您需要创建您的主干驱动程序。您可以使用 File 菜单上的 Platform

Builder New Project or File 命令创建一个 Microsoft Windows CE DLL。创建用于公开函数或资源的

DLL 与创建用作驱动程序的 DLL 之间没有什么不同；唯一的不同之处在于 DLL 公开哪些函数，以及如何在平台上注册或使用 DLL。

此 外，一种创建国际化应用程序的方法是，首先创建包含一组核心语言字符串、对话框和资源的基本应用程序，然后创建许多外部

DLL，其中每个都包含针对特定区域设置的对话框、字符串和资源。然后，应用程序就可以在运行时加载相应的语言资源。只需要添加 DLL

文件，您就可以将语言添加到应用程序中。在 Developing International

Software 一书中描述了与此相关的主题以及其他一些有趣的主题，可以在 Microsoft Press 网站上获得此书。

添加一个作为设备驱动程序的项目

用 Platform Builder 打开现有的 MyPlatform 工作区。

在 File 菜单上，单击 New Project or File。

选择 WCE Dynamic-Link Library，给它一个合适的名称（例如，StreamDrv），然后单击

OK，如下图所示。

在下图所显示的页面中多少填写一些您需要的信息，然后单击 Next。

单击 A simple Windows CE DLL project，如下图所示。

单击 Finish 完成此向导。

此时，DLL 只包含一个空的 DllMain

函数。您可以公开一些应用程序要调用的函数，并公开一些资源（可能使之成为识别语言/文化的应用程序的一部分），或者使之成为一个设备驱动程序。在本文中，您将使用

Windows CE Stream Driver Wizard 创建您的主干流驱动程序。

在 Windows CE 中，打开流驱动程序就像打开文件一样，只需根据唯一的三字母前缀（例如，COM）。

为您的驱动程序选择一个唯一的三字母标识符。在 Location

框中输入您之前创建的流驱动程序的完整路径。或者使用“browse”按钮定位到 Platform Builder 安装中的 PBWorkspaces

目录，找到您前面创建的平台，然后找到流驱动程序的名称（在前面的示例中，此路径为 PBWorkspaces\TuxPlat\StreamDrv）。

在 Driver Filename 框中输入驱动程序的名称。如下图所示，使用与您前面使用名称 (StreamDrv)

相同的名称，以确保改写在 Platform Builder 中创建的原始文件。

按 Go，将生成流驱动程序源代码。

返回页首

第二部分：测试流驱动程序测试代码

现在您已经编写了用于 Windows CE 的自定义流驱动程序的基本代码。此时，驱动程序还没有与任何硬件连接。

在 编写完驱动程序之后，您需要为开发人员提供一种测试它的方法。Windows CE 附带了 Windows CE Test Kit

(CETK)，它提供了用于各种驱动程序类型的驱动程序测试，包含网络连接、蓝牙、串行端口以及显示。您编写的驱动程序是一种自定义的流驱动程序，它没有

公开与现有的驱动程序测试一样的功能，因此您需要为该驱动程序编写一个自定义测试。虽然您完全可以编写一个应用程序来演练驱动程序，但提供一个 CETK

模块或许更好些，在开发期间可以使用此模块，并且还可以将此模块提供给客户，供他们在装配硬件上测试驱动程序。

在这一部分的练习中，您将执行以下过程：

创建主干 Tux 模块

将自定义驱动程序的测试代码添加到 Tux DLL 中

重新构建 *** 作系统

设置断点

创建主干 Tux 模块

在 Platform Builder 中，在 File 菜单上单击 New Project or File。

选择 WCE TUX Dynamic-Link Library，键入 TuxTest 作为项目名称，输入一个位置，单击

Workspace Project，然后单击 OK，如下图所示。（实际上，您可以选择任意一个项目类型；对于本文，单击

Workspace Project）。

在下图显示的页面中多少填写一些您需要的信息，然后单击 Next。

阅读下图所显示的屏幕上的信息，然后单击 Next。

在最后一页上，您可以选择选取 Release Type 下的

CETK，如下图所示。该选项关闭了某些二进制的优化，以提高调试工作效率。单击 Finish。

单击 View | File View，然后展开 Projects 树显示 tux

源代码，如下图所示。

前图中需要注意的重要文件是：

fth — 该文件包含 tux DLL 所用的函数表。

testcpp — 该文件包含从该函数表中调用的测试过程。

TuxStreamTestcpp — 该文件包含 DLLMain 和 ShellProc，后者是从 Tuxexe

调用的。

将自定义驱动程序测试代码添加到 Tux DLL 中

打开源代码 Testcpp。

使用 CodeClip 来获得 Tux_Custom_Test | TuxCode 源代码。

用 CodeClip 中的代码替代函数 TestProc 中的内容。

您会注意到，Testcpp 中的代码加载了一个名为 Demodll 的驱动程序。对于本文，您创建了一个名为 StreamDrv

的驱动程序。您需要修改源代码以加载您的 StreamDrvdll 驱动程序。

找到 Testcpp 中调用 LoadLibrary 的源代码的位置，然后将要从 Demodll

中加载的驱动程序的名称修改为 StreamDrvdll。

在 Platform Builder 文件视图中，右键单击 TuxTest 项目，然后单击 Build Current

Project。

您还需要从该目录中添加 Windows CE Test Kit 组件。

在 Device Drivers 下，找到该目录中 Windows CE Test Kit 组件的位置，然后选择

Add the Windows CE Test Kit，将该组件添加到您的平台中。

注 将该组件添加到您的平台上并没有将任何文件添加到最后的 *** 作系统映像中；它将 Clientside 文件添加到 build release

文件夹中。您可以从 Platform Builder 下载 Clientside 应用程序，并在目标设备上运行该应用程序。

现在您需要重新构建您的 *** 作系统，以便合并这些变更。

重新构建 *** 作系统

在 Platform Builder 中，选择 Build OS | Sysgen。

构建过程将会花大约 5 分钟完成。

当加载驱动程序时，在流驱动程序的入口点设置一个断点来观察非常有用。

设置断点

单击 File View，打开 StreamDrv 项目，然后打开 Source files。

找到并打开 StreamDrvcpp。

找到 DllMain，然后找到并单击 switch 语句。

按 F9 设置断点。

单击 Target | Attach，将 *** 作系统下载到模拟环境中。

您会看到以下调试输出，断点将启用。注意，在加载 *** 作系统的用户接口 (UI) 之前，这早就发生了。

4294780036 PID:23f767b6 TID:23f767e6 0x83fa6800: >>> Loading module

streamdrvdll at address 0x01ED0000-0x01ED5000

Loaded symbols for

'C:\WINCE500\PBWORKSPACES\DRVDEMO\RELDIR\EMULATOR_X86_DEBUG\STREAMDRVDLL'

单击 switch 语句，然后按 F9 禁用断点。

按 F5，允许 *** 作系统继续加载。

现在，您已经构建了一个 Windows CE 50

*** 作系统，它包含一个自定义流驱动程序，并且您已经在 *** 作系统引导顺序的过程中看到了驱动程序加载。

返回页首

第三部分：检验驱动程序

在这一部分的练习中，您将执行以下过程：

使用命令行工具查看从驱动程序公开的函数

使用远程系统信息 (Remote System Information) 工具检验驱动程序

确定驱动程序已加载

检验您所创建的设备驱动程序的第一种方法是查看从该驱动程序公开的函数。Windows CE 附带了一个名为 Dumpbin

的命令行工具，可以用于检验导入应用程序或模块的内容，或者从 DLL（或驱动程序）导出的内容。

使用命令行工具查看从驱动程序公开的函数

在 Platform Builder 中，单击 Build OS | Open Release

Directory。该 *** 作为当前的工作区打开 build release 文件夹中的 Command Prompt 窗口。

键入 dumpbin exports StreamDrvdll

下图显示输出。您可以看到，所有需要的流驱动程序函数都是从驱动程序公开的；函数是从 DLL 公开的（通过该项目的 def 文件）。

键入 Exit 关闭 Command Prompt 窗口

StreamDrvdef 文件的内容如下所示。

LIBRARY DemoDriver

EXPORTS

DEM_Init

DEM_Deinit

DEM_Open

DEM_Close

DEM_IOControl

DEM_PowerUp

DEM_PowerDown

DEM_Read

DEM_Write

DEM_Seek

CustomFunction

CustomFunctionEx

您可以检验驱动程序的第二种方法是通过远程系统信息工具。

通过远程系统信息工具检验驱动程序

在 Platform Builder 中，单击 Tools | Remote System

Information。

选择 Windows CE Default Platform | Default Device，然后单击

OK，如下图所示。

此过程将远程系统信息应用程序连接到 Platform Builder 正在使用的当前活动平台上。下图显示了结果。

您也可以使用加载模块列表来确定已加载了您的驱动程序。

确定驱动程序已加载

在 Platform Builder 中，使用 Target Control 窗口 (gi mod) 或 View |

Debug Windows | Modules and Symbols。

下图显示了此过程的结果。

返回页首

第四部分：使用 Windows CE Test Kit

Windows CE Test Kit 包含设备端组件和桌面组件。设备端组件叫做 Clientsideexe，通过从目录中添加 CETK

组件，您可以将设备端组件添加到您的工作区中。注意，将 Clientsideexe

应用程序添加到工作区中并没有将任何文件添加到最终 *** 作系统映像中，但它却将应用程序复制到 build release 文件夹中。

在桌面计算机上运行 CETK 之前，您需要启动设备上的 Clientsideexe 应用程序。没有链接工具（比如远程工具）的原因在于，CETK

也将运行在装配（零售）设备（比如 Pocket PC）上。

在这一部分的练习中，您将执行以下过程：

检验 Windows CE Test Kit 用户接口

运行一个标准测试

检验 Windows CE Test Kit 用户接口

在 Platform Builder 中，在 Tools 菜单上单击 Windows CE Test

Kit。

这 一步启动 Windows CE Test Kit 应用程序，如下图所示。注意，这不是一个标准的远程工具。Windows CE

附带的大多数远程工具都使用 Kernel Independent Transport Layer

(KITL)，一种将工具从基础通信硬件中抽象出来的传输，以便这些工具可以运行在以太网、串行端口、1394、USB 或者其他传输上。

虽然对于 Windows CE 50，Windows CE Test Kit 通常通过套接字连接，但是也已经更新了工具来支持 KITL。

在 Windows CE Test Kit 中，单击 Connection | Start

Client。

这一步显示 Device Connection 对话框，其中您可以选择是通过套接字连接还是通过 KITL 连接。

确保清除了 Use Windows Sockets for the client/server communication

复选框，如下图所示。

单击 Connect。

在远程工具 (KITL) 的标准用户界面中，选择 Windows CE Default Platform | Default

Device，然后单击 OK，如下图所示。

该过程在目标设备上启动 Clientsideexe，并连接到目标设备上。在完成连接之后，CETK 枚举目标平台上支持的设备，并禁用 CETK

中不支持的设备。

在 CETK 连接到目标设备并枚举设备之后，UI 如下图所示。注意，禁用了某些硬件类别，比如 Bluetooth、IR

Port 和 Modem。

将自定义测试添加到 CETK 中之前，您可以运行一个标准测试，以查看测试工作如何进行。

运行标准测试

在 CETK 中，展开 Windows CE (x86)。

找到并展开 Serial Port。

右键单击 Serial Port Driver Test，然后单击 Quick Start。

这一步只运行了这一个测试，还没有运行所选的其他测试。UI 指示测试正在进行，如下图所示。

CETK 提供测试过程和测试输出的更新。您也可以在 Platform Builder 中检验调试输出，以便查看测试过程，如下例所示。

405910 PID:83d4ee4a TID:83ea5a8a Test Name: Set event mask and wait for

thread to close comm port handle

405920 PID:83d4ee4a TID:83ea5a8a Test ID: 1007

405920 PID:83d4ee4a TID:83ea5a8a Library Path: \serdrvbvtdll

405920 PID:83d4ee4a TID:83ea5a8a Command Line:

405920 PID:83d4ee4a TID:83ea5a8a Result: Passed

405920 PID:83d4ee4a TID:83ea5a8a Random Seed: 15595

405930 PID:83d4ee4a TID:83ea5a8a Thread Count: 1

405930 PID:83d4ee4a TID:83ea5a8a Execution Time: 0:00:05110

405930 PID:83d4ee4a TID:83ea5a8a

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

如果 CETK UI

指示模拟器上的串行端口测试已经失败（如下图所示），那么失败可能不是由于每个测试的完全失败而导致的。它可能表明，全部测试套件只有一部分已经失败，并且这部分实际上也是期望的行为。

右键单击 Serial Port Driver Test [Failed]，然后单击 View

Results。

出现如下图所示的窗口。

查看上图所示的结果，您可以看到，已经运行了 10 个单独的测试。除了 Set and verify receive timeout

以外，所有这些测试都已经通过。

要获得更多信息，您可以单击个别测试。

返回页首

第五部分：创建自定义 CETK 测试

通过使用 Platform Builder User-Defined Test Wizard，您可以创建一个自定义 CETK

测试。该测试将验证自定义流驱动程序（您也已经将其添加到平台中）的导出函数。

在这一部分的练习中，您将执行以下过程：

列出 CETK 中的自定义流驱动程序测试

运行自定义流驱动程序测试

列出 CETK 中的自定义流驱动程序测试

在 CETK 中，单击 Tests | User Defined。

这一步启动 User-Defined Test Wizard。该向导的第一页只是一些信息。

单击 Next，如下图所示。

单击 Add a New Test，然后单击 Next，如下图所示。

输入下列信息，然后单击 Next：

· 在 Name of Test 框中键入 Custom Stream Driver Test

· 在 Tux Module (DLL) 框中，定位到

C:\Wince500\PBWorkspaces\MyPlatform\RelDir\Emulator_x86_Debug 目录，然后选择

testdll 或 TuxTestdll（这依赖于您在 Platform Builder 中所使用的 Tux

测试的名称）。

· 在 Command Line 框中，保留当前测试的默认设置。

· 在 Processor 框中键入 x86

下图显示信息如何出现在当前的向导页中。

单击 Copy the files to the directory for user-defined tests，然后单击

Next，如下图所示。

您需要将自定义驱动程序测试（您的 DLL）复制到用户定义的测试文件夹中。如果您要删除现有的工作区，那么自定义驱动程序测试仍然保持完好。

单击 Next，如下图所示。

单击 Finish，如下图所示。

CETK 应用程序不会用新的测试进行自动刷新。您需要重新同步桌面应用程序，以查看新添加的测试。

右键单击 Windows CE (x86)，然后单击 Redetect Peripherals。

该过程添加了一个名为 User Tests 的新驱动程序类别。您只添加了一个测试，因此，当您展开这个项目时，您只能看到 Custom

Stream Driver Test。

注 已经将自定义流驱动程序测试的 DLL 复制到下列位置： C:\Program Files\Windows CE Platform

Builder\500\CEPB\wcetk\user\x86

运行自定义流驱动程序测试

在可用的测试列表中展开 User Tests。

右键单击 Custom Stream Driver Test，然后单击 Quick Start。

小米工程模式第一部分：

##4636##

显示手机信息、电池信息、电池记录、使用统计数据、WiFi信息

##7780##

重设为原厂设定，不会删除预设程序，及SD卡档案。

27673855#

重设为原厂设定，会删除SD卡所有档案。

##34971539##

显示相机相机韧体版本，或更新相机韧体

##7594##6

当长按关机按钮时，会出现一个切换手机模式的窗口，包括:静音模式、飞航模式及关机，你可以用以上代码，直接变成关机按钮。

小米工程模式第二部分：

##273283255663282##

开启一个能让你备份媒体文件的地方，例如相片、声音及影片等

##197328640##启动服务模式，可以测试手机部分设置及更改设定WLAN、GPS及蓝牙测试的代码

##232339##或##526##或##528##–WLAN测试

##232338##–显示WiFiMAC地址

##1472365##–GPS测试

##1575##–其它GPS测试

##232331##–蓝牙测试

##232337##–显示蓝牙装置地址

小米工程模式第三部分：

##8255##启动GTalk服务监视器显示手机软件版本的代码

##49862650468##–PDA、Phone、H/W、RFCallDate

##1234##–PDA及Phone

##1111##–FTASW版本

##2222##–FTAHW版本

##44336##–PDA、Phone、csc、buildTime、anzhiname、changelistnumber各项硬件测试

##0283##–PacketLoopback

小米工程模式第四部分：

##0##–LCD测试

##0673##或##0289##–Melody测试

##0842##–装置测试，例如振动、亮度

##2663##–触控屏幕版本

##2664##–触控屏幕测试

##0588##–接近感应器测试

##3264##–内存版本

##284##生成log文件。

以上就是关于进行Struts应用程序单元测试开发全部的内容，包括:进行Struts应用程序单元测试开发、怎么测试自己编的程序、如何在 Windows CE 5.0 中开发和测试设备驱动程序等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！