软件质量管理是当今被讨论的越来越多的话题。我们期望软件能满足客户的需求、并且软件产品上线运行稳定、没有重大的问题，可惜现实与理想差异太大。
即便组织已经通过了CMM5认证，也未必代表软件的质量很高。软件产品的质量应该如何定义？应该如何保证质量？通常经典教科书里的内容并不能奏效。根本原因是不同的软件产品对质量的要求不同，是否已商业目标和价值来衡量项目软件的质量成了重要标准之一。
另外，项目管理中的质量与产品管理的质量也大不同，到底如何平衡收益与代价，越来越值得我们进一步思考。
1.质量管理发展阶段
第一阶段特征： 事后检查。将质量检验成为一种职能从生产过程中分离出来，成立独立的质量检验部门（QC部门）。
第二阶段特征：强调缺陷预防。添加了质量过程控制，在控制中引用统计数学方法，实施定量的质量管理。
第三阶段特征：同时关注结果和过程质量。
1.质量不仅仅是产品质量，还包括服务、工作质量，质量是全体人员的共同事务。
2.质量不仅仅考虑功能，还要考虑可靠性、经济性和可维护性等。
4.全员参与。
第四阶段特征： 客户满意、预防胜于检查、质量成本。
2.质量的定义
ISO定义：指产品或服务所具有的，能用以鉴别其是否合乎规定要求的一切特性和特征总和。
六西格玛定义：是顾客和供应商从商业关系各个角度共同认知的价值理念。
朱兰博士： 适合使用 ( Fitness to use)。
克劳斯比： 符合要求。
3.软件产品的衡量维度
4规划质量项目管理需要平衡范围、时间、成本和质量这几个关键相互制约的因素。客户希望获得的产品质量越高越好，而项目的实施组织则希望能够平衡“高质量”与所付出的代价，这就要求我们需要为达到什么样的质量标准作出规划、争取、协商甚至妥协。所以质量管理计划是质量管理的纲领。
软件质量管理计划的大纲通常包括以下组成部分：
1.质量元素分析
2.软件产品和过程的质量目标
3.实施质量活动的人员与职责
4.过程检查计划
5.技术评审计划
6.软件测试计划
7.缺陷跟踪工具
8.审批意见
衡量产品的基本测量指标：
衡量项目执行与测试的基本测量指标：
覆盖率
覆盖率(Coverage Ratio) – 度量完整性的一个指标和手段。
覆盖率 ＝ （至少被执行一次的item数） / item的总数。
1. 需求覆盖率。
通过设计一定的测试用例，要求每个需求点都被测试到。
需求覆盖率 = ∑被验证的需求量（个） / ∑总需求数量（个）。
还可以把需求进一步分解为功能点，每一个功能点对应一个测试用例来衡量。
需要参考：《用户需求说明书》《需求跟踪矩阵》。
2. 逻辑覆盖率。
3.语句覆盖
4.判定覆盖
5.条件覆盖
6.判定条件覆盖
7.路径覆盖等 。
8.逻辑覆盖率属于白盒测试。
覆盖率使用原则：使用最少测试用例来达到覆盖。
8.缺陷修复率
衡量解决问题、修复缺陷(BUG)的能力和效率。
缺陷修复率 = ∑修复（关闭）的缺陷数量（个） / ∑有效缺陷数量（个）。
需要参考内部的缺陷管理系统，通常从该系统导出数据进行分析，或者由系统直接生成报表。
还可以进一步观察缺陷的分布情况：
缺陷分布率 = 本模块的缺陷数（个） / ∑各模块的缺陷数（个）*100%。
通常，还需要收集每一次发布周期内的缺陷密度（DDD， Defects Density Distribution），做一个趋势分析。
系统或者模块的缺陷比率 = 本版本的缺陷数（个） / ∑已测各模块数（个）。
通过比较以往每次发布的缺陷比率（缺陷密度）来评价和预测软件质量的稳定和趋势。
3.测试绩效指标
如果想衡量我们的测试能力和绩效，可以使用一下的测试绩效指标来分析。
缺陷探测率。计算内部发现的缺陷数除以内部发现的缺陷数与用户发现的缺陷数之和，主要查看内部发现缺陷的能。
缺陷探测率 = 内部发现的缺陷数（个） / （内部发现的缺陷数（个）+用户发现的缺陷数（个））*100%。
有效缺陷率。计算被开发人员确认的BUG数总和除于本人上报BUG的总和，可用于查看测试人员的个人测试质量，也可用于查看整个测试组的测试质量。
有效缺陷率 = 测试人员发现的有效缺陷数（个） /测试人员发现的总缺陷数（个）*100%。
用例执行率。计算测试人员执行的用例数除以执行测试的时间，主要查看测试人员执行测试的效率。
用例执行率 = ∑测试人员执行的用例数（个） / ∑执行用例的时间（h）。
缺陷发现率。计算测试人员各自发现的缺陷数总和除于各自所花费的测试时间总和。
缺陷发现率 = ∑提交缺陷数（个） / ∑执行测试的有效时间（小时）。
4.软件上线交付指标
软件发布以后，可能会有故障或者功能回滚（Rollback），可以这么评价。
发布回滚率。计算计划上线需求个数减去加载回滚的需求个数之差除以计划上线需求个数，主要查看新需求上线交付质量。
发布回滚率 = （上线需求数（个）-发布当时回滚需求数（个））/上线需求数（个）*100%。
故障回滚率。计算计划上线需求个数减去故障回滚的需求个数之差除以计划上线需求个数，主要查看新需求上线交付质量。
故障回滚率 = （上线需求数（个）-故障回滚需求数（个））/上线需求数（个）*100%。
5.质量保证（SQA）
PMI这么评价质量保证：质量保证旨在建立对未来输出或未完输出（正在进行的工作）将在完工时满足特定的需求和期望的信心。
那么，质量保证 = 高质量吗？这大概是天下最大的谎言。
质量保证并不能保证获得高质量，旨在保证质量的提高。
SQA的目的是为管理者提供有关软件过程和产品的可视性。包括审计质量要求、评审软件产品及其活动，以验证其是否遵守既定的规程和标准，并向有关负责人汇报评审和审核的结果。还包括检查在过程运行期间遇到的问题、制约因素，发现非增值活动，实施过程改进。
一句话说，质量保证类似项目管理中的警察，来检查项目实施的合规性，并且组织活动实施过程改进。
软件行业的质量保证，可以通过不断实施一下活动。
1.正确的配置管理。
2.阶段性的技术评审。
3.同行评审(Peer Review)。
4.实施持续集成CI。
5.质量控制(QC)
质量控制主要是对软件产品的测试，确保缺陷尽可能少的落到生产环境下以影响业务的开展。
除了确保软件产品的功能完整和正确性，还需要确保达到了所需要的非功能性特征，如高性能、高负载下时的可用性、高可用性、安全性、易用性等。
虽然技术评审与软件测试都是为了消除缺陷，但是也有不同：
前者无需运行软件，评审人员和作者把工作成果摆放在桌面上讨论；
而后者一定要运行软件来查找缺陷。
技术评审在软件测试之前执行，尤其是在需求开发和系统设计阶段。
相比而言，软件测试的工作量通常比技术评审的大，发现的缺陷也更多。
为了高效、集中的处理检测出来的缺陷，组织往往会采用某些缺陷跟踪程序，同时也能更好的分享给其他的成员。
有很多免费的缺陷跟踪程序可以从互联网下载。但并不是所有软件都能提供一些数据分析。
对于缺陷，常用的统计与分析工具有一下：
此外上面耳熟能详的质量管理七工具，还有新的工具可以使用。
6组织的责任即便大家都认可质量的重要性，在当今社会，依然有很多公司并没有重视软件的质量管理，其中一个表现就是不重视质量管理人员， 比如没有很好的职业发展道路，也不重视和培养质量管理人才。
对于质量，企业应该做好以下几点：
1.质量管理、人人有责。不管是开发也好、测试也好、PMO也好，都要参与到努力提高质量并且交付合格的产品。企业有责任普及质量管理知识，也要让每一位员工意识到质量管理的价值和重要性。
2.培养优秀的质量管理人才，确保采用核实的流程、方法与工具有效和高效的开展质量管理活动。
3.对于相关质量保证部门的人，推动质量的改进是困难的，因为他们往往有责物权。如果能做到责权合适，则对于质量活动的开展有极大的推动作用。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
