ISTQB系列之：ISTQB概述和CTFL知识总结（一）
7月份考过ISTQB FL后，一直想总结一下它的知识体系，今天打算完成这件事情。
写作大纲如下：
- ISTQB概况
- ISTQB CTFL的知识体系
- 软件测试基础
- 软件生命周期中的测试
- 静态技术
- 测试设计技术
- 测试管理
- 软件测试工具
- 总结
一、ISTQB概况
ISTQB，全称International Software Testing Qualification Board。其培训和认证体系分为三个级别：
- 基础级Foundation Level （CTFL）：6个月软件测试或开发工作经验可报考
- 高级Advanced Level （CTAL）：完成CTFL + 3年以上测试工作经验可以报考，共三个考试模块 测试管理、测试分析、技术测试分析
- 专家级Expert Level （CTEL）：完成CTAL + 5年以上测试工作经验可以报考，共四个考试模块 测试过程改进、测试管理、测试自动化、安全性测试
目前只能报考前两个级别的考试。
二、ISTQB CTFL的知识体系
从ISTQB整个认证体系的结构大概就能够看出软件测试所涉及的知识域（包括广度和深度），因此对于从事软件测试工作的我们来说，对于完善自身的知识体系和职业发展来看，都有很高的参考价值。里面包含的内容但凡从事软件测试的人，大概都会听说过，实际工作中碰到的问题，里面很多也都给出了一些实践建议。体系的好处，就是能够给人一个系统化的、全局的视角，将自己实际从事的工作和掌握的知识与之对比，找到自己目前处在什么水平和不足，接下来的努力方向在哪里，帮助我们少走弯路。
关于CTFL，一共有六个部分：
- 软件测试基础
- 软件生命周期中的测试
- 静态技术
- 测试设计技术
- 测试管理
- 软件测试工具
关于CTAL和CTEL，由于我还没有考，计划明年考完之后再补上那部分的知识总结
三、软件测试基础
1.错误（Error, Mistake）、缺陷（Defect, Bug, Fault）和失效（Failure）
- 错误：人为原因导致的一个不正确的结果，包括人的思维错误和行为错误。侧重于人为因素（这里有个假定：人都会犯错）。
- 缺陷：错误的具体表现。由人设计的代码或文档出现错误后就会引入缺陷。侧重于错误的内在表现，即错误产生的直接原因，也是Developer做bug fix要定位的地方
- 失效：缺陷的外部反映，程序运行过程中由于代码的缺陷导致一个不正确的结果（期望与实际不一致）。侧重于缺陷的外部反映，是Tester工作中要发现的bug
总结一句话：人犯错导致程序缺陷，Tester通过测试活动发现缺陷提交bug，Developer根据bug定位并修复缺陷改正错误。测试的本质就是发现缺陷
2.软件测试的总体目标
软件开发是有生命周期的，在生命周期中不同的阶段，测试会有不同的目标：
- 早期：预防缺陷 Preventing defects（静态测试）
- 开发阶段：发现缺陷 Finding defects（组件测试、集成测试、系统测试）
- 验收：建立信心 Gaining confidence about the level of quality（验收测试）
- 运行阶段：提供信息 Providing information for decision-making（非功能测试、维护测试）
3.软件测试的7个基本原则
- Testing shows presence of defects 测试可以显示存在缺陷，但不能证明系统没有缺陷
- 要让领导对测试有一个正确的期望
- Exhaustive testing is impossible 穷尽测试不可行
- 实际工作中根据风险分析和不同系统功能的优先级，来确定测试的关注点
- Early testing 测试尽早介入
- 越早发现缺陷成本越低
- 需求阶段测试就可以介入
- Defect clustering 缺陷的集群性
- 少数模块发现大部分缺陷，80/20法则
- 对发现缺陷的地方进行重点测试，尤其是缺陷集中的地方要增加测试覆盖
- Pesticide paradox 杀虫剂悖论
- 采用同样的测试用例多次重复进行测试，最后将不再能发现新的缺陷
- 启示：对测试用例要进行定期评审和修改，同时不断增加新的不同的测试用例
- Testing is context dependent 测试活动依赖于测试背景
- 针对不同的测试背景，进行不同的测试活动
- 根据测试的环境和目标实施不同类型的测试，如安全测试、性能测试、压力测试等
- Absence-of-errors fallacy 不存在缺陷的谬误
- 若系统无法使用，或系统不能满足客户的需求，发现和修复缺陷没有任何意义
- 在进行测试之前，先确保系统可用
4.基本的测试过程
基本的测试过程主要由以下活动组成：
- 测试计划和控制
- 测试分析和设计
- 测试实现和执行
- 评估出口准则和报告
- 测试结束活动
4.1测试计划和控制
测试计划：1）识别测试任务。2）定义测试目标。3）为实现目标和任务确定测试活动。一般测试计划开始于软件需求分析结束阶段
测试控制：持续进行的活动，通过对测试实际进度和测试计划的对比，报告测试的状态，根据需要采取纠正措施或更改原计划
产出：测试计划、日常测试报告
4.2测试分析和设计
将概括的测试目标转化为具体的测试条件（即测试项）和测试用例的一系列活动：
- 评审测试依据（比如需求分析、系统架构、设计、接口说明等文档）
- 评估测试依据和测试对象的可测性
- 识别测试条件并确定优先级
- 确定测试数据
- 确定测试所需的基础设施和工具（测试环境）
- 创建测试依据和测试用例间的双向可追溯性
产出：确定测试条件、测试数据、测试环境、测试条件和需求的映射，只需大方向上的东西，不用具体实现
4.3测试实现和执行
主要包括：测试规程和脚本的设计、测试环境搭建、运行测试（即实现、准备、执行）
实现包括：
- Test Case：开发测试用例并确定其优先级，识别测试数据
- Test Procedure：开发测试规程（即，一组测试用例）并确定其优先级，创建测试数据。（可选，准备测试框架，开发自动化测试脚本）
- Test Suites：根据测试规程创建测试套件
准备包括：
- Test Environment：搭建测试环境（服务器的搭建、客户端环境的搭建、测试辅助（测试用例、bug等）管理环境的搭建、自动化测试环境搭建）
- 确认并更新测试依据和测试用例间的双向可追溯性。（测试用例对于测试需求的覆盖，多对一，可通过工具进行映射）
执行包括：
- 执行测试规程（跑case，手工或自动）
- 记录测试执行的结果（手工测试通过工具在跑case的时候进行记录passed或者failed，自动化测试的测试报告会自动记录测试执行结果）
- 对比实际结果和期望结果
- 对于实际结果和期望结果不一致的，作为事件上报，并分析确定引起差异的原因（分析问题，报bug）
- 缺陷修复后，重新进行测试活动（Regression test）
产出：测试用例、测试环境、测试执行记录、bug记录
4.4评估出口准则和报告
- 按照测试计划中定义的测试出口准则检查测试日志（测试用例是否执行完毕，是否达到功能、语句等计划的覆盖指标，继续测试发现缺陷的数量减少低于度量的标准，是否满足退出标准）
- 评估是否需要进行更多的测试，或者是否需要更改测试的出口准则（根据bug的情况确定）
- 为利益相关者提供一个测试总结报告（总结测试执行情况、缺陷情况、测试状态）
产出：测试报告
- 检查是否所有计划的交付物都产生并交付了
- 事件报告是否关闭、或对未关闭的事件报告提交变更需求
- 记录系统的验收
- 记录和归档测试件、测试环境和测试基础设备，便于以后复用
- 移交测试件到维护部门
- 分析和记录所获得的经验教训
- 使用积累的有效信息提高测试的成熟度
这里定义的测试结束活动在实际工作中可能会有所裁剪。
5.测试的心理学
独立测试，即开发和测试分离开来，单独进行。独立测试可以应用于任何测试级别。可以从低到高定义不同级别的独立：
- 开发人员自己写自己测
- 由同组的其他开发人员测
- 由专门的测试团队（同一组织内）测
- 测试外包（外部组织）
开发是建设性思维，测试是破坏性思维，如何避免二者的冲突？
- 测试人员以建设性的态度对发现的缺陷或失效与开发人员进行沟通
- 确立共同目标（追求高质量的产品），以合作而不是斗争的方式开始项目
- 对事不对人，对产品中发现的问题以中性和以事实为依据的方式来沟通，而不要指责引入这个问题的小组或个人
- 换位思考，尽量理解其他成员的感受以及他们为什么会有这种反应
- 确信其他成员已经理解你的描述，同时确保自己正确理解了其他人的描述
四、软件生命周期中的测试
1.软件开发模型
软件开发模型是软件开发所依据的方式和过程。软件测试不是孤立存在的活动，而是存在于软件开发生命周期中。因此需要了解软件开发模型，根据不同的模型，选择不同的测试方法。
V模型（顺序开发模型）
- 依次包括：用户需求、需求分析与系统设计、概要设计、详细设计、编码实现、模块测试、集成测试、系统测试、验收测试
- 此开发模型对应四种测试级别：组件/单元测试、集成测试、系统测试、验收测试
迭代-增量开发模型
- 由需求建立、设计、构建和测试等一系列相对较短的开发周期构成
- 常见模型：原型开发、快速应用开发（RAD）、统一软件开发过程（RUP）和敏捷开发模型（目标比较常用）
生命周期模型中的测试
- 每个开发活动（不仅仅是代码的开发，也包括需求文档、系统设计等）都有对应的测试活动
- 每个测试级别都有特有的测试目标
- 对于每个测试级别，都要进行相应的测试分析和设计
- 测试要参与文档的评审（文档初稿阶段）
2.测试级别
对于各个测试级别需要明确的内容：测试目标、测试依据、测试对象、典型缺陷和失效、对测试用具的需求、测试工具的支持、专门的方法和职责
1）组件测试/单元测试
- 测试目标：检查代码是否符合设计和规范，发现缺陷
- 测试依据：组件需求说明、详细设计文档、代码
- 测试对象：代码（组件、程序、数据转换/移植程序、数据库模型）
- 典型缺陷和失效：TBD
- 对测试用具的需求：会用到桩模块、驱动模块和模拟器
- 测试工具：单元测试框架，如JUnit
- 专门的方法：TDD测试驱动开发，先编写测试用例，测试覆盖率
- 职责：由开发人员完成
2）集成测试
- 测试目标：检查组件之间交互的接口，以及一个系统内不同部分的相互作用，发现缺陷
- 测试依据：软件和系统设计文档、系统架构、工作流、用例
- 测试对象：子系统、数据库实现、基础结构、接口、系统配置和配置数据
- 典型缺陷和失效：TBD
- 对测试用具的需求：有多种的集成级别：组件集成（组件之间的交互测试）、系统集成（不同子系统或软硬件之间的交互测试）
- 测试工具：集成的规模越大，定位缺陷的难度越大
- 专门的方法：集成程度逐步增加（自顶向下、自底向上），避免采用大爆炸式的集成
- 职责：由测试人员完成
3）系统测试
- 测试目标：在实际运行环境中充分运行系统，严重系统各部件是否能正常工作，符合软件需求规格说明，发现缺陷
- 测试依据：系统和软件需求规格说明、用例、功能规格说明、风险分析报告
- 测试对象：系统、用户手册和操作手册，系统配置和配置数据
- 典型缺陷和失效：TBD
- 对测试用具的需求：自动化测试
- 测试工具：功能测试、非功能测试（压力、性能、容量）、用户界面测试、兼容性测试、国际化测试、本地化测试等测试工具
- 专门的方法：基于需求的测试、基于业务流程的测试、基于用例的测试、基于风险评估的测试
- 职责：由独立的测试团队完成
4）验收测试
- 测试目标：建立信心
- 测试依据：用户需求、系统需求、用例、业务流程、风险分析报告
- 测试对象：基于完全集成系统的业务流程、操作与维护流程、用户处理过程、结构、报告、配置数据
- 典型缺陷和失效：TBD
- 对测试用具的需求：验收测试可以在多个级别上进行（组件测试、集成测试、系统测试）
- 测试工具：根据需求和实际情况而定
- 专门的方法：用户验收测试、操作测试、合同和法规性验收测试、Alpha和Beta（现场）测试
- 职责：由用户或客户进行，其他利益相关者可能参与其中
3.测试类型
1）功能测试
- 功能测试基于功能和特征以及专门的系统之间的交互，可以在各个级别的测试中进行
- 功能测试主要考虑软件的外部表现行为，不考虑程序的具体执行路径
- 通常采用黑盒测试（又称为功能测试、数据驱动测试）
- 安全性测试是功能测试的一种，关注安全相关的功能（如防火墙）
- 互操作性测试是功能测试的一种
目前很多公司所做的测试基本都会包含功能测试
2）非功能测试
- 包含但不限于：性能测试、负载测试、压力测试、可用性测试、可维护性测试、可靠性测试、可移植性测试
- 非功能测试测试系统运行的表现如何，可以在任何级别上执行
- 非功能测试关注的是软件的外部行为表现，通常采用黑盒测试设计技术来实现测试用例
公司中做的较多的就是性能测试
3）软件结构/架构测试（结构测试）
- 结构测试也称为白盒测试、逻辑驱动测试
- 结构测试可以在任何测试级别上进行（不局限于组件测试/单元测试，也可用于系统测试、集成测试、验收测试）
- 覆盖coverage：指结构通过测试套件检验的程度，以项被覆盖的百分比来表示。若覆盖率不足100%，可能需要设计更多测试用例来测试被遗漏的项，提高测试的覆盖
- 白盒测试的主要方法：语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖，基本路径测试
4）与变更相关的测试（再测试和回归测试）
- 再测试：当发现和修复一个软件缺陷后，需要重新进行测试以确定已经成功修复了原来的缺陷，这称之为确认测试，再测试
- 回归测试：对已被测过的程序在修改缺陷后进行的重复测试，以发现在这些变更后是否有新的缺陷引入或被屏蔽。
- 回归测试的规模可以根据以前正常运行的软件中发现新的缺陷的风险大小来确定
- 回归测试可在所有测试级别上进行，同时适用于功能测试、非功能测试和结构测试
4.维护测试
- 软件发布之后，系统通常要运行数年甚至数十年，在软件生命周期中的维护阶段，由于业务等方面的变化而进行修改、拓展、移植及部分软件被淘汰等原因所进行的测试称为维护性测试
- 维护性测试是在一个运行的系统上进行，且一旦对软件或系统进行修改、移植或系统被淘汰时，就需要进行维护性测试
五、静态技术
1.静态技术和测试过程
- 静态测试技术：通过手工检查（评审）或自动化分析（静态分析）的方式对代码或其他项目文档进行检查而不需要执行代码
- 评审：对软件工作产品（包括代码）进行测试的一种方式，可以在动态测试之前进行
- 在生命周期早期的评审过程中发现并修改缺陷的成本比在动态测试中发现并修复缺陷的成本低
- 评审可以完全以手工方式进行，也可以通过工具的支持来进行。人工评审是检查工作产品，并对其做出评估
- 评审的目的在于发现工作产品的缺陷和需要改进之处
- 与动态测试的对比
- 评审、静态分析和动态测试具有共同的目标：识别缺陷。它们之间是互补的，不同的技术可以发现不同类型的缺陷。
- 静态技术发现的是软件失效的原因（缺陷），动态测试发现的是失效本身
- 评审发现的典型缺陷：与标准之间的偏差、需求内的错误、设计错误、可维护性不足和错误的接口规格说明等
- 静态测试技术分类：评审（非正式评审、正式评审（走查、技术评审、审查））、静态分析（词法和语法分析、静态错误分析）
2.评审过程
- 评审的类型：
- 非正式评审：不需要遵循明确定义的过程
- 正式评审：遵循明确定义的过程，参与人员由明确的职责和检查表，有明确定义的进入和完成评审的准则（结构化和规范化）
- 正式评审包括：走查 Walk Through（作者主持）、技术评审 Technical Review（有专门主持人、无管理者参与）、审查 Inspection（管理者参与、引入度量项）
- 评审的目标：发现缺陷、增加理解、培训测试员和团队新成员、对讨论和决定达成共识
- 正式评审的阶段：典型的正式评审又以下六部分组成
- 计划阶段：定义评审标准、选择人员、分配角色、制定入口和出口准则、选择要进行评审的文档内容、核对入口准则
- 预备会阶段：分发文档、向评审参与者解释评审的目标过程和文档
- 个人准备阶段：先行评审文档，为评审会议做准备；标注可能的缺陷、问题和建议
- 检查/评价/记录结果（评审会议阶段）：讨论和记录；标注缺陷、提出处理建议、对缺陷做出决策；检查、评价和记录问题
- 返工阶段：修改发现的缺陷、记录缺陷更新的状态
- 跟踪结果阶段：检查缺陷是否已得到解决，收集度量数据，核对出口准则
- 角色和职责：经理（拍板的）、主持人（协调的）、作者（责任人）、评审员（发现问题和给出建议）、记录员（会议记录）
- 评审成功的因素：明确的目标、合适的评审人员、对发现的缺陷持欢迎态度、不对参与者进行评价、合适的检查表、提供评审技术培训、管理层支持、强调学习和过程的改进
3.静态分析的工具支持
- 静态分析的目的：发现软件源代码和软件模型中的缺陷
- 静态分析通常发现的是缺陷而不是失效
- 静态分析工具能够分析程序代码（比如控制流和数据流），以及产生如HTML和XML的输出
- 静态分析工具发现的典型缺陷：
- 引用一个没有定义值的变量
- 模块和组件之间接口不一致
- 从未使用的变量
- 不可达代码
- 逻辑上的遗漏与错误（潜在的无限循环）
- 过于复杂的结构
- 违背编程规则
- 安全漏洞
- 代码和软件模型的语法错误
- 静态分析的策略：开发人员在组件测试和集成测试之前或期间、或当代码签入配置管理工具时使用静态分析工具；设计人员在软件建模期间使用静态分析工具
（未完待续）