软件质量度量

前两天PMO因为想了解开发人员的工作质量，所以要求测试部协助出具一组数据，即在测试人员发现的bug中，有多少应该在开发阶段就通过自测发现。为了配合这个工作，也是为了防止以后扯皮，简单制定了以下约束，去跟各个项目经理、部门经理沟通了一下。

标准:

研发应发现：

1. 主功能流程无法正常使用，以及联调时主功能流程是否正常
2. 功能缺失
3. 打包时数据库表非最新、程序文件非最新；
4. 文件导出时有明显错误（如无法导出、导出后格式明显不对、批量导入出错）
5. 输入检查
   • 非空验证
   • 数据类型验证（如身份证和电话等）
6. 页面显示
   • 初始化时的默认条件加载是否正确？
   • 主功能、流程界面有JS错误
   • 风格和元素跟设计不符（在设计未变更的前提下）
   • 对齐方式错误
7. 数据正确性
   • 查询模块单条件查询是否正确
   • 模糊查询
   • 有联动关系的下拉菜单（如省市区联动）
   • 下拉菜单的值无明显错误（比如省的下拉菜单加载了市区），不包含数据字典中删除了字段导致的错误
8. 易用性
   • 信息提示格式不统一
   • 重要数据删除时没有提示

测试应发现：

1. 偶发类、或客户端导致的问题
2. 路径较深类
3. 兼容性问题
4. 像素和分辨率类问题
5. 服务异常重启，网络异常等诱发的bug
6. 易用性体验、建议类（如语言描述不清晰易懂）
7. 次要功能流程界面有js错误
8. 导出文件时有不影响正常使用的错误（如容错性验证、格式验证）
9. 系统日志记录问题
10. 输入验证，如边界值
11. 性能问题

数据统计这个事本身不复杂，不过从我的经验来讲，做这个事的时候有几个地方需要注意：

1. 事先把标准跟部门内外沟通清楚，避免下面的人不清楚活怎么干，也避免没标准做出来的工作开发人员不认可。
2. 提供数据这个事，不建议主动提供给高层。一旦提供根据bug管理系统得出的个人表现数据，以后会被要求继续提供这些数据（如果你觉得不影响你的工作安排，或者能增加测试部的话语权，当我白说）。第二个原因是高层掌握的项目质量相关数据可能没有我们全面，如果我们提供了一些简单的、抽象的数据给高层，可能会导致他们做出错误的决策，也就是说通过度量信息有时候并不能完整的说明一个项目的整体情况。---另外就是，特别需要注意某些控制欲比较强的领导。
3. 在整理度量数据的时候，先把目的弄清楚，也要知道自己在统计什么数据，谁将看到这些数据，要了解度量的条件背景。。。我做度量的目的重要有两个：这个数据是否有助于提高质量，或者是否有助于提升开发的效率。
4. 质量度量这个事可以多去尝试，多利用度量帮助项目干系人了解项目进展，以及各个方面的质量状况。