ISTQB-CTFL学习笔记

基础测试过程包括：

• 测试计划和控制

• 测试分析和设计

  • 评审测试依据
  • 评估测试依据和测试对象的可测性
  • 基于对测试项、规格说明、软件行为和结构的分析，识别并确定测试条件优先级
  • 设计并确定概要测试用例的优先级
  • 设计测试环境的搭建、确定测试需要的基础设施和工具
  • 创建测试依据和测试用例间的双向可追溯性

• 测试实现和执行

  • 最终确定并实现测试用例，以及为测试用例设定优先级
  • 开发测试规程并确定优先级，创建测试数据，准备测试用具和编写自动化测试脚本
  • 为了有效的执行测试，根据测试规程创建测试套件
  • 验证正确的搭建了测试环境
  • 验证和更新测试依据和测试用例间的双向可追溯性
  • 根据计划的顺序，通过手工或使用测试执行工具来执行测试规程
  • 记录测试执行的结果，记录被测软件、测试工具、测试件的标识和版本
  • 将实际结果和预期结果进行比较
  • 将差异报告为事件，同时对他们进行分析以找到引起差异的原因
  • 针对每个偏差重复执行原来的测试活动

• 评估出口准则和报告

  • 根据测试计划中定义的出口准则检查测试日志
  • 评估是否需要进行更多的测试，或是否需要更改出口准则
  • 为利益相关者编写一份测试总结报告

• 测试结束活动

  • 检查哪些计划中的交付已经提交了
  • 关闭事件报告或为任何未关闭的事件报告提交变更记录
  • 记录对系统的验收
  • 最终确定和归档测试件、测试环境和基础测试设备，以便以后的重复使用
  • 移交测试件到维护部门
  • 分析经验教训，确定未来发布和项目中需要的改变
  • 利用收集的信息提高测试成熟度

软件开发模型

• V模型（顺序开发模型）：4个测试级别与4个开发级别相对应

  • 组件（单元）测试
  • 集成测试
  • 系统测试
  • 验收测试
• 迭代-增量开发模型：通过一系列短开发周期创建需求、设计、构建和测试系统的过程

• 生命周期模型中的测试，特点如下：

  • 每个开发活动都有对应的测试活动
  • 每个测试级别都有其对应的测试目标
  • 任何测试级别的测试分析与设计，都应随着相应开发活动中开始
  • 在开发生命周期中，测试人员应该文档初稿阶段就参与评审

测试级别：

• 每个测试级别都可以明确以下内容

  • 测试的总体目标
  • 识别测试用例可以参考的工作产品（测试依据）
  • 测试对象
  • 发现的典型缺陷和失效
  • 测试用具的需求和工具支持
  • 特定的方法和职责

• 组件测试

  • 测试依据

    • 组件需求
    • 详细设计
    • 代码

  • 典型的测试对象

    • 组件
    • 程序
    • 数据转换/迁移程序
    • 数据库模型

• 集成测试

  • 测试依据

    • 软件和系统设计
    • 架构
    • 工作流
    • 用例

  • 典型的测试对象

    • 子系统
    • 数据库的实现
    • 基础架构
    • 接口
    • 系统配置和配置数据

  • 根据不同的测试对象规模，集成测试可以有多个测试级别

    • 组件集成测试：完成组件测试之后开展，关注软件组件之间的交互
    • 系统集成测试：完成系统测试之后开展，关注不同系统之间，或软硬件之间的交互

• 系统测试

  • 测试依据

    • 系统和软件需求规格说明
    • 用例
    • 功能规格说明
    • 风险分析报告

  • 典型的测试对象

    • 系统、用户和操作手册
    • 系统配置和配置数据

• 验收测试

  • 测试依据

    • 用户需求
    • 系统需求
    • 用例
    • 商业流程
    • 风险分析报告

  • 典型的测试对象

    • 完整的集成系统上的商业流程
    • 操作和维护流程
    • 用户规程
    • 表单
    • 报告
    • 配置数据

  • 包括以下几种类型

    • 用户验收测试

    • 运行（验收）测试

      • 备份和恢复测试
      • 灾难恢复
      • 用户管理
      • 维护任务
      • 数据加载和迁移任务
      • 周期性的安全漏洞检查
    • 合同和法规验收测试
    • Alpha和Beta测试

测试类型

• 关注特定测试目标

  • 软件提供的功能
  • 非功能质量属性
  • 软件或系统结构或架构
  • 变更相关
• 功能测试
• 非功能测试（软件非功能属性测试）
• 结构测试（软件结构/架构测试）-白盒
• 与变更相关的测试（再测试和回归测试）

静态技术--评审过程

• 正式评审活动：

  • 1、计划

    • 定义评审标准
    • 选择评审相关人员
    • 分配角色
    • 为较为正式的评审定义入口和出口准则
    • 选择需要评审的文档的内容
    • 检查入口准则（针对较为正式的评审类型）

  • 2、开工会

    • 分发文档
    • 向参与者解释评审目标、流程和文档

  • 3、个人准备

    • 评审文档为评审会议做准备
    • 标注潜在的缺陷、问题和意见

  • 4、检查、评估、记录结果（评审会议）

    • 讨论或者记录，并记录为文档或者会议纪要（针对较为正式的评审类型）
    • 标注缺陷，为处理这些缺陷提供建议，针对这些缺陷做出决定
    • 检查/评估和记录在任何会议中讨论的问题，或者跟踪任何线上的群组交流

  • 5、返工

    • 修复发现的缺陷（通常由作者完成）
    • 记录更新后的缺陷的状态（针对较为正式的评审类型）

  • 6、跟踪

    • 检查缺陷是否得到处理
    • 收集度量数据
    • 检查出口准则（针对较为正式的评审类型）

• 正式评审包括的角色

  • 经理：决定评审的执行、在项目进度中分配时间，并判断是否达到了评审目标。
  • 主持人：主持文档或文档集评审的人，包括计划评审、主持会议以及会议以后的跟踪结果。如果需要的话，主持人可以对不同的观点进行调解。主持人经常是决定评审成功的关键。
  • 作者：被评审的文档（集）的编写者或者主要责任人
  • 评审员：具有特定的技术或者业务背景的人（也称为检查员或者审查员），在进行了必要的，准备之后，识别并描述针对被评审产品的发现（例如：缺陷）。在评审过程中，选择的评审员应该代表不同的观点和角色，并参加所有的评审会议
  • 记录员：记录会议期间识别的所有争论、问题和未解决的讨论

• 评审的角度

  • 基于用户、维护人员测试人员或操作人员的角度获取的检查表
  • 典型需求问题的检查表

• 评审的类型

  • 非正式评审

    • 没有正式的过程
    • 可以表现为结对编程或者技术负责人评审设计和代码的形式
    • 评审结果可以记录成文档
    • 不同的评审员起到的评审作用可能会不同
    • 主要目的：用低成本的方式获得收益

  • 走查

    • 由作者主持会议
    • 可以表现为场景、排练和同行集体参与的形式

    • 开放式的会话

      • 评审人员的会前准备是可选的
      • 包括发现问题列表的评审报告是可选的
    • 记录员（不是作者本人）是可选的
    • 实践中可以从非常不正式到非常正式
    • 主要目的：学习、获得理解、发现缺陷

  • 技术评审

    • 定义好的文档化的缺陷检测过程，包括同行和技术专家的参与，管理人员的参与是可选的
    • 可以是没有管理人员参与的同行评审
    • 理想情况下由培训过的主持人（不是作者）来主持
    • 评审员需要进行会前准备
    • 检查表的使用是可选的
    • 准备评审报告，报告包括发现问题列表、软件产品是否符合需求的判断以及针对发现的问题提出的建议
    • 实践中可以从非常不正式到非常正式
    • 主要目的：讨论、制定决策、评估可选方案、发现缺陷、解决技术问题、检查与规格、计划、法规和标准的符合程度

  • 审查

    • 由培训过的主持人（不是作者）来主持
    • 通常是同行检查
    • 对角色进行了定义
    • 包括了度量数据的收集
    • 基于规则和检查表的正式的过程
    • 针对软件产品的验收制定的具体的入口和出口准则
    • 会议之前的准备
    • 包括发现列表的审查报告
    • 正式的跟踪过程（过程改进部分是可选的）
    • 朗读者（可选）
    • 主要目的：发现缺陷

测试技术：黑盒、白盒

• --目的：为了识别测试条件、测试用例和测试数据

• 黑盒（基于规格说明的技术）

  • 特征：

    • 针对需要解决的问题、软件或其组件的规格说明使用正式或非正式的模型
    • 从这些模型中系统的生成测试用例
  • 等价类划分
  • 边界值分析
  • 决策表测试
  • 状态转换测试
  • 用例测试

• 白盒（基于结构的技术）

  • 特征

    • 根据软件的结构信息生成测试用例（例如：代码和详细的设计信息）
    • 可测量已有的测试用例对软件的覆盖程度，更进一步可以系统的生成测试用例以提高覆盖率
  • 语句测试和覆盖率
  • 判定测试与覆盖率

  • 其他基于结构的技术

    • 如条件覆盖、多条件组合覆盖

• 基于经验的技术

  • 特征

    • 根据参与人员的知识和经验生成测试用例
    • 测试人员、开发人员、用户和其他利益相关者对软件、软件的使用和它的环境等方面的知识是信息的来源之一
    • 关于可能存在的缺陷及其分布情况的知识是另外一个信息来源

  • 错误推测法（缺陷攻击）

    • 根据经验、已有的缺陷和失效数据以及有关软件失败的常见知识来构建缺陷和失效的列表

  • 探索性测试

    • 基于包含了测试目标的测试章程，同时在指定的时间段完成
    • 在规格说明较少或不完备且时间压力大的情况下使用更有意义
    • 作为其他更为正式的测试的补充
    • 可以作为对测试过程检查，以帮助确保大部分严重的缺陷都被发现了

测试组织

• 测试人员的典型任务

  • 评审并帮助测试计划的编写
  • 分析、评审和评估用户需求、规格说明和模型的可测试性
  • 创建测试规格说明
  • 搭建测试环境（通常需要与系统管理员和网络管理员协同完成）
  • 准备并获取测试数据
  • 所有测试级别上实现测试，执行并记录测试日志，评估测试结果，记录和预期结果之间的偏差
  • 根据需要使用测试管理工具和测试监视工具
  • 将测试自动化（可能需要开发人员或测试自动化专家的支持）
  • 度量组件和系统的性能（如果适用的话）
  • 评审其他人开发的测试

• 测试组长的典型任务

  • 与项目经理以及其他人协调测试策略和测试计划
  • 编写或评审项目的测试策略和组织的测试方针
  • 为其他项目活动提供测试的看法，例如：集成计划
  • 计划测试 – 考虑上下文，理解测试的目标和风险 - 包括选择测试方法、估算测试的时间、估算测试的工作量和成本、获取资源、定义测试级别和测试周期以及计划事件管理
  • 启动测试的规格说明、准备、实现和执行，监视测试结果并检查出口准则
  • 根据测试结果和进度（有时记录在状态报告中）调整测试计划，并采取必要措施解决问题
  • 建立适当的测试件的配置管理以保证可追溯性
  • 引入合适的度量以测量测试进度，评估测试和产品的质量
  • 决定什么应该自动化，自动化的程度，以及如何实现
  • 选择测试工具支持测试，并为测试人员培训测试工具的使用
  • 决定测试环境的实现
  • 根据测试时收集的信息编写测试总结报告

测试计划

• 测试计划活动包括

  • 确定测试的范围和风险，明确测试目标
  • 决定总体测试方法，包括测试级别、入口和出口准则的定义
  • 将测试活动与软件生命周期活动进行集成和协调（采购、供应、开发和运维）
  • 决定测试什么？测试活动由什么角色来执行？如何进行测试？如何评估测试结果？
  • 为测试分析和设计活动安排时间进度
  • 为测试实现、执行和评估安排时间进度
  • 为已定义的不同测试活动分配资源
  • 定义测试文档的数量、详细程度、结构和模板
  • 为监控测试准备和执行、缺陷解决和风险问题选择度量
  • 确定测试规程的详细程度，以提供足够的信息支持可重用的测试准备和执行

• 入口准则

  • 测试环境的可用和准备就绪
  • 测试环境中的测试工具准备就绪
  • 可测试的代码可用
  • 测试数据可用

• 出口准则

  • 完整性测量，例如：代码、功能或风险的覆盖率；
  • 对缺陷密度或可靠性度量的估算
  • 成本
  • 遗留风险，例如：未修复的缺陷或在某些领域测试覆盖不足
  • 进度，例如：基于交付到市场的时间

• 测试估算

  • 方法

    • 基于度量的方法：根据以前或相似项目的度量，或根据典型的数据来对测试工作量进行估算
    • 基于专家的方法：由任务的责任人或专家来对测试任务进行工作量的估算

  • 测试工作量依赖因素

    • 产品的特征：用于构建测试模型的规格说明和其它信息的质量（例如：测试依据），产品的规模，问题领域的复杂度，可靠性和安全性的需求，以及文档的需求
    • 开发过程的特征：组织的稳定性、使用的工具、测试流程、参与者的技能和时间压力
    • 测试的输出：缺陷的数量和需要返工的工作量

• 典型的测试方法

  • 分析的方法

    • 例如：基于风险的测试，其直接针对风险最高的区域进行测试

  • 基于模型的方法

    • 例如：利用失效率（如：可靠性增长模型）或使用率（如：运行概况）的统计信息进行随机测试

  • 系统的方法

    • 例如：基于失效的方法（包括错误推测和故障攻击），基于经验、基于检查表和基于质量特征的方法

  • 符合过程或标准的方法

    • 例如：那些在特定的工业标准中规定的方法或各种敏捷的方法

  • 动态和启发式的方法

    • 例如：探索性测试，其测试比预定义方法对事件有更好的反应，其中执行和评估是并行的任务

  • 咨询式的方法

    • 例如：测试覆盖率主要是根据测试团队以外的技术和/或业务领域专家的建议和指导来推动的

  • 可回归的方法

    • 例如：重用已有的测试材料，广泛的功能回归测试的自动化，测试套件的标准化

测试进度监控

• 测试度量

  • 测试用例准备工作完成的百分比（或按计划已准备的测试用例的百分比）
  • 测试环境准备工作完成的百分比
  • 测试用例执行度量（例如：执行/没有执行的测试用例数目、通过/失败的测试用例数目）
  • 缺陷信息度量（例如：缺陷密度、发现并修复的缺陷、失效率、再测试结果）
  • 需求、风险或代码的测试覆盖率
  • 测试人员对产品的主观信心
  • 测试里程碑的日期
  • 测试成本，包括寻找下个缺陷或执行下个测试用例所获得收益的比较
• 测试汇报

• 测试控制

  • 措施

    • 基于测试监视信息作出决策
    • 在已识别的风险确实发生时（例如：软件交付延期），重新确定测试优先级
    • 根据测试环境是否可用，更新测试的时间进度表
    • 设定入口准则，规定修复后的缺陷必须经过开发人员再测试（确认测试），才能将它们集成到版本中去

配置管理

• 作用

  • 所有测试件条目都被识别，版本受控，变更可跟踪，相互关联并且和开发项（测试对象）关联，从而在整个测试过程中维护可追溯性
  • 测试文档清楚的引用所有被标识的文档和软件项

项目风险

• 组织因素：

  • 技能、培训和人员的不足；
  • 个人问题；

  • 政治问题

    • 与测试人员沟通他们的需求和测试结果方面存在的问题
    • 团队没有对测试和评审中发现的缺陷信息进行跟踪（例如：没有改进开发和测试实践）
  • 对测试的态度或预期不合理（例如：不重视测试发现缺陷的价值）

• 技术问题：

  • 无法定义正确的需求
  • 在现有的限制条件下，没能达到需求的范围
  • 测试环境没有按时准备好
  • 数据转换、迁移计划、数据转换/迁移工具的开发和测试等的延期
  • 低质量的设计、代码、配置数据、测试数据和测试

• 供应商问题：

  • 第三方的失败
  • 合同方面的问题

“测试框架”的至少三种意思

• 用于构建测试工具的可重用和可扩展的测试库（也称为测试用具）
• 种测试自动化的设计（例如：数据驱动、关键字驱动）
• 测试执行的总体流程