在动手用TESSY的分类树编辑器还有生成测试数据组合的时候，很多人会把注意力放在怎么使用和怎么生成上面，其实真正要留心的地方，不是简单地把输入值摊成几个测试用例就算完事。更靠得住的思路，是先把被测函数的输入条件、会得出什么输出结果，还有那些处在边界上的情况拆解清楚，然后再用分类树这套方法组合出一批相对完整、又不会重复太多的测试数据。分类树编辑器，也就是常说的Classification Tree Editor或者CTE，它本身就是用一种图形的办法来设计测试用例规格的工具，常见的做法是先找出测试相关的方面和对应的类别，然后再把不同的类别拼成测试用例。

　　一、TESSY分类树编辑器怎么使用

　　在开始用分类树编辑器的时候，最好不要一上来就直接去填具体的数值，因为它更适合先拿来做测试思路的拆分这件事。先把输入条件、状态条件、边界条件，还有预期的结果分到不同的分类里面，然后再一步一步地去生成测试能用得上的组合，这样要顺畅一些。

　　1、明确被测对象

　　动手之前，先要把被测函数的功能说明、接口上能接收哪些参数、会返回什么值，还有它那一套异常处理的逻辑都大致看一遍，别漏掉。打个比方，如果是一个做电压判断的函数，输入这边可能就包括了电压值本身、诊断使能没有、采样是不是有效的这类信息，而输出那一头呢，也许就对应着正常、过压、欠压，或者直接报一个无效输入之类的状态。分类树往下面展开时，就得绕着这些真正要测的点去走，不能光盯着代码里面的分支去硬拆，那样容易跑偏。

　　2、建立分类和类别

　　在【Classification Tree Editor】中，把测试相关因素拆成不同分类，再给每个分类补充类别。

　　举例来说，“输入电压”这个分类，下面可以接着分出低于下限、落在正常范围里头，还有高于上限这么几种类别；而“诊断使能”这边呢，分出使能和没使能就行；至于“采样状态”，也可以分成有效跟无效两类。在做这些划分的时候，分类最好是尽量顺着需求和接口的定义去走，而不是开发人员临时想到哪里就写到哪里，那样后面很容易乱。

　　3、补充约束关系

　　分类树也不是说所有类别都能随随便便地挑出来组合在一起，有些输入条件之间天生就不太可能同时冒出来，就比如诊断功能压根儿没打开的时候，那些跟故障确认绑在一块儿的结果就不该被组合出来。好在CTE这东西允许在测试方面之间去定一些依赖的规则，而且它也能自己去生成测试用例规格，还能做些自动的检查，把这类本事用起来，就可以帮着砍掉不少没什么用的无效组合。

　　4、检查分类树完整性

　　等分类树大概搭出一个样子以后，还得掉回头去细细查上一遍，看看有没有漏掉边界值、异常的输入、状态跟状态之间是怎么切的，还有预期输出这些地方。分类树有一个挺实在的好处，就是它的结构看起来很直观，哪些输入已经被覆盖到了，哪些类别还没被用过，跟直接盯着一张Excel表格比起来通常要清楚不少。要是碰到的函数本身比较复杂，那也可以先拆出一个主干，再慢慢地把边界和异常那些场景补进去，这样不容易漏。

　　二、TESSY测试数据组合怎么生成

　　测试数据组合这件事，并不是堆得越多就越有道理，它最要紧的地方是要把主要的等价类、处在边界上的那些条件，还有异常的场景都给照顾到，同时又得躲开一大堆重复的用例。分类树这套法子，它的价值正好就落在这里，因为这套方法能把整个测试的空间拆解开，然后再靠着一张组合表把那些真正值得测的用例给挑出来。

　　1、先生成组合规格

　　通过【Combination Table】把不同分类下的类别组合成测试用例规格。

　　这一步做出来的东西，其实还不能算是最终要拿去跑的测试数据，它更像是把测试的意图先画出来，比方说一条组合可以写成这个样子：电压低于下限、诊断使能是开着的、采样也有效、然后预期跳出一个欠压故障。这种写法比直接塞一个数值过来要明白不少，因为它把“为什么要测这一条”的道理一块儿给亮出来了。

　　2、再填具体数据

　　等组合规格都定下来之后，再接着去把那一项项类别转成具体的输入值，就拿前面提到的来说，“低于下限”这一栏就可以填个9V，而“正常范围”往里面填个12V，“高于上限”那一条不妨就填16V。如果事情牵涉到了边界，那还得把下限值、比下限再小1的值、上限值、还有比上限再多1的数值这些数据都给补进去，这么一圈走下来，测试数据才不是随手抓来的，而是每一条背后都有它明明白白的覆盖目的。

　　3、控制组合数量

　　假如对每一个分类都傻傻地去做全组合，用例的数量一下子就会膨胀到很难收拾，在实际的项目里面，我们一般会先紧着正常的路径、边界的路径、出错的路径，还有那些跟安全扯上关系的路径来做覆盖，然后再把那些没什么意思的重复组合给清掉。分类树方法它本身强调的一点，就是去生成那种冗余压得比较低、又比较容易把错误给揪出来的测试用例规格，而不是闭着眼睛非要把所有的组合都轮上一遍。

　　4、关联预期结果

　　生成测试组合的时候，光是把输入填进去还差着一截，得同时把预期的输出、返回的值、全局变量会跟着怎么变、故障会落在什么状态，还有调用的结果这些东西一块儿给整理出来。因为TESSY在后面真正跑测试的时候，就是靠这些预期结果去判断每条用例是过了还是挂了。万一预期结果写得太粗线条，像只丢下一句“应该正常”就没下文了，那等到哪天用例失败的时候，再想去把问题定位出来，可就头疼了。

　　三、使用分类树生成测试数据时要注意什么

　　分类树编辑器要是用得顺手，是可以让测试设计变得清清爽爽的；可要是路子走得不对，它也可能变成另外一种形式，就是表格在那儿堆来堆去，看着热闹却没抓到实处。所以往下落地的时候，我们得把眼睛盯在几件事上：分类划得是不是合理、组合出来的是不是真的有效、数据能不能真的拿过去跑起来，还有跑出来的结果方不方便往回追溯。

　　1、不要把分类写得太细

　　刚一开始的时候，如果把每一个输入值都单独拎出来设成一个类别，那整棵分类树马上就会变得又大又笨，组合的数量也会跟着失控。更合适的做法是先照着等价类和边界的范围去拆，等到那些真正要紧的数值，再放进测试数据里面去具体化，这样树才不会乱长。

　　2、不要只覆盖正常场景

　　很多函数在正常的输入下边都能顺顺当当跑过去，可真正容易捅娄子的地方，往往是那些无效的值、卡在边界上的值、状态跳来跳去的时候，还有组合跟组合之间互相冲突的地方。所以在生成测试数据的时候，就得有意地去塞进一些异常的输入、无效的状态、超出范围的数据，还有恢复的条件，这样整个测试才撑得起实际的意义。

　　3、不要让组合和需求脱节

　　分类树里头摆着的那些分类、类别、组合，还有预期结果，最好是能一股脑儿地往回跟对应的需求或者详细设计挂上钩，这样走下来，评审的时候就能讲明白每一条测试数据到底是因为什么才摆在这里，后头一旦需求发生了什么变动，也能很快地找出哪些测试组合得跟着重新调整。

　　总结

　　TESSY分类树编辑器怎么使用TESSY测试数据组合怎么生成，整体上可以按这样一个顺序往下推：先是把测试的因素拆开，然后把分类和类别建起来，接着生成组合的规格，最后再把具体数据和预期结果填进去。分类树编辑器它不单单是一个用来填数据的家伙，更多的用处是帮着测试人员把整个测试空间给梳理清楚。测试数据的组合也不是越多就越管用，真正关键的是把需求、边界、异常，还有那些重要的状态都盖住，同时还得把手边那些没什么价值的重复用例给减掉。