对异常终止情况，要确定未能被测试活动充分地覆盖的区域。且将理由记录于总结报告的“测试充分性评价”一章内（见GB 9386）。
确定未能解决的软件测试事件以及不能解决的理由，并记录于测试总结报告的“结果概述”一章中。
b. 描述单元状态
将通过测试所反映的单元与其需求文件之间的差异记录于测试总结报告的“差异”一章中。
将测试结果及所发现的错误情况同需求对照，评价单元的设计与实现，将评价信息记录于测试总结报告的“测试充分性评价”一章中。
c. 完成测试总结报告
根据GB 9386，完成测试总结报告。
d. 保存测试文件
确保测试得到的成果的收集、组织和存储。以备调用及重用，这些成果包括测试设计说明、附加和测试用例说明，附加的测试规程说明、测试数据、测试用例的产生规程、测试驱动程序和桩模块以及测试总结报告。
4.8.3 输出
a. 测试总结报告（从4.8.2 条的c得到）；
b. 测试成果的收集存储（从4.8.2 条的d得到）。
附录A
实现及使用指南
（参考件）
本附录包含使用本标准时有益的信息。因此建议在作出更作详细的计划之前先阅读本附录。
A1 标准的使用
本标准有以下作用：
a.作为确定当前的实践活动而比较的基础；
b.作为修改当前实践活动的思路之源；
c.作为当前实践活动的替代物。
A2 附加的测试需求
对每个项目，象附加测试文件（如测试日志）的数量，应当描述的细致程度及批准、复查的数量和类型等等这样的需求都应详细说明，有些因素，如单元的批语意见，读者需求或合同说明会经常影响这些需求，本标准将这种需求留给用户自己去描述，该描述可作为单独项目的需求，亦可作为某个组织的标准。若这些需求是某个项目特指的，则应在项目计划、质量保证计划、证明及验证计划或全局的测试计划中进行描述。
A3 附加的测试文件
一般认为。测试设计说明和测试总结报告中包含的信息是完成测试过程后得到的最小文件集合。另外，通过在这些文件中增加内容或增加额外的文件，GB 9386中描述的测试文件集可以满足所要求的任何测试信息。
A4 认可及评审
如要求更多的控制，应考虑以下附加任务：
a.在计划阶段的末尾认可总的方法；
b.在确定测试特性阶段的末尾认可所确定的需求
c.在细化计划阶段的末尾认可所描述的计划；
d.在设计测试集的末尾认可测试说明；
e.在实现测试阶段的末尾认可测试准备情况；
f.在评估阶段认可总结报告。
A5 审计
当描述控制需求时有必要考虑审计问题。因此，应当从测试评审中产生足够的测试文件及报告，以满足所要求的所有审计信息。
A6 配置管理
配置管理以软件需求、软件结构设计、软件数据结构及单元需求作入输入源。必须合理地管理这些输入文件，以便确保我们持有的是现行的信息，并且任何变动都能得到通知。
单元测试的最终文件也应进行配置管理。必须管理好这些输出文件以便进行全面而经济的测试，详见GB/T12505。
A7 确定基于需求的特性
对单元开发人员而言，当在测试中确定基于需求的元素（如特性、状态转换、数据特征）的有效集合时，心理因素（如自信心，关于单元设计的详细知识）起了阻碍作用。通常，这样的“确定特性”过程应当由其他人来完成。
有以下几种方式完成这种活动：
a.开发人员之间相互确定这些特性；
b. 开发人员之间完整地测试他人的代码，这带来的优点是至少两名开发人员将会熟悉每个单元的详细知识；
c.组织一个独立的测试小组。项目的大小或软件的重要性可以决定是否适合组织这样的独立的测试小组
若开发人员为自己的软件确定基于需求的元素，他们应当的软件设计开发之前完成这种确定工作。
文章来源于领测软件测试网 https://www.ltesting.net/
