ITIL给IT运维及服务管理带来了新鲜血液，但其引入的一系列概念和最佳实践同样适用于软件测试。
如果你在互联网搜索引擎Google上输入关键词“ITIL”或者“ITSM”，两秒钟后，铺天盖地的是各种ITIL的学习资料、经验分享以及行业资讯。不难看出，ITIL，这个曾在6年前只为IT人士零星了解的概念，已经被极大地推动和传播了。从ITILV1到V2，又到了V3，一次次的飞跃为IT人士指明了“标准化”管理的方向。
毋庸置疑，ITIL给IT运维及服务管理带来了新鲜的血液，然而，在软件质量控制的核心环节—软件测试领域却对ITIL鲜有提及。事实上，ITIL所引入的一系列概念和最佳实践同样适用于软件测试。
服务战略
随着时间的推移，行业及技术都发生了很大变化。ITIL是最佳实践经验总结，于是它也从V1发展到V2，继而扩展到V3。ITILV3 定义了服务生命周期的 5个阶段：服务战略（ServiceStrategies）、服务设计（ServiceDesign）、服务转化 （ServiceTransition）、服务运营（ServiceOperation）、持续改进 （ContinualServiceImprovement），这包含了生命周期内管理服务需要的流程。
服务战略是服务设计、服务转化、服务运营和持续改进的基础，这个阶段涵盖了服务管理的实践、服务原则、服务评估、服务战略流程、服务管理的财务模型等内容，从整体业务目标和管理层期望出发，保证IT发展战略与业务相一致。
ITIL提到3个核心流程，这些核心流程在软件测试中都能所起到相应的作用。需求管理是整个服务管理的重要内容，糟糕的需求管理导致的需求不确定性对于服务提供商来说是一个巨大的隐患。
在软件测试管理中也是如此，只有通过有效的需求管理来捕获所有的需求，才能知道用户需要的是什么，并且将可用资源集中在优先级最高的业务上。同时需求管理的流程还能够帮助确定采用何种测试方法来满足不同用户的需求。
服务投资组合管理根据业务价值描述了提供商的服务，它反映了服务提供商所提供的服务的能力、范围、优势、劣势及资源和能力有效分配的问题。在软件测试中，可以被定义为：我们能够提供哪些测试服务给我们的用户，我们是否有足够的资源可以提供性能测试、功能测试甚至安全测试服务。
财务管理流程就是为了帮助有效平衡成本和回报的。在软件测试中，财务管理能够帮助评估测试覆盖率和相应的成本的关系，也能帮助回答是否需要购买自动化测试工具来取代部分人工测试等问题。
服务设计
服务设计描述了对服务及服务管理流程的设计和开发。它包括了将战略目标转变成服务投资组合和服务资产的原则和方法。服务设计的范围不仅限于新的服务，它还包括为了保持和增加客户价值，而实行服务生命周期过程中必要的变更和改进具体而言，ITIL包括了以下主要管理流程，而这些流程与软件测试也是紧密相连的。
服务目录管理维护着所有的服务目录，包括了那些内部用户或外部用户可见的服务。在软件测试中也是我们可以通过这些服务目录窗口告知用户我们能够提供哪些软件测试的服务，例如白盒测试、黑盒测试、性能测试、安全测试等。
服务级别管理流程的目标是确保所有当前的及双方协议过将要交付的未来的IT服务处于协议水平。
在软件测试中实际上就是测试范围的界定，例如交付的应用必须能够满足100个并发用户数同时登录，并且响应时间必须在20秒内。准确地定义SLA将有助于制定合理的测试计划及配备相应的测试资源。
容量管理流程指的是不仅仅能够满足当期的服务需求，所提供的服务还应有一定的长期容量规划。
在软件测试中，以前面服务级别管理中提到的例子来看，交付应用除了满足100个并发用户数同时登录，并且响应时间必须在20秒内这个要求之外，从容量规划的角度来看，还应告知用户该应用在要求登录响应时间在20秒的前提下，最多能够满足多少并发用户数，是200、300还是仅仅只能满足150并发。这样应用系统上线后，用户就可以预见系统何时需要扩容。
可用性管理的目标在于保证在考虑成本效率的情况下，所有服务的可用性水平都能够满足或超出当前和将来的既定需求。
同样的，可用性管理在软件测试中也非常重要，软件测试根本目标之一就是保障应用的可用性。于是一方面我们需要在应用上线前做大量的业务性能测试，以确保应用上线后能够在突发高峰时仍能够保障其可用性；另一方面，上线后需要可持续的手段来实时监控业务，主动跟踪应用的可用状况，一旦发生可用性问题，可以及时自动化响应处理，如重启服务，报警人工干预等。
这一点在软件测试中尤其需要引起重视，由于长期以来软件测试人员更多地强调测试软件的功能和性能，而由于其大多不懂应用安全，于是安全测试被极大地忽略。事实上，相当多的Web应用存在着很多安全漏洞，诸如SQLInjection、 CrossSiteting等，其产生的危害将远远大于应用本身的质量问题。因此，安全测试必须引起足够的重视，当然由于测试人员不懂安全，这个可以在具体实践中借用一些自动化安全评估工具来进行测试。
服务转换
服务转换描述了如何将新的或变更的服务有效地导入到服务运营体系中去，与此同时考虑控制失败的分析和服务中断。以下就是软件测试和主要管理流程的关系。
转换规划和支持流程主要负责规划转换所必须的资源，了解在引入新的服务时所必需的内容。
在软件测试中，为了保证测试的质量，经常会引入一些新的测试方法和工具来测试新的业务应用，这样我们在转换过程中，就有义务为测试人员提供相应的培训支持，以保证他们了解新工具的使用，懂得新测试方法的运用等。
服务资产和配置管理流程帮助提供了正确更新的配置信息，让使用者能够在正确的时间做出决策，从而维持高效的服务管理流程。
在软件测试中，我们通过服务资产和配置管理流程，确保软件的测试是在相应标准的测试环境中进行，同时所有的测试都是针对正确的应用版本进行的。
变更管理流程能够帮助对客户业务需求的变化做出快速响应，使得服务与业务需求真正吻合。
软件测试中的变更比比皆是，一方面我们需要通过测试管理对于需求的变更和版本的变更进行有效的跟踪和控制，另一方面需要进行大量的回归测试来确保变更不会对已经测试过的软件质量产生影响。当然回归测试的工作量非常巨大，必要时需要借助相应的自动化测试工具来进行具体的测试。
发布和部署管理的目标是部署和发布到生产环境中，设定服务的有效使用及将服务传递到服务运营阶段。
在软件测试中发布管理也是非常重要的，在整个测试管理中必须有发布管理，这样缺陷才能有效得到跟踪和关联，它也是变更管理密切相关的部分。
在服务检查和测试这个流程中，测试服务已经全部完成，我们进入了UAT（UserAcceptanceTest）阶段。最终确保软件质量的各个方面（功能、性能、安全）都符合质量要求，成功地完成测试服务交付。
评价流程是一个通用流程，通过评价流程我们来总结本次测试工作产生的价值、发生了哪些问题，是否在下次软件测试中需要考虑更多的资源投入，或是引入一些更好的工具用于具体的测试实践中。
知识管理流程的目标是确保在整个生命周期中都能获得安全可靠的信息数据，从而提高组织知识共享的能力。从软件测试角度看，很多测试中的人为积累非常有价值，这包括所有的测试计划、测试脚本、测试中遇到的问题和解决方法、测试方法论等。因此有效的测试管理必须能够统一管理所有的测试资产（包括文档、脚本、知识库等），并能够有效地为其他测试人员共享，以帮助今后的回归测试。
服务运营
服务运营主要包含了在服务运营管理方面的实践。它对如何达到服务支持和交付的效果和效率，以确保为客户和服务供应商的价值提供指导。
从某种意义上来看，软件测试已经和投产后的应用无关，毕竟经过终验，软件已经被交付投入运营了。实则不然，至少有两方面内容仍然和软件测试息息相关。
在软件测试阶段，性能测试帮助我们有效地测试了各种业务应用，确保业务应用在高峰时刻能够承受相应的并发用户数压力。
试想，同样的性能测试脚本，如果不是在10分钟内并发1000进行性能测试，而是每过1小时运行1次，这样返回的响应时间不正是如同一个真实用户进行的业务操作吗，这不就是运维中最需要的真正的业务流程监控吗？
没有一个应用是没有缺陷的，在实际应用上线使用的过程中，我们会发现很多先前测试中遗漏的缺陷，于是我们必须将服务运营中遇到的缺陷记录到测试管理流程中的缺陷跟踪模块中，以确保下一个应用版本更新中将缺陷彻底解决。
持续性服务改进
持续性服务改进主要是为了创造和保持客户价值，而用更优化的服务设计、导入和运营提供指导。
事实上，通过服务运营中我们提到的两方面“业务监控”和“缺陷再发现”就能够帮助我们有效地持续改进应用服务。例如，从主动式“业务监控”的数据我们可以非常清晰地了解到监控的业务在哪些时间段是繁忙阶段，哪些时间段是相对空闲阶段，这样我们就可以在繁忙易发事故阶段投入更多的关注，同时有些硬件设备可以动态分派资源，我们就可以在繁忙阶段分派更多的资源给这个业务应用，而在空闲阶段收回资源供其他应用使用。而缺陷的发现也可以帮助我们在下一个应用版本发布时为客户提供更好的服务。
ITILV3这个服务管理的最佳实践并非IT运维的“专利”，它同样适用于软件测试领域。将ITIL的最佳实践合理地融入到软件测试的方方面面，企业的业务应用质量控制将“更上一层楼”。