Microsoft 模式与实践 Composite UI Application Block：Shell 应用程序启动时间和内存使用验证测试

验证测试说明

本文介绍了使用 NUnit 对基于 Microsoft patterns & practices 复合 UI 应用程序块 (CAB) 的 shell 应用程序进行启动时间和内存使用验证测试。本地启动目录仅使用原生的 CAB 基于反射的模块加载服务。使用了一个测试模块作为测试对象，该模块实现了以下内容：

• MyTestModuleInit：最小实现
• MyTestWorkItem：包含三个事件订阅（订阅以下发布）
• MyTestPresenter：包含三个事件发布和相应的公共调用器；三个命令，每个命令调用其中一个事件发布；六个 UI 扩展站点，其中三对调用其中一个命令（每对由一个带图标的菜单项和一个带图标的工具栏项组成）
• MyTestView：最小实现

可以公平地说，上面描述的测试模块的扩展量低于平均水平到平均水平，并且初始化量极其有限（即，工作项中不包含任何功能服务，例如 Web 服务、数据库连接或其他持久化，也没有具有丰富 UI 初始化的表示服务等）。尽管如此，根据下面提供的配置，仍建立了基线 shell 应用程序的启动时间和内存使用情况。在 shell 应用程序上执行了一个启动时间测试方法，每次启动时加载的测试模块数量从 0、1、2、3…48（任意最大值）递增；该测试方法确保 shell 应用程序启动时间小于或等于 15 秒，容差为 0.5 秒，结果分辨率为 0.125 秒。

验证测试配置

操作系统 

• Microsoft Windows XP Professional 版本 (2002) 5.1.2600 Service Pack 2 Build 2600
• Microsoft Internet Explorer 6.0.2900.2180 Service Pack 2

处理器/内存

• 移动英特尔奔腾 4 @ 3.20 GHz，1.00 GB 内存

测试程序集/工件大小列表（调试编译）

程序集/工件	字节
MyTestModule[01-48].dll	24,576
菜单栏/工具栏图标	1,908
扩展配置文件	4,105
每个测试程序集总计	28,999

 

       

 

基本 Shell 应用程序程序集大小列表（调试编译）

程序集	字节
ConverterBase.dll（内部对象构建器）	69,632
ConverterRegistry.dll（内部对象构建器）	53,248
Microsoft.Practices.CompositeUI.dll	196,608
Microsoft.Practices.CompositeUI.Winforms.dll	69,632
Microsoft.Practices.ObjectBuilder.dll	61,440
XtensibleSolutions.CompositeUI.Extensions.dll （内部 CAB 扩展）	45,056
XtensibleSolutions.EventViewerModule.dll （内部事件查看器模块）	36,864
XtensibleSolutions.Shell.exe （内部 shell 应用程序）	28,672
总计	561,152

 

 

 

 

 

 

 

 

支持软件版本列表：  

• 复合 UI 应用程序块 (CAB) 1.0.51205.0
• Microsoft .NET Framework 2.0.50727.42
• Microsoft Visual Studio 2005 Professional Edition 8.0.50727.42

• NUnit 2.2.5

启动时间验证测试结果

shell 应用程序启动时间表现出以下行为，如下表所示： 

• 最小启动时间：3.614 秒（启动时加载了 2 个测试模块）
• 最大启动时间：10.545 秒（启动时加载了 48 个测试模块）
• 最大启动时间增量：1.173 秒（从 14-15 个和 23-24 个模块启动时加载）
• 平均启动时间增量：0.13975 秒

 

 

 

 

 

 

 

 

 

内存使用验证测试结果

shell 应用程序内存使用（即占用空间）表现出以下行为，如下表所示

• 最小占用空间：25,820 KB（基线；启动时未加载测试模块）
• 最大占用空间：32,884 KB（启动时加载了 45 个测试模块）
• 最大占用空间增量：1,700 KB（从 14-15 个和 19-20 个模块启动时加载）
• 平均占用空间增量：134.75 KB

 

 

 

 

 

 

 

 

验证测试结果分析

总的来说，观察到的结果并不意外，因为使用初始化量极小的测试模块时，shell 应用程序的启动时间（和内存使用量）缓慢但稳定地增加；此外，由于测试是一个真正的验证型环境，每个测试都进行完整的系统执行（即，测试是在系统本身上执行的，而不是在校准的模块加载器/扩展/等服务上执行），因此启动时间频繁减少（尽管幅度很小）。鉴于测试模块仅进行最小程度的更新以避免模块加载服务错误检查（即，程序集和程序集模块属性名称保持唯一），程序集命名空间、类、事件扩展、命令扩展等都命名相同，这可能会略微降低绝对初始化时间（以及内存使用量），但不会相对降低，因为这些特性在整个测试中保持不变。框架对 shell 应用程序/NUnit 程序集进行缓存也可能导致加载效率提高（理论上，这在标准测试过程中不是一个因素……正常执行 shell 以确保预期的模块数量并收集内存使用量，关闭 shell，启动 NUnit 并加载/执行单元测试程序集，保存启动时间结果并关闭 NUnit）。

最后，鉴于以上所有情况，导致 shell 应用程序启动时间超过 15 秒（无容差）的估计模块数量大约为 52 个（使用最大启动时间增量）到 80 个（使用平均启动时间增量；忽略负值和零最小值启动时间增量）。

启动时间验证测试间接观察

由于上述最小的测试模块更新以及测试模块本身的实现，单个命令调用导致事件在每个加载的模块之间广播/接收（也就是说，任何一个命令调用广播/接收的事件数量相当于加载的模块数量 N 的平方，或者……1 个模块加载时 1 个事件，2 个模块加载时 4 个事件，3 个模块加载时 9 个事件，最多 48 个模块加载时 2304 个事件）。有用的观点是，事件广播/接收性能在 48 个模块（或 2304 个同时事件）的最大 3-4 秒（视觉事件查看器显示）下似乎是可接受的；其中大部分是事件查看器根据其当前实现进行的重新生成，而不是即时的事件广播/接收本身。

结论

最重要的是，从测试驱动开发的角度来看，启动时间验证测试结果将基线配置的启动时间测试用例预期从任意（且相当长）的 15 秒重新调整为随着附加模块开发向前推进更具确定性的 5 秒预期（粗略计算为 3.614 秒的最小启动时间加上 1.173 秒的最大启动时间增量作为容差）。同样，在利用启动时间验证测试结果彻底评估系统行为时，已从基线配置中移除了内部对象构建器（有效地替换为本机 .NET 功能），从而在加载模块数量较少时将启动时间减少约 0.5 秒，在加载模块数量较多时减少多达 1.5 秒。同样具有广泛重要性的是，验证测试结果确保在测试覆盖范围中，复合 UI 应用程序块 (CAB) 以及提供智能客户端架构基线配置的内部扩展不会出现不可接受或令人惊讶的启动时间。最后，鉴于特定测试配置，验证测试结果提供了“事实而非其他”的信息，说明了当 CAB 基 shell 应用程序加载更多模块时可能预期的近似启动时间增量。