在单元测试、集成测试、回归测试，还有那种对安全要求特别严格的软件验证里面，testbed的测试数据要怎么去隔离开，还有，数据串着用了的问题，又要怎么去避免它，这一类的情况是会经常碰到的，拿跟它相关的那一套工具链来打个比方，测试的管理、执行出来的结果、覆盖率的统计，还有需求的追溯，这几样东西，是可以被放在同一套验证的流程里面，去统一管起来的，而且，它还会靠着分析代码的控制流和数据流，去把单元的接口、参数、全局变量，还有返回值这些信息，给摸清楚，可也正因为，数据能钻进来的入口实在是多，结果又是环环相扣的链条，所以，一旦测试的数据给混着用了，它就会去影响到对用例的判断、对覆盖率的解释，还有最后评审得出来的那个结论。

　　一、testbed测试数据要怎么去隔离开

　　要把testbed的测试数据给隔离开，首先就要把输入的测试数据、心里预期的那个结果、桩函数要返回的值、全局变量一开始的状态、执行过程里打出来的输出，还有最后记下来的日志文件，这好几样东西，给分开来管，可不要把所有的数据，一股脑儿地全都给堆在同一个文件夹里面，更不要，让好几个不同的用例，去共用同一份会被改来改去的数据。

　　1、去照着用例，一个一个地给它们建好数据的目录

　　对于每一个用例，都去单独地给它建好，用来放输入数据的、放输出结果的、放预期结果的，还有放那些临时文件的目录，目录的名字里面，可以把模块的名字、函数的名字、用例的编号，还有它的版本号，都给带进去，就比如，刹车控制模块的第一个测试用例的输入数据，这么起名字，那到了后面，就算是把一大堆用例放在一起去跑，也都能搞清楚，哪一份数据，是归哪一个用例管的。

　　2、去把做初始化的那个入口，给它固定下来

　　在每一条用例，开始被执行以前，都得去把全局变量、静态变量、桩函数的状态、缓存的文件，还有环境里面设好的那些参数，全都给恢复成，事先已经指定好了的那个初始值，尤其是在用C语言写单元测试的时候，上一个用例跑完了，把某个全局变量的值给改掉了，要是紧跟在后面的那个用例，没有去重新把它给初始化一遍，那它跑出来的结果，就很容易被前面那个用例，给弄脏了。

　　3、去把那种只拿来读的数据，和跑起来才产生的数据，给区分开

　　像基准的输入数据、心里期望的输出数据，还有参数表，这一类的文件，最好是把它给设成只能读不能写的，或者是把它给纳进配置管理里面去管起来；至于那些在跑的过程当中，新生成出来的中间文件、实际跑出来的输出结果，还有日志，就应该把它们给放到一套独立的、专门放结果的目录里面去，只读的那些数据，只要它不会被测试过程，给动手改写掉，那到了后面，再去重新跑一遍的时候，才能有一个牢靠的依据。

　　4、去照着版本，把数据的基线给锁死

　　测试用的数据，是要跟代码的版本、测试脚本的版本，还有桩函数的版本，给死死地对应起来的，只要代码动过了、接口被改掉了、判断的门槛值也变了，那测试的数据，就得跟着去重新确认一遍，可不能再继续拿着旧的、过时了的数据，去解释新跑出来的结果。

　　二、数据串着用了的问题要怎么去避免

　　数据会串着用，这通常倒不是哪一次操作上不小心，而是因为在命名、目录、做初始化、同时跑好几个任务，还有结果怎么保存，这些事情上，没有定下来一套清清楚楚的规矩，要想去避免串用，那就要让每一条用例，都有它自己明明白白的边界，要让那个执行的工具，在它开跑之前，还有跑完了以后，都能留下可以去追查的记录。

　　1、在起名字的时候，不要光靠着干巴巴的数字

　　可不要只用1、2、3这种数字，去给测试的数据起名字，更合适的做法，是把模块的名字、函数的名字、是在测哪一种场景，还有用例的编号，都给写进那个文件的名字里头去，就比如说，一个叫速度计算的、测无效输入的、编号是三的用例，它的数据文件就可以带着这些信息，名字看着长那么一点，其实没有多大的关系，能让人一眼就看明白，那是要比等到事后，再抓破脑袋去猜，要省下不少时间的。

　　2、要躲开那种，好多个用例都往同一个文件里写结果的情况

　　有一些数据串用的问题，它的根子，就出在输出的文件，被取成了一模一样的名字，就比如，所有的用例，都把结果写进一个叫结果的文本文件里，那在跑批量的那一下子，后面跑完的结果，就会把前头的结果，给严严实实地盖掉，弄到最后，一眼望过去，就好像是某一些用例，它也不知道为什么，就稀里糊涂地通过了，或者是失败了，所以，输出的文件，也得把用例的编号给带上，又或者，是让跑批量的那个脚本，自己去给每一个用例，都建一个单独的文件夹。

　　3、要是在同一时间里跑好几个任务，那就得把工作区给隔开

　　要是测试的任务，它是会同时被并排着跑起来的，那每一个任务，都得去用一套属于自己的、独立的工作目录、临时目录，还有存放日志的目录，可不要让好几个正在跑的进程，在同一时间，都去读写同一份中间生成的文件，也不要让它们，去共享那种会被改来改去的、桩函数的配置文件。

　　4、在重新开始跑以前，要先把旧的结果给打扫干净

　　在再一次动手去执行以前，要先去把上一轮跑出来的实际输出、临时的缓存，还有旧的日志，都给清理掉，只去保留那些，已经被管起来的、受控的输入数据和期望的结果，要不然的话，新跑出来的结果，跟以前的旧文件，就全给搅和到一起去了，等到评审的时候，你是非常难去判断，这一次跑失败，它到底是因为这一轮代码的问题，还是上一次跑完，剩在那里的旧东西在作怪。

　　三、测试的记录，要怎么去证明数据没有被串着用过

　　测试数据的隔离这件事，就算是做得再好，你也得能在书面的记录里面，把它给讲得头头是道才行，当客户来评审，或者是做过程审核的时候，你不能就光靠嘴说一句“数据已经是隔离开的了”，就完了，你得能拿得出来，目录是怎么建的、版本是怎么管的、执行的日志是怎么写的，还有结果，又是怎么去跟这些一一对应上的。

　　1、去把数据的清单给留下来

　　在每一批测试动手以前，都去把那份数据的清单给整理好，在这份清单里头，要把用例的编号、输入的文件是哪些、期望的结果是哪个、桩函数是怎么配的、执行的脚本又是哪一个，还有结果最后被输出到了哪里，都给写得明明白白，这份清单，倒不用搞得有多复杂，但是它得能把每一条用例，跟它所对应的每一份数据，都给稳稳当当地挂上钩。

　　2、去把执行的日志给留下来

　　在执行的日志里面，是要能一眼就看得见，测试是在什么时间跑的、用的是哪一版的代码、跑的是哪一条用例、数据都是从哪条路径里取出来的、执行完了以后是个什么结果，还有报告被搁在了哪里，等到出了失败的时候，要先顺着这份日志，去往回倒腾，看看到底是从哪里拿的数据，可别一上来，直接就动手去改用例，或者是去改心里期望的那个结果值。

　　3、去挑几个用例，做一下复跑的验证

　　对于那些特别关键的用例、曾经跑失败过又修好了的用例，还有覆盖率看着不大对劲的用例，是可以去挑几个出来，让它们再重新跑上一遍的，在复跑的时候，要拿着跟原来一模一样的数据基线去跑，然后把两次跑出来的输出结果，给放到一起去比一比，看看它们到底是不是一样的，要是发现结果它不太稳定，那就得回过头去查一查，是不是初始化没做好，或者是数据隔离那里，出了什么纰漏。

　　4、去把造成异常的原因，给写进记录里面去

　　一旦发现了有数据串用的情况，就要去把它记下来，到底是目录给混着用了、输出的内容被不小心盖掉了、有变量忘了做初始化、还是上回的旧缓存留在那里没清干净，又或者是因为好几个任务一起跑，发生了冲突，等把这些都处理完了以后，还要再补上一步，为了防止它再犯，都做了些什么动作，就比如，把命名的规则给改了一下、多加了一步清理的脚本、或者是把工作区给拆开了。

　　总结

　　testbed的测试数据，要怎么去把它给隔离开，这件事的关键，就是要让每一条用例，都能拥有属于它自己的一套、独立的输入数据、期望跑出来的结果、实际运行时的输出，还有做初始化的那一整个过程；而testbed的数据串用问题，又要怎么去避免它，这里的重点，则是要去把命名的规则给统一好、把文件存放的目录给分离开、把旧的结果给清理干净，还有，把那些会同时跑起来的任务，它们的工作区也给控制好，等到测试数据的边界，都被弄得清清楚楚了以后，那么不管是问题的复现、对覆盖率的解释说明、报告的归档，还是审核时候的答疑，就都会变得更加稳当，也就不至于，会因为一份数据被串着用了，就把整批测试最后得出来的那个结论，都给生生地拖进一种，怎么都说不确定的被动局面里面去。