八、产品发布
当测试产品达到测试计划所制定的产品质量目标和测试质量目标，整理产品发布包和编写相关文档，在发布前对照功能列表进行一次全面的确认测试，确认发布包和文档完整后进行产品发布。对于新产品来说，必要的文档必须包括：（1） 产品安装操作手册;（2） 产品白皮书;（3） 产品管理维护手册;（4） 用户操作手册;（5） 总体测试报告（6）性能测试报告。
九、版本控制
在测试过程中，软件的打包统一由Build Master完成。新版本软件发布之后，马上对代码进行 质量控制：（1） Build Master给新版本的源代码打一个cvs tag，方便代码回滚check out。比如，发布版本为IAGW1.0.0，则给该软件源代码也打一个与发布版本相同名字的tag IAGW1.0.0。这样做的一个好处是，在目前的软件的基础上做了修改并发布新的版本后，如果需要check out某个版本的源代码，则可以通过这个版本的tag来check out，代码的修改可以在该版本上进行。（2） Build Master对新发布的软件源代码进行cvs lock，不允许开发人员在软件发布之后commit源代码，直到有新版本需求修改再给开发人员开放commit权限。这样做的好处是避免开发人员随意修改和commit源代码，确保源代码服务器上的源代码版本与当前最新的发布版本一致。
十、自动测试
产品稳定后，进行自动 测试工具开发，对于稳定的功能使用自动测试工具进行测试，新增的功能使用手工测试，使用自动测试+手工测试的模式，可以大大提供测试效率。
十一、小结：应用推广思路与体会
整体思路是：首先对项目进行需求分析，有效的需求分析方法是需求分析人员、 项目经理、开发经理与测试负责人分别阅读规范与原始需求，特别是需求分析负责人与项目经理，需要对需求进行深入的分析研究，然后开会讨论，消除对需求的误解与遗漏，讨论结束后编写功能列表说明文档与需求规格说明书并评审；对于规范中不明确的问题集中后由测试负责人（或需求分析负责人）直接与移动总规范负责人直接交流，确保不会因为规范的理解不正确导致项目实现与需求不一致。需求分析完成后，编写项目计划书与测试计划书；项目计划、测试计划编写前先开会讨论，由模块负责人估算工作量，能确定的问题和时间安排都在讨论中确定下来，然后根据工作量和工程需求制定项目计划和测试计划。开发在编码前需要进行概要设计和详细设计，开发工程师在编码前对系统的总体设计架构、各自所负责的模块有一个清晰的设计思路，经评审后确认模块的设计是否合理；开发在编码完成后在提交测试前必须进行单元测试与联调测试，提交给测试的软件是一个可运行的产品。测试工作中，在项目设计或编码阶段，测试负责人对项目进行测试设计，指导测试实施有依可循，在编写案例的过程中会遇到很多与流程和细节处理相关的问题，与开发一起讨论也有助于提前发现问题与完善代码；在测试实施阶段，测试人员记录所发现的问题，并协助开发及时解决，在测试过程中所遇到的问题，测试负责人进行记录和分析，在每个阶段完成后提交经分析后的测试阶段报告，在 软件测试阶段报告中总结分析了测试过程中所发现的问题并对这些问题提出解决建议，在后续的开发与测试中进行改进与调整，确保项目能够按时保质发布。为了节约 资源，计划或设计都是以邮件的形式进行评审；对于存在严整分歧的问题，组织一个小型 会议进行讨论有效解决问题，小型讨论会是解决问题的一种有效途径，任何问题都可以通过face-to-face的交流达到共识。软件的管理和版本管理则由Build Master负责，确保软件得到良好的控制。在整个项目实施的过程中，需要有一个PPQA对流程进行检查与监督。
这个精简的实施流程，不但确保了软件的质量，而且实施成本较低，在 团队实施中非常容易推广。 在整个流程中，测试负责人除了负责测试相关任务以外，同时承担了需求管理、流程跟踪、协调 沟通等工作（当然，也可由项目经理或开发经理等担任），在其中由测试推动项目开发与实现，在开发成员之间、开发与测试之间搭了一座沟通的桥梁，这样的一个协调与推动促进了项目的顺利完成，适合于五至二十的小型团队。不过这种测试与开发的模式，对测试负责人的要求很高，不但要求测试负责人具有很强的责任心与沟通协调能力，而且还需要具有很高的业务分析能力和 CMMI5实施经验。
文章来源于领测软件测试网 https://www.ltesting.net/
