简析ISTQB考试大纲之二

2. 软件生命周期中的测试（K2）

2.1 软件开发模型（K2）

2.1.1 应用具体项目和产品类型的例子解释在开发生命周期中开发、测试活动与工作产品之间的关系（K2）

测试不是孤立存在的，测试活动与开发活动息息相关。在开发过程中生成的软件产品(业务场景、用例、需求规格说明、设计文档和代码)常常作为一种或多种测试级别的测试基础。

 

 

2.1.2 知道必须根据项目背景和产品特征来选择软件开发的模型（K1）

对于需求明确且很少变更的项目，如二次开发或升级型项目可以使用瀑布模型

对于需求经常变化的大型复杂系统，应采用螺旋模型

对于需求经常发生改变的软件开发，应采用增量模型

对于用户需求不明确的情况，应采用快速原型模型

对于事先不能完整定义产品的所有需求，计划多期开发的项目，应采用迭代模型

对于以用户需求胃动力，以对象为驱动的开发，应采用喷泉模型

对于侧重测试的软件开发，应采用V模型

 

2.1.3 理解在任何生命周期模型中良好的测试应具备的特征（K1）

良好的测试应具备的特曾：

每个开发活动都有相对应的测试活动；

每个测试级别都有其特有的测试目标；

对于每个测试级别，需要在相应的开发活动过程中进行响应的测试分析和设计；

在开发生命周期中，测试员在文档初稿阶段就应该参与文档的评审。

 

2.2 测试级别（K2）

2.2.1 比较不同测试级别之间的区别：测试的主要目的、典型的测试对象、典型的测试目标（功能性的或结构性的）、相关的工作产品、测试的人员、识别缺陷和失效的种类（K2）

组件测试/单元测试

测试的主要目的：验证单元是否满足了详细设计规格说明，发现需求和设计中的错误

典型的测试对象：组件，程序，数据转换/移植程序，数据库模型

相关的工作产品：组件需求说明，详细设计文档，代码

测试人员：通常是开发人员

缺陷和失效的种类：接口参数，数据结构，独立路径，控制流程，异常处理

 

集成测试

测试的主要目的：集成各个模块，测试数据能否正确传递和调用，能否正确的协同工作

典型的测试对象：子系统，数据库实现，基础结构，接口，系统配置和配置数据

相关的工作产品：软件和系统设计文档，系统架构，工作流，用例

测试人员：开发或测试

缺陷和失效的种类：数据传输，单元接收数据操作，单元间通讯，数据传输时间

 

系统测试

测试的主要目的：整个系统或产品是否满足规格说明书的需求，确定需求都完整，正确和和需求一致的实现

典型的测试对象：系统、用户手册和操作手册，系统配置和配置数据

相关的工作产品：系统和软件需求规格说明，用例，功能规格说明，风险分析报告

测试人员：测试

缺陷和失效的种类：压力，容量，性能，安全，容错等

 

验收测试

测试的主要目的：建立对系统，系统的某部分或特定的系统非功能特征建立信心

典型的测试对象：基于完全集成系统的业务流程，操作与维护流程，用户处理过程，结构，报告，配置数据

相关的工作产品：用户需求，系统需求，用例，业务流程，风险分析报告

测试人员：测试或使用者

缺陷和失效的种类：可用性，操作，合同法规，验收

 

 

2.3 测试类型（K2）

2.3.1 通过举例比较四种不同的软件测试类型（功能测试、非功能测试、结构测试和与变更相关的测试）（K2）

功能测试：处理文件；访问系统

非功能测试：处理非常大的文件；未授权的访问

结构测试：处理文件流程，访问系统的流程

与变更相关的测试：修复bug测试

 

2.3.2 明白功能测试和结构测试可以应用在任何测试级别（K1）

功能测试应用的测试级别：单元测试，集成测试，系统测试，验收测试

结构测试应用的测试级别：单元测试，集成测试，系统测试，验收测试

 

2.3.3 根据非功能需求来识别和描述非功能测试的类型。（K2）

非功能测试的类型

负载测试：增加系统负载来测量系统的行为(并发用户，事务数)

性能测试：测量特定用例的处理速度和响应时间，通常依赖于不断增加的负载。

容量测试：在大容量数据下系统行为的观察(处理非常大的文件)

压力测试：观察超负荷下系统的行为

安全性测试：针对未授权的访问，拒绝访问攻击等。

可靠性测试：在长时间运行中的测试(失效的平均时间或指定用户配置的失效率)

健壮性测试：测量在系统对于错误操作、错误编程、硬件故障的响应，以及检查系统异常处理和恢复的能力

兼容性测试：检查给定系统的兼容性，导入和导出数据，平台的兼容性测试

可用性测试：客户学习系统的容易性，操作的容易性和效率、系统输出的可理解性等[一般有特定的需求]

 

2.3.4 根据对软件系统结构或构架的分析来识别和描述测试的类型（K2）

结构测试也可称为白盒测试的类型

语句覆盖测试

判定覆盖测试

条件组合覆盖测试

判定/条件覆盖测试

路径覆盖测试等

 

2.3.5 描述确认测试和回归测试的目的（K2）

确认测试的目的：发现却先后，再测试以确定成功修改了原来的缺陷

回归测试的目的：确认缺陷已经成功修改，新增功能已经正确实现，系统变更没影响原来的功能和系统的运行

回归测试可以用在所有级别的测试上也适用于功能和非功能测试。

 

2.4 维护测试（K2）

2.4.1 比较维护测试（一个现存系统的测试）与一个新的应用软件的测试在测试类型、测试的触发和测试规模等方面的区别（K2）

测试主要是：需求分析，单元测试，集成测试，系统测试和验收测试

维护测试是：移植测试[转换测试]，数据的存档测试，已变更部分的基本测试和未变更部分的回归测试，变更影响分析

 

2.4.2 识别维护测试的原因（由于修改、移植或退役等因素）（K1）

修改：增加或减少或改变现有功能

移植：从一个平台一直到另一个平台，需要考虑两个平台的差异

退役：系统退役，应该进行数据移植的测试，和长期数据的存档的测试

 

2.4.3 描述回归测试和变更的影响分析在软件维护中的作用（K2）

回归测试可以对没有发生变更的其他部分进行很好的测试，保证未变更的和已变更的能很好的协同工作

变更的影响分析可以确定变更对现有系统产生了什么影响，可以确定实施回归测试的广度和深度。