确定补丁包的内容(详见补丁包的内容)–制定补丁包测试计划–补丁包测试准备–补丁包测试执行–补丁包成品测试–补丁包发布–项目收尾。
补丁包内容的选择：
一般情况下，评估某一需求是否可以被加到补丁包里的最根本的原则说起来很简单，那就是不能破坏客户已有的功能实现，包括产品发布时的功能实现及客户针对产品的拓展接口作的定制实现。
评估某个需求是否可以被补丁包所包含时，需要考虑以下几点：
该需求实现时对已有客户的意义和重要性，对潜在客户的意义和重要性。
产品的开发部门能否按计划实现需求的功能设计、代码并完成单元测试。
产品的测试部门能否按计划实现需求的功能测试、性能测试及所有可能需要的其他测试类型，即对新功能需求实现完整的测试覆盖。
制定补丁包测试计划：
开发、测试期间要做的所有事情都需要考虑并计划在内，包括潜在的风险、对上游问题可能的依赖、对下游问题的影响、当前存在的问题、如何解决或规避问题等。
补丁包测试中回归测试的范围：
需要依赖回归测试来保证在补丁包中解决的问题或者引入的新的功能增强不会对系统已有的功能点造成破坏
为了合理地界定回归测试的覆盖范围，需要和负责特定产品模块的开发人员和模块测试专家进行详细探讨。
软件版本、平台、浏览器和测试内容的搭配矩阵：补丁包测试必须包含多个不同的操作系统和多种不同的应用服务器的搭配。
测试计划的审阅流程：
要有一个清晰的审阅人员名单列表，预留足够的时间个审阅人以保证计划能够得到很充分的审阅，可以考虑通过离线交流或组织审阅回忆来尽快地用最有效的方式在不同的审阅人之间就某个特定问题达成一致，更改的计划被正式提交进行审阅后必须有记录来描述相应的部分。
最终审批之前要保证所有的必要审阅人的意见和建议都得到了很好的回复且得到了他们的同意。
补丁包测试准备：
遵循测试计划，在测试机到位后，将测试机的宿主操作系统安装上，鼓励测试人员对计划进行通盘的解读和了解。
如果开发人员在解决一个特定问题时发现该问题比较严重，需要及时对问题进行初步定位分析，并和售后支持部门沟通问题本身的描述是否到位，是否遵循了代码版本控制的模块。
测试组长可在这期间和测试人员进行充分的沟通，以期对测试工作的具体安排、可能的对开发或其他功能团队的依赖关系等尽早明确，做到心中有数。
需要安装的软件或软件需要的补丁包，可以在准备期间由专人下载，并上传到项目组的文件服务器里供整个团队使用。
补丁包测试执行：
安装补丁包并验证补丁包的安装向导
根据测试用例进行功能或性能测试
进行相应的回归测试
进行补丁包的安装和卸载测试，对补丁包安装文档进行验证
补丁包的发布：
需要发布什么信息，通过什么渠道让客户了解这些信息。
补丁包内容的发布信息必须准确、清晰，能够为客户所理解，即，发布我们能带给客户价值的东西：
该补丁包中解决的问题，包括问题的简单描述等需要清晰的罗列。
有一些意义重大的问题得到解决且能带来功能、性能或可定制性的任何方面的 提升，需要详细让客户了解。
产品支持的平台的拓展和延伸的信息。
对于产品自动化测试的持续投入是十分有必要的：
已有的自动化框架的整体架构和功能提升。
增加针对新功能的自动化测试资产。
优化和提升已有自动化测试资产的功能和质量。
本文来自投稿，不代表展天博客立场，如若转载，请注明出处：https://www.me900.com/325335.html
