在单元测试的收尾阶段，TESSY测试文档到底该怎么去生成，它的格式又要怎么去调整，这是很多项目在准备交付评审时都会撞上的事情。实际工作中，不少团队在TESSY里已经把测试用例设计好了、桩函数也配过了、覆盖率也统计了、连执行结果都确认完了，可等到真要拿去给别人看的时候，才发现手头的测试文档要么内容不完整，要么格式乱糟糟的不统一，再要么就是测试报告跟项目的其他证据对不上号。TESSY的测试文档，并不是简单导出一份报告就能算完事的，它还得能把测试的对象、测试的环境、测试的用例、执行的结果、代码的覆盖率，还有缺陷的处理情况都给说明白，这样后面才能稳稳地撑住ASPICE、ISO 26262这些评审，或者企业内部的质量审查。

　　一、TESSY测试文档怎么生成

　　在动手生成TESSY测试文档之前，有一件事得先做，就是去确认当前的测试工程本身是不是已经完整的。假如用例还没有全部执行完，覆盖率的结果也还没有刷新过，桩函数的配置也没顾得上保存，那这个时候直接导出来的报告，充其量也就是个只做了一半的半成品。文档的生成，绝不是最后关头随手去点一下导出按钮就行的，它必须建立在测试数据全都已经整理妥当的基础上，这样才有意义。

　　1、先检查测试工程状态

　　在生成文档之前，要把测试对象、测试用例、测试数据，还有执行的结果都确认一遍，看它们是不是全都更新到了当前的版本。特别是那些代码刚刚才被改过、用例刚刚才被调整过、覆盖率刚刚才重新统计过的项目，尤其不能贪图省事去继续沿用旧的报告，要不然的话，报告的日期倒是新的，可里面躺着的数据却还是对上旧版本的，等到评审的时候，被人追问起来就容易站不住脚。

　　2、通过报告功能生成测试文档

　　进入【Report】功能后，根据项目需要选择单元测试报告、测试结果报告或覆盖率报告。

　　这一步主要是选一下报告的类型，不同类型的报告关注的东西是不一样的。单元测试报告更适合拿来展示测试的对象、用例和结果；覆盖率报告就更偏向于去说明语句覆盖、分支覆盖、MC/DC这些情况；如果项目这边需要一份完整的交付物，那通常会把测试结果和覆盖率的内容一并导出来，搁在同一个文件里。

　　3、确认导出范围和版本信息

　　在导出之前，一定要先确认好报告的范围，是只导出某一个测试对象，还是把整个测试集合都导出来。报告里面，最好能体现出软件的版本、测试工程的版本、工具的版本、编译的环境，还有执行的时间。测试文档最怕的就是看起来结果都是通过的，可翻遍了却不知道它对应的是哪一个版本，所以版本这一类信息，一定要和代码基线、测试用例基线保持一致才行。

　　二、TESSY测试文档格式怎么调整

　　调整TESSY测试文档的格式，最主要的目的是让这份报告能更适合拿来交付，而不是光保留着工具默认生成的那种样子。工具自己吐出来的默认报告，也能把基本的结果说清楚，可是一旦到了正式评审、客户交付或者流程审查的场合，往往还需要往上头再补充项目名称、版本信息、测试的范围、执行的结论，还有签核信息这些内容。

　　1、先把文档结构统一一下

　　测试文档的结构，一般可以照着测试概述、测试环境、测试对象、测试用例、执行结果、覆盖率结果、问题记录和结论这么几大块来搭。这样组织起来，读的人会感觉比较清楚，评审人员想要快速翻到某一块内容也会很方便。如果只是把工具导出来的东西原封不动地塞进去，信息也许是有的，可它的阅读顺序却不一定对得上人家交付的习惯。

　　2、调整报告模板内容

　　在【Report Settings】中，可以根据项目要求调整报告章节、显示字段和导出内容。

　　在调整模板的时候，建议把测试对象、用例编号、输入数据、预期结果、实际结果、执行状态，还有覆盖率这些信息都给留下来。至于那些不需要交付出去、仅仅是用做调试参考的字段，可以适当地删掉一些，别让报告显得太臃肿。调整格式的重点，倒不是为了省篇幅去砍内容，而是要保证那些真正关键的证据能让人一眼就找到，不用在厚厚一沓纸里翻来翻去。

　　3、补上项目交付需要的信息

　　工具自动生成的报告，内容往往更偏向于测试结果本身，但真正做项目交付的时候，还得额外补充一些说明进去，比如这次测试圈了多大的范围、有没有哪些项是没测到的、碰到的异常又是怎么处理的、有什么限制条件，还有评审的记录等等。特别是那些自动生成的代码、第三方的代码，或者那些没办法直接去测试的底层接口，一定得在文档里交代清楚，到底用了什么替代的办法去验证的，千万不能让那块地方就那么空着、一句解释都没有。

　　三、TESSY测试文档怎么作为证据留存

　　等TESSY的测试文档生成出来以后，还要再想一步，就是这些东西该怎么去好好地归档和追溯。单元测试的证据，不能只看最后生成的一份PDF或者Word文档就了事，而是要能做到跟需求、详细设计、代码版本、测试用例，还有缺陷的记录，一套东西都能够对应起来。也只有这样子，往后走项目审查的时候，才不会出现报告是孤零零的、证据跟证据之间断开了的情况。

　　1、把报告和测试基线对应起来

　　每一份测试文档，都得对上一个明明白白的软件版本和测试版本。就比如，某一次代码修改过后重新执行了测试，那就要重新生成一份测试报告，并且在文档里说清楚它对应的是哪一条代码基线。千万不能用旧的报告去覆盖新代码的结果，也不能光是给报告换个新的封面，里面的实际测试内容却还停在老地方没动。

　　2、保留关键的原始证据

　　除了导出那份测试文档，TESSY的工程文件、测试用例的数据、桩函数的配置、覆盖率的结果，还有执行的日志，这些东西都应该一块儿保留下来。

　　这样做是为什么呢，就是为了往后面需要的时候，还能回过头去把测试的过程再翻出来复查一遍。要是报告里出现某条用例先是失败了，后来又被修成通过了，那我们就能顺着当初的原始记录，去查查它到底是什么原因被改的，复测的结果又是个什么样子，而不是只能看到最后那一个冷冰冰的通过结论。

　　3、检查文档和缺陷记录是不是一致的

　　如果在测试的过程中确实发现了问题，那就要去确认一下，测试文档里记下来的失败情况、相关联的缺陷单、代码修改的记录，还有复测的结果，这全套东西能不能彼此对应上。很多项目出毛病的根子，倒不是因为没做测试，而是在缺陷都已经被关掉了的情况下，测试报告却没有同步去更新；要么就是报告看着一片绿，全是通过的，可缺陷系统里头却还挂着没处理干净的问题，这一类不一致的地方，会直接把整份文档的可信度给往下拽。

　　总结

　　TESSY测试文档的生成和格式调整，最关键的地方并不是单纯地往外导出一个文件就拉倒，而是要先去保证测试工程里面的数据是完完整整的，然后再去挑一个对路的报告类型和导出范围，末了再对照着项目交付的要求，把报告的章节、显示的字段，还有版本的各类信息好好地归置一遍。等到文档生成出来以后，还要把TESSY工程、测试报告、覆盖率结果、执行日志，还有缺陷闭环这一圈材料统统留档保存。这样一路整理下来，产出的测试文档才不再只是工具自己吐出来的那点东西，而是真正能拿去给评审用、给交付用、给质量追溯用的有效证据。