恰当选择软件测试自动化方案

发表于:2011-09-02来源:未知作者:领测软件测试网采编点击数: 标签:自动化测试
随着测试流程的不断规范以及软件测试技术的进一步细化,软件测试自动化已经日益成为一支不可忽视的力量。能否借助于这支外在力量以及如何借助于这支力量来规范企业测试流程、提高特定测试活动的效率,正是本 期所要讨论的话题。

    随着测试流程的不断规范以及软件测试技术的进一步细化,软件测试自动化已经日益成为一支不可忽视的力量。能否借助于这支外在力量以及如何借助于这支力量来规范企业测试流程、提高特定测试活动的效率,正是本 期所要讨论的话题。

  目前,软件测试自动化的研究领域主要集中在软件测试流程的自动化管理以及动态测试的自动化(如单元测试功能测试以及性能测试方面)。在这两个领域,与手工测试相比,测试自动化的优势是明显的。首先自动化测试可以提高测试效率,使测试人员更加专注于新的测试模块的建立和开发,从而提高测试覆盖率; 其次,自动化测试更便于测试资产的数字化管理,使得测试资产在整个测试生命周期内可以得到复用,这个特点在功能测试回归测试中尤其具有意义; 此外,测试流程自动化管理可以使机构的测试活动开展更加过程化,这很符合CMMI过程改进的思想。根据Oppenheimer Funds的调查,在2001年前后的3年中,全球范围内由于采用了测试自动化手段所实现的投资回报率高达1500%。

  方案选型六大原则

  然而存在优势是否就一定意味着选择自动化测试方案都能为企业带来效益回报呢?也不尽然,任何一种产品化的测试自动化工具,都可能存在与某具体项目不甚贴切的地方。再加上,在企业内部通常存在许多不同种类的应用平台,应用开发技术也不尽相同,甚至在一个应用中可能就跨越了多种平台; 或同一应用的不同版本之间存在技术差异。所以选择软件测试自动化方案必须深刻理解这一选择可能带来的变动、来自诸多方面的风险和成本开销。

  以下笔者给出企业用户进行软件测试自动化方案选型的参考性原则,这些原则是从笔者实际工作中凝练而成的,它包括以下六个方面的建议:

  选择尽可能少的自动化产品覆盖尽可能多的平台,以降低产品投资和团队的学习成本;

  测试流程管理自动化通常应该优先考虑,以满足为企业测试团队提供流程管理支持的需求;

  在投资有限的情况下,性能测试自动化产品将优先于功能测试自动化被考虑;

  在考虑产品性价比的同时,应充分关注产品的支持服务和售后服务的完善性;

  尽量选择趋于主流的产品,以便通过行业间交流甚至网络等方式获得更为广泛的经验和支持;

  应对测试自动化方案的可扩展性提出要求,以满足企业不断发展的技术和业务需求

  实战模拟

  以下笔者结合一个典型的企业客户,剖析其适用的软件测试自动化方案选型过程。

  1.公司背景介绍

  A公司是一家大型保险公司,拥有近20个城市的分公司,并在其中5个城市建立了IT支持中心。平均每年的上线应用数量在20个左右(新业务系统和原有业务系统的主要版本发布)。目前A公司的专职测试团队人数不足30人,而且测试团队的测试人员技能参差不齐,目前测试只是作为项目上线前的一道工序而已。在测试团队内部也几乎没有自动化的手段,主要依靠手工测试。由于已上线应用系统的问题,开发团队必须分出一部分资源去维护和修复上线应用,而同时测试团队的测试成果和效率却无法和这些应用质量挂钩,也更无从谈起对软件质量的控制。所以,A公司决定在软件质量和测试方面进行投入,他们考虑以下几方面:

  引进软件测试流程管理的自动化,提高软件测试过程的管理水平,使软件测试和软件开发一样可被评估、被衡量。

  实现性能测试自动化,所有应用上线之前必须有应用性能风险评估报告和相关部门的确认

  逐步实现功能测试的自动化,在目前人员配置的情况下,把部分手工测试变成自动化测试,提高测试可信度,降低人为错误。

  通过软件测试自动化,管理软件测试中的案例、缺陷、报告等资产,进一步提升软件测试的效率并建立测试基础库。

  在规划中,将来的2~3年内使所有的应用系统上线都必须有数字化的测试数据作为依据。

  2.公司应用系统的情况

  由于保险公司的业务种类繁多,同时在经过了几十年的经营后,公司内的应用系统从早期的终端方式到现代的J2EE和.NET等应有尽有,鱼龙混杂。IT部门已经建立的3年规划,即在未来的3年时间内将所有终端和C/S方式的应用转换成B/S架构,但当前仍然需要对这些旧应用系统进行维护,以保证业务的顺利进行。对于开发部门来说,目前新应用开发基本上已经以B/S架构为主,主要是基于J2EE架构的Web HTTP应用和部分Window.NET Form的应用。

  3.公司软件测试现状

  企业机构在做测试自动化选型时一定要考虑清楚企业内部哪些部分可以实施自动化、哪些部分暂不实施自动化、哪些部分仅在某几个项目做自动化试点。切忌匆忙上马或盲目否定,缺乏实事求是的理性思考。

  测试部门目前仅负责系统测试和对用户验证测试进行管理,对于之前的单元测试集成测试主要由开发团队中划分出的一部分临时测试人员完成。由于缺乏监测手段,测试部门也无法收集和确定集成测试和单元测试的完成情况,在整个软件测试过程中,业务需求是由开发部门通过Rational RequisitePro进行管理,但测试需求目前尚没有提出要求,测试案例主要通过在公司公用的文件服务器中的目录管理方式管理,对测试中缺陷流程等管理主要依靠邮件的流转进行处理。目前90%以上的测试是通过Excel和Word等测试案例文档来完成,测试人员对软件测试自动化的认识仅停留在“记录+回放”的认识上。

  4.可供选择的方案

  方案A: A公司可以采用美科利(Mercury)公司产品为主的软件测试自动化方案。

  依照原先的邮件流转过程配置TestDirector缺陷管理流程,为每个保险业务的开发小组和测试团队分配相应的用户许可证,取消原有邮件方式。

  部署Mercury Quick Test Professional,以便完成应用程序相关功能测试。

  部署Mercury Load-Runner。从测试团队中分化出专职的性能测试自动化工程师和小组,和业务部门协调,建立A公司应用系统上线性能指标,通过LoadRunner给出测试指标。

  建议A公司成立专门的质量控制部门,对TestDirector中的数据定期进行分析,建立相关质量模型,以便于企业量化管理和过程改进。

  方案B: A公司也可以采用IBM Rational产品为主的软件测试自动化方案。

原文转自:http://www.ltesting.net