9、测试组长对于通过稳定期测试的产品填写综合测试报告，测试中心依此发布产品发行通知。
10、测试组对整个测试过程和产品质量进行总结和评价，形成文档并备案。同时，将测试过程中对测 试设计的改动纳入基线。最后，组长整理并在指定地点保存相关测试数据和测试样张。
11、测试中心解散测试小组。
另外，在系统测试阶段，我们要求测试小组要进行一些常规内容测试(如：Y2K测试，病毒检查、裸机
测试、加密检查、说明书检查…)，并要求写入测试方案中。
4、传统测试流程遇到的挑战和对策----问题发现得越早，解决的代价就越小
1、 自动测试工具和测试理论
由于我们的产品开发模式还不够规范、相关文档不够完备，所以测试工具的应用效果不理想，只能部 分应用。如：SQA。
对于测试理论，测试思想/测试理念的灌输工作还是有成效的，但是测试数学模型的研究和建立工作 进展不顺利，主要原因也是我们的产品生命周期内部操作不够规范。
目前主要依赖于：测试人员的经验和素质;产品说明文档和项目组的技术咨询;测试设计。
2、 测试分类
根据目前的实际情况(已经由传统的瀑布开发模式、使用结构化设计和实现手段，变为现在的RAD开发 模式、使用OOD和OOP)，我们将把测试分为三种：产品测试、项目测试、系统评测。我们的依据是：问题 发现得越早，解决的代价就越小。
产品测试的流程基本和上面提到的一样。
项目测试的原则是尽早加入测试，并充分重视和支持用户测试。
系统评测是简化工作流程。
三、 测试中常见问题分析及对策
我们一般把发现的错误bug(我们也称为缺陷defect)按严重性分为4类：死机(系统崩溃或挂起)、致命 (使系统不稳定、或破坏数据、或产生错误结果，而且是常规操作中经常发生或非常规操作中不可避免 的)、严重(系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果，如：显示不正确但输出正确)、一般(界面拼写错误或用户使用不方便)。
我们也把发现的错误按优先级分为三种：高、中、低：一般是越影响用户接受或使用该产品的错误优 先级越高。
但下面，将不对所有的问题进行列举和分析，而只是列出一些显而易见的、容易被项目组忽略的错 误，这些错误可能是容易修改的、或是容易避免的，但是对于测试组或用户来说可能却是非常头痛和不方 便的。
文章来源于领测软件测试网 https://www.ltesting.net/
