抛开复杂的统计分析学原理，将 IBM SPSS Statistics 作为一个统计分析工具，结合实际工作中的实例，一步一步从而成为这个工具的应用专家。了解与熟悉这个工具最为基本的功能，做好准备，开始学习吧！

引言

当前在软件项目开发中，一定都会使用到 Bug 系统来记录开发过程中发现的各种各样的问题，同时也会利用 Bug 系统提供的一些分析图表进行一些基本的统计和分析工作来指导项目管理，但是大部分的 Bug 系统由于功能的限制，这些分析图表都相对比较简单，并且还存在扩展功能不足的情况。IBM SPSS Statistics 具有强大的统计分析功能，以及丰富的统计图表，因此本篇就如何使用 IBM SPSS Statistics 与 Bug 系统相结合，通过简单、易学的操作之后，可实时获得丰富的统计分析报表，以满足项目管理不同层次的需求，同时也希望能够抛砖引玉，激发用户更多的灵感，结合实际工作中的需要，充分利用 IBM SPSS Statistics 分析出更多有价值的信息，达到事半功倍的效果。

关于 Bug 分析的 QA 报告

根据项目管理的需求，QA 的质量分析报告中都会针对当前的 Bug 状况进行一些分析和说明，从而让管理人员可以快速、清晰的获得当前的工作状态，及时的采取相应的措施来保证项目顺利进行。

QA 报告中的图表

纯文字的描述既不便于分析、也不便于理解，因此在 QA 报告中通常都会使用到以下的图表：

缺陷分类比例图：根据某一特征来进行比例区分，用于快速找到最需要关注的内容，如按功能（Feature）区分的 Bug 数量统计饼图或者直方图，可以很容易区分出哪些功能存在的问题较多，要更为关注。

缺陷趋势图：根据缺陷处理活动的时间，给出趋势图，包括提交、分配、修复、验证等活动，从而能够及时了解当前的工作趋势，及时采取措施解决当前潜在的风险。

缺陷状态图：给出指定日期的缺陷状态，能够及时了解当前 Bug 在各状态的数量，从而为后续工作的安排提供指导。

IBM SPSS Statistics 解决方案的优势

更丰富的统计图表

IBM SPSS Statistics 提供了丰富的图表，对于 QA 报告中经常使用到的图表都有定义，同时还提供更多更为细致的图表用于进一步的数据挖掘。这些图表都可以直接复制到 MS Office 软件当中，极大的简化了统计报告的制作工作。

更深入的分析

IBM SPSS Statistics 的强项就是数据的统计分析。针对实际数据可以灵活定制各种条件进行统计与分析，并结合统计分析的结果定制各种统计图表，其能力远超过各类 Bug 系统中的分析功能。

如简单的图表分析，可以获得按照功能分类的 Bug 数量统计图表，进一步分析的话，可以添加开发人员的信息，从而获得每个开发人员处理过的 Bug，然后按照 Feature 数量统计，得出每个开发人员的对应各功能的熟悉程度与能力，当出现 Bug 过多，需要进行工作协调的时候，可以较为容易的找出合适开发人员并进行任务指派。

实时反馈

实时反馈的最大好处就是及时的反馈出当前的状态，同时可以为按需统计提供基础，仅根据项目管理的需要进行即时的统计，既能减少报告的数量，又能满足不同层次管理人员的需求。如一些简单的开发人员或者测试人员的工作状态统计，可以直接由各开发或者测试人员自己随时查看。

从 Bug 系统中导入数据

要在 IBM SPSS Statistics 中对 Bug 系统中的数据进行分析，那么首先需要将这些数据导入到 Statistics 中。为了简单、明了的描述 Statistics 的应用，这里首先简单的介绍数据的构成，即 Bug 的基本信息，以及处理活动，然后再说明如何在 Statistics 中进行定制化操作。

Bug 的基本信息

为了将过程尽可能的简化，这里只保留 Bug 定义中最为基本的一些信息，如表 1 所述：

表 1.Bug 的基本内容

结合上面的处理动作以及状态，绘制出 Bug 处理活动图来说明 Bug 的处理流程以及状态。

图 1 Bug 处理活动图

表 1 中的内容将会以变量（Variable）的形式出现在统计数据中。图 1 处理活动图中的每一个活动都在数据库中记录一条记录，这条记录将作为一个案例（Case）出现在统计表格中。

IBM SPSS Statistics 的数据导入方式

Statistics 本身支持多种方式导入统计数据，最为常用的是文本文件导入和数据库读入两种方式。

文本文件导入：该方法相对简单，但是限制较多，第一就是很难做到实时，因为要实时的从 Bug 系统中导出数据为文本文件，然后再读入到 Statistics 中，这个工作量比较大，也很难自动化。

数据库读入：数据库读入要求用户对数据库知识有一定了解，并且了解 Bug 系统中数据库字段的设计，从而可以准确的获得需要的数据。当然优点就是可以实现自动化读取，从而极大的减轻了工作量，达到实时的目的。

因此，本篇这里重点描述从数据库读入的方式。

数据库读入步骤

从菜单栏（文件à打开数据库 ? 新建查询）打开“数据库向导”画面。

图 2 打开数据库连接向导画面

图 3 数据库向导画面

进入到“数据库向导”画面，Statistics 可以通过 ODBC 数据源进行数据库连接的，关于如何创建 ODBC 数据源，可以参考 Windows 系统的帮助，这里就不再描述了。唯一需要提醒的是，Statistics 仅支持用户数据源，其他类型的 ODBC 数据源是无法再 ODBC 数据源列表中显示出来的。

图 4 ODBC 数据源定义

点击“添加 ODBC 数据源”按钮后，将会出现 Windows 系统的 ODBC 数据源管理器，关于如何在 ODBC 数据源管理器中添加一个文件数据源，可以参考 Windows 的帮助文件。

图 5 连接数据库后获取的字段信息

建立好合适的数据源后，在数据源窗口就可以进行选择了，点击下一步就可以检索到数据源所关联的数据库中的表和字段，如图所示。这是一个简化后的 Bug 信息系统的数据库。

图 6 指定数据库表中的关系

这里可以通过图形化的方式来指定数据之间的关系，这也是要求用户对基本数据结构比较清楚，当然如果用户对 SQL 的检索非常熟悉，可以跳过这一步，直接通过 SQL 脚本来设定数据的选取。

7 限制检索的个案

指定关系后，可以针对数据进行条件过滤，即在 SQL 检索脚本中添加 Where 子句部分。

图 8 定义变量类型

筛选完数据后，需要重新定义变量的类型，默认会使用数据库字段的类型作为变量的类型，为了简单定义并能清晰的进行转换，建议保持变量的原有类型，在后续统计分析过程中，根据需要进行必要的字段转换。

图 9 数据库 SQL 查询脚本

最终向导画面生成的 SQL 检索脚本，当然，如果用户对 SQL 检索熟悉的，可以直接将自己定义的 SQL 脚本粘贴在这里，点击“完成”按钮，Statistics 会根据这个检索条件从数据库中检索对应的数据，并显示在 Statistics“数据编辑器”的窗口中。

图 10 实际导入数据示例

通过上图可以再次理解案例（Case）与变量（Variable）的定义。数据库中的字段对应统计数据中的变量，每一条记录对应统计数据中的一个案例。

定制饼图 - 功能分类比例图

有了数据就可以开始进行数据统计与分析了。首先以功能分类比例图来进行说明，即按照功能（Feature）来进行分类，然后统计各功能目前已经发现的 Bug 数量。

变量格式化

在开始进行统计分析前，还有一项非常重要的工作就是数据准备，并不是所有导入到统计表格中的数据都可以直接进行统计分析的，还需要进行一定的格式化操作，让这些数据变成统计工具能够理解的变量，实际也就是将这些数据通过数字能够准确的表述出来。

对于功能分类比例图而言，功能（Feature）这个变量是字符串，因此需要将这个字符串进行编码，使用数字来准确定义这些功能，即一个功能字符串对应一个功能代码。从菜单栏中打开转换（Transform）? 自动重新编码（Automatic Recode）功能就可以完成这个工作。

图 11 自动重新编码

选择功能（Feature）字段，在新名称栏中填写“FeatureCode”，然后点击“添加新名称”按钮，可以看到新的变量名称由 8 个问号变成了“FeatureCode”。最后点击“确定”按钮，在统计数据集窗口就会增加一个新的变量列，名称为“FeatureCode”

使用该功能还可以将状态（State）、活动（ActionStep）等变量也进行重新定义，从而使得用户进行深入的数据筛选和统计操作。

筛选数据

接下来需要对数据进行筛选，因为在实际统计数据中，每一个 Bug 是有多条记录的，每一个记录表示这个 Bug 所经历的一个活动，而按照功能统计，是不能直接统计该功能（Feature）下的记录条数的，这样就会出现一个 Bug 被多次重复计数，所以需要过滤掉多余数据。

使用“标识重复个案”功能可以非常简单的完成这个工作。

图 12 标识重复的个案

选择 CQID 作为匹配依据，是具有唯一性的，因此用它可以来进行重复数据的判别，由于不存在顺序的关系，只要保证一个 Bug 仅出现一次，所以不需要进行任何排序的工作，使用默认的配置，以 CQID 分组，每组中抽出一个个案来统计数量即可。

当然，如果想得到更为深入的统计信息，例如查找当每一个 Bug 当前的状态，则可以增加一个排序，使用 ActionDate 进行升序排列，选择每组中最后一个个案（Case），个案中的 Status 就是当前 Bug 的状态。

图 13 重复个案标识结果

如图所示，统计数据中增加了一个变量（Variable），名称为“最后一个基本个案”，被选中的个案所对应的变量值为 1（主个案），其他重复 Bug 记录的值为 0（重复个案）。

图 14 选择个案

既然重复数据已经被标识出来，使用“选择个案”功能就可以很容易的选择出需要进行统计的个案，标记为“主个案”的记录，并生成一个新的数据集。

图 15 选择个案的条件定义

如图所示，选择变量“最后一个基本个案”，然后定义值等于 1。这里的定义简单，明确，不会产生二义性，所以在做统计分析前，一个好的习惯就是将需要使用到的变量都尽可能的进行重编码工作，将其定义为数值，这样在数据筛选过程中会极大的提高效率。

生成饼图

筛选后的数据已经满足一个功能分类统计图的需要了，所以直接调用“图表构建程序”来完成饼图的绘制即可。

图 16 图表构建程序对话框

选择图形为饼图，拖拽“FeatureCode”变量到横轴栏中，“计数”功能会自动出现在纵轴上，点击“确定”按钮即可。

图 17 Bug 功能分类数量统计饼图

在输出窗口中可以看到期望的功能分类饼图。

丰富饼图

Statistics 提供的图表不是一个简单的图片，而是可以进行一定程度的编辑的图例。在输出结果窗口中双击饼图，就可以在图标编辑器中对图表进行更多的编辑，如增加实际的比例数值。

图 18 图表编辑器

自动化定制

通过以上的操作最终可以获得期望的图示，但是每次都手工操作一遍，还是非常不便利的，因此，自动化这一系列的操作是非常必要的。在 Statistics 中可以采用两种方式可以完成自动化功能。

脚本方式

脚本方式最为简单，也容易掌握。上述所有的手工活动都会在结果输出窗口中生成对应的脚本，将上述所有的脚本按照实际操作步骤保存到一个脚本文件中，在需要生成报告的时候，从语法编辑窗口打开这个脚本文件，点击运行，结果查看窗口中就会得到最后所期望的图表。对用户而言，只需要能够掌握正确的操作步骤即可，操作一次就能得到对应的脚本，之后就可以不断的重复使用了。

图 19 手工操作生成的脚本

扩展开发方式

扩展开发方式则是利用 Statistics 提供的 PlugIn 插件，如 .NET PlugIn 来进行一些封装性开发，然后给最终用户发布新开发出来的可执行程序（EXE）即可，对于最终用户而言，这种方式更为简单，易用，但是需要有开发人员对中间过程进行编程开发，对于开发人员而言，即需要一定的编程技巧，还需要对 Statistics 的语法能够熟练应用，但是对于最终用户而言，则最为简单方便，不需要了解任何统计、分析的操作，甚至不需要打开 IBM SPSS Statistics 就能得到期望的结果。这个话题将在以后的讲解中继续介绍。