第二章：软件生命周期中的测试
1. 软件开发模型：
V模型（顺序开发模型）；
迭代-增量开发模型：原型开发、快速应用开发、统一软件开发过程、敏捷开发模型等；
2. 每个测试级别都需要明确的内容：
测试的总体目标，
测试用例设置需要参考的产品（即测试的依据），
测试的对象，
发现的典型缺陷和失效，
对测试用具的需要，
测试工具的支持，
专门的方法和职责等。
3. 组件测试/单元测试
依据：组件需求说明、详细设计文档、代码。
典型测试对象：组件、程序、数据转换/移植程序、数据库模型。
桩、驱动器和模拟器：底层打桩，中间驱动，上层行为模拟
可能包括：功能测试、特定的非功能特征测试，如资源行为测试（如内存泄漏）、健壮性测试和结构测试（如分支覆盖）
4. 集成测试
依据：软件和系统设计文档、系统架构、工作流、用例；
典型测试对象：子系统、数据库实现、基础结构、接口、系统配置和配置数据。
5. 集成级别不同：
组件集成测试对不同的软件组织之间的相互作用进行测试，一般在组件测试之后进行；
系统集成测试对不同系统或软硬件之间的相互作用进行测试，一般在系统测试之后进行。
6. 系统测试：
依据：系统和软件需求规格说明、用例、功能规格说明、风险分析报告；
典型测试对象：系统、用户手册和操作手册，系统配置和配置数据。
通常由独立的团队进行。
7. 验收测试
依据：用户需求、系统需求、用例、业务流程、风险分析报告；
典型测试对象：基于完全集成系统的业务流程、操作与维护流程、用户处理过程、结构、报告、配置数据。
通常由使用系统的用户或客户来进行。
8. 验收测试的典型类型：
用户验收测试：由商业用户验证系统可用性；
操作（验收）测试：由系统管理员来进行，包括：系统备份/恢复测试、灾难恢复测试、用户管理测试、维护任务测试、数据加载和移植活动、安全漏洞阶段性检查；
合同和法规性验收测试：根据合同规定、根据必须遵守的法律法规进行测试；
Alpha和Beta测试：
alpha测试在开发组织现场进行，但由潜在用户测试；
beta测试或实地测试，在客户现场又客户执行；
也可称为工厂验收测试和现场验收测试。
9. 从测试的级别划分：
组件测试/单元测试、
集成测试、
系统测试、
验收测试
10. 根据特定的目标或测试原因：
功能测试：主要考虑软件的外部表现行为（黑盒）；可以包括：
安全性测试：系统和数据是否能抵御外部恶意威胁；
互操作性测试：与其他组件或系统交互能力的测试；
非功能测试：测试系统运行的表现如何；
包括但不限于：
性能测试
负载测试
压力测试
可用性测试
可维护性测试
可靠性测试
可移植性测试
11. 软件结构/架构测试（结构测试）：可以在任何测试级别使用；最好在进行基于规格说明测试之后使用，以便通过评估结构类型的覆盖来测量测试的完整性；
12. 确认：
当发现和修改了一个缺陷后，应进行再测试以确定已经成功的修改了原来的缺陷，称之为确认。
13. 维护测试
在现有的运行系统上进行，且一旦对软件或系统进行修改（功能增加、修正和应急变更、环境的变化（如升级、漏洞））、移植（平台迁移）或退役处理（数据移植、存档测试）时，就需要进行维护测试。
维护测试的范围取决于变更的风险、现有系统的规模和变更的大小。
第三章 静态技术
1. 静态测试技术：
通过手工检查（评审）或自动化分析（静态分析）的方式对代码或者其他的项目文档进行检查而不需要执行代码。
2. 评审：
更容易发现：与标准之间的偏差、需求内的错误（需求遗漏）、设计错误、可维护性不足和错误的接口规格说明等等。
3. 评审过程：
评审过程的正式性和以下因素有关：开发过程的成熟度、法律法规方面的要求或审核跟踪的需要。
评审的目标：发现缺陷、增加理解、培训测试员和团队新成员或对讨论和决定达成共识等。
4. 正式评审的阶段：
1）计划阶段：
定义评审标准，
选择人员，
分配角色，
为更加正式的评审类型（比如审查）制定入口和出口准则，
选择需要进行评审的文档内容，
核对入口准则（针对更正式的评审类型）。
2）预备会阶段：
分发文档，
向评审参与者解释评审的目标、过程和文档。
3）个人准备阶段：
先行评审文档，为评审会议做准备；
标注可能的缺陷、问题和建议。
4）检查/评价/记录结果（评审会议阶段）：
讨论和记录，并留下文档化的结果或会议纪要（针对更正式的评审类型）；
标注缺陷、提出处理缺陷的建议、对缺陷做出决策；
在任何形式的会议期间或跟踪任何类型的电子通信期间检查/评价和记录问题。
5）返工阶段：
修改发现的缺陷（通常由作者进行）；
记录缺陷跟踪的状态（在正式评审中）；
6）跟踪结果阶段：
检查缺陷是否已得到解决；
收集度量数据；
核对出口准则（针对更正式的评审）
|
