【IT168技术文档】
如果你在互联网搜索引擎Google 上输入关键词“ITIL”或者“ITSM”,两秒钟后,铺天盖地的是各种ITIL 的学习资料、经验分享以及行业资讯。不难看出,ITIL,这个曾在6 年多前只为IT 人士零星了解的概念,已经被极大的推动和传播了。从ITIL V1 到V2,又到了V3,一次次的飞跃为IT 人士指明了“标准化”管理的方向。
毋庸置疑,ITIL 给IT 运维及服务管理带来了新鲜的血液,然而,遗憾的是,在软件质量控制的核心环节--- 软件测试领域却对ITIL 鲜有提及。事实上,笔者认为,ITIL 所引入的一系列概念和非常好的实践同样适用于软件测试。
ITIL 简介
ITIL,全称Information Technology Infrastructure Library(信息技术基础架构库),最早的起源是20 世纪80 年代末期由英国国家计算机和电信局(CCTA,后来并入英国商务部)主持的一个名为“政府信息技术基础架构管理方法论——Government Information Technology Infrastructure Management
Methodology(GITMM)”的项目,该项目的目标是为政府部门开发一套规范化的、可进行财务计量的IT 资源使用方法。这种方法应该是独立于厂商的并且可适用于不同规模、不同技术和业务需求的组织。该项目成果就是ITIL V1 版本。
随着时间的推移,行业及技术都发生了很大变化。ITIL 是非常好的实践经验总结,于是它也从V1 发展到V2,继而扩展到V3。 ITIL v3 定义了服务生命周期的5 个阶段:服务战略(Service Strategies)、服务设计(Service Design) 、服务转化(Service Transition) 、服务运营(Service Operation)、持续改进(Continual Service Improvement),它包含了生命周期内管理
服务需要的流程。

【注】 51Testing授权IT168独家转载,未经明确的书面许可,任何人或单位不得对本文内容复制、转载或进行镜像,否则将追究法律责任。 本文出自51Testing电子杂志《51测试天地》第十四期,http://www.51testing.com/html/82/n-141082.html
服务战略(Service Operation)
服务战略是服务设计、服务转化、服务运营和持续改进的基础,这个阶段涵
盖了服务管理的实践、服务原则、服务评估、服务战略流程、服务管理的财务模型等内容,从整体业务目标和管理层期望出发,保证IT 发展战略与业务相一致。
ITIL 提到3 个核心流程,下面让我们分别了解一下,这些核心流程在软件测试中的所起的作用:
需求管理(Demand Management)
需求管理是整个服务管理的重要内容,糟糕的需求管理导致的需求不确定性对于服务提供商来说是一个巨大的隐患。在软件测试管理中也是如此,只有通过有效的需求管理来捕获所有的需求以便于才能知道用户需要的是什么,并且将可用资源集中在优先级最高的业务上。同时需求管理的流程还能够帮助确定采用何种测试方法来满足不同用户的需求。
服务投资组合管理(Service Portfolio Management)
服务投资组合管理根据业务价值描述了提供商的服务,他反应了服务提供商所提供的服务的能力、范围、优势、劣势及资源和能力有效分配的问题。
在软件测试中,可以这样被定义为:我们能够提供哪些测试服务给我们的用户?我们是否有足够的资源可以提供性能测试、功能测试甚至安全测试服务?
财务管理(Financial Management)
财务管理流程就是为了帮助有效平衡成本和回报的。在软件测试中,财务管理能够帮助评估测试覆盖率和相应的成本的关系,也能帮助回答是否需要购买自动化测试工具来取代部分人工测试等问题。
服务设计(Service Design)
服务设计描述了对服务及服务管理流程的设计和开发。它包括了将战略目标转变成服务投资组合和服务资产的原则和方法。服务设计的范围不仅限于新的服务,它还包括了为了保持和增加客户价值,而实行服务生命周期过程中必要的变更和改进,服务的连续性,服务水平的满足和对标准、规则的遵从性。具体而言,ITIL 包括了以下主要管理流程,而这些流程与软件测试也是紧密相连的。
服务目录管理(Service Catalog Management)
服务目录管理维护着所有的服务目录,包括了那些内部用户或外部用户可见的服务。
在软件测试中也是我们可以通过这些服务目录窗口告知用户我们能够提供哪些软件测试的服务,例如白盒测试、黑盒测试、性能测试、安全测试等等。

服务级别管理(Service Level Management)
服务级别管理流程的目标是确保所有当前的及双方协议过将要交付的未来的IT 服务的提供处于协议水平。在软件测试中实际上就是测试范围的界定,例如交付的应用必须能够满足100 个并发用户数,同时登录同时响应时间必须在20 秒内。准确的定义SLA 将有助于制定合理的测试计划及配备相应的测试资源。
容量管理(Capacity Management)
容量管理流程指的是不仅仅能够满足当期的服务需求,所提供的服务还应有一定的长期容量规划。
在软件测试中,以前面服务级别管理中提到的例子来看,交付应用除了满足100 个并发用户数,同时登录同时响应时间必须在20 秒内这个要求之外,从容量规划的角度来看,还应告知用户该应用在要求登录响应时间在20 秒的前提下,最多能够满足多少并发用户数,是200、300 还是仅仅只能满足150 并发。这样应用系统上线后,用户就可以预见系统何时需要扩容。
可用性管理(Availability Management)
可用性管理的目标在于保证在考虑成本效率的情况下,所有服务的可用性水平都能够满足或超出当前和将来的既定需求。
同样的,可用性管理在软件测试中也非常重要,软件测试根本目标之一就是保障应用的可用性。于是一方面我们需要在应用上线前做大量的业务性能测试,
以确保应用上线后能够在突发高峰时仍能够保障其可用性;另一方面,上线后需要可持续的手段来实时监控业务,主动跟踪应用的可用状况,一旦发生可用性问题,可以及时自动化响应处理,如重启服务,报警人工干预等等。
考虑到成本问题,非常好的情况是性能测试的测试脚本能够不做修改的便用于上线后可持续业务监控,这样投资回报率将大大提高。在目前这个市场上,HP 的LoadRunner 测试软件和HP Business Availability Center 就完全能够满足这类需求。
IT 服务连续性管理(Service Continuity Management)
IT 服务连续性管理流程的目标是通过确保所需的IT 技术和服务设备能够在规定的业务时间进度内重新运作,从而支持整个业务连续性管理。
在软件测试中,为了保证业务应用将来连续工作的目标,就需要做尽可能多的异常测试,保证最大化测试场景的覆盖率,同时需要进行特定的峰值测试和边界测试。最新的测试理念中提到的“业务流程测试”实际上也是为了保证服务连续性。所谓“业务流程测试”是指在测试中应该尽可能引入业务人员来进行,因为业务人员是需求的提出者,也是未来业务应用的使用者,他们对于需求的了解
准确度要大于测试人员,因此他们的参与将大大提高测试的准确度,从而确保未来服务连续性。当然由于业务人员缺乏技术背景,对于测试工具使用有困难,因此业务流程测试必须借助简化的特殊测试产品来帮助业务人员轻松进行测试。
信息安全管理(Information Security Management)
信息安全管理流程的目标是使IT 安全和业务结合起来,确保在所有的服务和服务管理活动中都能实现信息安全。这一点在软件测试中尤其需要引起重视,由于长期以来软件测试人员更多的强调测试软件的功能和性能,而由于其大多不懂应用安全,于是安全测试被极大的忽略。事实上,相当多的Web 应用存在着很多安全漏洞,诸如SQL Injection、Cross Site Scripting 等等,其产生的危害将远远大于应用本身的质量问题。因此,安全测试必须引起足够的重视,当然由于测试人员不懂安全,这个可以在具体实践中借用一些自动化安全评估工具来进行测试。

供应商管理(Supplier Management)
供应商管理流程的目标是管理供应商和供应商所提供的服务,为业务部门提供无缝的IT 服务,使投入物有所值。
这个在软件测试中具体表现为采用第三方测试工具来进行功能测试、性能测试和安全测试前需要进行一系列评估,包括测试软件本身的特点、优势,以及厂商提供的服务是否及时有效等等,这样才能确保对于测试软件工具的投入能够产生价值回报。
服务转换(Service Transition)
服务转换描述了如何将新的或变更的服务有效的导入到服务运营体系中去,与此同时考虑控制失败的分析和服务中断。
让我们来了解以下软件测试和和以下主要管理流程的关系:
转换规划和支持(Transition Planning and Supporting) 转换规划和支持流程主要负责规划转换所必须的资源,了解在引入新的服务时所必需的内容。
在软件测试中,同样的我们为了保证测试的质量,经常会引入一些新的测试方法和工具来测试新的业务应用,这样我们在转换过程中,就有义务为测试人员提供相应的培训支持,以保证他们了解新工具的使用,懂得新测试方法的运用等等。
服务资产和配置管理(Service Asset and Configuration Management)
服务资产和配置管理流程帮助提供了正确更新的配置信息,让使用者能够在正确的时间做出决策,从而维持高效的服务管理流程。
在软件测试中,我们通过服务资产和配置管理流程确保软件的测试是在相应标准的测试环境中进行,同时所有的测试都是针对正确的应用版本进行的。
变更管理(Change Management)
变更管理流程能够帮助对客户业务需求的变化做出快速响应,使得服务与业务需求真正吻合。软件测试中变更是比比皆是,一方面我们需要通过测试管理对于需求的变更和版本的变更进行有效的跟踪和控制,另一方面需要进行大量的回归测试来确保变更不会对已经测试过的软件质量产生影响。当然回归测试的工作量是非常巨大,必要时需要借助相应的自动化测试工具来进行具体的测试。
发布和部署管理(Release & Deployment Management)
发布和部署管理的目标是部署和发布到生产环境中,设定服务的有效使用及将服务传递到服务运营阶段。在软件测试中发布管理也是非常重要的,在整个测试管理中必须有发布管理,这样缺陷才能有效得到跟踪和关联,它也是变更管理密切相关的部分。
服务检查和测试(Service Validation & Testing)
在服务检查和测试这个流程中,测试服务已经全部完成,我们进入了UAT(User Acceptance Test)阶段。最终确保软件质量的各个方面(功能、性能、安全)都符合质量要求,成功地完成测试服务交付。
评价(Evaluation)
评价流程是一个通用流程,通过评价流程我们来总结本次测试工作产生的价值、发生了哪些问题,是否在下次软件测试中需要考虑更多的资源投入,或是引入一些更好的工具用于具体的测试实践中等等。
知识管理(Knowledge Management)
知识管理流程的目标是确保在整个生命周期中都能获得安全可靠的信息数据,从而提高组织知识共享的能力。从软件测试的来看,很多测试中的人为积累非常有价值,这包括所有的测试计划、测试脚本、测试中遇到的问题和解决方法、测试方法论等等。因此有效的测试管理必须能够统一管理所有的测试资产(包括文档、脚本、知识库等),
并能够有效的为其他测试人员共享,以帮助今后的回归测试。
服务运营(Service Operation)
服务运营主要包含了在服务运营管理方面的实践。它对如何达到服务支持和交付的效果和效率,以确保为客户和服务供应商的价值提供了指导。
从某种意义上来看,软件测试已经和投产后的应用无关,毕竟经过终验,软件已经被交付投入运营了。实则不然,至少有两方面内容仍然和软件测试息息相关:
1、从性能测试到业务监控
在软件测试阶段,性能测试帮助我们有效的测试了各种业务应用,确保业务应用在高峰时刻能够承受相应的并发用户数压力。试想,如果同样的性能测试脚本,如果不是在10 分钟内并发1000 进行性能测试,而是每过1 小时运行1次,这样返回的响应时间不正是如同一个真实用户进行的业务操作吗,这不就是运维中最需要的真正的业务流程监控吗?

2、缺陷再发现
没有一个应用是没有缺陷的,在实际应用上线使用的过程中,我们会发现很多先前测试中遗漏的缺陷,于是我们必须将服务运营中的遇到的缺陷纪录到测试管理流程中的缺陷跟踪模块中,以确保下一个应用版本更新中将缺陷彻底解决。
持续性服务改进(Continual Service Improvement)
持续性服务改进主要是为了创造和保持客户价值,而用更优化的服务设计、导入和运营提供指导。事实上,通过服务运营中我们提到的两方面“业务监控”和“缺陷再发现”就能够帮助我们有效的持续改进应用服务。例如,从主动式“业务监控”的数据我们可以非常清晰的了解到监控的业务在哪些时间段是繁忙阶段,哪些时间段是相对空闲阶段,这样我们就可以在繁忙易发事故阶段投入更多的关注,同时有些硬件设备可以动态分派资源,我们就可以在繁忙阶段分派更多的资源给这个业务应用,而在空闲阶段收回资源供其他应用使用。而缺陷的发现也可以帮助我们在下一个应用版本发布时为客户提供更好的服务。
小结
正如在本文中所述,ITIL V3 这个服务管理的非常好的实践并非IT 运维的“专利”,它同样适用于软件测试领域。将ITIL 的非常好的实践合理的融入到软件测试的方方面面,那么您的业务应用质量控制将“更上一层楼”。
