ISTQB系列之：ISTQB概述和CTFL知识总结（二）

六、测试设计技术

1.测试开发过程

1）测试开发过程

• 之前测试过程中也有介绍，这里侧重于测试的开发过程，大体分为：分析阶段、设计阶段和实现阶段
• 分析阶段：确定测什么（即明确测试条件），将测试条件定义为能通过测试用例进行验证的一个条目或事件，建立测试条件到需求的可追溯性
• 设计阶段：定义和记录测试用例和测试数据。完成测试设计规格说明和测试用例规格说明。
  • 测试用例包括：一组输入值、执行的前提条件、预期结果、执行的后置条件、输出、数据和状态的变化等
• 实现阶段：测试用例的开发、实现、确定优先级和组织包含在测试规程说明中。测试规程描述了测试用例执行的顺序，即执行测试选取的case和执行顺序
• 总结：测试开发过程就是确定测什么、设计怎么测试、以及决定如何执行测试的过程

2）测试设计规格说明、测试用例规格说明、测试规程规格说明：分别是测试条件（测试项）、测试用例、一组包含优先级和顺序的测试用例

3）如何评价测试用例的质量：建立测试条件和需求的可追溯性（便于需求变更时的影响分析和测试用例集的需求覆盖率分析）、期望结果

2.测试设计技术的种类

使用测试设计技术的目的：识别测试条件、开发测试用例（即确定测试什么和怎么测）

测试设计技术的分类：

• 基于规格说明的测试技术（黑盒）：依据文档来选择测试条件、测试用例和测试数据的技术。包含功能和非功能的测试。
• 基于结构的技术（白盒）：基于分析被测组件或系统的结构的测试技术
• 基于经验的技术：根据测试人员对相似的应用或技术的经验以及知识和直觉进行的测试

3.基于规格说明的或黑盒测试技术

• 等价类划分：基于一个假定，将软件或系统的输入分成不同的组，对于同一组输入，软件或系统应该有相似的表现。进而划分为有效等价类和无效等价类
  • 等价类的划分可以基于输入、输出、时间相关的值（例如在事件之前或之后）、接口参数等进行
  • 确定等价类的步骤：
    • 分类：将输入按照相同特性或者类似功能进行分解
    • 抽象：在各子类中抽象出相同特性并用实例表征该特性
    • 确定有效等价类（测试程序实现了规定的功能）和无效等价类（测试程序的容错性，对异常情况的处理）
  • 根据等价类设计测试用例
• 边界值分析：是等价类法的有效补充，在各等价类的边界通常更可能出现不正确的行为，因此边界是测试可能发现缺陷的地方。
  • 每个划分的最大和最小值就是它的边界，有效部分的边界就是有效边界值，无效部分的边界就是无效边界值
  • 边界值分析可以应用于所有的测试级别
  • 边界值的选择方法：若输入条件规定了值的范围，则取刚达到这个范围的边界的值，以及刚刚超过这个范围边界的值作为测试输入数据
• 决策表测试：决策表也叫判定表，用来表示和分析复杂逻辑关系，适合描述不同条件组合下采取行动的若干组合情况
• 建立决策表时，要分析规格说明，识别系统的条件和动作
• 决策表通常由4部分组成：条件桩（列出问题的所有条件，不强调条件的顺序）、动作桩（列出问题规定可以采取的操作）、条件项（列出条件桩的取值：真或假）、动作项（列出在条件项的各种取值情况下应该采取的动作）
• 任何一个条件组合的特定取值及其相应要执行的操作，可视为一条规则，可设计为一条测试用例
• 在设计决策表时可以将动作项相同的规则合并，减少冗余
• 状态转换测试：将软件运行或操作的过程看作是其状态不断发生变化的过程，可以根据软件的状态、状态间的转换、触发状态变化的输入或事件、状态转换导致的可能的行动来进行测试。
  • 被测系统或对象的状态时独立的、可确认的，并且数量有限
  • 一个状态表描绘了状态和输入之间的关系，并能显示可能的无效状态转换
  • 设计的测试可以覆盖一个典型的状态序列、覆盖每个状态
  • 执行每个状态的转换、执行特定的状态转换顺序、执行无效的状态转换
• 用例测试：用例描述了参与者之间的相互作用，基于系统最有可能使用的情况描述了过程流，可以从用例中得到测试用例。
  • 用例都有前置条件（用例成功执行的必要条件）和后置条件（用例执行完后能观察到的结果和系统的结束状态）
  • 用例测试便于发现不同组件之间相互作用而产生的集成缺陷，可用于验收测试
  • 用例通常都有一个主场景（最有可能发生的场景）和可选的分支

4.基于结构的技术或白盒技术

• 结构测试的级别：基于结构的测试/白盒测试可应用于所有测试级别，不仅仅局限于组件级（平时大家说的白盒测试多指组件级的单元测试）
  • 组件级别：结构是指软件组件的结构，比如：语句、判定、分支或每个不同的路径
  • 集成级别：结构可能是调用树（模块调用关系图）
  • 系统级别：结构可能是菜单结构、业务过程或Web页面结构
• 语句覆盖：设计若干测试用例运行所测程序，使得每一条可执行语句至少执行一次
  • 语句覆盖率：被（设计或执行）测试用例覆盖的可执行语句数量除以被测代码中所有可执行语句数量
  • 语句覆盖不能发现判断中逻辑运算中出现的问题，语句覆盖是最弱的逻辑覆盖
• 判定覆盖：设计若干测试用例运行所测程序，使得程序中每个判定的取真分支和取假分支至少经历一次
  • 判定覆盖率：被（设计或执行）测试用例覆盖的所有判定出口数量除以被测代码中所有可能的判定出口数量
  • 判定覆盖比语句覆盖更全面，100%的判定覆盖可以保证100%的语句覆盖，反之则不行
• 条件覆盖：判定条件中，保证每个条件至少有一次取真、取假。
  • 条件覆盖是对判定覆盖的有效补充，可以覆盖判定覆盖中遗漏的判定条件
  • 白盒测试要求同时满足判定覆盖和条件覆盖

5.基于经验的技术

• 概念：根据测试人员对相似应用或技术的经验以及知识和直觉来进行测试，是对系统化生成测试用例的一个有效补充，其效果取决于测试人员的经验
• 错误推测法：预测缺陷，列出可能的错误，并设计测试来攻击这些错误，称之为缺陷攻击
  • 可以根据经验、已有的缺陷和失败数据、有关软件失败的常识等设计缺陷
• 探索性测试：根据测试计划中包含的测试目标，同时进行测试设计、测试执行的测试活动。非形式化的测试方法，由测试人员积极的参与和控制测试的设计，利用在测试过程中获得的信息设计出新的、更好更完善的测试。（最近探索性测试在网络上大家讨论的比较火）
  • 常用于缺少有价值的测试文档、测试时间压力大的场合
  • 可作为对其他正式的测试的增加或补充
  • 可作为测试过程中的检查，有助于发现严重的缺陷

6.选择测试技术

•  测试技术的选择，在实际设计测试用例过程中需要根据实际情况进行交叉使用，保证对测试对象足够的覆盖率
• ISTQB大纲中给出的考量因素有：系统类型、法律法规标准、客户或合同的需求、风险的级别、风险的类型、测试目标、文档的可用性、测试人员的技能水平、时间和成本预算、开发生命周期、用例模型和以前发现各类缺陷的经验等

七、测试管理

1.测试的组织结构：

• 涉及两个角色：测试组长和测试员
• 测试组长：主要负责测试计划、监督与控制、协调
  • 可能的任务：测试策略、测试方针、测试计划、测试监督和控制、测试进度、自动化选取、测试报告、各种问题的协调
• 测试员：主要负责测试分析、设计与执行
  • 可能的任务：测试规格说明、测试环境、测试数据、测试执行和记录、自动化实施

2.测试计划和估算

• 测试计划
  • 测试计划受到以下因素影响：组织的测试方针、测试范围、测试目标、风险、约束、关键程度、可测性、资源的可用性等
  • 测试计划是个持续的活动，需要在整个生命周期过程和活动中，从测试中不断得到反馈识别风险，从而对计划做相应的调整
  • 测试计划活动包括：
    • 确定测试范围和风险，明确测试目标
    • 决定总体测试方法，包括测试级别、入口和出口准则的界定
    • 决定测什么？谁来测？怎么测？如何评估测试结果？
    • 为测试分析、设计、实现、执行和评估安排时间进度
    • 为已定义的不同测试活动分配资源
    • 定义测试文档的数量、详细程度、结构和模板（确定输出）
    • 为监控测试准备和执行、缺陷解决、风险问题选择度量项
• 入口准则：定义什么时候可以开始测试，主要包括：
  • 测试环境准备就绪并可用
  • 测试工具准备就绪
  • 测试对象可用
  • 测试数据可用
• 出口准则：定义什么时候可以停止测试，主要包括：
• 完整性测量，比如代码、功能或风险的覆盖率
• 对缺陷密度或可靠性度量的估计
• 成本
• 遗留风险，比如没有修复的缺陷或在某些区域缺少测试覆盖
• 进度表，如基于交付到市场的时间
• 测试估算：这里介绍了两种估算方法，基于度量的方法（基于相似项目和典型数据）和基于专家的方法（依赖于专家）
  • 实际估算过程：将软件测试工作进行WBS分解，通过分解定义的任务，并根据以前项目测试的经验和历史数据确定任务的工作量，根据工作量并结合企业生产率估算出成本
  • 一旦估算了测试工作量，就可以识别资源和制定时间进度表
  • 测试工作量的内容：测试用例设计、测试环境设置、测试用例执行、测试缺陷报告
• 测试策略、测试方法
  • 测试策略通常是描述如何测试软件的总体方法和目标，包括确定测试环境、阶段、类型、方法和技术。
  • 制定测试策略的目的：确定合理的测试方案、识别测试主要任务和风险，使得测试更有效
  • 测试方法是测试策略的具体实现，在测试计划和设计阶段被定义并逐步细化的，通常取决于测试目标和风险评估
  • 典型的测试方法：分析的方法、基于模型的方法、系统的方法、基于过程或符合标准的方法、动态和启发式的方法、咨询式的方法、可重用的方法。

注：实际工作中，我们用到的出口准则：

• 测试执行对于功能的覆盖达到100%（在设计测试用例时就提前做好了全覆盖，只是对于不同轮次的测试会有所剪裁，比如第一轮覆盖100%，回归测试只覆盖新功能和bug出现的模块）
• 严重及以上级别bug为0（将bug的严重级别分为5个级别：5极其严重（系统崩溃）、4非常严重（功能模块不可用）、3严重（功能部分可用）、2中度（不影响使用但影响用户体验）、1轻微（其他））
• 遗留的bug作为变更请求已经提交

3.测试过程监控

• 测试监控的目的：为测试活动提供反馈信息和可视性。测试监控包括监督（搜集数据）和控制（纠正偏差）
• 监控的对象：测试覆盖率（需求、风险、代码）、进度（测试用例执行）、缺陷（数量、趋势）
• 监控的体现形式：测试报告

4.配置管理

• 配置管理的目的：在整个项目和产品的生命周期内，建立和维护软件或系统产品（组件、数据、文档）的完整性
• 对测试的作用：保证测试件被识别，版本受控，变更可跟踪可追溯

5.风险和测试

• 风险：事件、危险、威胁或情况等发生的可能性，以及由此产生的不可预料的后果，即一个潜在的问题（未实际发生）
• 风险级别：由发生不确定事件的可能性和产生的影响（事件引发的不良后果）来确定
• 项目风险：项目按目标交付的能力方面的风险
  • 从组织因素、技术因素、供应商因素来考虑
• 产品风险：软件或系统中的潜在失效的部分
• 风险和测试的关系：风险通常可以用来决定从什么地方开始测试，什么地方需要更多的测试。测试可以降低风险或减少负面事件的影响

6.事件管理

• 事件：实际结果和预期结果之间的差异需要作为一个事件被记录。（即我们通常所说的bug、defect）
• 事件和缺陷：事件可能由于缺陷导致，也可能不是；缺陷是已经确认需要修复的实际问题。（我们实际工作中被接受的bug才算作缺陷）
• 事件可能发生在任何地方（需求文档、开发文档、测试文档、用户文档、代码等），不局限于测试执行过程中发现的不一致
• 事件报告的目的：提供问题反馈、跟踪系统质量和测试进度、为测试过程改进提供资料
• 事件报告的内容包括：预期和实际的结果、识别测试项和环境、软件所处的生命周期阶段、事件描述（日志、数据库备份或截屏）、影响范围、严重程度、修复的紧迫性/优先级、事件状态、结论、全局的影响、变更记录、参考

八、软件测试工具

1.测试工具的类型

• 测试工具的意义：支持测试活动
  • 根据不同类型的测试活动，就有了不同的测试工具。大体包括：直接用于测试的工具、测试过程管理工具、用于观测的工具、对测试有帮助的工具
  • 测试框架：被大量的应用于工业界，它至少包含以下三个含义
    • 可重用、可扩展的测试库，可用于搭建测试工具（也叫测试用具）
    • 设计测试自动化的设计类型（比如，数据驱动、关键字驱动）
    • 测试执行的全过程
• 测试工具的分类：可分为功能测试工具（白盒测试工具/黑盒测试工具）、性能测试工具、测试管理工具（测试流程管理、缺陷跟踪管理、测试用例管理）
• 测试管理工具：测试管理工具、需求管理工具、事件管理工具（缺陷跟踪工具）、配置管理工具。实际应用中的TD、JIRA、RTC等
• 静态测试工具：评审工具、静态分析工具、建模工具
• 测试规格说明的工具：测试设计工具、测试数据准备工具。QTP、WinRunner、Robot、RFT、Selenium
• 测试执行和记录工具：测试执行工具、测试用具/单元测试框架工具、测试比较器、覆盖率测量工具、安全性测试工具
• 性能和监控工具：动态分析工具、性能测试/负载测试/压力测试工具、监控工具。LoadRunner、JMeter、Nmon

2.有效使用工具：潜在的利益和风险

• 收益：
  • 减少重复性的工作（比如执行回归测试、重新输入相同测试数据、代码规则检查）
  • 更好的一致性和可重复性
  • 客观的评估（比如，静态测量、覆盖率）
  • 容易得多测试和测试相关的信息（比如，测试进度的统计和图表、事件发生率和性能等）
• 风险：
  • 对工具抱有不切实际的期望（功能性和易用性）
  • 低估首次引入所需的时间、成本和工作量（包括培训和额外的专业知识）
  • 对工具过分依赖（对适合手工测试的任务使用自动化工具）
  • 忽视了在工具中对测试对象的版本控制

3.组织中工具的引入

• 组织选择工具所需考虑的关键点：
  • 组织的成熟度、引入工具的优缺点、引入工具能改善测试过程的可能性
  • 根据清晰的需求和客观的准则进行评估
  • 基础设施是否需要改变，及如何改变
  • 评估供应商
  • 收集内部需求
  • 测试团队的自动化测试技能
  • 成本收益比
• 将选择的工具引入组织要从一个试点项目开始（增加认识、收集反馈进行改进、定义使用标准、评估投入产出）
• 在组织内成功部署工具的因素：逐步推广、过程改进的配合、提供培训、定义使用指南、监控工具的使用和收益、提供支持、收集经验和教训

九、总结

ISTQB FL的知识体系，基本涵盖了我们测试工作的所有方面，包括：软件测试基础、软件生命周期中的测试、静态技术、测试设计技术、测试管理、测试工具。给我们提供了一个测试的广度。关于测试的深度，我想随着工作经验和知识的积累会不断加深，也就有了ISTQB的AL和EL。通过总结的过程，加深了自己对测试知识体系的认识，同时也感觉到很多点理解的不够透彻，还需要在实际工作中不断的体会和总结。争取明年一举拿下AL。