【ISTQB-CTFL（基础级）】错题A卷

1. List item
   题目解析
   这道题考察的是ISTQB 基础级测试原则的理解。
   考纲知识点定位
   在 ISTQB 基础级 CTFL v4.0.1 考纲中，测试原则部分（FL-1.3.1）明确提到：

测试会无效（Pesticide
Paradox）：如果重复执行相同的测试用例，最终这些测试将不再发现任何新的缺陷。为了发现新的缺陷，必须修改现有的测试用例，或者创建新的测试用例。

2. List item
   题目解析
   这道题考察的是测试过程中不同阶段的活动划分，核心是区分测试分析与测试设计等阶段的职责。

题干场景：在订餐移动应用的迭代中，新增支付功能，问哪项属于测试分析。
选项 A：估算测试工作量（8 人日）属于测试规划阶段，不是测试分析。
选项 B：决定针对 “多个用户之间的共享付款功能” 进行测试，这是在定义测试条件 / 测试范围，属于测试分析的核心活动。
选项 C：使用边界值分析（BVA）推导测试数据、编写测试用例，属于测试设计阶段，是在测试分析之后的具体设计工作。
选项 D：执行测试用例、分析结果并报告缺陷，属于测试执行阶段。

考纲知识点定位
在 ISTQB 基础级 CTFL v4.0.1 考纲中，测试过程部分（FL-1.4.1）明确了测试分析的定义：

测试分析：确定
“测试什么”，即定义测试条件和测试范围。它关注于从需求、用户故事或其他测试依据中导出测试条件，明确需要测试的功能、特性或场景。

而测试设计则是在测试分析的基础上，具体设计测试用例、测试数据和测试步骤。
3. List item
题目解析
这道题考察的是影响测试方法选择的关键因素，需要我们区分哪些是重大影响因素，哪些不是。
考纲知识点定位
在 ISTQB 基础级 CTFL v4.0.1 考纲中，测试过程部分（FL-1.4.2）明确指出，选择测试方法时需要考虑的主要因素包括：
软件开发生存周期（SDLC）
已识别的产品风险
法规、标准和合同要求
可用的测试工具和技术
测试团队的技能和经验
4. List item
题目解析
这道题考察的是测试工程师的核心职责，需要区分测试工程师与其他角色（如产品负责人、开发、测试经理）的任务边界。
考纲知识点定位
在 ISTQB 基础级 CTFL v4.0.1 考纲中，测试过程与角色部分（FL-1.4.5）明确了测试工程师的典型活动：
分析测试依据（如需求、用户故事）
设计和实现测试用例
准备和配置测试环境
执行测试用例
记录和报告测试结果
而 “制定测试计划” 更多属于测试管理角色的职责。

5. List item
   题目解析
   这道题考察的是对 ** 测试左移（Shift-Left Testing）** 概念的理解，核心是判断哪项活动没有体现 “尽早测试” 的原则。

C. 在组件测试过程中进行性能效率测试：✅ 属于测试左移。将非功能测试（如性能）提前到组件测试阶段，而不是等到系统测试或验收测试阶段，符合左移思想。
D. 在配置管理过程之前编写测试脚本：❌ 不属于测试左移。测试脚本的编写需要依赖于配置管理（如版本控制、环境管理），在配置管理过程之前创建测试脚本是没有意义的，也不符合 “尽早且合理地开展测试” 的左移原则。

考纲知识点定位
在 ISTQB 基础级 CTFL v4.0.1 考纲中，测试左移（FL-2.1.5）的核心定义是：
测试左移是指在软件开发生命周期中，尽早地开展测试活动，而不是将测试推迟到项目后期。其目的是尽早发现缺陷，降低修复成本，提升产品质量。
典型的左移活动包括：
尽早评审需求、设计文档
测试驱动开发（TDD）
尽早开展非功能测试（如组件级性能测试）

6. List item
   题目解析
   这道题考察的是确认测试与回归测试的区别：
   确认测试：验证之前失败的测试用例在缺陷修复后是否通过。
   回归测试：验证之前通过的测试用例，在代码变更后是否依然通过，确保没有引入新的缺陷。
   考纲知识点定位
   在 ISTQB 基础级 CTFL v4.0.1 考纲中，测试类型部分（FL-2.2.3）明确了：
   确认测试：在缺陷修复后，重新执行之前失败的测试用例，以确认缺陷已被修复。
   回归测试：在代码变更后，重新执行之前通过的测试用例，以确保变更没有影响其他功能。
7. List item
   题目解析
   这道题考察的是不同评审类型的典型特征，需要我们根据题干给出的属性，匹配最可能的评审类型。
   考纲知识点定位
   在 ISTQB 基础级 CTFL v4.0.1 考纲中，评审类型部分（FL-3.2.4）对各类型的定义如下：
   走查（Walkthrough）：由作者主持，目的是发现缺陷、评估质量，有记录员，需要个人准备并生成报告。
   技术评审（Technical Review）：由技术专家主持，目的是评估技术方案，主持人通常不是作者。
   审查（Inspection）：由中立的主持人主持，有严格的流程和角色，目的是发现缺陷，主持人不能是作者。
   非正式评审（Informal Review）：无固定流程和角色，形式灵活。
8. List item
   题目解析
   这道题考察的是成功评审的关键因素，需要我们找出不属于成功评审因素的选项。

D. 应持欢迎态度和客观地处理所发现的失效：❌ 不是成功因素。在静态评审中，我们发现的是缺陷（Defect），而不是 “失效”（Failure）。失效是指软件在运行时（动态测试）表现出的不符合预期的行为。因此，这个陈述本身概念错误，不属于成功评审的因素。

考纲知识点定位
在 ISTQB 基础级 CTFL v4.0.1 考纲中，评审成功因素部分（FL-3.2.5）明确了：
为参与者提供充足的准备和评审时间。
将大型工作产品分解为更小的部分。
培养专业、尊重的沟通氛围。
聚焦于发现缺陷，而非指责个人。
同时，考纲也区分了缺陷和失效：
缺陷：存在于工作产品中的问题，在静态测试中发现。
失效：软件运行时表现出的问题，在动态测试中发现。
9. List item
这道题明确要求使用等价类划分法（EP），而不是边界值分析法（BVA），所以我们只需要覆盖每个有效等价类，不需要考虑边界值。
TC1：底楼 + 小花园（覆盖 E1, G2）
TC2：底楼 + 大花园（覆盖 E1, G3）
TC3：二楼 + 无花园（覆盖 E2, G1）
TC4：三楼或更高 + 无花园（覆盖 E3, G1）
10. List item
1、先画状态 - 转移表
把所有状态和转移整理成表格，避免遗漏。

2、找最长路径
尝试从初始状态（INIT）出发，找到一条能覆盖最多转移的路径，作为第一个测试用例。
例如：INIT → run → IN OPERATION → pause → ON HOLD → resume → IN OPERATION → error → DEBUG MODE → done → OFF，这条路径覆盖了转移 3, 5, 6, 4, 2。
3、补全剩余转移
检查还有哪些转移没被覆盖，然后设计新的用例去覆盖它们，尽量复用已有路径。
在上例中，还剩下转移 1（test）和 7（ON HOLD → done）未被覆盖，因此需要再设计两个用例：
INIT → test → DEBUG MODE → done → OFF（覆盖转移 1, 2）
INIT → run → IN OPERATION → pause → ON HOLD → done → OFF（覆盖转移 3, 5, 7）
这样总共是 3 个用例
11. List item
题目解析
这道题考察的是语句覆盖率的核心定义，需要区分语句覆盖与路径覆盖、穷尽测试的差异。

选项 A：正确。100% 语句覆盖率的定义是代码中每一条可执行语句都至少被执行一次，包括包含缺陷的语句。
选项 B：错误。覆盖率由测试用例覆盖的语句决定，而非用例数量。比如单个用例可实现 100% 语句覆盖，增加用例反而可能只覆盖部分语句。
选项 C：错误。语句覆盖≠路径覆盖，代码中的分支、循环会产生多条路径，100% 语句覆盖无法保证所有路径都被执行（如循环的不同执行次数对应不同路径）。
选项 D：错误。穷尽测试（覆盖所有输入组合）是不可能的（测试原则），且 100% 语句覆盖无需覆盖所有输入组合。

考纲知识点定位
语句覆盖率定义（FL-4.3.1）
ISTQB 基础级 CTFL v4.0.1 考纲中对语句覆盖的定义：

语句覆盖（Statement Coverage）：度量被测试用例执行的代码语句占总可执行语句的比例。100%
语句覆盖率意味着代码中每一条可执行语句都至少被执行一次。

语句覆盖与路径覆盖的区别（FL-4.3.1）
考纲明确：

语句覆盖是最基础的覆盖准则，它不考虑代码中的分支和循环结构，因此无法保证所有路径都被覆盖。路径覆盖则要求覆盖代码中所有可能的执行路径，其覆盖强度远高于语句覆盖。

穷尽测试不可能（FL-1.3）
考纲中 “七项测试基本原则” 的第四条：

穷尽测试是不可能的：无法对软件的所有输入组合、执行路径进行测试，除非软件极其简单。

12. List item
    题目解析
    这道题考察的是白盒测试的核心特征与局限性，需要找出对其描述不正确的选项。

A：正确（题干要求选 “不正确”，因此 A 不是答案）。白盒测试的核心是基于代码结构、逻辑和实现细节进行测试，必然会考虑整个软件的实现。
B：正确。白盒覆盖率指标（如语句覆盖、判定覆盖）能量化测试的充分性，据此可设计额外测试用例来提升覆盖率。
C：正确。白盒测试技术可用于静态测试，比如代码审查、静态代码分析（通过分析代码结构发现问题，无需运行程序）。
D：不正确。白盒测试仅基于代码实现，不直接对照需求规格说明，因此无法识别 “需求实现的差距”（这是黑盒测试的核心目标）。
考纲知识点定位
在 ISTQB 基础级 CTFL v4.0.1 考纲中，白盒测试部分（FL-4.3.3）明确了：
白盒测试的定义：

白盒测试（结构测试）是基于对被测组件或系统的内部结构、设计和实现的了解来设计和执行测试的方法。

白盒测试的局限性：

白盒测试专注于代码的内部逻辑和结构，无法验证软件是否符合用户需求，也无法发现需求与实现之间的偏差。

白盒测试与静态测试的结合：

静态白盒测试包括代码审查、静态分析等，通过检查代码结构和语法来发现缺陷，无需执行程序。

13. List item
    题目解析
    这道题考察的是不同测试技术的适用场景，核心是根据题干中的约束条件（需求未共享、测试启动晚、有领域知识）选择最适配的技术。
    A. 基于检查表的测试：❌ 全新应用无现成检查表，且需求不明确无法制定检查项，因此不适用。
    B. 错误猜测法：❌ 该方法依赖对同类系统缺陷模式的积累，而全新应用缺乏历史缺陷数据，无法进行有效的错误猜测。
    C. 探索性测试：✅ 无需预先设计测试用例，依靠测试人员的领域知识和分析能力，边探索系统边设计执行测试，完美匹配 “需求未共享、测试启动晚、有领域知识” 的场景。
    D. 分支测试：❌ 属于白盒测试，需依赖代码结构，且耗时较长，不符合 “快速提交测试结果” 的要求，也与领域知识关联度低。
    考纲知识点定位
    在 ISTQB 基础级 CTFL v4.0.1 考纲中，探索性测试部分（FL-4.4.2）明确了其定义和适用场景：

探索性测试：是一种同时进行测试设计和测试执行的测试技术，测试人员基于对系统的理解、领域知识和经验，实时调整测试策略。它适用于需求不完整、测试时间紧迫或系统较为复杂的场景。

而错误猜测法的适用前提是：需有同类系统的缺陷历史或明确的故障模式参考，否则无法有效开展。
14. List item
题目解析
这道题考察的是测试人员在敏捷迭代和发布计划中的价值体现，需要区分测试人员的核心贡献与其他角色的职责、以及表述的准确性。
C：正确。测试人员通过参与用户故事的风险识别与评估，能帮助团队预判测试难点、制定合理的迭代和发布计划，这是为计划增加价值的核心方式。
D：错误。早期测试设计是提升软件质量的手段，但 ** 无法 “保证”** 发布高质量软件（测试原则中 “不存在缺陷的谬论” 也说明测试不能完全保证无缺陷），且考纲明确早期测试设计并非发布计划的组成部分。
考纲知识点定位
在 ISTQB 基础级 CTFL v4.0.1 考纲中，敏捷测试部分（FL-5.1.2）明确了测试人员在迭代和发布计划中的作用：

测试人员应参与用户故事的风险识别和评估，为迭代规划提供质量相关的输入，帮助团队确定合理的交付范围和时间节点。

同时，考纲中的测试原则也指出：测试只能证明缺陷存在，不能证明缺陷不存在，因此 “保证发布高质量软件” 的表述不符合测试的本质。

15. 三点估算期望工期（均值）：乐观 + 4× 最可能 + 悲观，整体除以 6。
16. List item
    题目解析
    这道题考察的是风险应对策略的识别，核心是根据题干中的风险应对措施，匹配对应的策略类型。
    A. 风险接受：❌ 风险接受是指不采取任何主动措施，仅被动承担风险后果。但题干中明确提出了 “执行性能效率测试”“alpha/beta 测试” 等具体措施，并非接受风险。
    B. 应急计划：❌ 应急计划是风险发生后采取的补救措施，而题干中的测试措施是风险发生前的预防行为，并非事后应对。
    C. 风险缓解：✅ 风险缓解是通过采取措施降低风险发生的可能性或影响程度。题干中通过测试提前发现性能问题、验证系统表现，能有效降低 “响应时间太长” 这一风险的影响，属于典型的风险缓解策略。
    D. 风险转移：❌ 风险转移是将风险的责任或后果转移给第三方（如购买保险、外包），题干中并未涉及第三方，因此不适用。
    考纲知识点定位
    在 ISTQB 基础级 CTFL v4.0.1 考纲中，风险应对策略部分（FL-5.2.4）明确了：
    风险缓解：

通过采取措施降低风险发生的可能性或减少风险造成的影响，测试是风险缓解的重要手段之一，通过测试可提前发现缺陷，降低产品发布后出现问题的概率。

风险接受：

主动或被动地接受风险，不采取任何针对性措施，适用于风险影响极小或应对成本过高的情况。

风险转移：

将风险转移给第三方，如合同约定、购买保险等。

应急计划：

针对已发生的风险制定的补救措施，属于风险发生后的应对方式。

17. List item
    题目解析
    这道题考察的是测试相关过程的核心定义，需要区分 “维护测试” 与 “配置管理” 在测试脚本版本控制中的不同作用。
    A. 追溯管理：❌ 追溯管理关注的是需求、测试用例、缺陷等不同工作产品之间的关联关系，而非同一脚本的版本控制。
    B. 维护测试：❌ 维护测试是指为修正缺陷、适配新需求而执行的测试活动，侧重 “测试执行”，而非测试脚本的版本创建与管理。
    C. 配置管理：✅ 配置管理的核心是对软件项目中的工作产品（包括测试脚本）进行版本控制、变更管理和基线管理，创建测试脚本新版本正是其核心工作。
    D. 需求工程：❌ 需求工程是对需求进行收集、分析、文档化的过程，与测试脚本版本控制无关
    考纲知识点定位
    在 ISTQB 基础级 CTFL v4.0.1 考纲中，测试配置管理部分（FL-5.4.1）明确了：

配置管理用于管理测试过程中的所有工作产品，包括测试脚本、测试数据、测试环境等，核心活动包含版本控制、变更控制、基线建立与维护，确保测试资产的可追溯性和一致性。

而维护测试的定义是：针对软件变更（如需求更新、缺陷修复）开展的测试，目的是验证变更的正确性，而非管理测试资产的版本。
18. List item
题目解析
这道题考察的是数据准备工具对应的测试活动阶段，核心是区分测试各阶段的核心任务与数据准备的关联。

考纲知识点定位
在 ISTQB 基础级 CTFL v4.0.1 考纲中，测试活动阶段部分（FL-6.1.1）明确了各阶段的核心任务：
1、测试分析与设计：分析需求、确定测试条件、设计测试用例。
2、测试实施：创建测试数据、准备测试环境、开发自动化脚本等。
3、测试执行：运行测试用例、记录测试结果。
4、测试监测与控制：跟踪测试进度、处理测试中的偏差。
5、测试完成：生成测试报告、归档测试资产。