Tessy学习
赞
踩
一、Tessy大致了解
1.1分类树(CTE)检测流程
1.2覆盖测试
使用覆盖测试时，覆盖测试一次，不覆盖测试一次，确保代码没有改变。
以下情况不选择覆盖度量，源代码也被检测：
①使用调用跟踪功能
②使用静态局部变量
以下情况，会将一些额外代码添加复制到源文件末尾：
①测试静态函数时
②使用静态全局变量时
1.3Tessy测试时的局限性
- 待测试的源代码应可由各自微控制器目标的编译器编译而无错误和警告。如果源代码中存在语法错误，TESSY可能无法分析待测试模块的接口。
- TESSY不检查被测函数的任何运行时行为或时间约束。
- 目标系统上的测试执行高度依赖于目标设备本身的正确配置，TESSY环境中的正确编译器/链接器设置以及TESSY中其他目标设备相关设置(如果适用)。支持设备的TESSY工具的任何预定义设置都需要用户手动检查，以确保单元测试执行的正确操作。
- 使用特定于编译器的关键字和编译器命令行设置可能需要额外的工具资格测试。TESSY工具集对资格测试套件(QTS)测试结果的正确操作仅为符合ANSI的C代码提供。
Tessy4以后的限制：
- 用户代码使用的所有类型必须在各自测试对象的源文件中可用。
- 当在模块级使用用户代码定义/声明时，所有使用类型必须在模块的所有源文件可用。
向后兼容的设置：环境编译器TEE在项目属性“Enable CLANG”配置为“false”，禁用CLANG解析器和测试驱动程序生成的使用。
二、一般处理
2.1创建数据库和使用文件系统
2.1.1创建、导入、克隆、编辑、删除项目
2.2 了解图形用户界面
2.2.1Menu bar
菜单栏提供了“文件”、“Windows”等操作。在“帮助”中，您可以找到TESSY的在线帮助。如果这些操作适用于视图中的项，那么这些操作中的许多也可以在单个视图的上下文菜单中使用。
2.2.2Tool bar
在TESSY界面的全局工具栏中，您可以选择一个项目，保存更改等。通过用光标滚动图标，工具提示将告诉您每个图标的用途。视图中也可能有单独的工具栏。在这里你可以找到操作的工具，例如，开始测试执行通过单击Save图标。
2.2.3Perspectives and perspective (tool) bar
TESSY包含了几个透视图来显示基于测试工作流中不同任务的信息(“需求管理”、“概述”、“TIE”等)。每个透视图提供多个视图。在透视图栏(包含透视图名称)中，您可以在不同的透视图之间切换。透视图——从左到右跟踪准备、运行和评估测试时所采取的操作。每个透视图名称都有几个右键菜单选项(上下文菜单)。点击左边的符号可以打开其他透视图:
2.2.4 Views
每个透视图中的每个视图都包含配置的可能性或提供呈现数据的部分。有些视图对于几个透视图是通用的(例如源的属性)，有些视图特定于一个透视图(例如TIE中的图)。
请注意，视图与其他视图组合在一起的方式是不同的，例如，Overview透视图中的视图Test Results与Test Items视图组合在一起，但是在TDE透视图中，它与Test Project视图组合在一起。使用不同组合的原因是为了让您快速概述和比较每个项目步骤中的各种信息。
您可以根据自己的需要更改视图的外观，并将一个透视图打开到另一个透视图:
- 激活(打开)要在其中添加视图的透视图。
- 点击“窗口”>“显示视图”。将打开一个显示所有视图的窗口(参见图A)。
- 选择要打开的视图。
- 点击“OK”。选中的视图被添加到活动透视图中。
图A
通过拖放改变视图的位置:
- 单击视图的名称并将其移动到您喜欢的位置:您可以将视图移动到在同一视图组内的另一个位置，或进入另一组视图，甚至在当前窗口外。
- 右键单击透视图开关并选择“Reset”以切换回各视角下所有视图的原始位置(见图B)。
图B
重置工作台：.在菜单栏中选择“Window”>“Reset Workbench”。
2.2.5 Status bar
2.3使用上下文菜单和快捷方式
三、基础知识
3.1嵌入式软件的单元测试
3.1.1需要检测的标准
IEC 61508等国际标准要求进行模块测试。根据IEC 61508第3部分，模块测试应表明被测模块执行其预期功能，不执行非预期功能。模块测试的结果应形成文件。
IEC 61508根据其安全临界性对系统进行分类。有四个安全完整性级别(SIL)，其中1是最低级别，4是最高级别，即4级的系统被认为是对安全最关键的。即使是低临界的应用(即在SIL 1)，模块测试已经“强烈推荐”。IEC 61508第3部分附件中包含的表格指定了应该使用的技术，例如，对于模块测试，在SiL 1中已经强烈推荐使用“功能和黑盒测试”技术。其他技术，如动态分析和测试，推荐用于SIL 1，强烈推荐用于SIL 2或更高级别。
IEC 61508第4部分将(软件)模块定义为由过程和/或数据声明组成的结构，并且可以与其他此类模块交互。如果我们考虑用C语言编写的嵌入式软件，我们可以将C级函数作为模块。为了防止C级函数和C源模块之间的混淆，从现在开始我们将C级函数称为单元。
此外，其他标准如英国Def Stan 00-55、ISO 15504或DO-178B要求模块测试(其中命名范围从“模块”到“单元”到“组件”)。然而，所有标准对这类测试都有或多或少相同的要求:必须提前计划测试，必须指定测试数据，必须进行测试，必须对结果进行评估和记录。
3.1.2关于单元测试
3.1.2.1什么是单元测试？
在C程序的单元测试期间，对单个C级函数进行严格测试，并且与应用程序的其余部分隔离进行测试。严格意味着测试用例是专门为有问题的单元制作的，并且它们还包含可能被测试单元意想不到的输入数据。隔离意味着测试结果不依赖于应用程序中其他单元的行为。与应用程序其余部分的隔离可以通过直接调用被测单元并用存根函数替换对其他单元的调用来实现。
单元测试在单元的接口上进行测试，单元测试不考虑单元的内部结构，因此单元测试被认为是黑盒测试。单元的接口由单元的输入变量(即单元读取的变量)和输出变量(即单元写入的变量)组成。一个变量既可以是输入也可以是输出(例如，一个按单位递增的变量)，而单位的返回值——如果存在的话——总是一个输出。测试用例的结构遵循接口的结构。
单元测试是通过使用输入变量的特定数据执行被测单元来进行的。将实际结果与预测的结果进行比较，从而确定测试用例是通过了还是失败了。
单元测试(c级功能的测试，如前所述)非常适合满足IEC 61508的模块测试要求，因为单元测试是功能性，因为测试了单元的功能，并且一个黑盒，因为这个单元的内部没有被考虑在内，而且动态，因为测试对象是在测试期间执行的。
3.1.2.2有什么好处？
- 尽早发现错误:单元测试可以在被测试单元编译完成后立即进行。因此，可以很早就检测到单元内部的错误。
- 省钱:众所周知，较晚发现的错误改正起来比较早发现的错误要昂贵得多。因此，单元测试可以节省资金。
- 减少复杂性:与其尝试创建测试整个交互单元集的测试用例，不如将测试用例特定于被测单元。测试用例可以很容易地包含被测试单元没有预料到的输入数据，或者甚至是随机输入的测试数据，如果被测试单元是由应用程序的完整功能单元调用的话，这是相当难以实现的。如果测试失败，失败的原因可以很容易地识别，因为它必须来自被测试的单元，而不是来自调用层次结构更低的单元。
- 给予信心:在单元测试之后，应用程序由单个的、经过全面测试的单元组成。针对整个应用程序的测试将更有可能通过，如果某些测试失败，原因可能源于单元之间的交互(而不是单元内部的错误)。对失败的研究可以集中在这一点上，绝不能怀疑这些装置的内部。
3.1.3单元测试的注意事项
3.1.3.1哪些单元是好的测试候选者？
单元测试验证某些输入数据是否生成预期的输出数据。因此，在最广泛的意义上进行数据处理的单元，例如生成数据、分析数据、排序、做出复杂的决策、困难的计算，最适合进行单元测试。为了找到这样的单位，度量的应用(例如，根据McCabe的圈复杂度)可能是合适的。
选择要测试的单元的其他标准可能是功能对单元操作的关键程度，或者单元在应用程序中使用的频率。
3.1.3.2哪些不属于单元测试的范围？
在单元测试期间，不测试单元之间的相互作用。这包括在单位之间传递参数的语义(例如值的物理单位)，以及单位之间的及时关系(例如，一个单位是否足够快地完成其任务，以使调用单位也以所需的速度完成其任务?)另外，应用程序的中断行为不在单元测试的范围内。像“我的中断真的每10毫秒发生一次吗?”或“哪个中断延长了我的单元，使其无法接受?”这样的问题不是单元测试解决的，因为单元测试明确地旨在测试与环境影响(如中断)隔离的单元的功能行为。
3.1.3.3为什么需要进行回归测试？
回归测试是在软件中修复错误或进行改进之后，对已经通过的测试进行重复。回归测试证明软件中的更改不会导致任何意外的行为。回归测试是软件质量的关键。显然，回归测试的实践需要测试的自动化，因为手动重复测试的工作量太大了。即使对于非重复的单元测试，适当的工具支持也会为您节省大量时间，但是对于重复的单元测试，工具支持是必不可少的。
3.1.3.4有谁进行测试？
困境:人们普遍认为软件开发人员不适合测试他自己的软件，特别是如果完整的实现，或者实现与规范的一致性是一个问题(对自己的错误视而不见)。如果开发者忘记了实现某个功能，很可能他还会忘记一个测试那将显示缺失的功能。如果开发人员错误地解释了规范，那么它可能会导致错误尽管有错误的功能，他的测试很可能会通过。
另一方面，经验表明，一个测试人员，谁应该测试一个代码不写他必须投入大量的精力去理解这个函数的接口。测试人员必须找出变量的含义，以及使用哪些值来进行某些测试。例如，如果测试规范要求测试“绿色”的东西，哪个变量(或变量)表示颜色，变量的哪个值表示绿色?的对预期结果的预测也带来了类似的问题。
如果开发人员不做测试，就会增加额外的工作量，因为测试失败了测试必须传递给开发人员，他必须重现失败，纠正问题，然后通常要进行一个结论性的外部回归测试。此外，由于开发人员不会在没有完成至少一些测试的情况下将其软件交给QA部门，因此会增加额外的工作量。重复的测试工作如果开发人员立即开始使用外部预定义的测试，是否可以保存测试用例。
解决方法:摆脱这种困境的一种方法可能是测试人员，他没有编写代码，根据单元的功能规格说明指定测试用例，包括预期的结果。他可以使用抽象数据(例如color = green)。测试用例集被移交给软件的开发人员。对他来说，应该没有问题将输入变量设置为所需的值(例如，为绿色设置适当的RGB值)。如果测试失败，开发人员可以立即纠正问题并重新运行到目前为止已经通过(回归测试)所有测试。与编译步骤相比，测试被视为软件实现过程中的一个额外步骤，编译步骤中编译器发现所有语法错误，开发人员交互地纠正它们，并通过随后的编译器运行来验证他的更改。
然而，由于最初提到的对自己的错误视而不见的原因，标准要求组织分离开发和测试。可能，仅仅将测试用例的说明从开发中分离出来，并且考虑预先定义的测试用例的指导，就足以避免在上面提到的盲目性下受苦。
此外，开发人员的时间通常被认为是非常宝贵的，不能浪费在测试上，这就是为什么在实践中不经常发现开发人员测试。然而，这将被重新考虑。
3.1.3.5测试嵌入式软件有什么特殊之处?
对于嵌入式软件，必须使用具有所有非ansi关键字和非ansi特性的未更改源代码进行测试。例如，一些用于嵌入式系统的交叉编译器允许比特字段小于整数大小，例如，在16位应用程序中使用8位宽的位域。这是ANSIC标准所禁止的，但是对于嵌入式系统的完美适应是合理的。如果在测试期间不能维护这个非法的大小，那么单元测试结果自然是毫无价值的。这需要专门的工具。此外，结论测试至少在实际硬件上执行也是至关重要的，即嵌入式微控制器。这是一个挑战，但有一些方法可以减轻它。为所讨论的微控制器使用交叉编译器是一个先决条件，最好是将用于用户应用程序的确切版本。
3.1.4单元测试方法
单元测试工具可以遵循两种技术方法来进行单元测试:测试应用程序方法使用特殊的应用程序来执行单元测试。这是通常的方法。原始二进制测试使用未更改的用户应用程序进行测试。
3.1.4.1 a.试验应用
单元测试工具进行单元测试的通常方法是生成一个测试驱动程序(也称为测试工具)，并将测试驱动程序与被测单元的源代码一起编译。它们一起构成了测试应用程序。测试驱动程序包括启动代码用于嵌入式微控制器，main()函数入口，以及对被测单元的调用。如果需要，测试驱动程序还包含存根函数之类的代码。对于每个要测试的单元，创建一个自己的测试应用程序。此测试应用程序用于执行单元测试。为此，测试应用程序被加载到能够执行测试应用程序的执行环境中。该执行环境通常是连接到(指令集)模拟器的调试器、独立的在线仿真器或连接到目标系统的调试器、JTAG或BDM调试器等。在将测试数据传输到执行环境之后(测试数据可能已经包含在测试应用程序中)，将执行测试并评估结果。
要在实际硬件上执行测试应用程序，测试应用程序不仅必须使用有关微控制器的交叉编译器进行编译，而且测试应用程序必须适合实际硬件上存在的内存。此外，测试应用程序的启动代码必须考虑到实际硬件的特性，例如启用芯片选择等。使测试应用程序适合内存可以通过使用一个在线仿真器来简化，该仿真器提供仿真内存，并作为一种通用的硬件平台，用于所讨论的微控制器。
当必须使用实际的硬件并且该硬件上的内存非常有限时，测试应用程序必须最小化以适应该内存。这对于单芯片应用来说尤其具有挑战性，因为只有微控制器的内部存储器可用。如果测试数据包含在测试应用程序中(并且内存有限)，那么单个测试应用程序只能包含几个测试用例，这反过来意味着对一个单元的测试需要几个测试应用程序，这是很麻烦的。避免这种情况的一种方法是将测试数据与测试应用程序分离，这不仅允许最小化测试应用程序，还允许您更改测试数据，而不必重新生成测试应用程序。
3.1.4.2 b.原始二元试验
另一种方法是使用未更改的用户应用程序进行单元测试。这类似于通常由开发人员在应用程序完成后进行的手动测试。将完整的应用程序加载到执行环境中，并执行应用程序，直到最终到达要测试的单元。然后将输入变量设置为所需值，进行测试。
3.1.4.3利与弊
原始二进制测试方法的优点是被测试单元完全在其最终内存位置进行测试。编译和链接测试应用程序没有额外的工作(或麻烦)，因为使用的是用户应用程序，它已经被编译和链接，或者无论如何必须被编译和链接。因为用户应用程序无论如何都必须适合内存，所以有关应用程序大小的问题可以忽略不计,可行的。甚至已经驻留在硬件ROM中的应用程序也可以进行测试。即使用于编译用户应用程序的交叉编译器不再在手，但测试仍然存在。
然而，与使用测试应用程序相比，这种原始二进制测试方法有一些缺点:
- 没有对测试执行的控制。这取决于用户应用程序，测试从未达到，或只有在一些特殊的外部事件发生后，例如，按下实际硬件的按钮并产生中断当到达被测单元时。可能是这个单位的情况下从这个。
- 在进行原始二进制测试时，不能使用stub函数。这很明显因为应用程序已经使用当前函数进行了链接被测试单元调用。一个单元总是使用的其他单元进行测试应用程序。因此，被测单元不会与其他单元隔离的测试过程中，可能会出现调用单元的错误被测单元。
- 不可能在单元测试中使用任意的测试数据。例如，如果被测单元通过指向内存区域的指针获取测试数据，测试数据的数量必须适合此内存区域，该内存区域由用户应用程序。
除了它易于使用之外，它可能是进行单元测试的唯一方法总之，原始二进制测试有很强的缺点，这是必要的适当的单位测试，因此，人们甚至可以坚持说，它不是严格意义上的单元测试。
3.1.5结论
除了被标准所要求之外，单元测试还减少了测试的复杂性尽早发现错误，可以节省资金，并为整个应用程序的测试提供信心。如果以正确的方式使用，单元测试可以减少开发/测试时间，从而减少投放市场的时间。要进行回归测试，测试自动化是必不可少的。这需要工具支持。
3.2分类树(CTM)
分类树方法(CTM)的目标是将问题的(功能)定义系统地转换为一组对错误敏感、低冗余的定义1组测试用例规范。本文档给出了CTM的全面概述。
3.2.1一般准备
测试是软件开发过程中必不可少的步骤。这种测试的计划经常会提出同样的问题:
- 应该运行多少个测试?
- 应该使用什么测试数据?
- 如何创建对错误敏感的测试?
- 如何避免重复的测试?
- 是否有任何测试用例被忽略了?
- 什么时候结束测试是安全的?
任何遇到这种问题的人都会很高兴知道CTM提供了一个系统的过程来创建基于问题定义的测试用例说明。
CTM的目标是将问题的(功能性)定义系统地转换为一组对错误敏感的、低冗余的测试用例说明。系统的方法产生了一个高概率的结果集测试规范是完整的，没有相关的测试被忽视。当然，在开发过程中正确使用方法和适当集成是先决条件。拥有一套完整的测试可以证明何时可以安全结束测试。
CTM是由人应用的。因此，该方法的结果取决于CTM用户的经验、反思和评价。对于同一个功能问题，两个不同的用户很可能会使用一组不同的测试用例规范。这两个集合都可以被认为是正确的，因为没有绝对的正确性。应该清楚的是，有一组测试用例是绝对错误的或不完整的。由于人为的原因，错误是无法避免的。一个补救措施是方法中固有的系统性。这是系统的引导和刺激用户的创造力。用户应指定高概率的测试用例，以检测测试对象中的故障。这样的测试用例被称为错误敏感测试用例。另一方面，用户应该避免指定太多的测试用例，那是多余的，也就是说，不要增加测试强度或测试相关性。这样的测试用例被称为“冗余”测试用例。如果用户熟悉该方法的应用领域，这是有利的。
CTM是一种通用方法:它不仅可以应用于嵌入式软件的模块/单元测试，还可以应用于一般的软件测试以及与软件无关的问题的功能测试。应用该方法的先决条件是对测试对象的行为有一个可用的功能规范。CTM结合了几种众所周知的测试用例规范方法，例如等效划分和边界值分析。
CTM起源于德国柏林的前戴姆勒软件研究实验室。
4.2.2应采取的步骤
a.定义功能问题
第一步是描述测试对象的预期行为，例如:“按下按钮，灯就亮;如果按下按钮，灯就会熄灭。数据处理软件通常解决功能问题，因为输入数据是根据算法(函数)处理的，成为输出数据(解)。
b.确定测试相关方面
分析功能规范。这意味着，您考虑该规范的目的是找出规范中与测试相关的方面。如果用户期望某个方面在测试期间影响测试对象的行为，则认为该方面是相关的。换句话说，如果用户希望在测试期间为这个方面使用不同的值，那么这个方面就被认为是相关的。为了绘制树，这些方面是分开处理的。这大大降低了原始问题的复杂性，这是CTM的优点之一。
测试相关方面的例子
考虑在一些米范围内测量距离的系统，例如到的距离房间里的墙。这些系统通常会发出信号并测量时间，直到它们接收反射信号。这些系统可以基于两种不同的物理效应:一种可以使用声纳来确定距离，而另一种可以使用雷达。
现在的问题是:房间里的空气温度是这些测量系统测试的一个测试相关方面吗?对于一个系统，答案是肯定的，而对于另一个系统，答案是否定的。
声纳在空气中的传播速度取决于空气的温度。因此，为了得到准确的结果，声纳系统在计算距离时考虑了这个温度。为了测试这是否正确工作，您必须在不同的温度下进行一些测试。因此，温度是声纳系统测试的一个重要方面。另一方面，我们都知道，以光速传播的雷达信号的速度与它所处的空气的温度无关(它甚至不需要空气来传播)。因此，对于雷达系统的测试来说，空气温度不是一个与测试相关的方面。在不同的温度下做测试是多余的。
这个例子表明，需要仔细思考找出(所有)测试相关的方面。如果有人只是简单地将雷达系统的测试用例应用于声纳系统，而没有添加一些与温度相关的测试用例，这将导致糟糕的测试。另外，这个例子说明了在设计测试用例时，熟悉手头的问题域是有利的。
c.对测试相关方面的值进行分类
在所有测试相关的方面确定之后，考虑每个方面可能采取的值。根据等效划分方法将值划分为不同的类:如果在测试中认为值相等，则将值分配到相同的类。测试的等价意味着，如果某个类中的一个值导致测试用例失败，从而显示一个错误，那么这个类中的每个其他值也将导致相同的测试失败，并显示相同的错误。
换句话说:它与测试无关，因为它们都被认为是等价的。因此，您可以从类中提取任意值进行测试，甚至可以对所有测试使用相同的值，而不会减少测试的值。但是，这样做的先决条件是正确地完成了等效分区，这是CTM的(人类)用户的责任。
请注意:
- 等效的测试并不一定意味着测试的结果(例如，计算值)对于类中的所有值都是相同的。
- 等效划分在数学意义上必须是完整的:必须将测试相关方面的每个可能值分配给一个类。
- 等效划分在数学意义上必须是唯一的:测试相关方面的值必须分配给单个类，而不是分配给多个类。
等价分区示例:Ice Warning
汽车仪表盘上的结冰警告标志应进行测试。这种结冰警告指示取决于汽车外部温度传感器报告的温度，该传感器可以报告温度从-60°C到+80°C。在温度高于3℃时，冰警告关闭，在温度低于3℃时，冰警告打开。
很明显，温度是唯一与测试相关的方面。为了进行合理的测试工作，我们不希望对每个可能的温度值都有一个测试用例。因此，所有可能的温度值都需要根据等效划分方法进行分类。
最佳实践是找出是否可能存在无效值。在我们的情况下，短路或电缆中断可能导致无效值。因此，我们应该首先将温度分为有效值和无效值。无效值可能与温度过高(高于80°C)和温度过低(低于-60°C)有关。在有效温度中很容易形成两类:第一类应包含导致冰警告显示打开的所有值(从-60°C到3°C)，另一类应包含导致冰警告显示关闭的所有值(从3°C到80°C)。
上图中的等价划分导致至少四个测试用例，因为我们需要从每个类中取出一个值用于测试。
d.重复等价分区
等价类可以根据其他方面进行细分。这种在多个级别上的等价分区降低了等价分区的复杂性，因为您可以考虑将每个类与其他类隔离开来，并决定是否需要对其进行细分以及如何细分。此外，这种在几个层次上的等价划分记录了思想的响应。工作阶段，直到最后的等效分区。这有助于结果的可理解性和可追溯性。此外，如果最终的等效分区变得过于细粒化，它也可以很容易地恢复步骤。
重复等价分区的例子
对于示例ice警告，有效值的分类不够详细，因为根据等效划分方法，在所有测试中使用类中的单个任意值就足够了。例如，这可能是冰警告显示打开的温度类别中的值2C。因此，没有测试与零下温度将检查冰警告显示是否打开。为了避免这种结果，您可以根据温度的符号进一步划分这类:
结果:分类树
使用CTM，在CT中描述了所有测试相关方面重复等效划分的结果。根表示功能问题，测试相关方面。测试相关方面(分类)绘制在用矩形表示的节点中。类是省略号。
e.使用边界值
使用边界值背后的思想是，值范围边界处的值是比中间的值更适合于形成对错误敏感的测试用例。边界值分析背后的思想与等价划分相反，因为一种方法需要一组值是等价的，而另一种方法更倾向于这种集合中的特殊值。尽管事实上，边界值分析背后的思想与等价划分，两种方法都可以在CTM中表示。
f.测试磁滞
目前的冰预警实例问题规范中没有提到滞后问题。扩展当前的问题规范可能很有诱惑力，因为应该避免冰警告显示状态的快速变化。例如，冰的警告显示只有当温度上升到4摄氏度以上时才应关闭。这可能是通过迟滞函数实现。这种迟滞函数的必要测试用例可以由CTM指定。
g.指定测试用例
测试用例在CT下面所谓的组合表中指定。叶类的CT形成组合表的头部。组合表中的一行描述了测试用例。测试用例是通过选择叶子类来指定的，类的值来自叶子类应使用测试用例。这是由方法的用户通过在组合表中各自的测试用例的行中设置标记来完成的。
在测试用例的说明过程中，将每个类与其他每个类结合起来可能很诱人。此外，由于逻辑原因，并非所有组合都是可能的，这不是CTM的意图，它可以由工具自动完成。这将导致许多测试用例，缺点是失去概述和执行测试用例花费太多的精力。
CTM的目标是通过尝试在单个测试用例中覆盖多个方面，尽可能找到最小的、非冗余的但足够的测试用例集。与树形图类似，它依赖于方法用户的评估和经验，指定了多少和哪些测试用例。
显然，树的大小影响所需测试用例的数量:具有更多叶类的树自然会产生比具有更少叶类的树更多的测试用例。对于给定的树，至少需要叶子类的数量称为最小准则。考虑到每个叶子类应该至少在一个测试用例中被标记，并且一些叶子类不能在单个测试用例中组合，因为这些类相互排斥。
可以计算出类似的最大准则，它给出给定CT的最大测试用例数。经验法则表明，树的叶子类的数量给出了给定树的合理覆盖所需的测试用例数量的数量级。
3.2.3示例 is_value_in_range
问题定义:
起始值和长度定义了值的范围。确定给定的值是否在定义的范围内。只考虑整数。
很明显，完成测试实际上是不可能的，因为我们得到65536 * 65536 * 65536 = 281.474.976.710.656个测试用例，即使我们假设只有16位整数。如果我们假设32位整数…好吧，我们最好不要。
3.2.3.1测试相关方面
范围的开始和长度可以看作是测试的相关方面。这很方便，因为根据问题定义，值的范围是由起始值和长度定义的。它反映了在测试期间使用不同的起始值和长度的意图。
我们应该有一些测试用例，结果是inside，而其他测试用例结果是outside。我们称之为相应的方面位置，因为被测值相对于范围的位置决定了结果。因此，用于分类的三个与测试相关的方面是初始值、长度和位置，它们构成了CT的基础:
3.2.3.2形成类
现在根据等价划分方法对基分类进行分类。通常，问题规范会提示我们如何形成类。例如，如果问题规范声明:“如果起始值大于20，长度值加倍”，那么我们应该为大于20的起始值和小于或等于20的起始值形成一个类。
不幸的是，手头的问题规范太简单，无法给我们类似的提示。然而，由于起始值可以为所有整数，因此合理的做法是为正值、负值和另一个为零值创建一个类。只形成两个类也是合理的，例如，一个类用于包含零的正起始值，另一个类用于负起始值。这取决于在测试用例中强调的范围的开始值是否为零。
由于CTM固有的系统性，并且range_length和range_start一样都是整数，因此严格要求range_length使用与range_length相同的类。这导致了下面的树:
3.2.3.3第一范围规范
要指定第一个范围(在第一个测试用例中使用)，我们必须在组合表中插入一行，并在该行上设置标记:
在第一个规格的线上设置了两个标记。一个标记为范围的开始选择类正。另一个标记选择范围长度为正的类。例如，起始值为5，长度为2的范围将符合规范。第一个规范被命名为平凡。
3.2.3.4第二个量程规范
我们可以在组合表中插入第二行，并指定一个更有趣的测试用例:
对于第二个规范，同样设置了两个标记。它们指定范围的开始和结束都应使用负值。因此，起始值为-5且长度为-2的范围将符合第二个规范。但是这个值对提出了一些问题:值-6应该在范围内吗?或者值-4应该在范围内吗?或者如果值域的长度为负，值域内应该没有任何值?每种观点都有其支持者，很难决定哪种观点是正确的。实际上，在这一点上，我们没有能力决定什么是正确的。我们发现规格有问题!
在功能问题规范中发现问题(遗漏或矛盾)，并且在功能问题的测试用例规范期间在用例中实现，这是一个有价值的结果。如果测试用例规范是系统化的，那么通常更有可能在功能规范中发现问题。CTM是测试用例规范的系统方法。因此，CTM提供了很好的方法来检测功能问题规范中的问题。
如果测试用例规范是自发的和非系统的，那么使用负长度的测试用例可能不会被使用。但是对于上面给出的功能问题说明，负长度是完全合法的。如果您认为手头的问题规范非常简单，那么您可以想象在更全面和复杂的问题规范中忽略问题的可能性有多大。
3.2.3.5通过边界类扩展树
如果我们不满足于在所有的测试用例中，一个固定的单个正值，例如5，可以作为范围的起始值，我们可以根据合适的分类对类positive进行细分。在我们的例子中，我们根据大小进行分类。这背后的思想是让一个类只包含一个值，在我们的例子中是给定整数范围内存在的最大正值。我们使用这个值是因为它是一个极值，并且正如我们所知，在测试用例中使用极值(或边界值)非常适合生成对错误敏感(或有趣)的测试用例。
在上图中，范围起始的正值根据其大小进行细分。这就产生了正常正和最大正两个类。类maximum positive保存最大可能的正值(即MAX_INT)，而normal positive类保存所有其他正值。这满足数学完备性。
备注1:另一种对正起始值进行分类的可能性是，例如对奇数和偶数值进行分类。这是完全合法的。这对于例如数论问题也可能是明智的，但对于手头的问题不是目标导向的。
备注2:请注意，目前我们不知道，也不需要知道当前问题中使用的整数的大小(以位为单位)。我们只需指定“给定整数范围内的最大正值”。这使我们的测试用例规范保持抽象!例如，我们的测试用例规范适用于任何整数大小。一旦我们假设我们使用16位整数，并因此通过指定32767作为类最大正数的值来参数化我们的测试用例，我们就失去了这个抽象。例如，如果我们将参数化测试用例移植到32位整数系统，测试用例就失去了意义。如果我们移植抽象的测试用例规范，情况就不是这样了。
3.2.3.6另一个有趣的测试用例规范
根据图3.2.3.6对CT进行扩展，is_value_in_range的CT，第四步，d，我们可以在组合表中插入额外的一行，并为第三个测试用例再次指定一个有趣的范围:
上图中的第三个范围规格将范围起始值的最大正数与正长度相结合，即范围超过给定的整数范围。第三种范围规范的情况类似于上图所描述的情况。这种情况提出了一些问题:测试对象是否能够合理而优雅地处理这种情况?还是会因为溢出而崩溃?左边的负值是否会被认为在范围内?关于最后一个问题，什么是正确的?上面的问题说明并没有给出后一个问题的答案，我们再次发现了问题说明中的一个弱点。
综上所述，根据CT方法设计测试用例揭示了问题说明的两个问题，并导致了迄今为止有趣的测试用例。
3.2.3.7完成分类树 
在上图中，描绘了一个可能完成的CT。分类描述如下矩形，按椭圆分类。“range”节点是一个包含两个分类的组合作为子元素。这棵树的讨论如下:
- 与范围起始值的类极大正值类似，引入了类极大负值。该类背后的思想是将最大负启动值与范围的负长度相结合，这将引起下流或负环绕。这个想法来自于CTM中的系统:如果一个积极的围绕被视为一个有趣的测试用例，那么也应该执行一个消极的围绕。
- 一个组合的例子是由范围给出的。组合可用于“由……组成”的关系。在本例中，范围由起始值和长度组成。
- 最后的树的特征仍然是三个初始类，对于范围的长度为正、零和负。值得注意的是，该树一眼就能看出，对于当前的测试问题，没有任何东西像最大正长度或类似的东西被认为是有用的。
- 很明显，一个位置既可以在范围内，也可以在范围外，因此这种分类是不言而喻的。此外，很明显，在范围之外有两个不同的区域:范围以下和范围以上。这就体现在分类位置之外。(如果树没有这样的分类，它很可能被认为是不正确的)。
- 分类位置内部的类很可能是分类树的叶子类。然而，在上图的CT中，该类被进一步细分为子类范围start, opposite border和inlying。这样做是为了在测试用例中强制使用边界值。如果一个测试用例规范选择了range_start类，那么检查它是否在范围内的值应该取范围的起始值，即认为在范围内的最低值，一个边界值。类opposite_border旨在创建一个逻辑测试用例规范，但是使用被认为在范围内的最大值。类range start和类opposite_border都只包含一个值。范围内的所有其他值都在类中收集;该类的存在主要是因为对等价划分的完备性要求。在边界位置的类中，可以看到使用边界值的类似方法，用于范围外的位置。
3.2.3.8完成的测试用例规范
在下一个图中，用一个完整的组合表描述了相同的CT，这导致了功能问题的完整测试用例规范:
上面的测试用例说明列出了14个测试用例。请注意，这些是由用户指定的，并取决于其判断。基于CT，可以确定一些值，为所需测试用例的数量提供线索。
第一个值是测试用例的数量，如果每个叶子类在测试用例规范中至少包含一次的话。这个数字被称为最小标准。在我们的例子中，最大数量的叶类，即7个，属于基本分类位置。因此，7是最小标准的值。最大标准是在考虑所有允许的叶类组合时产生的测试用例的数量。
在我们的示例中，最大标准达到105(即5 * 3 * 7)。最大标准考虑到不可能为相同的测试用例规范选择例如负长度和正长度，因为这是不可能通过树的构造实现的。最大标准没有考虑到它不是可以选择例如零长度和内嵌，因为这不是不可能的树的结构，而是由函数问题的语义。
测试用例规范的合理数量显然位于最小和最大标准之间。根据经验，叶子类的总数给出了获得足够测试覆盖率所需的测试用例数量的估计。在测试用例规范中，CT有15个叶子类，适合14个测试用例。
通过上图中的测试用例规格说明，您可以推断出功能问题规格说明是如何根据“第二范围规格说明”和“另一个有趣的测试用例规格说明”部分提出的问题进行扩展的:
- “如果范围的长度为负，那么范围内是否存在值?”答案是“是”，因为在测试用例规范中没有。5和no。6应采用负长度，且值的位置应在范围内。
- “如果范围的长度超过给定的整数范围，该范围内是否应包含负值?”测试用例规格编号。12澄清不应该是这种情况。
嵌入的叶子类仅为一个测试用例规范(no. 1)选择。1).这反映了这样一个事实，即该类的存在仅仅是因为对等价划分的数学完备性的要求，而不是因为认为所包含的值会产生对错误敏感的测试用例。
3.2.3.9另一个测试用例规范
下面是一个可选的测试用例规范，以替代手头描述的功能问题规范:
与上面部分中更详细的测试用例规范有什么不同?
- 范围的起始值在CT中没有提到。这意味着，CTM的用户不认为开始值是与测试相关的方面。因此，在这四个测试用例中，任何任意值都可以用作起始值。这个值可以为所有的测试用例修复，但不是必须的。
- 负长度的问题完全被忽略了。对于problem部分的问题说明，它指定长度为整数，因此长度也为负数，这是一个严重的缺陷。
- 环绕的问题被忽略了。这可能被认为是一个深奥的问题，因此在可选的测试用例规范中没有提到它是可以接受的。
- 边界值的使用不是由可选测试用例规范强制的。这是有问题的，因为边界值产生错误敏感的测试用例。可选的测试用例规范最小化了测试工作(通过只指定四个测试用例)，但是这是以彻底测试为代价的。
- 但是重点不在于哪个测试用例规范更好。其要点是:测试用例规范根据CTM可视化测试思路!
