ISTQB认证工程师学习笔记（4）——测试技术

测试技术一般可分为黑盒测试、白盒测试、基于经验的测试技术

黑盒测试

黑盒测试技术（也称为行为的或基于行为的技术）基于对适当测试依据的分析（例如：正式需求文档、规格说明、用例、用户故事或业务流程）。这些技术适用于功能和非功能测试。黑盒测试技术关注在测试对象的输入和输出，而不考虑其内部结构。

黑盒测试技术的共同特点包括：
 测试条件、测试用例和测试数据的获取源自测试依据，可能包括软件需求、规格说明、用例和用户故事
 测试用例可用于检查需求和需求实现之间的差距，以及需求本身的错误
 覆盖度量是根据在测试依据中已测试的项和应用到测试依据的技术

常见的黑盒测试技术

等价类划分
等价类划分将数据划分为不同分区（也叫等价类），使得给定分区内所有成员期望被相同方式处理。
等价分区有针对有效值和无效值。

有效值：组件或系统应接受的值，包含有效值的等价分区称为“有效等价类”。
无效值：组件或系统应拒绝的值，包含无效值的等价分区称为“无效等价类”。

可以为与测试对象相关的任何元素数据识别有效分区，包括输入、输出、内部值、与时间相关的值，接口参数等。
如果有必要，可将等价分区进一步细化成为子分区。
每个值必须属于且只属于一个等价类。
当测试用例中使用无效等价类时，必须保证单独使用，而不是和其他无效等价类同时使用，以确保没有失效屏蔽。当多个失效同时发生，而只能观察到一个失效时，代表其他失效被屏蔽，这导致其他失效无法被发现。
等价类划分适用于所有测试级别。

边界值分析
边界值分析是等价类划分的扩展，但仅适用于等价类是有序的、由数字或顺序数据组成。等价类的最小和最大值（或第一和最后的值）是其边界值。
在区域的边界上的行为往往比在区域内的行为更容易出现错误。值得注意的是，不仅定义的边界，而且已实现的边界可能会被移动到它们预期位置的上方或下方，或可能会被完全忽略，或还可能会增加不需要的额外边界。边界值分析和测试是通过激发软件显示出与边界值所属区域预期不同的行为，边界值分析和测试将能发现几乎所有这类缺陷。
边界值分析可以应用于所有的测试级别。这个技术通常用来测试需要调用一系列数字的测试需求（包括日期和时间）。
对区域的边界值覆盖度量是测试的边界值数量除以识别的边界测试值总数，通常用百分比表示。

判定表测试
判定表是记录系统必须实现的复杂业务规则的一种很好的方法。当建立判定表时，测试员识别系统的条件（通常为输入）和导致的动作（输出）。通常情况下条件在顶部，动作在底部。判定表的每一列对应了一个判定规则，该规则定义了各种条件下的一个唯一组合，其表示与该规则相关的动作的执行。条件值和动作通常表示为布尔值（“真、假”或“1、0”）或离散值（如红、黄、蓝），但也可以是数字或者数字范围。这些不同的动作和条件可能一起出现在一个判定表中。

判定表的常见符号如下：
对条件：
 Y 表示条件是真（也可能显示为 T 或 1）
 N 表示条件是假（也可能显示为 F 或 0）
 - 表示条件值不关心（也可能显示为 N/A）
对动作：
 X 表示动作应发生（也可能显示为 Y 或 T 或 1）
 空格 表示动作不应该发生（也可能显示为 - 或 N 或 F 或 0）

完全的判定表有足够多的列（测试用例）来覆盖条件的每个组合。通过删除不影响结果的列，测试用例的数量可以大大减少。
判定表测试的最小覆盖标准通常是对判定表中每个判定规则至少有一个测试用例。这通常涉及覆盖所有条件的组合。
覆盖度量是至少被一个测试用例测试过的判定规则的数量，除以判定规则总数，通常以百分比表示。
判定表测试的优点是可以帮助识别所有重要的条件组合，否则其中有些条件组合有可能被忽视。判定表测试也会帮助发现需求中的漏洞。判定表测试可能应用到所有基于条件组合决定软件行为的情况，可以在任何测试级别进行。

状态转换测试
根据组件或系统当前条件或先前历史（例如自从系统初始化后发生过的事件），组件或系统可能会产生不同的响应。先前历史可以用状态的概念来总结。状态转换图不但显示可能的软件状态，同时包含了软件如何入口、出口，以及状态之间的转换的。转换是通过事件触发的（例如，用户输入一个值到输入域内）。事件导致转换。相同的事件从相同状态能导致两个或多个不同转
换。状态改变可能导致软件采取动作（例如，输出计算或错误信息）。
状态转换表不但可显示状态之间所有有效转换和潜在的无效转换，而且可表示有效转换的事件和导致的动作。状态转换图通常仅仅显示有效转换，而不包括无效转换。
设计测试可以用来覆盖典型的状态序列、执行所有状态、执行每个转换、执行转换的特定序列，或测试无效的转换。
状态转换测试可以用于基于菜单的应用，其广泛使用在嵌入式软件行业。此技术也适用于有特定状态的业务场景的建模，或测试屏幕上显示的引导或“菜单”。状态的定义是抽象的，即可能表示几行代码或整个业务流程。
覆盖度量通常是识别出已测试状态或已测试转换的数量，除以测试对象已识别出的状态或转换的总数，一般以百分比表示。

用例测试

测试可以从用例中推导出来，用例又是设计软件项交互的一种特殊方式，包含了软件的功能需求。
用例关联了参与者（用户，外部设备等）和主体（用例所应用的组件或系统）。每个用例规定了一个主体能与一个或多个参与者合作开展的行为。一个用例能通过交互和活动以及前置条件、后置条件进行描述，如合适，还可以以自然语言进行描述。参与者和主体之间的交互可能导致主体的状态改变。交互可能以工作流、活动图，或业务流程模型的图示方式表示。
用例包含了其基本行为的可能变化，包括期望行为和错误处理（系统对程序、应用和通讯错误的反应和恢复，例如，导致一个错误信息）。设计测试来执行已定义的行为（基本的、异常的或替代的和错误处理）。覆盖度量是已测试的用例行为数除以用例行为的总数，通常以百分比表示。

白盒测试

白盒测试是基于测试对象的内部结构。白盒测试技术能用在所有的测试级别，但更多运用在组件测试环节。

语句测试和覆盖
语句测试执行代码中可执行语句。覆盖度量是被测试执行的语句数，除以测试对象中可执行语句总数，通常以百分比表示。

判定测试和覆盖
判定测试执行代码中的判定，以及测试基于判定结果的可执行的代码。为此，测试用例跟随发生在判定点的控制流（例如，针对 IF 语句,一个对真（true）结果和一个对假（false）结果；针对 CASE 语句，测试用例将要求对所有可能结果，包括缺省（default）结果进行覆盖）。
覆盖度量是被测试执行的判定结果数，除以测试对象中判定结果的总数，通常以百分比表示。

语句测试和判定测试的价值
当实现 100％语句覆盖时，它确保代码中的所有可执行语句至少已被测试过一次，但不能确保所有判定逻辑都已被测试过。

当达到 100％的判定覆盖时，它会执行所有判定结果，包括测试取值为真（true）的结果和取值为假（false）的结果，即使没有清晰的假（false）语句（例如，IF 语句的代码中没有 else）。语句覆盖有助于发现那些未被其他测试执行到的代码中的缺陷。判定覆盖有助于发现那些在其他测试中没有对其所有真值（“真”/“假”）都执行到的代码（例如，判定语句）中的错误。

实现 100％的判定覆盖可保证 100％的语句覆盖（但反之不成立）。

基于经验的测试技术

在应用基于经验的测试技术时，测试用例源自测试员的技能和直觉，以及他们在类似应用和技术方面的经验。这些技术有助于识别一些其它系统化技术无法轻易识别的测试用例。根据测试员的方法和经验，这些技术可以达到不同程度的覆盖和有效性。使用这些技术，可能会难以评估和度量覆盖。

错误推测
错误推测法是一种基于测试员的知识来预估错误、缺陷和失效发生的技术，包括：
 应用软件在过去是如何工作的
 常犯的错误类型
 在其它应用软件中发生的失效

错误推测技术的一个系统化方法是创建一个可能的错误、缺陷和失效的列表，并设计测试以发现失效以及导致它们出现的缺陷。可以根据经验或缺陷和失效的信息，也可根据软件故障原因的一般知识创建此错误、缺陷和失效列表。

探索性测试
在探索性测试中，在测试执行期间动态地设计、执行、记录、和评估非正式的（非预定义的）测试。测试结果常用来进一步了解组件或系统，并对可能需要进一步测试的区域生成测试。
探索性测试有时通过基于会话的测试来构造活动。在基于会话的测试中，探索性测试在定义的时间盒内进行，测试员使用包含测试目标的测试章程来指导测试。测试员可能使用测试会话表格来记录随后步骤和发现。
探索性测试在规格说明文档较少或不充分，或测试的时间压力大的情况下是最有帮助的。探索性测试作为对其他更正式的测试技术的补充也是有用的。

基于检查表的测试
在基于检查表的测试中，测试员设计、实施和执行测试来覆盖检查表中的测试条件。作为分析的一部分，测试员可以创建新的检查表或扩充现有的检查表，但测试员也可能使用没有修改的现有检查表。可以基于检验、对用户重要内容的了解，或对软件失效的原因和方式的理解来构建检查表。
可产生用于支持各种测试类型的检查表，包括功能和非功能测试。在没有详细测试用例的情况下，基于检查表的测试能提供指南和在一定程度上保持一致性。由于它们是概要性的列表，因此在实际测试中往往会出现一些变化和衍生，可能导致更高的覆盖，但又保持了低重复性。