1.初识Visual Leak Detector

       灵活自由是C/C++语言的一大特色，而这也为C/C++程序员出了一个难题。当程序越来越复杂时，内存的管理也会变得越加复杂，稍有不慎就会出现内存问题。内存泄漏是最常见的内存问题之一。内存泄漏如果不是很严重，在短时间内对程序不会有太大的影响，这也使得内存泄漏问题有很强的隐蔽性，不容易被发现。然而不管内存泄漏多么轻微，当程序长时间运行时，其破坏力是惊人的，从性能下降到内存耗尽，甚至会影响到其他程序的正常运行。另外内存问题的一个共同特点是，内存问题本身并不会有很明显的现象，当有异常现象出现时已时过境迁，其现场已非出现问题时的现场了，这给调试内存问题带来了很大的难度。

       Visual Leak Detector是一款用于Visual C++的免费的内存泄露检测工具。可以在http://www.codeproject.com/tools/visualleakdetector.asp 下载到。相比较其它的内存泄露检测工具，它在检测到内存泄漏的同时，还具有如下特点：

1、  可以得到内存泄漏点的调用堆栈，如果可以的话，还可以得到其所在文件及行号；

2、  可以得到泄露内存的完整数据；

3、  可以设置内存泄露报告的级别；

4、  它是一个已经打包的lib，使用时无须编译它的源代码。而对于使用者自己的代码，也只需要做很小的改动；

5、  他的源代码使用GNU许可发布，并有详尽的文档及注释。对于想深入了解堆内存管理的读者，是一个不错的选择。

       可见，从使用角度来讲，Visual Leak Detector简单易用，对于使用者自己的代码，唯一的修改是#include Visual Leak Detector的头文件后正常运行自己的程序，就可以发现内存问题。从研究的角度来讲，如果深入Visual Leak Detector源代码，可以学习到堆内存分配与释放的原理、内存泄漏检测的原理及内存操作的常用技巧等。

       本文首先将介绍Visual Leak Detector的使用方法与步骤，然后再和读者一起初步的研究Visual Leak Detector的源代码，去了解Visual Leak Detector的工作原理。

2.使用Visual Leak Detector(1.0)

       下面让我们来介绍如何使用这个小巧的工具。

       首先从网站上下载zip包，解压之后得到vld.h, vldapi.h, vld.lib, vldmt.lib, vldmtdll.lib, dbghelp.dll等文件。将.h文件拷贝到Visual C++的默认include目录下，将.lib文件拷贝到Visual C++的默认lib目录下，便安装完成了。因为版本问题，如果使用windows 2000或者以前的版本，需要将dbghelp.dll拷贝到你的程序的运行目录下，或其他可以引用到的目录。

       接下来需要将其加入到自己的代码中。方法很简单，只要在包含入口函数的.cpp文件中包含vld.h就可以。如果这个cpp文件包含了stdafx.h，则将包含vld.h的语句放在stdafx.h的包含语句之后，否则放在最前面。如下是一个示例程序：

#include <vld.h>

void main()

{

…

}

       接下来让我们来演示如何使用Visual Leak Detector检测内存泄漏。下面是一个简单的程序，用new分配了一个int大小的堆内存，并没有释放。其申请的内存地址用printf输出到屏幕上。

#include <vld.h>

#include <stdlib.h>

#include <stdio.h>

void f()

{

    int *p = new int(0x12345678);

    printf("p=%08x, ", p);

}

void main()

{

    f();

}

编译运行后，在标准输出窗口得到：

p=003a89c0

在Visual C++的Output窗口得到：

WARNING: Visual Leak Detector detected memory leaks!

---------- Block 57 at 0x003A89C0: 4 bytes ----------  --57号块0x003A89C0地址泄漏了4个字节

  Call Stack:                                               --下面是调用堆栈

    d:\test\testvldconsole\testvldconsole\main.cpp (7): f  --表示在main.cpp第7行的f()函数

    d:\test\testvldconsole\testvldconsole\main.cpp (14): main –双击以引导至对应代码处

    f:\rtm\vctools\crt_bld\self_x86\crt\src\crtexe.c (586): __tmainCRTStartup

    f:\rtm\vctools\crt_bld\self_x86\crt\src\crtexe.c (403): mainCRTStartup

    0x7C816D4F (File and line number not available): RegisterWaitForInputIdle

  Data:                                   --这是泄漏内存的内容，0x12345678

    78 56 34 12                                                  xV4..... ........

Visual Leak Detector detected 1 memory leak.   

第二行表示57号块有4字节的内存泄漏，地址为0x003A89C0，根据程序控制台的输出，可以知道，该地址为指针p。程序的第7行，f()函数里，在该地址处分配了4字节的堆内存空间，并赋值为0x12345678，这样在报告中，我们看到了这4字节同样的内容。

可以看出，对于每一个内存泄漏，这个报告列出了它的泄漏点、长度、分配该内存时的调用堆栈、和泄露内存的内容（分别以16进制和文本格式列出）。双击该堆栈报告的某一行，会自动在代码编辑器中跳到其所指文件的对应行。这些信息对于我们查找内存泄露将有很大的帮助。

这是一个很方便易用的工具，安装后每次使用时，仅仅需要将它头文件包含进来重新build就可以。而且，该工具仅在build Debug版的时候会连接到你的程序中，如果build Release版，该工具不会对你的程序产生任何性能等方面影响。所以尽可以将其头文件一直包含在你的源代码中。

3.Visual Leak Detector工作原理

       下面让我们来看一下该工具的工作原理。

       在这之前，我们先来看一下Visual C++内置的内存泄漏检测工具是如何工作的。Visual C++内置的工具CRT Debug Heap工作原来很简单。在使用Debug版的malloc分配内存时，malloc会在内存块的头中记录分配该内存的文件名及行号。当程序退出时CRT会在main()函数返回之后做一些清理工作，这个时候来检查调试堆内存，如果仍然有内存没有被释放，则一定是存在内存泄漏。从这些没有被释放的内存块的头中，就可以获得文件名及行号。

       这种静态的方法可以检测出内存泄漏及其泄漏点的文件名和行号，但是并不知道泄漏究竟是如何发生的，并不知道该内存分配语句是如何被执行到的。要想了解这些，就必须要对程序的内存分配过程进行动态跟踪。Visual Leak Detector就是这样做的。它在每次内存分配时将其上下文记录下来，当程序退出时，对于检测到的内存泄漏，查找其记录下来的上下文信息，并将其转换成报告输出。

3.1初始化

       Visual Leak Detector要记录每一次的内存分配，而它是如何监视内存分配的呢？Windows提供了分配钩子(allocation hooks)来监视调试堆内存的分配。它是一个用户定义的回调函数，在每次从调试堆分配内存之前被调用。在初始化时，Visual Leak Detector使用_CrtSetAllocHook注册这个钩子函数，这样就可以监视从此之后所有的堆内存分配了。

       如何保证在Visual Leak Detector初始化之前没有堆内存分配呢？全局变量是在程序启动时就初始化的，如果将Visual Leak Detector作为一个全局变量，就可以随程序一起启动。但是C/C++并没有约定全局变量之间的初始化顺序，如果其它全局变量的构造函数中有堆内存分配，则可能无法检测到。Visual Leak Detector使用了C/C++提供的#pragma init_seg来在某种程度上减少其它全局变量在其之前初始化的概率。根据#pragma init_seg的定义，全局变量的初始化分三个阶段：首先是compiler段，一般c语言的运行时库在这个时候初始化；然后是lib段，一般用于第三方的类库的初始化等；最后是user段，大部分的初始化都在这个阶段进行。Visual Leak Detector将其初始化设置在compiler段，从而使得它在绝大多数全局变量和几乎所有的用户定义的全局变量之前初始化。

4.记录内存分配

       一个分配钩子函数需要具有如下的形式：

int YourAllocHook( int allocType, void *userData, size_t size, int blockType, long requestNumber, const unsigned char *filename, int lineNumber);

       就像前面说的，它在Visual Leak Detector初始化时被注册，每次从调试堆分配内存之前被调用。这个函数需要处理的事情是记录下此时的调用堆栈和此次堆内存分配的唯一标识——requestNumber。

       得到当前的堆栈的二进制表示并不是一件很复杂的事情，但是因为不同体系结构、不同编译器、不同的函数调用约定所产生的堆栈内容略有不同，要解释堆栈并得到整个函数调用过程略显复杂。不过windows提供一个StackWalk64函数，可以获得堆栈的内容。StackWalk64的声明如下：

BOOL StackWalk64(

  DWORD MachineType,

  HANDLE hProcess,

  HANDLE hThread,

  LPSTACKFRAME64 StackFrame,

  PVOID ContextRecord,

  PREAD_PROCESS_MEMORY_ROUTINE64 ReadMemoryRoutine,

  PFUNCTION_TABLE_ACCESS_ROUTINE64 FunctionTableAccessRoutine,

  PGET_MODULE_BASE_ROUTINE64 GetModuleBaseRoutine,

  PTRANSLATE_ADDRESS_ROUTINE64 TranslateAddress

);

STACKFRAME64结构表示了堆栈中的一个frame。给出初始的STACKFRAME64，反复调用该函数，便可以得到内存分配点的调用堆栈了。

    // Walk the stack.

    while (count < _VLD_maxtraceframes) {

        count++;

        if (!pStackWalk64(architecture, m_process, m_thread, &frame, &context,

                          NULL, pSymFunctionTableAccess64, pSymGetModuleBase64, NULL)) {

            // Couldn't trace back through any more frames.

            break;

        }

查看(2868) 评论(0) 收藏 分享 管理

界面风格与测试的必要规则

界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页制作的兴起，才受到专家的青睐。
 
目前流行的界面风格有三种基本方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。
 
1：易用性：
按钮名称应该易懂，用词准确，屏弃摸棱两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。
易用性细则：
1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。
2):完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。
3):按功能将界面划分局域块，用Frame框括起来,并要有功能说明或标题。
4):界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。
5):界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
6):同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。
7):分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab
8):默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。
9):可写控件检测到非法输入后应给出说明并能自动获得焦点。
10):Tab键的顺序与控件排列顺序要一致，目前流行总体从上到下，同时行间从左到右的方式。
11):复选框和选项框按选择几率的高底而先后排列。
12):复选框和选项框要有默认选项，并支持Tab选择。
13):选项数相同时多用选项框而不用下拉列表框。
14):界面空间较小时使用下拉框而不用选项框。
15):选项数较少时使用选项框，相反使用下拉列表框。
16):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。
 
2： 规范性：
通常界面设计都按Windows界面的规范来设计，即包含“菜单条、工具栏、工具厢、状态栏、滚动条、右键快捷菜单”的标准格式，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具箱。
 
规范性细则：
1):常用菜单要有命令快捷方式。
2):完成相同或相近功能的菜单用横线隔开放在同一位置。
3):菜单前的图标能直观的代表要完成的操作。
4):菜单深度一般要求最多控制在三层以内。
5):工具栏要求可以根据用户的要求自己选择定制。
6):相同或相近功能的工具栏放在一起。
7):工具栏中的每一个按钮要有及时提示信息。
8):一条工具栏的长度最长不能超出屏幕宽度。
9):工具栏的图标能直观的代表要完成的操作。
10):系统常用的工具栏设置默认放置位置。
11):工具栏太多时可以考虑使用工具箱。
12):工具箱要具有可增减性，由用户自己根据需求定制。
13):工具箱的默认总宽度不要超过屏幕宽度的1/5。
14):状态条要能显示用户切实需要的信息，常用的有：
 
目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，
 如果某一操作需要的时间较长，还应该显示进度条和进程提示。
15):滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。
16):状态条的高度以放置5号字为宜，滚动条的宽度比状态条的略窄。
17):菜单和工具栏要有清楚的界限;菜单要求凸出显示，这样在移走工具栏时仍有立体感。
18):菜单和状态条中通常使用5号字体。工具栏一般比菜单要宽，但不要宽的太多，否则看起来很不协调。
19):右键快捷菜单采用与菜单相同的准则。
 
3：帮助设施：
 
系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。
 
帮助设施细则：
1):帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明，让人困惑)。
2):打包新系统时，对作了修改的地方在帮助文档中要做相应的修改。
3):操作时要提供及时调用系统帮助的功能。常用F1。
4):在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
5):最好提供目前流行的联机帮助格式或HTML帮助格式。
6):用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。
7):如果没有提供书面的帮助文档的话，最好有打印帮助的功能。
8):在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。
 
4：合理性：
 
屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。
 
合理性细则：
1):父窗体或主窗体的中心位置应该在对角线焦点附近。
2):子窗体位置应该在主窗体的左上角或正中。
3):多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。
4):重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。(默认界面应该只显示目标用户最常使用的功能，至于不常用到的高级功能，可以“隐藏”起来，比如说，放到菜单里，不要都做成按钮摆到界面上。果真需要需要这些高级功能的话，用户自然会到菜单里去找的。 )
5):错误使用容易引起界面退出或关闭的按钮不应该放在易点位置。横排开头或最后与竖排最后为易点位置。
6):与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。
7):对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
8):非法的输入或操作应有足够的提示说明。
9):对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。
10):提示、警告、或错误说明应该清楚、明了、恰当。
 
5：美观与协调性：
界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。
美观与协调性细则：
1):长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。
2):布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。
3):按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
4):按钮的大小要与界面的大小和空间要协调。
5):避免空旷的界面上放置很大的按钮。
6):放置完控件后界面不应有很大的空缺位置。
7):字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。
8):前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。蓝色文字以白色背景容易识别，而在红色背景则不易分辨，原因是红色和蓝色没有足够反差，而蓝色和白色反差很大。除非特殊场合，杜绝使用对比强烈，让人产生憎恶感的颜色。常用色考虑使用Windows界面色调。
9):整个界面色彩尽量少的使用类别不同的颜色。统一色调，针对软件类型以及用户工作环境选择恰当色调:如：安全软件，根据工业标准，可以选取黄色，绿色体现环保，蓝色表现时尚、紫色表现浪漫等等，淡色可以使人舒适，暗色做背景使人不觉得累等
10):如果使用其他颜色，主色要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
11):大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
12):界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。
13):如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放。
14):对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。
15):通常父窗体支持缩放时，子窗体没有必要缩放。
16):如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。

6：菜单位置：
菜单是界面上最重要的元素，菜单位置按照按功能来组织。
菜单位置细则：
1):菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows风格。
2):常用的有“文件”、“编辑”，“查看”等，几乎每个系统都有这些选项，当然要根据不同的系统有所取舍。
3):下拉菜单要根据菜单选项的含义进行分组，并切按照一定的规则进行排列，用横线隔开。
4):一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。
5):没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头， 不常用的靠后放置；重要的放在开头，次要的放在后边。
6):如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。
7):菜单深度一般要求最多控制在三层以内。
8):对常用的菜单要有快捷命令方式，组合原则见8。
9):对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式——即只有需要的菜单才显示——最好。
10):菜单前的图标不宜太大，与字高保持一直最好。
11):主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。
12):主菜单数目不应太多，最好为单排布置。

7：独特性：
如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。
独特性细则：
1):安装界面上应有单位介绍或产品介绍，并有自己的图标。
2):主界面，最好是大多数界面上要有公司图标。
3):登录界面上要有本产品的标志，同时包含公司图标。
4):帮助菜单的“关于”中应有版权和产品信息。
5):公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。
 
8：快捷方式的组合
在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些。在西文Windows及其应用软件中快捷键的使用大多是一致的。
菜单中：
1):面向事务的组合有:
        Ctrl-D 删除
        Ctrl-F 寻找
        Ctrl-H 替换
        Ctrl-I 插入
        Ctrl-N 新建
        Ctrl-S 保存
        Ctrl-O 打开
2):列表:
        Ctrl-R   刷新
        Ctrl-G   定位
        Ctrl-Tab 下一分页窗口或反序浏览同一页面控件
3):编辑:
        Ctrl-A 全选
        Ctrl-C 拷贝
        Ctrl-V 粘贴
        Ctrl-X 剪切
        Ctrl-Z 撤消操作
        Ctrl-Y 恢复操作
4):文件操作:
        Ctrl-P 打印
        Ctrl-W 关闭
5):系统菜单
        Alt-A 文件
        Alt-E 编辑
        Alt-T 工具
        Alt-W 窗口
        Alt-H 帮助
6):MS Windows保留键:
        Ctrl-Esc 任务列表
        Ctrl-F4 关闭窗口
        Alt-F4 结束当前程序
        Alt-Tab 切换当前程序
        Enter 缺省按钮/确认操作
        Esc 取消按钮/取消操作
        Shift-F1 上下文相关帮助
按钮中：
可以根据系统需要而调节，以下只是常用的组合。
        Alt-Y 确定(是)
        Alt-C 取消
        Alt-N 否
        Alt-D 删除
        Alt-Q 退出
        Alt-A 添加
        Alt-E 编辑
        Alt-B 浏览
        Alt-R 读
        Alt-W 写
这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母（不推荐）。

9:安全性考虑：
在界面上通过下列方式来控制出错几率，会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。
如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。

安全性细则： 
1):最重要的是排除可能会使应用非正常中止的错误。
2):应当注意尽可能避免用户无意录入无效的数据。
3):采用相关控件限制用户输入值的种类。
4):当用户作出选择的可能性只有两个时,可以采用单选框。
5):当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
6):当选项特别多时，可以采用列表框，下拉式列表框。
7):在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。
8):对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。
9):对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
10):对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
11):对错误操作最好支持可逆性处理，如取消系列操作。
12):在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。
13):对可能造成等待时间较长的操作应该提供取消功能。
14):特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!,.。?/还有空格。（此外，还要注意全角和半角符号的区别）
15):与系统采用的保留字符冲突的要加以限制。
16):在读入用户所输入的信息时，根据需要选择是否去掉前后空格。
17):有些读入数据库的字段不支持中间有空格，但用户切实需要输入中间空格，这时要在程序中加以处理。

10:多窗口的应用与系统资源：
设计良好的软件不仅要有完备的功能，而且要尽可能的占用最底限度的资源。
应用细则：
1):在多窗口系统中，有些界面要求必须保持在最顶层，避免用户在打开多个窗口时，不停的切换甚至最小化其他窗口来显示该窗口。
2):显示多个窗口时，窗口的名称是否被适当地表示？
3):活动窗口是否被适当地加亮？
4):如果使用多任务，是否所有的窗口被实时更新？
5):在主界面载入完毕后自动卸出内存，让出所占用的WINDOWS系统资源。
6):关闭所有窗体，系统退出后要释放所占的所有系统资源 ，除非是需要后台运行的系统。
4):尽量防止对系统的独占使用。
美丽的事物常常会让人无法抗拒。这就是为什么产品出色的外观设计对于电脑、汽车、日用品、家具、食品、服装等等几乎所有商品的销售与推广，都有着举足轻重的作用的原因。
同样的道理，对于软件公司来说，软件产品就是他们的商品，而软件界面就是他们产品的外观，界面的美观与否，直接关系到了软件产品的营销成败。
 
我们可以清楚地看到，微软公司对软件界面设计的重视。请回想一下您在第一次见到win2000时的情景，与nt4.0相比是否惊叹他界面的美观性与易用性？而您如果使用过xp系统，则会被其令人神奇的感官概念而震惊折服！金山公司的金山词霸就是国内软件成功的例子了，从金山词霸3.0到金山词霸2001 的变化堪称经典。著名的网页动画制作软件flash从3.0到4.0，仅仅修改了图标和窗体，立即大为增色…

现今世界上成功的软件公司都非常重视软件界面的美化设计工作，因为他们深刻地知道，在激烈的市场竞争中，仅仅有强大的功能是远远不够的，不足以战胜强劲的对手。我们可以相象一下，您在挑选手机的时候，如果有两款手机，性能相同，而第一款比第二款要美观很多，那么您将选择哪一款呢？当然是美观的那一款了。试想，您的客户，也会拿您和您竞争对手的软件做这样的比较的。
 
现在的软件企业都知道，广告和市场推销活动对市场营销的作用是多么的重要，并不遗余力地打广告、做活动、做推广。但我们知道，这些活动的最终目的，是为了让用户购买并使用软件产品，而用户最终使用的也是您的产品，那么为什么不在软件界面的美观性上多下些工夫呢？在诸如家用电器、汽车、电脑等成熟的市场中，用非常精美的广告去推广一种功能强大却丑陋无比的产品，是一种笑话。然而，这样的笑话在软件行业里却屡见不鲜。这也是像中国足球一样，中国软件业与国外相比较存在的一个很大的差距。

测试设计中需要考虑的22种测试类型

软件产品的可用性测试

  关于可用性的测试和评估，在国外现在已经形成一个新的专业，称为可用性工程（Usability Engineering）。由于是一个专业，因此就有专门的人员来从事这项工作，并发展出一整套的方法和技术来进行可用性的测试和评估。根据我们给软件可用性所下的定义，一个软件可用性的测试和评估应该遵循以下原则：

        （1）最具有权威性的可用性测试和评估不应该是专业技术人员，而应该是产品的用户。因为无论这些专业技术人员的水平有多高，无论他们使用的方法和技术有多先进，最后起决定作用还是用户对产品的满意程度。因此，对软件可用性的测试和评估，主要应由用户来完成。

        （2）软件的可用性测试和评估是一个过程，这个过程早在产品的初样阶段就开始了。因此一个软件在设计时反复征求用户意见的过程应与可用性测试和评估过程结合起来进行。当然，在设计阶段反复征求意见的过程是后来可用性测试的基础，不能取代真正的可用性测试。但是如果没有设计阶段反复征求意见的过程，仅靠用户最后对产品的一两次评估，是不能全面反映出软件的可用性。

        （3）软件的可用性测试必须是在用户的实际工作任务和操作环境下进行。可用性测试和评估不能靠发几张调查表，让用户填写完后，经过简单的统计分析就下结论。可用性测试必须是用户在实际操作以后，根据其完成任务的结果，进行客观的分析和评估。

        （4）要选择有广泛代表性的用户。因为对软件可用性的一条重要要求就是系统应该适合绝大多数人使用，并让绝大多数人都感到满意。因此参加测试的人必须具有代表性，应能代表最广大的用户。

        软件是高新技术，人们对软件的认识通常是从技术上来考虑，似乎技术越先进，水平越高，系统就越好。所谓人们的认识，不仅包括设计人员和管理人员，而且包括普通用户。因此提出软件的可用性问题，不仅是设计人员思想上的一场革命，也是普通人认识上的一场革命。

        在软件产品开发过程中，软件可用性的测试是必不可少的一环。可用性是从人的角度来看软件系统是否易用，高效，使人满意。作为一种特殊的IT产品，它的可用性显得格外重要：

        考察软件系统的可用性一般来讲就是测试软件的可用性是否达到了用户的要求。目前的方法大致可以分为四类，用户模型法，用户调查法，专家评审法和用户测试法。

        用户模型法是用数学模型来模拟人机交互的过程。这种方法把人机交互的过程看作是解决问题的过程。它认为人使用软件系统是有目的的。而一个大的目的可以被细分为许多小的目的。这了完成每个小的目的，又有不同的动作和方法可供选择，每一个细小的过程都可以计算完成的时间。这个模型就可以用来预测用户完成任务的时间了。这个方法特别适合于无法进行用户测试的情形。在人机交互领域中最著名的预测模型是GOMS（Goals, Operators, Methods, Selections）模型。

        用户调查法包括问卷调查法和访谈法。这两种方法是社会科学研究，市场研究和人机交互学中沿用已久的技术，适用于快速评估，可用性测试和实地研究，以了解事实，行为，信仰和看法。

        访谈与普通对话的相似程度取决于待了解的问题和访谈和类型。访谈有4种主要类型：开放开（或非结构化）访谈，结构化访谈，半结构化采谈和集体访谈.具体就采用何种访谈技术取决于评估目标，待解决的问题和选用的评估范型。例如，如果目标是大致了解用户对新设计构思（如交互设计）的反映，那么非正式的开放式访谈通常是最好的选择。但如果目标是搜集关于特定特征（如新型WEB浏览器的布局）的反馈，那么，结构化的访谈调查通常更为适合，因为，它的目标和问题更为具体。

        调查问卷是用于收集统计数据和用户意见的常用方法，它与访谈有些相似，也是用来了解用户的满意度和遇到的问题。问卷需要认真的设计。可以是开放式的问题，也可以是封闭的问题，但必须措辞明确，避免可能的误导问题，保证所收集的数据有高的可信度。在学术论文中常见的可用性问卷包括：用户交互满意度问卷（questionnaire for user interaction satisfaction, QUIS）,软件可用性测量目录(software usability measurement inventory, SUMI)计算机系统可用性问卷(computer system usability questionnaire, CSUQ). 

        专家评审法分为启发式评估和走查法。启发式评估是由Jakob Nielsen和他的同事们开发的非正式可用性检查技术，使用一套相对简单，通用，有启发性的可用性原则来进行可用性评估。具体方法是，专家使用一组称为“启发式原则”的可用性规则作为指导，评定用户界面元素（如对话框，菜单，在线帮助等）是否符合这些原则。在进行启发式评估时，专家采取“角色扮演”的方法，模拟典型用户使用产品的情形，从中找出潜在的问题。参与评估的专家数目可以不同。由于启发式评估不需要用户参与，也不需要特殊设备，所以它的成本相对较低，而且较为快捷，因此也称为“经济评估法”。

        走查法包括认知走查和协作走查，是从用户学习使用系统的角度来评估系统的可用性的。这种方法主要用来发现新用户使用系统时可能遇到的问题，尤其适用于没有任何用户培训和系统。走查就是逐步检查使用系统执行的过程，从中找出可用性问题。走查的重点非常明确，适合于评估系统的一小部分。 

        用户测试法：可用性既然是评价软件质量的标准，而且是从用户的角度出发，评价起来当然少不了用户的参与，在所有的可用性评估法中，最有效的就是用户测试法了。该方法是在测试中，让真正的用户使用软件系统，而测试人员在旁边观察，记录，测量。因此，用户测试法最能反映用户的要求和需要的。根据测试的地点不同，用户测试可分为实验室测试和现场测试。实验室测试是在可用性实验室里进行的，而现场测试则是由可用性测试人员到用户的实际使用现场进行观察和测试。根据试验设计的方法不同，用户测试以可分为有控制条件的统计试验和非正式的可用性观察测试。这两种试验方法在某些情况下也可以混合使用，所以经常被笼统的称为可用性试验。可用性的实验就是在产品实际应用的环境之外，就特定的环境、条件、使用者进行测试，藉以记录系统的表现，更能对特定的因果关系进行验证，得到量化的数据。 

        用户测试常用的方法包括实验室的实验、焦点团体讨论(Focus Group Discussion)及发声思考(Thinking Aloud)。焦点团体讨论是一般市场营销研究常用的手段。邀请一群使用者，一般五至八人一起就几个焦点问题进行讨论，由一位主持人掌控讨论的方向，围绕着预定的题目进行，让参与者都能畅所欲言并热烈讨论。不过若针对软件进行讨论，必须要考虑系统的规模与使用的体验，对企业的软件来说，一次的讨论绝对不够，必须要进行一系列的讨论与评价。

        发声思考法是心理学研究所用的研究方法，在国外被人机交互或可用性的研究者用来评估软件的使用。发声思考法要求受测者使用指定的系统，边用边说话，说出使用之时心中想的一切，包括困难、问题、感觉等。这个方法能从每位受测者的评价过程中收集到相当大的信息，而所需邀请的受测者也不多，在国外的相关业界可说是标准的软件使用质量评价方法。

        小结一下，以上介绍的可用性工程方法都是多年工业实践证明切实有效的。在各个方法的实际运用中，可以根据具体情况对方法执行上的某些细节灵活掌握。在特定的产品开发项目中，如何选择所使用的可用性工程方法直接关系到可用性工程的运用效果。在这里一定要综合考虑开发过程当时所处的阶段、各种方法所能提供的信息以及它们所需要的技能、人员、时间、设备等方面的资源，在此基础上，选择一组适合具体情况、能够互补和相互衔接的方法，使得以用户为中心的设计理念得到尽可能的充分体现。

防火墙性能测试浅析

防火墙是目前网络安全领域广泛使用的设备。 其主要目的就是保证对合法流量的保护和对非法流量的抵御。众所周知, 在世界范围内网络带宽(包括核心网络及企业边缘网络)总的趋势是不断的提速升级, 然而从网络的整体结构上看, 防火墙恰处于网络的末端。显而易见,防火墙的性能将对最终网络 用户得到的实际带宽有决定性的影响。所以目前防火墙的性能指标日益为人们所重视,地位也越来越重要。

    防火墙的分类 

        关于防火墙的分类方式有很多种: 例如按体系结构可分为纯软件,软硬结合和 纯硬件防火墙; 按逻辑功能可分为静态包过滤、动态包过滤和 应用代理型防火墙等。 本文所讨论的测试内容适合绝大部分上述防火墙。 有关各种类型防火墙的信息, 读者可从各大国际信息安全实验室的网站中获得, 这 里将不再赘述。

    防火墙的二层和三层测试

        一般说来, 对于一个没有设置规则的防火墙设备, 我们可以近似的当作一个普通的网络互联设备来进行性能测试。 虽然对于少数设备来说这样的近似并不准确。 RFC1242和RFC2544是在进行这种测试的主要标准。 RFC1242是对于一般的网络设备的测试术语的定义, 而RFC2544则是对于测试方法的定义。 对大多数在中国从事网络工作的技术人员来说, 这两个RFC并不陌生。 这里对个别要点做以简单的介绍。

        首先将防火墙设置为“透明模式”。 如果其支持“网桥透明模式”和“路由透明模式”, 则在两种情况下建议都进行测试比对。 普遍的测试 帧封装格式为UDP, 测试帧的大小为64,128,256,512,1024,1280、1518。 在时间紧迫的情况下, 也可抽取64、512、1518这几种帧长做为选择。 测试的指标包括吞吐量(Throughput)、发送延迟(Latency)、丢包率(Packet Loss)、背对背 缓冲(Back to Back)。 这几个指标实际上侧重在相同的测试条件下对不同的网络设备之间做性能比较, 而不针对仿真实际流量。 我们也称其为“基准测试”(Base Line Testing)。 基准测试是一个很重要的概念, 贯穿于各种不同的数据设备的评测之中。在四个指标里面, 吞吐量 是应该先被测试的,然后用测出的数值作为发送速率上限,来进行延迟指标的测试。从经验上来讲,纯软件和软硬结合的防火墙在测试的时候有可能表现不太稳定,常出现测试结果有上下波动的情况。 这是个在测试防火墙时候的现实问题。要解决它, 一般建议将防火墙在每次测试之间上电重启动, 以保证测试的可重复性。 另外一个办法就是测多次, 取平均值。 后者考虑到了防火墙稳定性的因素,相对来讲反映了更贴近实际使用的方面, 所以也不失为一个好选择。

        这个二层和三层的测试可以提供哪些有用的信息呢? 它可以帮助确定性能瓶颈是存在于下层的交换转发机制, 还是在上层协议的处理。 换句 话说,它有利于故障的定位。 即使对于一些不做交换转发的厂商,他们也可以发现所采用的网卡及所改写的驱动程序是否满足性能要求,同时也能够得到一些功能上的验证(如双工/速率状态是否正常等等)。对很多用户来讲, 除非他们想把这个防火墙只当作一个普通的路由器来用, 否则不配置任何的安全规则是比较少 见的。 而在有规则的条件下进行的性能测试显然更有意义一些。 我们将这部分的讨论放到后面的四层到七层的测试部分中。 因为有很多的规则都是既涉及到三层的信息也有四层的信息。

测试工具testlink

四款主流测试工具的测试流程

主流测试工具的测试流程
========winrunner
1　启动时选择要加载的插件
2　进行一些设置（如录制模式等）
3　识别应用程序的GUI，即创建map(就是学习被测试软件的界面）
4　建立测试脚本（录制及编写）
5　对脚本除错及调试（保证能够运行完）
6　插入各种检查点（图片，文字，控件等）
7　在新版应用程序中执行测试脚本
8　分析结果，回报缺陷
　
=========quicktestpro========
1　准备录制
打开你要对其进行测试的应用程序，并检查QuickTest中的各项设置是否适合当前的要求。
2　进行录制
打开QuickTest的录制功能，按测试用例中的描述，操作被测试应用程序。
3　编辑测试脚本
通过加入检测点、参数化测试，以及添加分支、循环等控制语句，来增强测试脚本的功能，使将来的回归测试真正能够自动化。
4　调试脚本
调试脚本，检查脚本是否存在错误。
5　在回归测试中运行测试
在对应用程序的回归测试中，通过QuickTest回放对应用程序的操作，检验软件正确性，实现测试的自动化进行。
6　分析结果，报告问题
查看QuickTest记录的运行结果，记录问题，报告测试结果。

＝＝＝＝TestDirect============
安装好后，先进入站点管理
1　创建域及工程
2　添加用户
3　编辑licenses及本服务器
4　编辑数据库
－－TD
1　选择新建的工程进行定制(列表，用户，组，版本等)
2　在require中增加需求
3　把需求转化为plan
4 在testlab中由计划新建测试具体用例与执行

5　发现bug，在defect中提交bug
（每一部分都可以相对独立地使用）

======loadrunner
1　制定负载测试计划
(分析应用程序， 确定测试目标，计划怎样执行LoadRunner）
2　开发测试脚本
（录制基本的用户脚本，完善测试脚本）
3　创建运行场景
（选择场景类型为Manual Scenario，选择场景类型，理解各种类型，场景的类型转化）
4　运行测试
5　监视场景
（MEMORY 相关，PROCESSOR相关，网络吞量以及带宽，磁盘相关，WEB应用程序 ，IIS5.0，SQL SERVER，NETWORK DELAY等)
6　分析测试结果
(分析实时监视图表,分析事务的响应时间,分解页面,确定WEBSERVER的问题,其他有用的功能)

　　1.负载压力测试工具

　　这类测试工具的主要目的是度量应用系统的可扩展性和性能，是一种预测系统行为和性能 的自动化测试工具。在实施并发负载过程中，通过实时性能监测来确认和查找问题，并针对所 发现问题对系统性能进行优化，确保应用的成功部署。负载压力测试工具能够对整个企业架构 进行测试，通过这些测试，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布 周期。

　　2.功能测试工具

　　通过自动录制、检测和回放用户的应用操作，将被测系统的输出记录同预先给定的标准结 果比较，功能测试工具能够有效地帮助测试人员对复杂的企业级应用的不同发布版本的功能进 行测试，提高测试人员的工作效率和质量。其主要目的是检测应用程序是否能够达到预期的功 能并正常运行。

　　3.白盒测试工具

　　白盒测试工具一般是针对代码进行测试，测试中发现的缺陷可以定位到代码级。根据测试 工具原理的不同，又可以分为静态测试工具和动态测试工具。静态测试工具直接对代码进行分 析，不需要运行代码，也不需要对代码编译链接和生成可执行文件。静态测试工具一般是对代 码进行语法扫描，找出不符合编码规范的地方，根据某种质量模型评价代码的质量，生成系统 的调用关系图等。动态测试工具一般采用“插桩”的方式，在代码生成的可执行文件中插入一 些监测代码，用来统计程序运行时的数据。它与静态测试工具最大的不同是，动态测试工具要 求被测系统实际运行。

　　4.测试管理工具

　　一般而言，测试管理工具对测试需求、测试计划、测试用例、测试实施进行管理，并且测 试管理工具还包括对缺陷的跟踪管理。测试管理工具能让测试人员、开发人员或其他的IT人员 通过一个中央数据仓库，在不同地方就能交互信息。

　　5.测试辅助工具

　　这些工具本身并不执行测试，例如它们可以生成测试数据，为测试提供数据准备。

　　参加完“2005年IT测试技术研讨会”以后，谢常君对软件测试和网络测试的主流厂商和产 品有了更全面的了解。不过最让他高兴的是结识了一批企业的代表和专家。

　　一个阳光明媚的下午，谢常君约上某位专家在一个咖啡馆会面。“非常谢谢你能前来，我 这次约你出来是希望你可以给我一些专业的建议。”谢常君说，“我们公司近期可能需要采购 一些测试工具，但是我们对此了解不多，希望你可以帮我们。”接下来，这位专家就首先从测 试工具的分类开始讲起……

　　IT测试工具集锦

　　Radview TestView系列

　　Radview公司的TestView系列Web性能测试工具和WebLoad Analyzer性能分析工具，旨在测 试Web应用和Web服务的功能、性能、程序漏洞、兼容性、稳定性和抗攻击性，并且能够在测试 的同时分析问题原因和定位故障点。

　　整套Web性能测试和分析工具包含两个相对独立的子系统：Web性能测试子系统Web性能分 析子系统。其中Web性能测试子系统包含3个模块：TestView Manager、WebFT以及WebLoad。 Web性能分析子系统只有WebLoad Analyzer。

　　左图表达了在一个完整的测试系统中，TestView Manager用来定制、管理各种测试活动； WebLoad模拟多个用户行为进行测试，所测试的是系统性能，容量，稳定性和抗攻击性；WebFT 模仿单一用户行为进行测试，所测试的是系统功能，漏洞，兼容性和稳定性； WebLoad Analyzer对Web服务、中间件和数据库进行监控和分析，找出问题原因和故障点。 （B6） 　　IBM Rational ClearQuest

　　IBM Rational ClearQuest提供基于活动的变更和缺陷跟踪。以灵活的工作流管理所有类 型的变更要求，包括缺陷、改进、问题和文档变更。能够方便地定制缺陷和变更请求的字段、 流程、用户界面、查询、图表和报告。拥有“设计一次，到处部署”的能力，从而可以自动改 变任何客户端界面（Windows、Linux、UNIX 和 Web）。可与IBM WebSphere Studio、Eclipse 和Microsoft .NET IDE进行紧密集成，从而可以即时访问变更信息。支持统一变更管理，以提 供经过验证的变更管理过程支持。易于扩展，因此无论开发项目的团队规模、地点和平台如 何，均可提供良好支持。

　　包含并集成于IBM Rational Suite和 IBM Rational Team Unifying Platform，提供生命 周期变更管理。

　　康博File-AID/RDX

　　康博公司提供的File-AID/RDX使程序员能够迅速在测试表格中装入准确反映生产性关系的 数据，但这些数据只是生产性数据的一个有关的子集，而且这是一个更小、更精确的数据库。

　　通过类似于ISPF的界面，用户可以迅速方便地浏览表格关系，建立数据抽取条件、将数据 装入目的表格。因为File-AID/RDX提供了一种简单的方法来显示，通过独立的表格串接起各种 关系，用户可以方便地选择所需的数据。

　　使用File-AID/RDX有3个好处：节省时间，用户不必编写一次性程序来向测试数据库中装 入数据；节省更多的时间，确保使用正确的数据来对应用系统进行合格的测试；节省磁盘空 间，测试中仅仅使用那些需要的生产性数据。

　　Mercury质量中心

　　Mercury质量中心（Mercury Quality Center）提供一个全面的、基于Web的集成系统，可 跨多种环境实施质量保证。它的集成应用自动化了关键质量行为，其中包括需求管理、测试管 理、缺陷管理、功能测试和业务流程测试。Mercury 质量中心提供用户所需的流程、自动化操 作和可见性，以实现高质量的应用。它通过将所有不同要素和正确应用维系起来，使质量流程 自动化，从而缩短部署时间。其结果就是，它极大地提高了应用质量和可靠性。

　　Mercury质量中心包括集成的、基于角色的应用，它们根据质量流程中每个相关人员的需 求而精心设计——从业务分析员和开发人员到QA工程师、测试人员以及架构工程师。

　　Mercury质量中心帮助用户管理和控制应用开发和测试中的风险。在流程中的所有点上， 用户可以直接观测到项目所处的质量水平——是否测试并满足了需求，是否执行了测试，或是 否发现并解决了缺陷。

　　IXIA IxChariot

　　美国IXIA公司的应用层性能测试软件IxChariot是一个独特的测试工具，也是在应用层性 能测试领域得到业界认可的测试系统。对于企业网而言，IxChariot可应用于设备选型、网络 建设及验收、日常维护等3个阶段，提供设备网络性能评估、故障定位和SLA基准等服务。

　　IxChariot由两部分组成：控制端（Console）和远端（Endpoint），两者都可安装在普通 PC或者服务器上，控制端安装在Windows操作系统上，远端支持各种主流的操作系统。控制端 为该产品的核心部分，控制界面（也可采用命令行方式）、测试设计界面、脚本选择及编制、 结果显示、报告生成以及API接口提供等都由控制端提供。远端根据实际测试的需要，安装在 分布的网络中，负责从控制端接收指令、完成测试并将测试数据上报到控制端。

　　福禄克

　　DTX系列

　　福禄克网络公司推出的 DTX系列电缆认证分析仪完成一次6类链路自动测试的时间比其他 仪器快3倍（进行光缆认证测试时快5倍）。DTX 系列还具有 IV级精度的智能故障诊断能力、 900MHz的测试带宽、12小时的电池使用时间和快速的仪器设置，并可以生成详细的中文图形测 试报告。

　　思博伦通信SmartBits

　　思博伦通信(Spirent Communications)的SmartBits网络性能分析系统为进行十兆/百兆/ 千兆和万兆以太网、ATM、POS、光纤通道、帧中继网络和网络设备的高端口密度测试提供了行业标准。

　　作为一种强健而通用的平台，SmartBits提供了测试xDSL、电缆调制解调器、IPQoS、 VoIP、MPLS、IP多播、TCP/IP、IPv6、路由、SAN和VPN的测试应用。

　　SmartBits使用户可以测试、仿真、分析、开发和验证网络基础设施并查找故障。从网络 最初的设计到对最终网络的测试，SmartBits提供了产品生命周期各个阶段的分析解决方案。

　　SmartBits产品线包括便携和高密度机架，支持不同技术、协议和接口的模块，以及软件 应用程序和脚本。旗舰级SMB-6000B在一个机架中最多可支持96个10/100 Mbps 以太网端口、 24个千兆以太网端口、6个万兆以太网端口、24个光纤通道端口、24POS端口或上述端口的任意 组合。

　　 安立MD1230A

　　安立公司的MD1230A提供以太网络和IP网络优良的测试能力。然而它的轻重量 (5公斤) 而 且内置点击设备，符合服务供给者和企业网经理最迫切的栏位可移植性需求。它的内置全球定 位测试接收机选项，可在1微秒内进行点对点网络延滞测试。这样的解像度对在IP上应用话音 和视像是十分重要的。

　　小巧、轻便的MD1230A已内置计算机、显示装置，利用点击设备和键盘就可在恶劣环境下 进行现场操作应用。

　　熟悉的视窗使用者操作界面和一致的远程控制操作界面，使用户能够很快上手操作。

　　通过传送、监视、计数和解码很多高层的IP协定，可以提供一系列专业服务，诸如在IP (VoIP)上测试声音传送，并作故障解决功能，以帮助解决极复杂的网络相关协定。这不是一般 测试器能胜任的。

　　基于Sniffer Technologies提供的可选择的译码模组及专家分析模组，可快速精确地解译 OSI所有7层约400多种协定码。

　　Shunra Storm

　　Shunra公司用于产品和系统测试阶段的硬件产品Storm，辅以各种软件选件，除了仿真各 种网络环境外，还可以提供协议分析等多种功能。Storm产品配套解决方案基本上由Storm Appliance和Storm Console，以及相关软件组成，以支持多种多样复杂的广域网及实验室的结 构。

　　Storm是一种将广域网仿真和用户端数据流模拟结合在一起的工具。它可以精确地模拟广 域网环境。将应用程序部署在这个模拟的广域网环境里，用户将看到所开发应用程序在广域网 环境中的性能表现，通过调节Storm的广域网模拟参数以及终端用户数据流，Storm可以模拟各 种各样的广域网。为检验应用程序对网络的适应性以及定位问题，Storm不但可以仿真出广域 网环境，还可以仿真大量用户产生的各种应用数据流，使用户得到更加真实的广域网环境，精 确地评估应用程序的网络性能。Storm可以方便地将地理上分布极广的网络复制到实验室中。