测试过程中“图”的思想－用例图（二）

这个时候可能很多人会有疑问了，这个图大部分运用在需求分析和设计阶段，跟测试有什么关系呢？然而我个人的经验却告诉我，通过用例图，我能在最短的时间内掌握系统的基本构成，了解系统的需求，为后续完成高质量的测试用例打下一个好的基础。

测试介入项目无论是在什么阶段，首先要做的就是尽快了解项目的组织架构以及构成。介入阶段的不同，完成的详尽程度也不同，但最关键的一步就是我们要了解项目的用户（参与者），项目的功能需求（用例），以及最基本的构成（用例图：用例描述）。由于本人参与的实际项目不能对外，这里我举一个我们常用的工具为例：

   通过上图，大家可以知道此工具只划分一个用户，各用例实际就是这个工具的功能模块，此用例图非常清晰的描述了这个工具具有7个大的功能模块（或者也可以认为是7个子系统）。通过同样的方式，我们可以把这个工具的功能模块进行细分这里以“常用配置”－“查杀流行木马”－“选择扫描方式”为例，细分情况如下：

大家可以发现，通过这种方式，在非常快速的了解待测试的项目的同时，也为我们后面测试用例划分了最细一节的功能点。

个人对用例图的“忠爱”主要源于我可以非常清晰的把我需要与我的测试团队描述清楚的项目用这种方式简单的实现了，虽然这种方式仅仅达到一个基本目的，但任何事情都是循序渐进的。我也很清楚有很多人并不喜欢这种方式，我跟我的测试团队的人说了这样一句话：“图，人见人智，只要你能表述清楚，你可以采用任何一种方式，图只是手段之一而已！”

上面的工具可能过于复杂，而且可能还有很多人并不清楚，这里我就举我们最常用的“登录”为例。登录通常需要用户名，密码，以及最后的触发（通常是点击登录按钮）：

通过上面这张用例图，大家清晰的知道“登录”是我们的一个功能，且“登录”已经是最细一层了，不能再进行细分，使用登录可以有两种类型的用户：管理员用户，普通用户。这里我暂且不讲用户名，密码，以及触发登录行为的作用，在后面的状态图一节我会详细为大家讲解。通过这么简单的方式，大家就把用户，功能都简单描述清楚了，至于后面进一步的描述就需要通过其他的方式了。

第一次尝试的把自己的经验写出来，发现还不是那么容易表达，请大家谅解！如果大家觉得还有哪里不够，需要我再解释清楚一些，可以给我留言，如果觉得不足，也请多提宝贵意见。