## 质量管理
### 管什么?
经过多年的发展,质量管理已经有了一套基本的理论和方法。质量管理包括质量保证和质量 控制两大类。质量保证是指在项目过程中实施的有计划、有系统的活动,确保满足相关的标 准,典型的例子是评审和审计。质量控制是指采取适当的方法监控项目结果,确保结果符合 质量标准,典型的例子就是测试以及之后的缺陷跟踪。
在IT行业软件开发领域中,常见的公认的质量活动包括:配置管理、评审、测试以及缺陷跟 踪。
* 评审:检查项目中间产品,早期发现缺陷以减少后期项目返工和修改的工作量。
* 测试:直接检测软件产品中的缺陷,确保符合质量要求。一般通过单元测试、集成测试、 系统测试和性能测试实现。
* 缺陷跟踪:记录和追踪缺陷从发现到解决的整个过程,确保所有的结论都有结论。
* 审计:对项目工作过程进行检查,确保所有活动按照规程进行。
* 变更控制:版本本更控制,也是重要的一环。
* 配置管理:记录中间和最终产品(配置项)的变更历史。
质量经理在项目中的职责如下:
* 贯彻公司的质量管理规范,负责质量管理过程中的检查和指导。
* 负责制定项目开发/测试环境的标准和规范。
* 负责项目的配置管理,通过权限控制和备份机制确保交付物的完备和安全。
* 负责组织同行评审,确保中间交付物的质量。
* 制定测试策略和测试计划,组织测试,确保最终交付成果的质量。
### 项目配置管理
项目配置管理是一项看不见的财富,可以在无形中减少因为版本意外等开发中出现的问题导 致的返工、重做等资源浪费。
**Q: 什么是项目配置管理?**
配置管理是在某一特定时点,确定软件配置的一个过程,通过对已标识的软件配置的一个过 程,通过对已表示的软件的配置的变更进行系统控制,从而在整个软件生命周期中保持软件 的整体性和可追溯性。
**Q: 配置管理的具体要做什么?**
通常来说,软件配置管理主要通过计划、标识和控制变更和发布配置状态报告来协调软件开 发,目的是使错误率达到最小并最有效地提高生产效率。
### 质量评审
评审的目的是尽早发现问题,一团和气的评审会完全达不到发现问题的目的。
**Q: 评审中的角色有哪些?**
首先要把评审中设计到的各个人员确认下来。评审过程中涉及的角色主要有四种:责任人、 主审人、评审专家和记录员。
主审人要先选定评审组的成员,然后再做评审的前期准备。在 评审过程中保证规范和高效, 评审结束后要将结果及时发布被评审相关人员。最后,还要对 评审中发现的问题追踪,直 到问题关闭。
责任人就是要被评审的对象。他们在评审之前准备好资料,在评审过程中解答提出的问题。 对于发现的问题要积极修正后提交给主审人。
记录员就是在评审过程中,把专家提出的问题都记录下来,还要记录责任人的回答信息,最 终要行程会议纪要,并且记录评审结果。
评审专家要彻底了解被评审的资料,其任务是寻找这些资料中的缺陷,侧重于发现问题而不 是解决问题。要保持客观。
**Q: 评审的过程是什么?**
评审的过程分为计划、预备会议、准备、评审会议和追踪几个阶段。
* 计划阶段与项目计划同步,也就是说项目中有哪些要评审在项目计划中就已经提前定义好 了。
* 预备会议,针对要评审的资料对评审组进行培训,并讨论评审资料。
* 准备工作,是评审专家要彻底熟悉评审资料,以保证评审的质量和高效。
* 评审会议,是主审人和评审专家对项目资料中的错误和缺陷进行确认。
* 跟踪,主审人要确保责任人采取必要的措施修正发现的错误。
一个评审反馈表如下:
![](https://box.kancloud.cn/2015-11-26_5656b0fe2ea2b.jpg)
### 让测试深入人心
保证质量最有效的措施就是测试。
**Q: 为什么要有多种测试呢?**
不同的测试是针对不同的开发活动来设置的。下面是软件测试的一个『V模型』:
![](https://box.kancloud.cn/2015-11-26_5656b0fe4ee55.jpg)
* 单元测试,主要是开发人员对编写的代码进行自测或相互进行交叉测试,用以检查代码是 否符合编码规范,是否存在逻辑错误。
* 集成测试,将经过单元测试的模块组装成完整的程序。工作任务包括制定集成测试策略, 确定集成测试步骤,设计集成测试用例,然后逐一添加模块进行测试。
* 系统测试,是为了验证需求分析确定的功能是否被正确的实现,同时还要对安装、部署、 适应性、安全性、界面等非功能性需求进行测试。
* 性能测试,用来测试系统是否满足规定的性能需求。性能测试通常选择一些典型的功能, 检验这些功能在大量用户同时使用时是否稳定。
* 用户验收测试,目的是验证需求与系统的匹配性,以及界面的友好性,响应时间等等。
### 缺陷跟踪
**Q: 为什么要进行缺陷跟踪?**
缺陷跟踪可以记录测试结果,确定代码质量,是确保问题得到解决的一个关键流程。其目的 是规范评审、测试、试运行等过程中发现缺陷的更改活动;跟踪缺陷处理的各个环节、避免 缺陷修改失控和遗漏;如实的反映缺陷处理过程。
**Q: 怎么进行缺陷跟踪?**
缺陷跟踪的起点是各种发现缺陷的活动,发现缺陷之后就进入了缺陷的跟踪流程,包括提交、 判断、分发、修改、复核和关闭几个关键步骤。
缺陷跟踪除了记录和跟踪缺陷的修复过程,很重要的还有对缺陷进行分类、统计和分析。
缺陷的类型一般分为一下几种:
| 缺陷类型 | 描述 | 可能的缺陷来源 |
| --- | --- | --- |
| 用户界面 | 用户界面显示或者操作存在问题 | 详细设计 |
| 架构 | 系统存在架构方面问题 | 架构设计、概要设计 |
| 接口 | 系统内、外部接口错误,不能正常连接和工作 | 架构设计、概要设计 |
| 业务功能 | 业务功能不完善、未实现或者出现错误 | 需求分析、需求规格 |
| 系统功能 | 与业务无关,但是系统必须实现的功能不完整、未实现或者出现错误 | 架构设计、概要设计 |
| 性能 | 系统的响应时间、吞吐量、并发量等不满足需求 | 架构设计、概要设计、编码 |
| 可重用性 | 不满足被其他系统或者模块复用的要求 | 概要设计、编码 |
| 可移植性 | 不满足可跨平台移植或者部署的要求 | 概要设计、详细设计 |
缺陷的严重性说明了缺陷给最终交付的系统或者产品可能造成的影响程度。其中A级影响程 度最大,E级最小。
| 严重性等级 | 描述 |
| --- | --- |
| A级(系统级) | 系统整体崩溃,或者不能稳定地连续工作 |
| B级(应用级) | 部分应用或者子系统不能运行,或者不能稳定地连续工作 |
| C级(业务级) | 导致业务流程终止,或者因结果错误、数据不一致失败;因安全、容错性和性能问题等非功能性问题影响使用 |
| D级(操作级) | 不易于学习使用,界面操作困难;难以理解而不容易使用 |
| E级(文档级) | 安装手册、操作手册、在线帮助等文档不能提供帮助或 |