如果只是盯着这一轮测试是通过还是失败，那TESSY历史结果的对比和回归差异的定位能看到的东西其实很少。回归测试真正要去解决的问题，是在代码、测试数据、桩函数、编译环境甚至目标平台发生过变动以后，确认原来已经跑通的那些功能有没有被意外碰坏。所以动手做历史结果对比之前，一定得先把用来比较的基准给找稳了，再一茬一茬地把差异拆开来细看，不能一瞧见Fail就急急忙忙判断代码里头出了毛病。
一、TESSY历史结果怎么做对比
开始比对之前，头一件要做的事就是先把“谁和谁在比”这件事给闹明白。不少冒出来的回归差异，并不是功能本身真的变坏了，而是因为拿来对照的那份历史结果、测试当时的配置，或者是执行环境压根儿就没对上号，弄得这两份结果搁在一块儿根本没有什么可比的地方。
1、确认对比基准
光靠一句“过去通过了，现在失败了”是远远不够用的，还得去弄清楚过去那个结果指的到底是哪一次跑出来的。比方说，上一次的测试是在本地的仿真环境里转的，这一轮却被搬到了目标板上头去；上一次挂接的还是旧版本的桩函数，这一次却给换成了活生生的真实依赖模块；像这两批结果要是硬拿来比，那比出来的结论自然也是站不住脚的。
2、检查历史报告
通过【测试报告】核对历史执行时间、测试对象、用例数量、执行环境和通过失败状态。
翻看的时候，要特别留颗心去瞅瞅测试的范围到底变了没有，比方说有没有新加进来的用例、有没有旧用例在什么时候被悄悄删掉了、当初填进去的输入数据是不是被人动过，还有那些预期结果又是不是被重新调整过。如果用例本身的内容都跟从前不一样了，那么结果上冒出来的这点差异，就不一定非得是代码回归捅的娄子，说不定只是测试规格更新之后带来的一种挺正常的变化。
3、对比用例状态
给用例的状态做对比的时候，比较省事的办法是先把它归拢成几堆来瞧：过去明明是通过的、这一次偏偏就挂了；过去是失败过的、这一回反倒给通过了；新加进来的用例一上来就失败了；还有那种一直撂在旁边没被执行过的，以及测到一半就冒出异常情况的。在这些个类别当中，最值得提到前头来料理的，就是那些“以前能顺顺当当通过，现在却莫名其妙挂了”的用例，因为这种情形最能够说明问题，它很可能是代码的修改、配置上的变动，或者是某些依赖模块的行为和以前不一样了，才把原有的功能给捎带着影响到了。
4、查看输出细节
历史结果的比对是不能只盯着最后那一个Pass或是Fail就停下来的，你还得去翻一翻返回来的值、瞧瞧它往外头吐了什么样的输出参数、那些全局变量是怎么悄悄变化的、桩函数从头到尾到底被喊了多少次，还有一些接口在调用的时候到底排了个什么样的先后次序。有那么一些问题，最后的测试结果冷不丁看过去还是能挂着通过的，可其实在半道上，某些中间的数据早就已经变了味道了；要是对这样的挪动没能及时地瞧出来，往后面去它就有可能慢慢憋成一个藏得更深的回归麻烦。
二、TESSY回归差异结果怎么定位
等到了要给回归差异定定位的那一步，最好别一上来就急急火火地去改手边的测试用例，也别一开口就把矛头对到工具是不是出了什么岔子上头。更靠得住一点的做法，是分成不同的层去把差异的来源捋上一遍，先往代码那块儿去瞧一瞧，然后再掉回头来查一查测试的数据，接着再去看看桩函数的情况，等这些都扫完了，最后还要去核对一下跑这些用例的环境到底是怎么配的。
1、先看代码改动
如果那些挂了红叉的用例碰巧就盖在了这一轮被改动过的函数、分支、判断条件，又或者是外接的接口上面，那就要头一个去检查这些地方的代码逻辑。比较常撞见的毛病是：卡边的条件跟从前不一样了，处理异常分支的那个套路和以前不一个样了，状态变量在更新的时候顺序给打乱了，又或者是代码里面新塞进去了什么保护条件，可原来拿过来的那一套测试数据已经没本事再去够着当初设好的预期结果了。
2、核对测试数据
检查【测试数据】中的输入值、预期输出、前置变量、全局变量初始值和桩函数返回值是否与历史版本一致。
有挺多回归上的差异，这口锅倒真不该让代码来背，而是测试数据被人家动过了以后，没有跟着在后头补上一句交代的话。就比如明明输入的值已经转到了另一边，可预期结果却还撂在旧的地方没挪窝；桩函数的返回值是改了，但挂在一旁的用例说明却连个标点都没更新；又或者某个全局变量在刚开始的时候少给它塞了一个值，照这么跑下去，捣腾出来的执行结果就很容易跟历史上的记录走得完全两路。
3、检查桩函数行为
桩函数那边哪怕只是稍微动了一动设置，也是很能搅乱回归结果的一件事情。比方说，过去那个外部的函数回回见到你都是老老实实返一个成功过来，可这一轮却闷声不响地给你撂回来一个失败；过去明明是被连着喊了两次才停嘴的，现在却只被叫了一次就没了下文；又或者是以前调用的时候人家是按着A、B、C这样的次序来排的，这一回却硬是跳成了一个A、C、B这样的先后关系。撞上这种情况，就一定得把调用记录给铺开来，好好地分清楚这到底是那个被测代码自己真正的行为已经转向了，还是光光因为桩函数的配置被人拨了一下才闹出来的岔子。
4、排查执行环境
万一到了这一步，代码、数据和桩函数这几块瞧着都还是老模样，那就得顺着藤再去摸一摸编译选项、宏定义、头文件的版本、目标平台，还有数据类型的长度这些个地方。在嵌入式C的测试这片地里，哪怕仅仅是一个宏开关、结构体对齐方式的调整，或者编译器选项的细小差别，都可能让同样的一条用例跑出完全不同的结果来。
三、TESSY回归差异结果怎么闭环
把差异的地方定位清楚了以后，这件事还不能就在这里把活儿停掉，得把整个处理的过程好好地留下来才成。要不然的话，这次靠着人工判断把问题对付过去了，等下个版本再冒出类似的结果，团队里的人还是照样闹不明白这到底是一次正常的变化、是测试方面捅的篓子，还是代码里头真的藏着缺陷。
1、记录差异原因
在【回归差异记录】中写清用例编号、历史结果、本次结果、差异现象、原因判断和处理结论。
这份记录倒不用被写得多么复杂，但它一定得能讲明白结果为什么要变。比如说，是因为需求改了所以预期的值得跟着调整；还是代码确确实实有毛病，把原来好端端的功能给弄坏了；又或者压根儿就是桩函数的配置弄错了，搞出了一场误报，这都得一一说清楚。
2、区分处理方式
不同的原因，后头跟着的处理办法也应该是各走各路的。如果碰见的是代码缺陷，那就得先修复，然后再老老实实地复测一遍；如果是需求或者设计上的合理变化，那就要同步去把用例和预期的结果给更新掉；而要是仅仅出在环境配置上面，那就干脆把配置改正过来，再重新执行一次。不能所有冒出来的差异都图个省事，随随便便写上一句“已更新用例”就翻过去，那样的话，往后再想去追溯当初到底是因为什么原因才出的错，就会很费劲了。
3、保留复测证据
差异被关掉以后，一定得把新跑出来的执行结果、测试报告、问题记录，还有那些必要的评审说明都给保存好。特别是当这些差异跟安全相关的功能扯上关系的时候，回归差异的确认绝不能光靠嘴上说说就过去，一定得能让人看得见最后的复测是不是真的通过了，以及那份关闭的结论底下到底有没有实实在在的证据在后面撑住。
总结
总地来说，TESSY的历史结果对比和回归差异定位，咱们不妨照着“先确认比对的那个基准，再去对比用例的状态，接着查看输出里头的细节，然后一层一层地去定位原因”这么个思路来走。回归测试这东西，本来就不单单是为了去看那些红红绿绿的结果，而是要去把结果为什么发生变化给解释清楚。把代码的改动、测试数据、桩函数的行为，还有执行的环境都一项一项排查明白了，再顺手把差异的记录和复测的证据给补齐，到了这个时候，TESSY的回归结果才算是真正地跑完了一个闭环。
