软件测试是软件工程的一个范畴,它作为软件工程的一部分,随着软件生产的产业化运作应运而生。从20世纪70年代开始,随着计算机技术的飞速发展,计算机软件在整个社会系统中的地位也越来越重要,而计算机软件开 发的规模和复杂度也随着其需求和重要度的增加而急速上升。在过去的20年里,对软件测试的最初认识只是“证明程序的正确性”,而后一系列的软件测试理论和方法被逐渐的提出,在1983年由IEEE提出了目前比较认可的软件测试定义,即:“为了检验某个应用系统的过程是否满足规定的需求,并了解预期结果和实际结果之间的差异,而使用手工和/或自动化手段来运行并验证这一过程”。按照这个定义,软件测试的目的是监测和排除缺陷,以确保软件产品在可用性,功能性,可操作性等多方面满足软件需求。 从上世纪90年开始,产业界开始意识到被动的以监测和发现错误为目的的软件测试无法避免软件开发过程中由于软件需求和设计等方面的缺陷所带来的巨大风险,所以在整个产业界开始从软件质量控制(SQC, Software Quality Control)开始转移到软件质量保证(SQA, Software Quality Assurance),从而使软件测试从单纯的缺陷检测和发现覆盖到整个软件开发过程,同时软件测试的流程和软件测试技术也成为了独立研究的方向。我们已经了解到一个典型的软件过程可以分为测试需求分析,测试设计,测试执行,缺陷和配置管理过程等许多个不同的阶段。在软件测试技术方面也已经被细化为单元测试,集成测试,系统测试,用户验收测试等不同的测试技术。
自动化软件测试管理流程,以达到始终一致的软件质量和可量化的,可衡量的测试过程管理。
在我们已经了解到的大多数的企业用户对软件测试自动化的需求之后,再来看看他们又是如何对软件测试自动化的方案进行选型的: 选择尽可能少的自动化产品覆盖尽可能多的平台,以降低产品投资和团队的学习成本 测试流程管理自动化通常被优先考虑,以满足为企业测试团队提供流程管理支持的需求 在投资有限的情况下,性能测试自动化产品将优先于功能测试自动化被考虑 在考虑产品性价比的同时,产品的支持服务和售后服务的完善性也备受关注 趋向于选择主流产品,以便于通过行业间交流甚至网络等方式获得更为广泛的经验和支持 对测试自动化方案的可扩展性提出要求,以满足企业不断发展的技术和业务需求 A公司是一家大型保险公司,拥有近20个城市的分公司,并在其中5个城市建立了IT支持中心。这些IT中心负责所有内部应用系统的开发和运维,同时负责管理IT集成商和第三方应用供应商。平均每年的上线应用数量在20个左右(新业务系统和原有业务系统的主要版本发布)。其开发团队主要分布在2个城市,大约有300名左右,同时20%左右的项目是通过项目开发外包,或直接从第三方采购获得。目前A公司的专职测试团队人数不足30人,而且测试团队的测试人员技能参差不齐,目前测试只是作为项目上线前的一道工序而已。在测试团队内部也几乎没有自动化的手段,主要依靠手工测试;但在和研发部门的沟通等方面,都有明确的邮件往来规范和例会等既定的管理方式。由于已上线应用系统的问题,开发团队必须分出一部分资源去维护和修复上线应用,而同时测试团队的的测试成果和效率却无法和这些应用质量挂钩,也更无从谈起对软件质量的控制。A公司已经决定在软件质量和测试方面进行投入,他们考虑: 2.实现性能测试自动化,所有应用上线之前必须有应用性能风险评估报告和相关部门的确认 3.逐步实现功能测试的自动化,在目前人员配置的情况下,把部分手工测试变成自动化测试,提高测试可信度,降低人为错误。 4. 通过软件测试自动化,管理软件测试中的案例,缺陷,报告等资产,进一步提升软件测试的效率并建立测试基础库。 5. 在规划中,将来的2-3年内使所有的应用系统上线都必须有数字化的测试数据作为依据。
初期实施阶段:
2.部署Mercury QuickTest Professional。选择Mercury QTP而非WinRunner和其它产品的考虑主要出于它对新应用平台的广泛支持性,和用户的易学易用性,可以使测试团队比较快的上手使用,并随着为当前的项目建立和运行最初的自动化测试,获得软件测试自动化尝试的信心。但目前对美科利(Mercury)建议的Business Process Testing不作考虑。 中期实施阶段: 1.通过Mercury集成Rational的需求管理工具RequisitePro,以实现测试需求的管理。并利用现有的Mercury Quality Center平台引入测试案例管理流程,把所有基于Word和Excel的旧有案例,利用美科利(Mercury)提供的转换工具导入到TestDirector中去,从而建立可被参考和追踪的测试案例库。同时由测试部门协调整个执行过程,对测试环境,测试数据,被测系统(SED)的调配实现统一管理,避免可能存在的各部门竞争测试资源的状况。 2.部署Mercury LoadRunner。从测试团队中分化出专职的性能测试自动化工程师和小组。和业务部门协调,建立A公司应用系统上线性能指标。值得注意的是由于A公司的应用系统的地域分布性,在通过公司内网远程执行LoadRunner测试案例时受到现有网络带宽的限制,很难达到测试成果。尽管美科利(Mercury)公司建议A公司引进美科利(Mercury)的Performance Center平台以实现整合和远程操控,由于公司预算和目前对性能测试的技能尚不足以建立整合平台,A公司最终没有采纳。最后,由于性能测试通常是在业务应用经过了一轮的系统测试以后进行的,A公司决定把性能测试实验室环境集中在一处,并不需要做性能测试的应用发布到该实验室进行统一测试。 3.对已经开始的功能测试自动化进行优化,从测试小组中筛选出自动化测试专家,负责A公司自动化测试库的建立,进一步提升软件测试自动化的价值。 长期实施阶段:
所以,我们说软件测试自动化是一个必然趋势,但对企业来说,它并不意味着是必须马上启动的项目,或者甚至所有企业都必须跟随的唯一道路。 首先,一个企业实施测试自动化,绝对不是拍脑袋说干就能干好的,它不仅涉及测试工作本身流程上、组织结构上的调整与改进,甚至也包括需求、设计、开发、维护及配置管理等其他方面的配合。如果对这些必要的因素没有考虑周全的化,必然在实施过程中会处处碰壁,既定的实施方案也无法开展。其次,尽管自动化测试可以降低人工测试的工作量,但并不能完全取代手工测试。100%的自动化测试只是一个理想目标,根据笔者的经验即便一些如SAP, Oracle ERP等测试库规划十分完善的套件,其测试自动化率也不会超过70%。所以一味追求测试自动化只会给企业带来运作成本的急剧上升。再次,比较测试自动化需要企业有相对规模的投入,对企业运作来说,投入回报率将是决定是否实施软件测试自动化的最终指挥棒,笔者建议企业在决定实施软件测试自动化之前,必须要求量化的投资回报分析。此外,软件测试自动化并不就是采购强大的自动化软件测试工具或自动化管理平台,毕竟软件质量的保证不是依靠产品或技术(Technology),而且更多的因素在与高素质的人员(People)和合理有效的流程(Process)。 |