前两天PMO因为想了解开发人员的工作质量，所以要求测试部协助出一组数据，即在测试人员发现的bug中，有多少是应该开发自测发现的。为了配合这个工作，花了半天的时间对禅道里的bug进行了归类，根据常见问题类型做了简单划分，如下。

主功能流程无法正常使用，以及联调时主功能流程是否正常

功能缺失，或重点功能错误，如文件导出时有明显错误（无法导出、导出后格式明显不对、批量导入出错等）

打包时数据库表非最新、程序文件非最新；

违反《界面设计和通用提示规范》规定的：

必要的输入检查，如金额只支持数字的输入

非空验证

缺少数据类型验证（如身份证和电话等）

页面显示变形

初始化时的默认条件加载不正确

风格和元素跟设计不符（在设计未变更的前提下）

对齐方式错误

信息提示格式不统一

重要数据删除时没有提示

应该提供模糊查询的查询框未提供

有联动关系的下拉菜单（如省市区联动），不能正确联动

下拉菜单的值无明显错误（比如省的下拉菜单加载了市区），如包含了数据字典中已经删除的字段

数据计算错误

偶发类、或客户端导致的问题

不常用功能bug、深路径下的bug

兼容性问题，像素和分辨率类问题

服务异常重启，网络异常等诱发的bug

易用性体验、建议类（如语言描述不清晰易懂）

功能流程界面有js错误

导出文件时有不影响正常使用的错误（如容错性验证、格式验证）

系统日志记录问题

输入验证，如边界值

性能问题

数据统计这个事本身不复杂，不过做这个工作时需要注意：

• 事先把标准跟部门内外沟通清楚，避免下面的人不清楚活怎么干，也避免没标准做出来的工作其他部门不认可。

• 提供数据这个事，不建议主动提供给高层。一旦提供根据bug管理系统得出的个人表现数据，以后会被要求继续提供这些数据。第二个原因是高层掌握的项目质量相关数据可能没有我们全面，如果我们提供了一些简单的、抽象的数据给高层，可能会导致他们做出错误的决策，也就是说通过度量信息有时候并不能完整的说明一个项目的整体情况。另外特别需要注意某些控制欲比较强的领导。

• 在整理度量数据的时候，先把目的弄清楚，也要知道自己在统计什么数据，谁将看到这些数据，要了解背景....我做度量一般是为了两个目的：这个数据是否有助于提高质量，或者是否有助于提升开发的效率。

• 质量度量这个事可以多去尝试，多利用度量帮助项目干系人了解项目进展，以及各个方面的质量状况。