9.1 系统测试原则
0. 测试的各个阶段和任务
软件缺陷的来源
软件缺陷可能存在于软件设计开发过程中的任何一个部分。其中：
(1)需求分析：不正确、遗漏或者不清晰的需求；
(2)系统设计：对需求设计的误读，不正确或不清晰的设计规格说明；
(3)程序设计：对系统设计的误读，不正确或不清晰的设计规格说明；
(4)程序实现：对程序设计的误读，不正确的文档，不正确的语法语义；
(5)单元/集成测试：不完全的测试过程，改正已有故障时引入新故障；
(6)系统测试：不完全的测试过程，改正已有故障时引入新故障；
(7)维护：需求变化，错误的用户文档，负面的人为因素，改正已有故障时引入新故障。
系统测试程序
process objectives 处理过程的各个目标
(1)功能测试——系统功能需求
(2)性能测试——其他软件需求
(3)验收测试——客户需求规格说明书
(4)安装测试——用户环境
build or integration plan 构造/集成计划
Configuration Management (SCM)(配置管理)
system configuration
交付给特定客户的一系列部件的集合
configuration managemen（配置管理）
对系统不同软件配置的管理及控制方法（既有开发，也有测试），通过控制系统差别以降低风险，减少错误。
确定配置管理(SCM)计划：
配置管理是整个开发过程中,用于管理软件产品内容的一系列措施.SCM流程旨在确保在任何时候产品的内容都是已知的、可用的，以及在设计到实施的过程中，产品的功能都是可跟踪的，可以完全控制和保护产品的内容。
使用配置管理计划的必要性：
- 如果不使用适当的配置管理计划，我们就经常无法知道哪一个模块是被确定、增强或测试过的。
- 我们会开发出功能错误或是缺少功能的产品来，而且我们不知道哪些测试正在进行，哪些缺陷已被确定。
- 我们不得不重新整理已经完成了的工作。
配置管理计划关键的功能：
每个产品元素（部件）版本的复件；
对每一个基线修改的记录；（修改内容的说明：修改位置，修改时间，修改内容等等）
基线：是指软件文档和其他资料的集合，它们代表了产品在某一时间点的情况(以及其他参考点)。
谁进行了这个改变；
他们什么时候改变的；(控制同时修改只能小规模有序进行)
改变具体内容是什么；
为什么他们要进行改变。
可能涉及的其他功能等等(从涉及的基本文档开始统计)。 (改动配置所进行的测试甚至可发现以前的问题)
技术支持经理负责草拟配置管理计划，并且和全组一起对它进行复核。
确定配置控制委员会和控制过程
确定任何所需的工具和设备。
和小组一起重申整个计划，并取得一致意见
软件配置管理的任务：
制定软件配置管理计划
确定配置标识规则
实施变更控制
报告配置状态
进行配置审核
进行版本管理和发行管理
versions and releases（版本和改进版本）
versions----a particular configuration for a system（针对特定系统的特定配置）
release----improved version/system（针对旧版本的改进版本）
regression testing（回归测试）
回归测试是用于新的版本或者改进版本的一种测试，以验证与旧版本或改进版本相比，他是否仍然以同样的方式执行同样的功能。
1. 回归测试
当现行系统被纠正/更改/更新时，识别出可能引入的新的缺陷，验证新版本/新发布跟老版本的功能一样
9.2 功能测试 Function Testing
目的：根据文档设计测试用例
Cause-and-Effect Graphs (因果图)
需求中的INPUT称为原因,OUTPUT称为结果.反映这种因果关系的布尔逻辑图称为因果图。
例：水位控制
9.3 性能测试 Performance Testing
several types of performance tests
A: stress tests（压力测试 / 强度测试）
(在短时间内加载极限负荷, 以验证系统能力)
B: volume tests（巨量数据测试 / 容量测试）
(验证系统处理巨量数据的能力)
C: configuration tests（配置测试） ---构建测试用例
对系统软硬件的各种配置(最小到最大)进行测试。
D: compatibility tests（兼容性测试）---测试接口等
E: regression tests (by old and new test cases) 回归测试
F: security tests ( security requirement ) 安全测试
G: timing tests 计时测试
H: environment tests 环境测试
I: quality tests 质量测试
J: recovery tests 维护测试
K: human factors test ( use interface-----usability) 人为因素测试/可使用性测试
//详情见ppt-zct
9.4 Reliability,Availability,Maintainability
（可靠性，可用性，可维护性） (关于性能测试)
reliability 可靠性：一个系统对于给定时间间隔内、、在给定条件下无失效运作的概率。(0~1)
availability 可用性：在给定的时间点上，一个系统能够按照规格说明正确运作的概率。(0/1)
maintainability 可维护性：在给定的使用条件下，在规定的时间间隔内，使用规定的过程和资源完成维护活动的概率。(0~1)
Failure data的不确定性
ppt算式错啦 除的应该是16：15+1
9.5 Acceptance Testing（确认/验收测试）
验收测试目的与职责：
验收测试的目的是使客户和用户能确定我们构建的系统真正满足了他们的需要和期望。
验收测试的编写、执行和评估都是由客户来进行的。只有在请求某个技术问题的答案的时候才会需要开发人员。
benchmark test（基准测试）
由用户准备典型测试用例，在实际安装后的系统运作并由用户对系统执行情况进行评估。
pilot test（引导测试）
在假设系统已经永久安装的前提下执行系统。它依赖系统的日常工作进行测试，相对基准测试不是非常的正式与结构化。
Parallel test（并行测试）
α测试：在向客户发布一个系统之前，先让来自自己组织机构或公司的用户来测试这个系统。在客户进行实际的试验性测试前先试验这个系统。
β测试：客户的试验称为β测试。
2. 几种测试分类
①pilot test先导测试：由用户准备典型测试用例，在实际安装后的系统运作并由用户对系统执行情况进行评估。
②α测试：软件开发公司组织内部成员模拟各类用户行为，对即将面世的产品（又称为α版本，或内部测试版本）进行测试，发现错误并纠正
③β测试：软件开发公司组织各方面的典型用户在日常工作中实际使用β版本或对外宣传将β版本免费赠送给典型用户，并要求用户报告异常情况、提出批评意见。
9.6 Installation Testing（安装测试）
安装测试定义：
在用户环境中配置系统，以测试可能因为开发环境与用户环境的不同而导致的问题
安装测试目的：
安装系统的完备性，验证任何可能受场所条件影响的功能和非功能特性。