服务转换

　　服务转换描述了如何将新的或变更的服务有效地导入到服务运营体系中去，与此同时考虑控制失败的分析和服务中断。以下就是软件测试和主要管理流程的关系。

　　转换规划和支持流程主要负责规划转换所必须的资源，了解在引入新的服务时所必需的内容。

　　在软件测试中，为了保证测试的质量，经常会引入一些新的测试方法和工具来测试新的业务应用，这样我们在转换过程中，就有义务为测试人员提供相应的培训支持，以保证他们了解新工具的使用，懂得新测试方法的运用等。

　　服务资产和配置管理流程帮助提供了正确更新的配置信息，让使用者能够在正确的时间做出决策，从而维持高效的服务管理流程。

　　在软件测试中，我们通过服务资产和配置管理流程，确保软件的测试是在相应标准的测试环境中进行，同时所有的测试都是针对正确的应用版本进行的。

　　变更管理流程能够帮助对客户业务需求的变化做出快速响应，使得服务与业务需求真正吻合。

　　软件测试中的变更比比皆是，一方面我们需要通过测试管理对于需求的变更和版本的变更进行有效的跟踪和控制，另一方面需要进行大量的回归测试来确保变更不会对已经测试过的软件质量产生影响。当然回归测试的工作量非常巨大，必要时需要借助相应的自动化测试工具来进行具体的测试。

　　发布和部署管理的目标是部署和发布到生产环境中，设定服务的有效使用及将服务传递到服务运营阶段。

　　在软件测试中发布管理也是非常重要的，在整个测试管理中必须有发布管理，这样缺陷才能有效得到跟踪和关联，它也是变更管理密切相关的部分。

　　在服务检查和测试这个流程中，测试服务已经全部完成，我们进入了UAT(UserAcceptanceTest)阶段。最终确保软件质量的各个方面(功能、性能、安全)都符合质量要求，成功地完成测试服务交付。

　　评价流程是一个通用流程，通过评价流程我们来总结本次测试工作产生的价值、发生了哪些问题，是否在下次软件测试中需要考虑更多的资源投入，或是引入一些更好的工具用于具体的测试实践中。

　　知识管理流程的目标是确保在整个生命周期中都能获得安全可靠的信息数据，从而提高组织知识共享的能力。从软件测试角度看，很多测试中的人为积累非常有价值，这包括所有的测试计划、测试脚本、测试中遇到的问题和解决方法、测试方法论等。因此有效的测试管理必须能够统一管理所有的测试资产(包括文档、脚本、知识库等)，并能够有效地为其他测试人员共享，以帮助今后的回归测试。

　　服务运营

　　服务运营主要包含了在服务运营管理方面的实践。它对如何达到服务支持和交付的效果和效率，以确保为客户和服务供应商的价值提供指导。

　　从某种意义上来看，软件测试已经和投产后的应用无关，毕竟经过终验，软件已经被交付投入运营了。实则不然，至少有两方面内容仍然和软件测试息息相关。

　　在软件测试阶段，性能测试帮助我们有效地测试了各种业务应用，确保业务应用在高峰时刻能够承受相应的并发用户数压力。

　　试想，同样的性能测试脚本，如果不是在10分钟内并发1000进行性能测试，而是每过1小时运行1次，这样返回的响应时间不正是如同一个真实用户进行的业务操作吗，这不就是运维中最需要的真正的业务流程监控吗?

　　没有一个应用是没有缺陷的，在实际应用上线使用的过程中，我们会发现很多先前测试中遗漏的缺陷，于是我们必须将服务运营中遇到的缺陷记录到测试管理流程中的缺陷跟踪模块中，以确保下一个应用版本更新中将缺陷彻底解决。

　　持续性服务改进

　　持续性服务改进主要是为了创造和保持客户价值，而用更优化的服务设计、导入和运营提供指导。

　　事实上，通过服务运营中我们提到的两方面“业务监控”和“缺陷再发现”就能够帮助我们有效地持续改进应用服务。例如，从主动式“业务监控”的数据我们可以非常清晰地了解到监控的业务在哪些时间段是繁忙阶段，哪些时间段是相对空闲阶段，这样我们就可以在繁忙易发事故阶段投入更多的关注，同时有些硬件设备可以动态分派资源，我们就可以在繁忙阶段分派更多的资源给这个业务应用，而在空闲阶段收回资源供其他应用使用。而缺陷的发现也可以帮助我们在下一个应用版本发布时为客户提供更好的服务。

　　ITILV3这个服务管理的最佳实践并非IT运维的“专利”，它同样适用于软件测试领域。将ITIL的最佳实践合理地融入到软件测试的方方面面，企业的业务应用质量控制将“更上一层楼”。