初级ISTQB笔记.docVIP

测试顺序：测试计划和控制、测试分析和设计、测试实现和执行、评估出口准则和报告、测试结束活动。 测试手段：静态测试、动态测试 测试目标：发现缺陷、增加对质量的信心、为决策提供信息、预防缺陷 独立测试可以应用于任何测试级别。 独立级别由低到高： 测试由软件本身编写的人员来执行 测试由一个其他开发人员（如来自同一个开发小组）来执行 测试由组织内的一个或多个其他小组成员（如独立的测试小组）或测试专家（如可用性或性能测试专家）来执行 测试由来自其他组织或其他公司的成员来执行（如测试外包或其他外部组织的鉴定） 软件开发模型 V模型（顺序开发模型） 相对开发的四种测试级别：组件/单元测试、集成测试、系统测试、验收测试 迭代-增量开发模型 生命周期模型中的测试应具备以下特点： 每个开发活动都有相应的测试活动 每个测试级别都有其特有的测试目标 对于每个测试级别，需要在相应的开发活动过程中进行相应的测试分析和设计 在开发生命周期中，测试员在文档初稿阶段就应该参与文档的评审 每个测试级别都需要明确的内容：测试的总体目标、测试用例设计需要参考的工作产品（及测试依据）、测试对象、发现的典型缺陷和失效、对测试用具的需求、测试工具的支持、专门的方法和职责。 测试级别 组件/单元测试 测试依据：组件需求说明、详细设计文档、代码 典型测试对象：组件、程序、数据转换/移植程序 集成测试 测试依据：软件和系统设计文档、系统架构、工作流、用例 典型测试对象：子系统、数据库实现、基础结构、接口、系统配置和配置数据 系统测试 测试依据：系统和软件需求规格说明、用例、功能规格说明、风险分析报告 典型测试对象：系统、用户手册和操作手册、系统配置和配置数据 系统测试可能包含基于不同方面的测试：基于风险评估的、基于需求规格说明的、基于业务过程的、基于用例的、基于其他对系统行为的更高级别描述或模型的、基于与操作系统的相互作用的、基于系统资源等的。 系统测试通常由独立的测试团队进行。 验收测试 测试依据：用户需求、系统需求、用例、业务流程、风险分析报告 典型测试对象：基于完全集成系统的业务流程、操作与维护流程、用户处理过程、结构、报告、配置数据。 验收测试通常由使用系统的用户后客户来进行，同时系统的其他利益相关者也可能参与其中。 测试类型 功能测试（黑盒测试） 安全测试时功能测试的一种。互操作性是另一种功能性测试，评估软件产品与其他一个或多个组件或系统交互的能力。 非公能测试 主要包括：性能测试、负载测试、压力测试、可用性测试、可维护性测试、可靠性测试、可移植性测试，非公能性测试就是测试系统运行的表现如何。 软件结构/架构测试（结构测试）（白盒测试） 最好在进行基于规格说明的测试之后使用，以便通过评估结构类型的覆盖来测量测试的完整性。 与变更相关的测试（再测试和回归测试） 维护测试 对软件或系统修改、移植、退役处理而进行的维护测试。 静态技术 评审、静态分析和动态测试具有共同的目标：识别缺陷。静态技术发现的是软件失效的原因（缺陷），而不是失效本身。通过评审更容易发现如下典型缺陷：与标准直接的偏差、需求内的错误、设计错误、可维护性不足和错误的接口规格说明等。 评审过程 正式评审的阶段：计划阶段、预备会阶段、个人准备阶段、检查/评价/记录结果（评审会议阶段）、返工阶段、跟踪结果阶段。 角色和职责 经理、主持人、作者、评审员、记录员。 评审类型 非正式评审（以较低的成本获得收益）； 走查（学习、增加理解、发现缺陷）； 技术评审(需要包含同行和技术专家，讨论、作决策、评估候选方案、返现缺陷、解决技术问题、检查与规格及标准的符合程度） 审查（通常是同行检查，引入了度量，主要目的是发现缺陷） 走查、技术评审和审查可以是在同行们-即由同一组织级别内的同事们内举行，这种评审类型称为同行评审。 静态分析的工具支持 静态分析的目的是发现软件源代码和软件模型中的缺陷。与评审一样，静态分析通常发现的是缺陷而不是失效。开发人员通常在组件测试和集成测试之前或期间，或当代码签入到配置管理工具时使用静态分析工具，设计人员在软件建模期间也使用静态分析工具。 测试设计技术 测试开发过程 测试分析阶段（对测试基础文档进行分析，明确测试什么。要建立测试条件到需求的可追溯性）； 测试设计阶段（要定义和记录测试用例和测试数据，预期的测试结果应该作为测试用例规格说明的一部分）； 测试实现阶段； 测试设计技术种类 使用测试设计技术的目的是为了识别测试条件和开发测试用例。 黑盒测试设计技术（也称为基于规格说明的测试技术）是依据分析测试基础文档来选择测试条件、测试用例或测试数据的技术；白盒测试设计技术（也称为结构化或基于结构的测试技术）是基于分析被测组件或系统的结构的测试技术。 基于规格说明的测试技术具有以下共同特点： ? 使用正