[2024 年 10 月 23 日] ISQI CTFL_Syll_4.0 新版试卷（含测试引擎和 PDF）[Q77-Q98］

基于经验的测试技术是依靠测试人员的经验、知识、直觉和创造力来识别和执行测试用例的测试设计技术，这些测试用例有可能发现软件系统中的缺陷。黑盒测试技术是一种测试设计技术，使用软件系统的外部行为和规格作为测试基础，而不考虑其内部结构或实现。
基于经验的测试技术可以补充黑盒测试技术，涵盖未明确指定的方面，如可用性、安全性、可靠性、性能等。其他说法都是错误的，因为
* 基于经验的测试技术不是依靠测试人员的经验来确定黑盒测试技术发现的缺陷的根本原因，而是根据他们自己的洞察力、启发式方法或探索性测试来确定缺陷的潜在来源。缺陷的根本原因通常是通过调试或根本原因分析确定的，这些活动涉及检查代码或开发过程，以找到并修复导致缺陷的错误。
* 白盒测试技术最常用的测试依据包括软件系统的源代码、设计文档、架构图和控制流程图。
白盒测试技术是以软件系统的内部结构和实现作为测试基础的测试设计技术，其目的是根据代码元素（如语句、分支、路径等）达到一定的测试覆盖率。用户故事、用例和业务流程是从用户或利益相关者的角度描述软件系统的功能性和非功能性需求，因此是黑盒测试技术使用的测试基础。
* 基于经验的测试技术的主要目标不是设计出可以使用基于图形用户界面的测试自动化工具轻松实现自动化的测试用例，而是设计出可以揭示其他测试技术（如边界值分析、等价分割、状态转换测试等）不易发现的缺陷的测试用例。测试自动化是指使用软件工具执行测试用例，并将实际结果与预期结果进行比较，而无需人工干预。测试自动化可应用于不同类型的测试技术，具体取决于测试目标、测试级别、测试工具和测试资源。然而，测试自动化并不总是可行或有益的，尤其是对于那些需要人为判断、创造或探索的测试用例，如基于经验的测试技术所设计的测试用例。参考资料：ISTQB 基础级认证测试员 (CTFL) v4.0 资料和文件：
* ISTQB 认证测试员基础级课程大纲 v4.0，第 2.2.1 章，黑盒测试设计技术
* ISTQB 认证测试员基础级别课程大纲 v4.0，第 2.2.2 章，白盒测试设计技术
* ISTQB 认证测试员基础级课程大纲 v4.0，第 2.2.3 章，基于经验的测试设计技术
* ISTQB 测试术语词汇表 v4.0、基于经验的测试技术、黑盒测试技术、白盒测试技术、测试基础、测试覆盖率、测试自动化

静态测试是一种不涉及执行被测软件或系统的测试形式。它包括审查、检查、演练以及文档、代码和模型分析等活动。静态测试可以在开发过程的早期发现缺陷，避免缺陷在后期变得更加昂贵和难以修复。静态测试还能从一开始就防止缺陷的出现，从而提高软件或系统的质量。静态测试是动态测试的补充，动态测试包括执行被测软件或系统，并根据预期结果检查结果。动态测试可以发现静态测试可能忽略的缺陷，如性能、可用性或集成问题。
然而，仅靠动态测试并不足以确保质量，因为动态测试可能无法涵盖所有可能的情景、输入或路径。因此，决定跳过静态测试的测试经理是一个错误的决定，因为他或她忽视了静态测试的好处，而仅仅依赖于动态测试，这可能在发现和预防缺陷方面不够有效或高效。参考文献 = ISTQB 认证测试员基础级别大纲，2018 年 4.0 版，第 2.1.1 节，第 14 页；ISTQB 测试术语词汇表，4.0 版、
2018 年，第 36 页；ISTQB CTFL 4.0 - 样本考试 - 答案，2023 年 1.1 版，第 3 题，第 9 页。

状态测试技术是一种动态测试技术，它基于被测系统在不同输入条件和事件下的行为。动态测试技术要求系统执行测试用例，而静态测试技术则不需要。静态测试技术可在代码准备好执行之前使用，如审查、检查、演练和静态分析。静态测试技术有助于在开发过程的早期发现缺陷，提高代码质量，减少动态测试的成本和工作量。参考 = ISTQB 认证测试员基础级别 (CTFL) v4.0 大纲，第 4 章，第 4.2.1 节，第 281 页；ISTQB 测试术语词汇表 v4.0，第 292 页

测试自动化能以一致的输入、输出和预期结果执行预定义的测试脚本或测试用例，因此可以减少人为错误。测试自动化还能减少执行重复或乏味测试（如回归测试、性能测试或数据驱动测试）所需的人工和时间。测试自动化不能证明不存在缺陷，因为它只能验证被测系统的预期行为，而不能验证意外或未知行为。测试自动化不能避免执行探索性测试，因为探索性测试是发现自动化测试未涵盖的新信息、风险或缺陷的重要技术。测试自动化不会通过促进缺陷管理来提高测试流程的效率，因为缺陷管理是一项单独的活动，涉及报告、跟踪、分析和解决缺陷，可能与自动化测试有关，也可能无关。参考资料：ISTQB Certified Tester Foundation Level (CTFL) v4.0 资料和文件：
ISTQB® 认证测试员基础级别教学大纲 v4.0，第 3.3.1 章，测试自动化1 ISTQB® 测试术语词汇表 v4.0，测试自动化2

静态测试是一种不涉及执行被测软件或系统的测试形式。它包括审查、检查、演练以及文档、代码和模型分析等活动。静态测试可以在开发过程的早期发现缺陷，避免缺陷在后期变得更加昂贵和难以修复。静态测试还能从一开始就防止缺陷的出现，从而提高软件或系统的质量。静态测试是动态测试的补充，动态测试包括执行被测软件或系统，并根据预期结果检查结果。动态测试可以发现静态测试可能遗漏的缺陷，如性能、可用性或集成问题。然而，仅靠动态测试还不足以确保质量，因为动态测试可能无法涵盖所有可能的情况、输入或路径。因此，决定跳过静态测试的测试经理是一个错误的决定，因为他或她忽视了静态测试的好处，而仅仅依赖于动态测试，这可能在发现和预防缺陷方面不够有效或高效。参考 = ISTQB Certified Tester Foundation Level Syllabus，Version 4.0，2018，Section 2.1.1，page 14；ISTQB Glossary of Testing Terms，Version 4.0，2018，page 36；ISTQB CTFL 4.0 - Sample Exam - Answers，Version 1.1，2023，Question 3，page 9。

* 软件测试并不能证明软件不存在缺陷，而只能证明软件存在缺陷或符合特定要求1。测试永远无法证明软件没有缺陷，因为不可能测试软件的所有可能情况、输入、输出和行为2。测试只能根据测试活动的覆盖面、有效性和效率，提供软件质量的可信度3。
* 其他选项正确的原因是
* A. 经过适当设计并通过的测试可降低系统的风险水平，因为这些测试可验证系统是否符合预期的质量属性，是否满足用户和客户的需求和期望4。风险是指由于不希望发生的事件而造成损失或伤害的可能性5。测试有助于识别、分析、优先处理和降低与软件产品和项目相关的风险6。
* C. 软件测试可发现缺陷，这些缺陷可用于改进开发活动，因为它们提供了有关软件质量和开发过程有效性的反馈7。缺陷是软件中的缺陷或错误，导致软件偏离预期或要求的结果或行为。测试有助于发现、报告、跟踪和解决缺陷，并防止缺陷在未来再次发生。
* D. 在实施系统前对需求规格进行审查可以提高质量，因为它可以确保需求清晰、完整、一致、可测试，并与用户和客户的需求和期望相一致。需求是软件应该做什么以及如何做的规范。测试有助于验证软件是否满足要求，并验证软件是否按照要求实施。
参考文献 =
* 1 ISTQB 认证测试员基础级别教学大纲 v4.0，2023 年，第 10 页。
* 2 ISTQB 认证测试员基础级别教学大纲 v4.0，2023 年，第 11 页。
* 3 ISTQB 认证测试员基础级别教学大纲 v4.0，2023 年，第 12 页。
* 4 ISTQB 认证测试员基础级别教学大纲 v4.0，2023 年，第 13 页。
* 5 ISTQB 认证测试员基础级别教学大纲 v4.0，2023 年，第 97 页。
* 6 ISTQB 认证测试员基础级别教学大纲 v4.0，2023 年，第 98 页。
* 7 ISTQB 认证测试员基础级教学大纲 v4.0，2023 年，第 14 页。
* [8] ISTQB Certified Tester Foundation Level Syllabus v4.0，2023 年，第 15 页。
* [9] ISTQB Certified Tester Foundation Level Syllabus v4.0，2023 年，第 16 页。
* [10] ISTQB Certified Tester Foundation Level Syllabus v4.0, 2023, p. 17
* [11] ISTQB Certified Tester Foundation Level Syllabus v4.0，2023 年，第 18 页。
* [12] ISTQB Certified Tester Foundation Level Syllabus v4.0, 2023, p. 19

对密码长度进行双值边界值分析的正确结果是选项 D 所代表的测试用例集。
边界值分析是一种测试设计技术，它侧重于等效分区边界上的值，如最小值和最大值，或边界上下的值。双值边界值分析对每个边界使用两个值，一个代表有效值，一个代表无效值。例如，如果有效值范围是 4 到 7，那么下边界的两个值就是 3 和 4，上边界的两个值就是 7 和 8。选项 D 中的测试用例使用这些值作为密码长度，同时也满足密码的其他要求，如至少包含一个数字字符、一个大写字母和一个小写字母。选项 D 中的测试用例是
1RhT：4 个字符的有效密码
rSp53：5 个字符的有效密码
3N3e10：6 个字符的有效密码
8sBdby：8 个字符的密码无效 其他选项中的测试用例是不正确的，因为它们要么使用的值不在密码长度的边界，要么不符合密码的其他要求。例如，选项 A 中的测试用例是
1xA：3 个字符的密码无效，但不包含大写字母 aB11：4 个字符的密码有效 Pq1ZZab：7 个字符的密码有效
7iDD0a1x：8 个字符的密码无效：ISTQB Certified Tester Foundation Level (CTFL) v4.0 资料和文件：
ISTQB® 认证测试员基础级别教学大纲 v4.0，第 2.2.1 章，黑盒测试设计技术1 ISTQB® 测试术语词汇表 v4.0，边界值分析，等效分区2

要测试的测试对象的特征和不包括在测试范围内的特征是通常包含在测试计划中的信息。测试范围定义了测试活动的边界和限制，如测试项目、要测试的功能、不测试的功能、测试目标、测试环境、测试资源、测试假设、测试风险等。测试范围有助于就测试包括和不包括的内容达成共识，避免利益相关者之间产生歧义、混淆或误解。另外两个部分，即 "测试交流 "和 "利益相关者"，也是测试计划的重要组成部分，但它们并不直接涉及测试对象的特征。测试交流描述了交流和报告测试进展、状态、问题和结果的方法、频率和责任。利益相关者确定参与测试活动或受测试活动影响的人员的角色和责任，如测试经理、测试团队、项目经理、开发人员、客户、用户等。参考资料ISTQB Certified Tester Foundation Level (CTFL) v4.0 资料和文件：
ISTQB® 认证测试员基础级别教学大纲 v4.0，第 2.1.1 章，测试计划1 ISTQB® 测试术语词汇表 v4.0，测试计划，测试范围2

说明
这个答案是正确的，因为产品风险是指影响软件产品质量的风险，如缺陷、故障或不符合要求或标准。项目风险是影响项目进度、预算、资源或范围的风险，如延误、成本超支、技能差距或范围变更。在本例中，[I]和[IV]属于产品风险，因为它们与软件产品的可访问性和安全性有关，而这是质量属性。[II]和[III]属于项目风险，因为它们与交付时间和测试团队的测试自动化技能有关，属于项目因素。参考资料：ISTQB 测试术语词汇表 v4.0，ISTQB 基础级教学大纲 v4.0，第 2.1.1.1 节

对代码中的所有决策至少执行一个决策结果，可确保实现全分支覆盖，这是一种测试覆盖标准，要求测试用例至少执行一次代码控制流中的所有分支。分支是具有单个入口点和单个出口点的基本代码块，而决策是代码中控制流可能有多个方向的点，如 if-then-else 语句、switch-case 语句、循环语句等。判定结果是指从判定出发的可能路径，如 then 分支或 else 分支、case 分支或默认分支、循环主体或循环出口等。其他语句都是假的，因为
* 实现完全分支覆盖所需的最少测试用例数，通常高于实现完全语句覆盖所需的最少测试用例数，后者是一种测试覆盖标准，要求测试用例至少执行一次代码中的所有可执行语句。这是因为分支覆盖率是比语句覆盖率更强的标准，因为它意味着语句覆盖率，反之亦然。例如，对于 if-then-else 语句，一个测试用例就能实现完整的语句覆盖，但要实现完整的分支覆盖，则需要两个测试用例，因为 then 分支和 else 分支都需要执行。
* 如果实现了全分支覆盖，那么代码中的所有无条件分支不一定都被执行了，因为无条件分支是不依赖于任何决定的分支，而且总是被执行，如 goto 语句、break 语句、return 语句等。
无条件分支不属于分支覆盖标准的一部分，因为它们并不代表代码控制流中的不同路径。不过，它们是语句覆盖标准的一部分，因为它们是代码中的可执行语句。
* 如果实现了全分支覆盖，那么决策表中的所有条件组合不一定都已执行，因为决策表是一种测试设计技术，它以表格的形式表示多个条件及其相应动作之间的逻辑关系。决策表中的条件组合可以多于代码中决策结果的数量，因为每个条件都可以有两个或两个以上的可能值，如真或假、是或否等。例如，一个有四个条件的决策表可以有 16 个条件组合，但相应的代码可能只有两个决策结果，如通过或失败。要对决策表中的所有条件组合进行测试，需要更强的测试覆盖率标准，如条件组合覆盖率，它要求测试用例至少执行一次代码中所有可能的条件结果组合。参考资料ISTQB 基础级认证测试员 (CTFL) v4.0 资料和文件：
* ISTQB 认证测试员基础级课程大纲 v4.0，第 2.3.1 章，基于软件结构的测试覆盖标准
* ISTQB 测试术语词汇表 v4.0、分支覆盖率、语句覆盖率、分支、决策、决策结果、无条件分支、决策表、条件组合覆盖率

边界值分析涉及分区之间边界的测试。测试最有效的边界值是输入范围边缘的边界值：
* 略低于最低值 (9)
* 最小值 (10)
* 略高于最小值 (11)
* 略低于最大值 (4999)
* 最大值 (5000)
* 略高于最大值 (5001)
测试这些值可确保程序正确处理边界，涵盖有效和无效输入情况。
表格顶部
表格底部

这个答案是正确的，因为错误猜测是一种测试设计技术，测试人员利用经验和直觉来预测错误、缺陷和故障已经发生或可能发生的位置，并设计测试用例来暴露它们。错误猜测可基于系统或组件的复杂性、系统或组件的已知或疑似弱点、以往的缺陷历史或该领域或技术中的常见错误类型等因素。错误猜测可作为其他更系统或正式技术的补充技术，或在没有足够信息或时间应用这些技术时使用。参考资料：ISTQB 测试术语词汇表 v4.0，ISTQB 基础级教学大纲 v4.0，第 2.3.2.5 节

说明
选项 D 是指测试人员应尽早参与工作产品评审，以利用早期测试原则。工作产品评审是一种静态测试技术，由一个或多个评审员（有无作者均可）对软件开发过程中的工作产品（如需求、设计、代码、测试用例等）进行审查，以找出缺陷、违规或改进之处。测试人员参与工作产品评审可为测试过程带来各种益处，如提高测试质量、测试效率和测试沟通。早期测试原则指出，测试活动应在软件开发生命周期中尽早开始，并在整个生命周期中迭代和持续进行。应用早期测试原则有助于在早期阶段预防、检测和消除缺陷，因为此时修复缺陷更容易、更便宜、更快捷，还能降低测试过程的风险、成本和时间。其他选项并不是无论选择哪种软件开发模式都适用的良好测试实践，而是根据测试活动的背景和目标，可能适用或不适用或对测试有益的具体测试实践，例如： 1：
测试应在代码编写之前以可执行格式编写，并应作为驱动编码的可执行规范：这是一种与测试驱动开发相关的特定测试实践，是一种软件开发和测试方法，在这种方法中，开发人员在编写源代码之前编写自动单元测试，然后重构代码，直到测试通过为止。
测试驱动开发有助于提高代码的质量、设计和可维护性，并为开发人员提供快速反馈和指导。然而，无论选择哪种软件开发模式，测试驱动开发都不是一个好的测试实践，因为在某些情况下，测试驱动开发可能不可行、不合适或不有效，例如需求不明确、不稳定或复杂时，测试自动化工具或技能不可用或不足时，测试目标或级别与单元测试不一致时，等等。
测试级别的定义应使一个级别的退出标准成为下一级别的进入标准的一部分：这是一种特定的测试实践，与瀑布模型、V 模型或 W 模型等顺序软件开发模型有关，在这些模型中，软件开发和测试活动按线性顺序依次进行，阶段、交付成果和依赖关系都有明确规定。测试级别是与软件系统集成级别相对应的测试阶段，如组件测试、集成测试、系统测试和验收测试。测试级别应有明确且可衡量的进入标准和退出标准，即在开始或完成一个测试级别前必须满足的条件。在顺序软件开发模型中，一个测试级别的退出标准通常是下一个测试级别的进入标准的一部分，以确保软件系统已准备就绪，可以稳定地进行下一个级别的测试。然而，无论选择哪种软件开发模式，这都不是一种好的测试方法，因为在某些情况下，这种方法可能与测试不相关、不灵活、不高效，例如，当软件开发和测试活动以迭代和增量的顺序进行，并经常进行更改、反馈和调整时（如 Scrum、Kanban 或 XP 等敏捷软件开发模式），当测试级别没有明确定义或区分时，或当测试级别并行或同时进行时，等等。
所有测试级别的测试目标都应相同，尽管不同级别设计的测试数量可能有很大差异：这是一种特定的测试实践，与统一的软件开发模型（如螺旋模型、增量模型或原型模型）有关，在这些模型中，软件开发和测试活动以循环和重复的方式进行，具有相似的阶段、交付成果和流程。测试目标是测试的目的或宗旨，可因测试级别、测试类型、测试技术、测试环境、测试利益相关者等而异。测试目标可以从测试基础、测试覆盖率、测试质量、测试风险、测试成本、测试时间等方面来定义。测试目标应该是具体的、可测量的、可实现的、相关的和有时限的，而且应该与项目目标和质量特性相一致。在统一的软件开发模式中，由于测试过程在每个周期或迭代中都会重复，测试的重点、范围和角度也相似，因此所有测试级别的测试目标可能都是相同的。然而，无论选择哪种软件开发模式，这都不是一种好的测试方法，因为在某些情况下，这种方法可能不合适、不现实或不能有效地进行测试，如在顺序软件开发模式中，软件开发和测试活动以分层和模块化的方式进行，有不同的阶段、交付成果和依赖关系、当测试目标根据测试级别（如组件测试、集成测试、系统测试和验收测试）的不同而变化时，或当测试目标根据反馈、学习或测试过程的调整而变化时，如在敏捷软件开发模型（如 Scrum、Kanban 或 XP 等）中。参考资料：ISTQB Certified Tester Foundation Level (CTFL) v4.0 资料和文件：
2 测试政策、策略和测试方法1 ISTQB 认证测试员基础级别课程大纲 v4.0，第 1.3.1 章，软件开发生命周期中的测试1 ISTQB 认证测试员基础级别课程大纲 v4.0，第 2.1.1 章，测试计划1 ISTQB 认证测试员基础级别课程大纲 v4.0，第 2.1.2、测试监控1 ISTQB 认证测试员基础级别大纲 v4.0，第 2.1.3 章，测试分析与设计1 ISTQB 认证测试员基础级别大纲 v4.0，第 2.1.4 章，测试实施1 ISTQB 认证测试员基础级别大纲 v4.0，第 2.1.5 章，测试执行1 ISTQB 认证测试员基础级别大纲 v4.0，第 2.1.6 章，测试管理5、测试执行1 ISTQB 认证测试员基础级别大纲 v4.0，第 2.1.6 章，测试关闭1 ISTQB 测试术语词汇表 v4.0，工作产品评审、静态测试、早期测试、测试驱动开发、测试级别、进入标准、退出标准、测试目标、测试基础、测试覆盖率、测试质量、测试风险、测试成本、测试时间2

测试中的全团队方法意味着测试责任由团队所有成员共同承担，而不仅仅是测试人员。这一概念在敏捷方法中得到了强调，在敏捷方法中，协作和集体质量所有权是关键原则。每个团队成员，包括开发人员、业务分析人员和测试人员，都要参与测试过程，确保从一开始就将质量融入产品。
参考资料
* ISTQB CTFL Syllabus V4.0，第 1.5.2 节 "整个团队方法 "描述了测试团队的集体责任。

可追溯性是指追溯测试基础项目（如需求、设计、风险等）与测试工件（如测试用例、测试结果、缺陷等）之间关系的能力。可追溯性能为测试过程带来各种好处，如提高测试覆盖率、测试质量、测试效率和测试沟通。然而，关于保持测试基础与测试工作产品之间的可追溯性的价值，并非所有说法都正确。不正确的说法是选项 C，该选项说，尽管不同级别设计的测试数量可能有很大差异，但所有测试级别的测试目标都应相同。这种说法是错误的，因为测试目标是测试的目的或宗旨，会因测试级别、测试类型、测试技术、测试环境、测试利益相关者等的不同而不同。测试目标可以从测试基础、测试覆盖率、测试质量、测试风险、测试成本、测试时间等方面来定义。测试目标应具体、可测量、可实现、相关、有时限，并应与项目目标和质量特性保持一致。所有测试级别的测试目标不应相同，因为不同的测试级别有不同的测试重点、范围和角度，如组件测试、集成测试、系统测试和验收测试。关于保持测试基础与测试工作产品之间的可追溯性的价值，其他说法都是正确的，例如： 1：
可追溯性有助于评估测试基础项目的变更对相应测试的影响：这句话是对的，因为可追溯性有助于确定哪些测试受到测试基础变化的影响，如新的需求、修改的设计、修订的风险等，并确定更新、重新执行或重新评估测试的必要行动。可追溯性还有助于估算实施变更所需的工作量、成本和时间，并验证其对软件系统的影响。
可追溯性有助于确定相应的测试覆盖了多少测试基础项目：这句话是对的，因为可追溯性有助于测量测试覆盖率，即测试用例对测试基础的应用程度。可追溯性有助于确定测试覆盖、部分覆盖或未覆盖的测试基础项目，并评估测试过程的充分性、完整性和有效性。可追溯性还有助于确定测试覆盖范围中的差距、重叠或冗余，并确定测试用例的优先次序、优化或改进。
可追溯性有助于满足测试审核的需要：这一说法是正确的，因为可追溯性有助于为测试活动、结果和成果提供证据、文档和理由。可追溯性有助于证明测试过程遵循了适用于软件系统、项目或组织的标准、规定、政策和最佳实践。可追溯性还有助于验证测试过程是否满足用户和利益相关者的期望、需求和满意度。参考资料：ISTQB Certified Tester Foundation Level (CTFL) v4.0 资料和文件：
ISTQB® 认证测试员基础级别大纲 v4.0，第 1.2.2 章，测试政策、策略和测试方法1 ISTQB® 认证测试员基础级别大纲 v4.0，第 2.1.1 章，测试计划1 ISTQB® 认证测试员基础级别大纲 v4.0，第 2.1.2、测试监控1 ISTQB® 认证测试员基础级别课程大纲 v4.0，第 2.1.3 章，测试分析与设计1 ISTQB® 测试术语词汇表 v4.0，可追溯性、测试基础、测试工件、测试目标、测试级别、测试覆盖率、测试质量、测试风险、测试成本、测试时间2

这个答案是正确的，因为测试中的左移是一种方法，目的是在软件开发生命周期中尽早执行测试活动，以便更快、更便宜地发现和修复缺陷，并提高软件产品的质量。持续集成是一种支持测试左移的做法，因为它涉及使用自动化工具和流程频繁集成和测试软件组件，通常每天数次。持续集成可以缩短从引入缺陷到发现缺陷之间的时间，从而降低修复缺陷的成本，并减少可能影响软件产品功能或性能的缺陷累积风险。参考资料ISTQB 基础级教学大纲 v4.0，第 3.1.1.3 节，第 3.2.1.3 节

测试驱动开发（TDD）将重构作为一项重要实践。在编写测试和满足这些测试的代码后，要进行重构，以在不改变功能的情况下提高代码和测试质量。这一持续的过程有助于保持代码的简洁、高效和可管理性。
参考资料
* ISTQB CTFL Syllabus 4.0，第 2.1.3 章，第 25 页：TDD、ATDD 和 BDD 实践

说明
故障可能由缺陷造成，也可能由环境条件造成。故障是指软件系统未按照预期行为执行所需的功能或错误执行功能的事件。缺陷是软件系统中的一个缺陷，或与要求或规范的偏差，可能会导致故障。然而，并非所有故障都是由缺陷造成的，有些故障可能是由环境条件造成的，如硬件故障、网络中断、断电、配置不兼容等。环境条件是影响软件系统运行的因素，但不是软件系统本身的一部分。其他说法都是错误的，因为
缺陷并不总是产生故障，而错误总是产生故障。这种说法是错误的，因为缺陷可能会产生故障，也可能不会产生故障，这取决于软件系统的输入、输出、状态或情景，而错误只是缺陷的另一种说法，因此它与缺陷一样有可能产生故障。例如，很少使用的功能或代码的隐藏分支中的缺陷可能永远不会产生故障，而经常使用的功能或代码的关键路径中的缺陷则可能经常产生故障。错误与缺陷不是不同的概念，而是缺陷的同义词或俗称，因此其定义和含义与缺陷相同。
缺陷可能导致故障，而故障一旦发生，总会导致错误。这种说法是错误的，因为错误不是故障的结果，而是缺陷的原因。错误是在软件系统中产生缺陷的人为行为或错误，如错字、逻辑缺陷、需求误解等。错误在软件系统中是无法观察到的，而是在人的头脑中或人的工作产品中，如代码、设计、文档等。故障不是错误的原因，而是缺陷的结果，缺陷是错误的结果。例如，代码中的错误可能导致软件系统的缺陷，而软件系统的缺陷可能导致软件行为的失败。
错误是在组件测试过程中发现的缺陷，而故障是在更高测试级别发现的缺陷。
这种说法是错误的，因为错误和故障并不是不同类型的缺陷，而是缺陷及其表现形式的不同术语。如前所述，错误只是缺陷的另一种说法，而故障则是指软件系统由于缺陷而无法达到预期性能的事件。
错误和故障可以在任何测试级别发现，而不仅仅是在组件测试或更高的测试级别。测试级别是与软件系统集成级别相对应的测试阶段，如组件测试、集成测试、系统测试和验收测试。根据测试目标、测试基础、测试技术和测试环境的不同，缺陷和故障可能在任何测试级别发生并被检测到。参考资料：ISTQB 基础级认证测试员 (CTFL) v4.0 资料和文件：
ISTQB 认证测试员基础级别教学大纲 v4.0，第 1.1.2 章，测试与质量1 ISTQB 认证测试员基础级别教学大纲 v4.0，第 1.2.1 章，测试原则1 ISTQB 认证测试员基础级别教学大纲 v4.0，第 1.3.1 章，软件开发生命周期中的测试1 ISTQB 测试术语词汇表 v4.0，失败、缺陷、错误、环境条件、错误、测试级别2

软件公司的思维过程是不正确的，因为它假定每个工件只能使用一种审查方法进行审查，而且审查方法完全取决于工件的关键性。这是一种简单僵化的方法，没有考虑到不同评审方法的优势和局限性、评审的背景和目的，以及从多次评审中获得的反馈和改进机会。根据 CTFL 4.0 大纲，审查方法的选择应基于多个因素，如人工制品的类型和详细程度、审查人员的可用性和能力、时间和预算限制、预期缺陷和风险以及预期结果和质量标准。此外，在开发生命周期的不同阶段，可以使用不同的评审方法对同一工件进行评审，以确保工件符合不断变化的需求、标准和利益相关者的期望。例如，可以使用非正式评审方法（如演练）对需求规格进行评审，以获得用户和开发人员的初步反馈，然后使用正式评审方法（如检查）来验证规格的完整性、正确性和一致性。因此，软件公司在针对不同的工件选择和应用评审方法时，应采用更灵活、对情境更敏感的方法，而不是遵循固定和武断的规则。参考 = CTFL 4.0 大纲，第 3.2.1 节，第 31-32 页；第 3.2.2 节，第 33-34 页；第 3.2.3 节，第 35-36 页。

测试金字塔是一个概念，说明了测试的不同层次及其相对数量。金字塔表明，低级单元测试应多于高级端到端测试。随着金字塔的上移，每个测试的范围都会增加，这意味着每个较高层次的测试通常会覆盖更多的生产代码。
* 单元测试：构成金字塔的基座，覆盖代码的各个单元。它们数量众多，因为编写和执行都很快。
* 服务/集成测试：位于金字塔中间，涵盖集成单元或服务之间的交互。
* 用户界面/端到端测试：在金字塔的顶端，这些测试涵盖整个工作流程和用户交互，由于其复杂性和执行时间，测试次数较少。
选项 B 准确地描述了测试金字塔的层级越高，单个自动测试所覆盖的生产代码就越多，因为与单元测试相比，这些更高层次的测试涉及更广泛的功能和交互。

说明
要涵盖与此情景相关的整个决策表，至少需要 6 个测试用例。
这是因为决策表有 4 个条件（客户类型和销售额）和 4 个操作（奖金百分比）。每个条件有 2 个可能值（基本或高级，以及 G1、G2 或 G3），因此组合总数为 2 x 2 x 2 x 2 = 16。然而，并不是所有的组合都有效，因为其中有些是矛盾的或不可能的。例如，一笔销售额不可能同时小于 300 欧元和大于 2000 欧元。因此，我们需要剔除无效组合，只保留有效组合。
有效组合为
客户类型
销售金额
奖金百分比
基本
G1
3%
基本
G2
5%
基本
G3
7%
高级
G1
5%
高级
G2
7%
高级
G3
10%
这 6 个组合涵盖了条件和操作的所有可能值，是涵盖整个决策表所需的最少测试用例数。
参考资料：ISTQB 认证测试员基础级别 (CTFL) v4.0 资料和文件、

要测试的测试对象的特征和不包括在测试范围内的特征是通常包含在测试计划中的信息。测试范围定义了测试活动的边界和限制，如测试项目、要测试的功能、不测试的功能、测试目标、测试环境、测试资源、测试假设、测试风险等。测试范围有助于就测试包括和不包括的内容达成共识，避免利益相关者之间产生歧义、混淆或误解。另外两个部分，即 "测试交流 "和 "利益相关者"，也是测试计划的重要组成部分，但它们并不直接涉及测试对象的特征。测试交流描述了交流和报告测试进展、状态、问题和结果的方法、频率和责任。利益相关者确定参与测试活动或受测试活动影响的人员的角色和责任，如测试经理、测试团队、项目经理、开发人员、客户、用户等。参考资料：ISTQB Certified Tester Foundation Level (CTFL) v4.0 资料和文件：
* ISTQB 认证测试员基础级课程大纲 v4.0，第 2.1.1 章，测试计划1
* ISTQB 测试术语词汇表 v4.0、测试计划、测试范围2