對異常終止情況，要確定未能被測試活動充分地覆蓋的區域。且將理由記錄于總結報告的“測試充分性評價”一章內（見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.組織一個獨立的測試小組。項目的大小或軟件的重要性可以決定是否適合組織這樣的獨立的測試小組
若開發人員為自己的軟件確定基于需求的元素，他們應當的軟件設計開發之前完成這種確定工作。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
