1、什么是软件质量
- 质量：确定一个实体的特性满足需求的程度
- 内部质量：软件研发过程中，评价的软件质量
- 外部质量：软件上市后，用户评论的质量
- 过程质量：评价软件研发中每个过程的质量
软件质量的三个层次
- 流程质量，领导关注
- 产品质量，测试工程师关注
- 使用质量，用户关注
2、质量要素
质量铁三角：技术、过程、组织
3、六大特性，27个子特性
1）质量模型列表
a、功能性
| 子特性 |
特点 |
常见测试点 |
案例说明 |
| 适合性 |
合适的功能(用户提出要有哪些功能)，功能的必要性 |
验证功能是否满足需要的要求，检测做没做 |
打电话、听音乐、发信息 |
| 准确性 |
正确的功能 |
需求文档中的预期动作和预期输出，做对没有 |
信息的发送内容是否正确 |
| 互操作性 |
和其他软件的互相操作 |
第三方软件的交互 |
word文档对打印机驱动程序的操作 |
| 保密安全性 |
保护信息和数据 |
1.保护得到授权的人或者系统能正常访问相关的信息或数据；2.保证未授权的人或系统无法看到相关的信息或数据 |
1.登录的用户名和密码2.权限使用3.防止DOS攻击(拒绝访问攻击)4.系统数据的保护和加密，如密码的加密5.传输加密，如密码的网络传输；6.防病毒7.防溢出，如char与varchar的字符数 |
| 功能性的依从性 |
遵循功能性相关的标准、约定或法规 |
是否符合国家法律规定 |
如色情网站 |
b、可靠性
| 子特性 |
特点 |
常见测试点 |
案例说明 |
| 成熟性 |
缺陷尽可能的少 |
|
|
| 容错性 |
提前考察的异常情况出错问题 |
整个系统的外部接口 |
如word打印时，打印机死机出现报错，但不影响word的使用 |
| 易恢复性 |
失效后恢复原有功能、性能 |
系统的性能测试 |
如网游延迟卡死现象、系统提示内存不足；银行系统的心跳监听；灾难备份 |
| 可靠性的依从性 |
法律法规 |
|
灾难备份 |
c、易用性(CUI测试)
| 子特性 |
特点 |
常见测试点 |
案例说明 |
| 易理解性(快速理解) |
系统交互的信息是否准确、清晰、易懂、指导下一步操作 |
系统提示信息是否准确 |
如网银密码超出位数报错 |
| 易学性(快速上手) |
易用好学 |
是否有说明书、是否在线帮助、是否有体术信息 |
msn的帮助手册 |
| 易操作性(快速做完) |
方便快速使用 |
操作的直观程度，操作步骤、操作动作多少与时间长短 |
鼠标、GUI层数、安装过程 |
| 易测试性 |
软件可控 |
提供工具给测试工程师，可以控制系统运行，以达到测试目的 |
Windows的性能工具与服务管理工具 |
| 易测试性 |
软件可观察 |
通过辅助手段 |
|
| 吸引性 |
外观 |
外观 |
|
| 易用性的依从性 |
法律法规 |
|
|
d、可移植性
| 子特性 |
特点 |
常见测试点 |
案例说明 |
| 适应性(跨平台、跨语言) |
软件产品无需采用特定的环境就可使用；是否适应其他系统环境 |
|
|
| 易安装性 |
在指定环境中是否易于安装 |
主流平台和系统100%测试用例，非主流10% |
flash安装 |
| 共存性 |
是否能与其他系统能共同运行 |
1.功能是否能正常运行；2.系统性能能满足要求 |
是否会抢占资源。迅雷和pplive抢占资源。杀毒软件，瑞星和金山不能共存 |
| 易替换性 |
替代为其他相同功能的产品的能力 |
升级过后的系统是否会造成系统崩溃 |
软件升级补丁升级 |
| 可移植性的依从性 |
法律法规 |
|
|
e、效率-性能
| 子特性 |
特点 |
常见测试点 |
案例说明 |
| 时间效率 |
规定条件下，软件产品执行其功能时，提供适当的响应和处理时间以及吞吐率的能力 |
系统的反应时间 |
提款机取款时间的快慢 |
| 资源效率 |
在规定条件下，软件产品执行其功能时，使用合适的资源数量和类别的能力 |
做一件事所占用的系统资源 |
电器做小号的电能是多少 |
| 效率依从性 |
法律法规 |
|
|
f、维护性-维护的难易程度与成本
| 子特性 |
特点 |
常见测试点 |
案例说明 |
| 易分析性 |
软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力 |
辅助工具或者日志文件或者常用问题帮助手册 |
qq异常退出的帮助文件 |
| 易改变性 |
代码容易被修复或修改 |
高内聚，低耦合 |
|
| 稳定性 |
软件产品避免由于软件修改而造成意外结果的能力 |
长期的监控一个系统的运行情况和系统的资源情况 |
淘宝的系统监控 |
| 维护性的依从性 |
法律法规 |
|
|
4、CMMI把企业分为5个等级
CMM/CMMI把软件过程的成熟度分为5个等级
| 过程能力等级 |
特点 |
关键过程区域 |
| 初始级 |
软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于团队的技能。管理是反应式(消防式)的 |
|
| 可重复级 |
建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功 |
需求管理，软件项目计划，软件项目跟踪和监督，软件子合同管理，软件质量保证，软件配置管理 |
| 已定义级 |
已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、裁剪的标准软件过程来开发和维护软件 |
组织过程定义，组织过程焦点，培训大纲，集成软件管理，软件产品工程，组际协调，同行评审 |
| 已管理级 |
收集对软件过程和产品质量的详细度量，对软件过程和产品都有定量的理解与控制 |
定量的过程管理，软件质量管理 |
| 优化级 |
过程的量化反馈和先进的新思想、新技术促使过程不断改进 |
缺陷预防，技术变更管理，过程变更管理 |
5、CMM和CMMI的区别
cmmi：是不同cmm的集成，集成并发扬cmm得优点，并借鉴其他模型得优点融入新理论和实际研究成果，不仅能应用于软件领域，而且能应用于系统过程和其他过程领域
CMMI和CMM最大的不同：
CMMI1.1包含4个成分：系统工程(SE)、软件工程(SW)、应用集成产品和过程开发（IPPD）、供应商外包管理(SS)
CMMI有两种表示方法：阶段式、连续式；CMM只有阶段式
CMMI相对于CMM：
- 降低了复杂度和规模(RS)
- 扩大了模型覆盖度
- 加强了对工程过程的重视，强调度量
- 强调对需求的管理
- 加强了对风险的管理
- CMM中的“组间协调”在CMMI中作为”集成化项目管理”中的一个目标
- CMM中的KPA‘同行评审’在CMMI中抽象为KPA验证
- CMM是作为评估标准出现的，是‘必要’的才能保证评估的标准
- CMMI是作为改进模型出现的，罗列了较多的最佳实践，利于过程改进
相关文章：