软件测试基础理论

测试笔记

第一阶段 7

第一章 测试基础 7

1. 什么是软件测试： 7

2. ★软件测试的目的、意义：（怎么做好软件测试） 7

3.软件生命周期： 7

第二章 测试过程 8

1.测试模型 8

H模型： 8

V模型 9

2.内部测试 10

3外部测试： 10

验收测试：（在系统测试之后） 11

回归测试： 11

4.测试过程（干什么，怎么干） 12

5.各阶段输入、输出标准以及入口、出口准则:（测试阶段过程要素） 12

第三章 测试方法 14

测试方法对比 14

测试方法组合 16

第四章 软件质量 19

1.什么是软件质量 19

2.质量要素 19

3. 6大特性27个子特性ISO国际标准组织CMM/CMMI（Capability maturity model）能力程度度模型 19

4.CMMI把企业分为5个等级 22

5. CMM与CMMI的区别 23

第五章 SQL 24

约束： 29

1主键约束 29

2 非空约束 not null 30

3 外键约束 FOREIGN KEY 30

4 默认约束 31

5 检查约束 check 31

6 唯一约束 unique 32

SQL语句 32

创建数据库. 32

表、字段、类型 33

查询 35

批量处理？ 40

视图/虚表 view 41

索引 42

存储过程 procedure 42

事务 transaction 43

触发器 trigger 46

练习 46

一、单表查询练习 46

二、聚合函数练习 47

三、分组查询练习 47

四、嵌套查询练习 48

五、联接查询练习 48

六、外联接查询 48

七、补充提高 49

第六章 C语言 49

C语言中的存储 50

数据类型 50

常量 53

结构体 54

条件／分支逻辑 54

Switch 54

If 55

循环 55

For 55

while 56

do…while 56

函数 56

第七章 Windows环境搭建 59

一、名词注解与定义： 59

C/S 60

B/S 60

进销存系统 64

OA系统 69

第八章 需求管理 78

1．什么是需求 78

2． 需求工程在做什么 78

3． ★需求变更 78

4．★需求的跟踪 78

需求跟踪矩阵的作用： 78

需求的特点： 79

需求工程 79

变更控制流程图 82

第九章 缺陷管理 83

缺陷相关概念 83

缺陷管理相关概念 83

BUG管理基本流程： 84

BUG单 84

第十章 测试需求分析 86

概念： 86

★如何做测试需求分析 86

★UML统一建模语言（Unified Modeling Language） 86

第十一章 配置管理 88

1.什么是配置管理 88

2.配置管理流程 88

3.SVN实战 88

配置管理工具SVN操作过程手册 90

一、 如何创建“project”项目版本库 90

二、 如何查看创建的“project”项目版本库 95

三、 在版本浏览器里面，创建文件，并进行检出 99

四、 如何对该项目入基线 103

五、 分支文件进行合并 105

六、 分支冲突的解决 112

第十二章 系统测试 117

概念： 117

分类： 117

功能测试：（Function testing中国 Feature testing国际） 118

性能测试：（Sercarity testing） 118

安全性测试：（Security Testing） 118

安装测试 119

GUI测试（Graphical user interface） 120

可用性测试（Usability testing） 120

异常性测试 121

文档测试 121

备份测试 121

配置测试 121

网络测试 121

第十三章 用例设计 122

等价类 122

练习 122

1.1年龄注册 122

1.2.年龄注册 123

1.3.扩充 124

边界值 125

2.1.年龄 125

2.2.用户名注册 126

2.3.变量命名 127

2.4.进销存价格 127

2.5.Windows文件命名 127

总结 128

边界值 129

第十四章 系统测试执行 129

测试环境搭建文档： 130

用例执行： 130

填BUG报告： 130

第十五章 QC（Quality Center） 131

QC后台： 133

QC前台： 134

Requirements 需求模块

134

Test Plan 测试用例模块

135

Test Lab 测试执行模块

135

第十六章 PYTHON 137

Python的安装 137

Python的集成环境： 137

数据类型： 137

运算符： 137

缩进： 138

控制语句： 138

IF条件 138

WHILE循环 139

FOR循环 141

BREAK \ CONTINUE 141

函数 143

定义： 143

调用： 143

第十七章 单元测试 144

单元测试概念： 144

单元测试静态测试： 144

单元测试动态测试： 144

测试评价准则： 144

逻辑覆盖率 144

单元测试策略 145

⑴ 孤立测试 145

⑵自顶向下的单元测试策略 146

⑶自底向上的单元测试方法 147

单元测试用例设计（基本路径覆盖法）★ （面试） 148

程序控制流图 148

单元测试执行 150

单元测试框架 151

第十八章 集成测试 153

第一阶段总结 155

Test platform 155

Bug的其他说法 155

第二阶段项目笔记 156

一．建立项目JXC 156

二．布置JXC 156

三．配置SVN 157

四．访问SVN 157

进销存项目 158

2011年10月20日 158

进销存项目总结 160

测试需求分析 160

1、定义测试范围 160

2、建立需求项 160

3、细化需求项 162

4、需求覆盖率分析 164

课前复习： 164

判定表 166

3.1.读书选择 166

3.2.Counter 168

3.3：word中的判定表举例 169

3.4.合并判定表 170

3.4.密码修改 171

3.5.进销存 173

3.6.总结 175

因果图 176

4.1.字母判定 177

4.2.自动售货机 179

课前复习： 180

状态迁移 181

5.1.飞机售票系统 181

5.2.缺陷跟踪 183

流程分析 184

6.1.处理流程 185

6.2.系统登录 186

6.3.字母判断 187

6.4.组合查询 188

课前复习 191

正交试验 192

7.1.环境搭建 192

7.2.Counter 193

7.3.组合 193

7.4.环境搭建 195

其他 196

输入域 196

输出域 196

异常分析 196

错误猜测 196

第一阶段

第一章测试基础

1. 什么是软件测试：

两个依据（需求、测试用例），两个方法（手工、自动），一个对比（预期结果和实际结果的对比）

2. ★软件测试的目的、意义：（怎么做好软件测试）

初期：尽量多的发现缺陷生成相关规范

中期：尽量早的发现缺陷

后期：尽量预防问题：通过以往的经验积累

控制成本（贯穿始终）尽量少的时间和人力发现更多的缺陷

3.软件生命周期：

就个人价值而言,一是给我们职业发展方向

如何尽量多的发现缺陷?

沟通

在测试前期与开发沟通确认测试重点 确认测试的优先级

了解开发人员技术和业务背景 业务水平 技术水平 代码质量 人员流动性

在测试结束后

对已发现的bug进行统计 知道高发概率bug 在新项目中要进行重点测试

针对代码 代码复杂度

版本管理

针对基础测试基础版本要进行充分的测试

验收前的最后一个版本一定要进行完全重复测试

测试方法

黑盒方法 功能问题 无法保证所有的代码逻辑都被执行到 用白盒测试思想补充黑盒测试

静态测试方法 文档评审 代码走查

测试过程

上一阶段为下个阶段提供重点指导

用户参与的测试或用户反映回来的错误和问题为下次测试的或测试补充的必备内容

第二章测试过程

1.测试模型

H模型：

H模型图

优点：

1 介入早 与开发并行 更早的发现问题

2 测试过程独立于开发过程 更客观 更主动

V模型

双V模型图

㈠需求阶段

产品经理，项目经理，产品工程师写《需求规格说明书》Software Reqwirment Specaficalion(SRS)

内容：需求项（业务，主要功能）需求子项，对子项的详细描述

测试的工作：对需求进行测试和评审A系统测试计划《系统测试计划书》B系统测试计划《系统测试方案书》C系统测试实现《系统测试用例》

㈡设计阶段

开发经理，架构师，开发工程师写出《概要设计说明书》High-level design(HLD)

内容：系统程序中的模块，子模块和他们之间的关系和接口

测试的工作：对HLD进行测试和评审A集成测试计划《集成测试计划书》B集成测试设计《集成测试方案书》C集成测试实现《集成测试用例》

㈢详细设计阶段

开发工程师，架构师，写出《详细设计说明书》Low-level desragn(LLD)

内容：函数代码逻辑

测试工作：对LLD进行测试和评审A单元测试计划《单元测试计划书》B单元测试设计《单元测试方案书》C《单元测试用例》

㈣编码阶段

开发工程师写代码

优点：介入早，提高测试质量；分成三个阶段，发现问题更有针对性；测试与开发并行，更好的利用项目资源。

缺点：项目成本高；技术要求高，对人员要求高；并行工作中，一方未完成就会对整个造成延误。

适用范围：规模大、软件成熟度高的项目。

2.内部测试

测试阶段	测试对象	测试方法	测试目的	经济价值	优点	缺点	必要性	资源
系统测试 system testing（ST）	整个系统 （整个产品）	黑盒测试	验证产品是否符合需求规格说明书	能够保证产品以较高的的质量尽早的上市销售，从而使公司获取利润	1简单 2技术要求低	1测试介入时间晚，修改成本高 2有一些问题可能被遗留不会被修改	必须保证	1对被测产品 2需求规格说明书 3系统测试工程师 4需求开发人员
集成测试 integration testing（IT）	模块 子模块 接口	灰盒测试	验证模块、子模块、接口是否符合 概要设计说明书	能够帮助更准确的定位缺陷的所在，从而降低了定位缺陷的成本	定位准确快速	1接口测试有技术要求，技术实现难度大 2接口太多，数量庞大，做所有接口的集成测试成本高	不是必须做的， 必须做测试的 1公共的主要模块 2核心模块 3和外界软件接口模块	1被测的产品 2概要设计说明书 3集成测试工程师 4概要设计人员
单元测试 unit testing(UT)	函数 代码 逻辑	白盒测试	验证函数代码逻辑是否符合详细设计说明书	能够最早的开展测试工作，降低修复成本，防止缺钱被扩大化（注意：加以重视：1公共的模块2全局性的数据结构3重要的使用频率较高的功能4以往项目经常出错的严重问题5复杂度较高的模块6当开发人员业务不熟悉编码不熟练的模块要进行单元测试）	介入时间早，发现问题早，修改成本低。	1技术难度高 2工作量太大	不是必须的	1开发环境 2LLD 3单元测试工程师 4架构师（详细设计人员）

3外部测试：

使用验收测试的原因

1内部测试只能模拟用户使用却不能代替用户使用

2由于专业不同业务背景不同无法模拟用户使用的习惯

3测试人员和用户对产品的理解可能不同

验收测试：（在系统测试之后）

α测试：由用户组织一部分人在开发环境下来对产品进行测试 如网游的内侧

β测试：所有系统使用者都可以参加的测试(在实际使用环境下) 如网游的公测

分类	测试过程	参与人员	目的	过程主要内容
针对项目类软件	验收测试	开发人员：提供满足验收要求的软件或系统，或用户需要的相关开发文档 测试人员： 1、搭建验收测试环境 2、准备验收测试用例 3、准备用户需要的相关测试文档 4、组织人员进行验收演示 用户代表：对系统进行一定的试用 客户代表：签字确认验收是否通过 行业：负责在验收过程中提出问题并协助用户和客户检查系统是否满足需求	1、检查软件的功能是否与用户最初需求相一致 2、是客户回款的标志	1、进行验收前准备 A、准备相关的资料 B、搭建验收测试环境 C、指定相关的验收参与人 2、进行验收演示 A 、对产品使用进行演示 B、回答专家、用户的提问 3、签署验收报告
针对产品类软件	α测试	开发人员： 1、提供可以进行α测试的软件 2、负责修改用户代表发现的问题 测试人员： 1、检查或协助用户填写缺陷报告 2、向用户学习相关的使用关注点 邀请的用户或客户代表（付费） 1、按照自己的操作习惯使用软件，提出易用性等方面的问题和改进建议	明确用户的使用体验，提高产品的适用范围和使用质量标准	1、明确进行α测试的版本 2、邀请潜在用户进行使用体验 3、针对用户提出的问题进行修复或改进
	β测试	潜在用户： 1、安装软件并使用 客服人员： 记录并反馈用户的问题	提前占领市场	1、发布一个下载地址 2、用户进行软件下载并使用

回归测试：

回归测试可以发生在任何一个阶段

分为完全回归和选择回归

回归范围	回归分类	特点	优点	缺点	适用范围
完全回归	完全重复法	每次回归测试都要执行全部测试用例	回归测试充分，覆盖面广，不容遗漏	工作量大，时间长，成本高	时间充裕且测试资源较充分时，第一次和最后一次做回归测试的时候用这种方法
选择性回归	覆盖修改法	每次回归测试时只执行发现错误的用例	时间最短，成本最低，简单效率高	回归测试不充分，漏洞较多	时间较紧且人力资源不足时，中间版本的测试轮次可以使用，关联度比较小的模块和功能
	周边影响法	每次回归除了执行发现bug的用例外，还要执行与其相关的用例	在考虑了测试成本的基础上有效提高了回归测试的质量效率	很难确定影响的周边范围，相关用例定位较困难	适合于全局数据结构被修改或公共模块被修改，或核心算法业务被修改时，公用的模块，关系、关联复杂的模块
	指标达成法	每次回归测试达到规定的语气指标 就可以停止测试了	所有的测试都可度量	1指标生成需要很长的周期， 很多的项目区累计经验 2要有比较稳定的团队这个指标才有意义	成熟度较高的测试团队应用于指标达成法 （适用度很低，很少有公司使用）

	分类	步骤	优点
确定周边 范围的方法	界面检查法	1明确被修改的功能	简单
		2修改功能的上下游功能
		3调用修改功能的功能和 修改功能调用了的功能
		4和修改功能游相同输入输出的功能
		5在测试中执行上诉关联的用例
	代码检查法	1明确被修改的函数和代码	准确，全面
		2在整个系统中检查所有 调用了修改函数的函数
		3明确上诉所有函数对应的界面
		4测试上诉界面测试用例

4.测试过程（干什么，怎么干）

整个系统的内容	需求项（业务、主要功能）	需求项	测试计划	测试需求项	系统测试阶段
		需求子项	测试方案	测试需求子项
		详细内容	测试用例	具体如何进行测试
整个系统的集成	概要设计	概要设计项	测试计划		集成测试阶段
		概要设计子项	测试方案
		具体内容	测试用例
整个系统最小单元	详细设计	函数	测试计划		单元测试
		逻辑	测试方案
		代码	测试用例

5.各阶段输入、输出标准以及入口、出口准则:（测试阶段过程要素）

系统测试	入口准则	输入文档	输出文档	出口准则
系统测试计划	开发计划通过评审并入基线 需求规格说明书通过评审并入基线	开发计划书 需求规格说明书	系统测试计划书	系统测试计划书通过评审并入基线
系统测试设计	系统测试计划书通过评审并入基线	需求规格说明书 开发计划书 系统测试计划书	系统测试方案书	系统测试方案书通过评审并入基线
系统测试实现	系统测试方案书通过评审并入基线	需求规格说明书 系统测试计划书 系统测试方案书	系统测试用例 预测试项	系统测试用例、预测试项通过评审并入基线
系统测试执行	系统测试用例、预测试项通过评审并入基线 集成测试报告通过评审并入基线	需求规格说明书 系统测试计划书 系统测试方案书 系统测试用例 预测试项	缺陷报告 预测试项报告 系统测试报告	系统测试报告、预测试项报告、缺陷报告通过评审并入基线
集成测试	入口准则	输入文档	输出文档	出口准则
集成测试计划	概要设计说明书通过评审并入基线	概要设计说明书	集成测试计划书	集成测试计划书通过评审并入基线
集成测试设计	集成测试计划书通过评审并入基线	集成测试计划书 概要设计说明书	集成测试方案书	集成测试方案书通过评审并入基线
集成测试实现	集成测试方案书通过评审并入基线	集成测试计划书 集成测试方案书 概要设计说明书	集成测试用例	集成测试用例通过评审并入基线
集成测试执行	集成测试用例通过评审并入基线 单元测试报告通过评审并入基线	集成测试计划书 集成测试方案书 集成测试用例 概要设计说明书	集成测试报告 缺陷报告	集成测试报告、缺陷报告通过评审并入基线
单元测试	入口准则	输入文档	输出文档	出口准则
单元测试计划	详细设计说明书通过评审并入基线	详细设计说明书	单元测试计划	单元测试计划通过评审并入基线
单元测试设计	单元测试计划通过评审并入基线	详细设计说明书 单元测试计划书	单元测试方案书	单元测试方案书通过评审并入基线
单元测试实现	单元测试方案书通过评审并入基线	详细设计说明书 单元测试计划书 单元测试方案书	单元测试用例	单元测试用例通过评审并入基线
单元测试执行	单元测试用例通过评审并入基线	详细设计说明书 单元测试计划书 单元测试方案书 单元测试用例	单元测试报告 缺陷报告	单元测试报告、缺陷报告通过评审并入基线

第三章测试方法

测试方法对比

分类方法	测试方法名称	依据	测试对象	理论上的测试目的	实际工作中的测试目的	测试评估标准	测试环境	测试工作介入点	优点	缺点	适用范围
按照不同的测试对象划分（黑白灰盒的区别）	黑盒	SRS	整个软件产品	检查软件的功能实现是否与SRS相一致	尽早进行验收，收回开发成本	需求覆盖率	尽量与用户环境相一致	只要功能可以进行操作	简单，测试效率高	1、无法保证所有的代码逻辑都被测试到 2、后台相关的非界面处理可能会遗漏（文件、数据库） 3、当前功能与其他功能有联系的部分可能也会被遗漏	适合进行功能、性能等使用和外部特性的测试适用范围广泛，适用所有可见功能
	白盒	LLD	代码逻辑函数	检查代码的逻辑实现是否与LLD相一致	尽早发现问题缺陷，降低缺陷修复成本.便于定位问题	逻辑覆盖率 语句覆盖 分支覆盖 条件覆盖 分支-条件覆盖 路径覆盖	开发环境	只要独立的函数或类代码编写完成后	覆盖充分，可以覆盖到每行代码	技术较难 效率较低 成本较高	针对核心业务、复杂算法、公共模块、全局数据结构、新增功能
	灰盒	HLD	模块\子模块接口	检查接口实现是否与HLD相一致	逐步集成，降低缺陷定位成本	接口覆盖率	子系统集成尽可能和用户环境一致,模块内部接口以及模块间接口可以在开发环境下进行 子系统间的接口最后要在与用户环境下测试	进行测试的接口模块已完成	可以提早定位和发现问题	技术最难 成本最高	公共模块之间的调用，复杂度较高的模块调用、使用频率较高的模块调用

		特点	分类	优点	缺点	适用范围
按照是否运行程序划分	静态	不执行程序	1、文档评审 A、正规检视 B、技术评审 C、同行评审 2、静态分析技术 A、控制流分析 可以发现以下缺陷 1、死循环 2、执行不到的语句 3、不存在的语句 B、数据流分析 可以发现以下缺陷 1、变量未定义被使用 2、变量已定义未使用 C、信息流分析 可以帮助开发人员定位缺陷 1、输入变量与语句的关系 2、输出变量与语句的关系 3、输入变量与输出变量的关系	较动态测试时间早,不用写代码	工作量大	重要的功能模块、核心的业务、算法 公共模块
	动态	执行程序	黑和测试 动态白盒：插装—在代码中加入print打印语句，检查程序的中间运行结果	复杂，效率高	测试较晚,写代码	所有功能

		优点	缺点	适用范围
按照不同的测试手段划分	手工	能够主动的发现bug	重复工作量大，容易引入疲劳缺陷,只能依靠见到的界面	绝大多数的场合
	自动化	可以无限制不断重复,把人从劳动里解放出来，提高劳动效率，提高了测试质量，能发现人不能发现的错误	无法发现脚本中未写明的缺陷	GUI界面稳定 回归阶段 需求稳定且功能已实现时才进行脚本的编写 性能测试工具：提取相关的系统数据，构造并发用户

测试方法组合

测试方法组合			典型案例		使用时机	特点
黑盒
黑盒静态手工
黑盒静态自动化
黑盒动态手工
黑盒动态自动化功能测试	Mercury的QTP：用于检测应用程序是否能够达到预期的功能及正常运行			通过自动录制、检测和回放用户的应用操作			1、能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试 2、提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行
	IBM Rational Robot 是功能测试工具						它集成在测试人员的桌面IBM Rational TestManager 上，在这里测试人员可以计划、组织、执行、管理和报告所有测试活动，包括手动测试报告。这种测试和管理的双重功能是自动化测试的理想开始。
	Borland SilkTest属于软件功能测试工具						是Borland公司所提出软件质量管理解决方案的套件之一。这个工具采用精灵设定与自动化执行测试，无论是程序设计新手或资深的专家都能快速建立功能测试，并分析功能错误。
基于Java语言的功能和性能测试工具	JMeter是Apache组织的开放源代码项目			主要针对Java语言			它是功能和性能测试的工具，100%的用java实现
黑盒动态自动化性能测试	Mercury的LoadRunner：是一种预测系统行为和性能的负载测试工具。			通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题			能够对整个企业架构进行测试。通过使用LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。
	Microsoft Web Application Stress Tool 是由微软的网站测试人员所开发，专门用来进行实际网站压力测试的一套工具。			功能强大的压力测试工具			您可以使用少量的Client端计算机仿真大量用户上线对网站服务所可能造成的影响
	webload是RadView公司推出的一个性能测试和分析工具			它让web应用程序开发者自动执行压力测试；			webload通过模拟真实用户的操作，生成压力负载来测试web的性能。
白盒
白盒静态手工
白盒静态自动化				检查语法规范、语法逻辑
白盒动态手工		目前的最流行的单元测试工具是xUnit系列框架		常用的根据语言不同分为JUnit（java），CppUnit（C++），DUnit（Delphi ），NUnit（.net），PhpUnit（Php ）等等。			该测试框架的第一个和最杰出的应用就是由Erich Gamma （《设计模式》的作者）和Kent Beck（XP（Extreme Programming）的创始人 ）提供的开放源代码的JUnit。
白盒动态自动化		Jtest是parasoft公司推出的一款针对java语言的自动化白盒测试工具，它通过自动实现java的单元测试和代码标准校验，来提高代码的可靠性。parasoft同时出品的还有C++ test，是一款C/C++白盒测试工具
灰盒
灰盒静态手工
灰盒静态自动化
灰盒动态手工
灰盒动态自动化			BMC的APPSight		系统会将问题发生的相关信息完整录制下来，包括问题发生的现场场景、信息及分析等，从而快速切入到问题根源
测试管理工具			是业界第一个基于Web的测试管理系统，它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分，包括需求管理，测试计划，测试执行以及错误跟踪等功能，TestDirector极大地加速了测试过程。

1自动化测试就是用程序驱动程序的测试

2黑白灰测试的区别

测试的对象不一样，对于代码实现逻辑程度不一样（黑盒不需要了解代码实现，白盒需要完全了解代码实现，灰盒需要部分了解代码实现）

3静态与动态测试的区别

被测程序执行与否静态不执行程序包括文档评审静态分析技术代码走读，动态包括黑盒测试和动态分析技术

4自动化合手工测试的不同

测试手段不同

第四章软件质量

1.什么是软件质量

质量：确定一个实体的特性满足需求的程度

内部质量：软件研发过程中，评价的软件质量

外部质量：软件上市后，用户评价的质量

过程质量：评价软件研发中每个过程的质量

软件质量的三个层次

⑴流程质量，领导关注 ⑵产品质量 测试工程师关注 ⑶使用质量 用户关注

2.质量要素

质量铁三角 ：技术过程组织

3. 6大特性27个子特性ISO国际标准组织CMM/CMMI（Capability maturity model）能力程度度模型

质量模型列表
质量模型特性	子特性	特点	常见测试点	案例说明
功能性	适合性	合适的功能（用户提出要有哪些功能）功能的必要性	验证功能是否满足需求的要求，检测做没做	打电话、听音乐、发信息
	准确性	正确的功能	需求文档中的预期动作和预期输出，做对没有	信息的发送内容是否正确
	互操作性	和其他软件的互相操作	第三方软件的交互	word文档对打印机驱动程序的操作
	保密安全性	保护信息和数据	保护得到授权的人或者系统能正常访问相关的信息或数据	1、登录的用户名和密码 2、权限使用 3、防止DOS攻击（拒绝访问攻击）4、系统数据的保护和加密，如密码的加密 5、传输加密，如密码的网络传输 6、防病毒 7、放溢出，如char与varchar的字符数
			保证未授权的人或系统无法看到相关的信息或数据
	功能性的依从性	遵循功能性相关的标准、约定或法规	是否符合国家法律规定	如色情网站
可靠性	成熟性	缺陷尽可能的少
	容错性	提前考察的异常情况出错问题	整个系统的外部接口	如word打印时，打印机死机出现报错，但不影响word的使用
	易恢复性	失效后恢复原有功能、性能	系统的性能测试	如网游延迟卡死现象。系统提示内存不足。银行系统的心跳监听。灾难备份。
	可靠性的依从性	法律法规		灾难备份。
易用性(CUI测试)	易理解性（快速理解）	系统交互的信息是否准确、清晰、易懂，指导下一步操作。	系统提示信息是否准确	如网银密码超出位数报错
	易学性 （快速上手）	易用好学	是否有说明书、是否在线帮助、是否有提示信息	msn的帮助手册
	易操作性 （快速做完）	方便快速使用	操作的直观程度，操作步骤、操作动作多少与时间长短	鼠标、gui层数、安装过程
	易测试性	软件可控	提供工具给测试工程师，可以控制系统运行，以达到测试目的	windows的性能工具与服务管理工具
		软件可观察	通过辅助手段可
	吸引性	外观	外观
	易用性的依从性	法律法规
可移植性	适应性（跨平台、跨语言）	软件产品无需采用有别于为考虑该软件的目的而准备的活动或手段就可能适应不同的指定环境的能力;是否适应其他系统环境	软件、硬件、外设、数据库	微软与苹果的前期竞争。主板与CPU
	易安装性	在指定环境中是否易于安装	主流平台和系统100%测试用例，非主流10%	flash安装
	共存性	不同的其他系统能共同运行	1、功能是否能正常运行满足要求 2、系统性能能满足要求	是否会抢占资源。迅雷和pplive抢占资源。杀毒软件，瑞星和金山不能共存
	易替换性	替代为其他相同功能的产品的能力	升级过后的系统是否会造成系统崩溃	软件升级补丁升级
	可移植性的依从性	法律法规
效率-性能	时间效率	规定条件下，软件产品执行其功能时，提供适当的响应和处理时间以及吞吐率的能力	系统的反应时间	提款机取款时间的快慢
	资源效率	在规定条件下，软件产品执行其功能时，使用合适的资源数量和类别的能力	做一件事所占用的系统资源	电器所消耗的电能多少
	效率依从性	法律法规
维护性-维护的难易程度与成本	易分析性	软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力	辅助工具或者日志文件或者常用问题帮助手册	qq异常退出的帮助文件
	易改变性	代码容易被修复或修改	高内聚，低耦合
	稳定性	软件产品避免由于软件修改而造成意外结果的能力	长期的监控一个系统的运行情况和系统的资源情况	淘宝的系统监控
	维护性的依从性	法律法规

配置管理