软件测试自动化的探索与管理(二)

By | 03月05日
Advertisement

第一章 自动化测试模式差异化

  1、产品、项目测试和运营测试

  (a)三种测试模式的异同

  大部分从业人士可能都知道产品开发的模式和具体流程,但可能并不是所有人都了解产品开发和开发完毕之后的运营维护的实际情况。笔者曾有幸在“神码融信”先后经历过东亚银行、兴业银行和国家开发银行这三个项目的测试,有现场实施也有基地化开发;之后进入平安集团信息管理中心,也就是现在的平安科技,这两份工作经历让笔者有幸简单了解了一下软件测试的不同模式。笔者理解,软件测试从项目类型上可以分为新产品开发项目测试、普通开发项目测试和运营测试(补丁需求版本)测试。本节简单阐述一下笔者心目中这三者的异同。

  1)新产品开发项目测试

  ● 因适应新的市场或内部需求诞生或衍生一个或一组全新的系统。这些系统可能是经过深思熟虑而设计的,也可能是探索性的,但是无论对于开发还是测试和用户,它们都是从未操作过的。测试人员对系统的了解仅限于需求文档和页面原型,鲜有经验可供参考,像Windows 7和Office的一些新组件等。

  ● 有着较为充裕的时间跨度,能够运用较多的新技术和新思想。为了满足业务需求开发时可能会引进新的技术或平台架构,对应的测试人员如果经验不是非常丰富,那么需要学习的东西就比较多,甚至有时会出现系统上线之后“才刚刚有了那么点感觉”的意思。

  ● 一次性,项目发布之后,项目组大部分人将撤离,只留下部分同事做后期维护工作。所以它在时间概念上是以一种一次性的模式存在的。

  2)一般的开发项目测试

  所谓一般的项目开发,主要是指:

  ● 技术、架构转平台项目,如某银行使用的核心对公交易管理系统从字符终端(C/S)升级到J2EE的Web页面(B/S)、保险公司传统业务系统的Forms转换到J2EE;

  ● 较大的系统变更项目,就是说系统变更所需要的人力、财力已经达到了立项标准的程度从而走了项目管理流程。

  相比较上文新产品开发测试提到的几点:

  ● 系统中保留了业务逻辑理念,架构转平台时UI发生极大的变更,而同平台下的大规模改造则会沿用较多的现有模型。对于测试来说,最实惠的是有经验可借鉴,主要参照现有系统的逻辑作对比的变更测试,目的更为明确。

  ● 已有技能和经验在测试过程中起到不少作用,测试人员上手速度比较快。同时系统改造或者技术转平台将会对没有发生变动的模块产生大量的关联影响,可能大家比较认同的是:每一轮向测试环境重要的发布都要经过全面的冒烟测试,即便关联影响在开发阶段得到了很好的控制,这种冒烟测试也不是多余的。

  ● 同项目开发测试,只不过多次改造、升级可能会连续进行,如每两、三年发生一次。

  3)运营维护性需求测试

  ● 系统中绝大多数的规则和页面都没有发生变更,前台操作和后台的逻辑对于测试人员来说都是轻车熟路,不会有太多障碍,除非测试人员本身技能有问题;

  ● 变更的关联影响比较小,基本上能够通过SA、设计、编码和测试人员的共同评估就可以轻松得出变更范围和关联影响程度。事实上为了“保险起见”或者出于对这几方人员的不完全信任,让测试人员在发布前做一次全面的回归测试也是大多数公司和领导愿意去做的事情。

  ● 持续不断的,在系统运营中,为了满足新的业务需求或者解决已有生产缺陷,系统将持续不断的向生产发布补丁版本。区别在于周期是不固定的,有可能是每半个月、一个月发布一次版本,也可能是一个季度一次版本;可能也有版本管理不严格的公司,随时开发、测试完毕随时发布生产。

  这里需要指出的是,在项目测试里面,只要是增量式移交模式,那么测试的工作内容也是增量的,除非每一阶段的代码完全独立、相互毫无关联。而事实上这是不可能的,也是违背目前开发设计理念的,因为很多好东西无法复用。为什么说增量式移交带来测试工作量递增呢?假设一个项目分三期移交,那么测试第二期移交的内容的同时就必须考虑第一移交内容受影响的可能性;在做第二期移交内容的完全测试的同时显然还要去做一期内容的测试,一旦发现问题就是反复好几次的移交……同理第三期移交将带来更加多的问题累积,传统的手工测试模式在同等的人力下很难支持这种移交模式。而在现代的先进开发模式里,敏捷开发占据了很大部分,恰巧敏捷开发基本都是增量式构建的,这就是对传统手工测试的最大挑战,之所以要在每日构建中引入自动化测试工具的使用,就是为了解决这种问题。

  (b)对自动化测试的要求

  1)新产品开发项目测试

  前文提到新产品开发可能会引进全新的架构和技术平台,即将诞生的新系统对于测试人员来说也是完全陌生的,所以至少在首次移交测试环境之前,做自动化的分析调研难度都是非常大的。一般来说一个公司现有的自动化测试框架能否满足这种情况下的自动化开发也是个未知数。无论是否可以满足,参与该项目自动化构建的人至少应该包括一个对系统架构非常熟悉的人(无论是开发还是测试)、一个对业务需求十分了解的人、一个对测试整体过程和规范十分了解的人、一个自动化测试技术很好的人,当然测试经理和项目经理都能参与或许能给出一些较为有价值的、有大局观和前瞻性的建议。如果有一个同时熟悉环境架构、业务、自动化测试技术和测试规范的人,那么很幸运,让他来吃螃蟹吧。这个人在测试工具选取、框架设计修改上承担着很大的责任,这个时候丰富的经验和灵活的头脑将成为很重要的资本。在项目编码的初期,测试设计专家就要能够有效论证已经选择的方案和方法是行得通的,并且做好技术风险的评估,找出自动化实现过程中可能遇到的类如安全性、兼容性、可移植性等等技术性问题。通常对系统架构熟悉或者决定系统架构的是EA,熟悉整体业务能预知UI设计细节的是SA和设计编码人员,熟悉自动化测试技术和测试流程规范的是资深测试工程师,所以完美的这么个兼各家之长的人是很难找到的。那么测试人员能做的是把大家聚到一起,对将要实现的目标和已有的资源做一个理性的分析,评估完毕给出分析报告,由测试经理和项目经理给出意见和建议,在不影响到项目成本和项目任务关键路径的情况下由测试经理给出最终的裁决:工具选取、人员、资源配备、进度计划等等。

综上所述,新产品项目开发的自动化测试在项目前期要做很多的调研和探索分析,一般需要选取一个或几个典型案例场景做出范例,论证其可行性。这样做的目的其实很简单:不让自动化成为项目的负担,让所有干系人明白自动化上的投入时值得的;让项目经理和测试经理放心、让参与自动化开发的同事树立信心。这一点无论对于什么模式下的测试都是十分重要的,但是在项目测试中显得尤为重要,因为这从根本上牵动着项目的铁三角:时间、成本、质量。如果投入的人力和资源没有给系统质量带来提高,或者中途反反复复,无疑是对项目的巨大打击。

  2)一般的开发项目测试

  相比之下,一般的系统开发项目倒因为自动化测试人员对现有技术平台和业务需求都是比较熟悉而变得稍微简单一些。

  ① 对于系统改造和大规模的补丁需求立项来说,如果这个系统(群)从未进行过自动化测试,那么笔者个人认为最好不要为了这么个项目做过多的自动化投入,至少在项目周期内不要做。因为项目周期一般没有那么长,人力资源配备远不如新产品开发,这样的情况下进行自动化首先要考虑已经成熟应用是否也要同步完成。如果需要完成整个系统的自动化那么对项目进度的影响和测试资源的占用是比较大的;如果只完成现有项目测试内容,那么前文提到的每次向测试环境的重要发布的回归测试可能不够全面,而且这样部分手工部分自动化执行对于测试分析和度量统计是一件较为麻烦的事情。

  ② 同上一点,如果这个系统(群)已经进行过自动化测试,在现有成熟的框架下已经有足够多的测试用例,那么自动化就非常简单。所要做的是:

  <a> 在原有的框架体系下扩展自动化测试的内容,完成项目测试的自动化;

  <b> 在SA或者BA的协助下重新梳理已有场景、流程,整合原有的、新增的自动化测试案例或者场景,分析项目变更重点和关联影响重点,为项目测试组建一套完整的自动化测试集合,用于每次版本发布测试环境的冒烟和回归测试。

  ③ 对于技术升级和架构转平台,如果项目经理和测试经理决定在项目中大规模进行自动化测试,无论之前的系统(群)是否已经完成自动化,整个自动化测试都要重头再来。同新产品开发项目测试的自动化类似,新架构、技术平台下的自动化分析、调研是必不可少的环节。之后的整个过程也是类似的,但是由于这种项目的周期可能不会有新产品开发那么长,资源也未必有那么充足,所以在论证自动化的可行性的时候一定要多关注在项目周期内的投入和产出是否协调的问题。

  3)运营维护性需求测试

  相比项目的两种测试模式,运营测试是铺开大规模的、系统化的全面自动化测试比较经济的一个模式,因为系统投入运营之后已经有了完善的文档和非常成熟稳定的界面,测试人员已经对系统业务流程和所采用的技术及其对应的测试技术非常熟悉了。显然项目阶段频繁的需求变更和界面改动在这个阶段内是比较少的,自动化开发和维护的成本非常低,并且应用于冒烟测试、回归测试的效果是立竿见影的。

  ① 如果在项目测试阶段已经完成自动化开发,那么在系统运营的时候只需稍微整理现有的功能点、场景和流程分支,搭建用于每次发布的冒烟和回归测试集合即可。当然,补丁需求带来新的功能点和关联的变更也是需要自动化工程师进一步自动化开发和维护的,不过比起整个系统自动化测试的组建,这部分内容将不会消耗很多人力资源。

  ② 还有一种情况是项目阶段某个(些)系统没有进行自动化功能测试或者没有进行完全的自动化测试。这种情况下的自动化开发需要了解如下几点:

  <a> 固定时间内,版本发布的周期和测试环境的修复移交次数将直接作用于投入产出比例。版本发布越频繁冒烟、回归测试的次数自然也就越多,自动化测试带来的直接价值越大;测试环境的修复移交次数越多,冒烟次数越多,用于每次移交版本的质量评估操作越简单。例如,版本部署窗口在17点,部署1小时内完成,18点半开始大规模的自动化运行,次日早上即可得出一份较完整的测试报告。

  <b> 反之,相同周期内版本发布的次数越少……那么从上一段的论述是不是可以得出这么一个结论呢:由于使用次数少自动化变得没有价值或者价值不大?事实上并不是这样的,看自动化的价值不仅仅是看投入和产出在开发时间和运行次数上的比例!在项目周期内这一点非常重要是因为它牵动着项目的各个方面,但是在项目之外除了单纯的考虑自动化开发和应用时间比例之外还要考虑管理成本和质量目标,后者往往被大家所忽略,这一点后文会继续分析。

  如果已经有了成熟的自动化测试体系框架,建议自动化工程师不要过多的参与运营测试阶段内的自动化开发。首先,一般测试人员对系统逻辑更加熟悉,对测试过程中使用自动化的需求更迫切。其次,让每个测试负责人都有机会学习一下自动化开发是一件好事,尤其是在有锻炼机会的情况下测试技术和测试理念的提升会很快。第三,无休止的开发和维护会把自动化测试工程师陷在某些系统中,虽然实践的机会比较多,但是或许有很多更重要、难度更大的自动化开发在等着他们,把他们的精力分散在长期的多系统的补丁测试开发和维护不利于人力的随时调度。第四,自动化测试工程师本身的职责应该偏向于测试框架的修补升级、自动化测试管理协助、新技术和疑难技术的研究和解答、自动化测试工具的开发,而不是单纯的做自动化测试的开发。

Similar Posts:

  • AutomationQA.com开始连载 TIB工作室核心成员 刘毅 的《软件测试自动化的探索与管理》专栏文章

    AutomationQA.com开始连载 TIB工作室核心成员 刘毅 的<软件测试自动化的探索与管理>专栏文章: http://www.automationqa.com/automation-view/tibexpertcolumns/item/96-software-test-automation-exploration-and-management_1.html

  • 软件测试自动化的纠结

    人们在谈到软件测试自动化时,首先会想到测试工具,包括功能测试工具.性能测试工具等.而测试工具能执行各种不同的.具体的测试,就依赖于测试脚本.测试人员通过开发测试脚本(test script),来实现测试用例所要进行的具体操作和验证.一旦选定测试工具,则测试脚本的开发就成为测试人员的日常工作之一,也是测试自动化的最主要的工作.也就是说,测试脚本的开发和维护直接关系到软件测试自动化的成败,至少对自动化测试的投入产出存在巨大的影响. 测试脚本从最初的录制脚本发展到结构化脚本.数据驱动 (data-dr

  • 企业软件测试自动化时机尚未成熟

    对于一个企业用户来说,什么样的软件自动化方案将是他们所需要的呢? 根据笔者和不同企业用户的沟通和交流,他们的软件自动化需求往往更多的集中在:自动化软件测试管理流程,以达到始终一致的软件质量和可量化的,可衡量的测试过程管理;通过实现测试自动化,以提高测试案例的复用和实现内部标准化,从而提高测试效率. 但同时,企业用户也将综合考虑测试自动化给当前的企业部门与部门间的合作以及现有的工作流程所带来的冲击,在软件测试自动化过程中也往往选择"进化"方式,而不是"革命"的方式.

  • 软件测试自动化解决方案之第一部分(下)

    接上文... ... 测试阶段 描述 备注 单元测试/组件测试 这个测试工作通常是开发人员的职责,很多不同的方法能够被使用,比如"测试先行",它是一个测试框架,开发人员在编写代码前编写不同的单元测试,当测试通过时,代码也被完成了. 通过使用正式的单元测试,不仅能够帮助开发人员产出更加稳定的代码,而且能够是软件的整体质量更加的好. 集成测试 这里的测试工作集中在验证不同的组件之间的集成上. 这种类型的测试通常是被测试系统的更加复杂测试的基础,大量的边缘测试被合并以制造出不同的错误处理测试

  • 软件测试自动化的注意事项

    软件测试自动化的注意事项 因为软件测试的工作量很大( 40% 到 60% 的总开发时间),而又有很大部分适于自动化,因此,测试的改进会对整个开发工作的质量.成本和周期带来非常显著的效果. 首先,谈谈在测试自动化的情况下,带有图形界面的产品的测试用例的设计问题.因为图形界面的输出显示不是很容易做到测试结果自动化比较,所以一般的做法是把图形界面输出的部分单独建立测试用例,以手工运行.而所有非图形输出则可进行自动测试. 下面举出一些测试自动化的例子: 1. 测试个案( test case ,或称为测试

  • 《软件测试自动化之道》读书笔记 之 底层的Web UI 测试

    <软件测试自动化之道>读书笔记 之 底层的Web UI 测试 2014-09-28 测试自动化程序的任务 待测程序 测试程序 启动IE并连接到这个实例 如何判断待测web程序完全加载到浏览器 操纵并检查IE Shell 操作待测Web页面上的HTML元素的值 验证Web页面上HTML元素 示例代码 测试自动化程序的任务 底层技术的核心是,通过直接调用mshtml.dll和shdocvw.dll库来访问并且操纵IE客户区域的HTML对象. 待测程序 新建一个网站"WebAUT"

  • 【软件测试自动化-QTP系列讲座 22】 == 描述性编程 ==

    Rss订阅IQuickTest(关于如何订阅?) GoogleReader订阅地址: http://feeds.feedburner.com/iquicktest 作者:zzxxbb112 时间:2009/12/09 版权所有,侵权必究. 出处:http://blog.csdn.net/zzxxbb112 这一章的内容较为简单,对描述性编程熟悉的朋友可以直接略过,为了教程的完整性还是把这章的内容补上去,在学习本章之前,请先务必完成以下讲座的学习: [软件测试自动化-QTP系列讲座 2] == 对

  • springsecurity扩展自定义会话管理(二)提供管理员调用踢出用户

    springsecurity扩展自定义会话管理(二)提供管理员调用踢出用户 配置文件基本上和(一)比没有做什么修改,只是不限制用户用同一账号登陆,所以配置maximumSessions为-1 <beans:bean id="currentController" class="org.springframework.security.concurrent.ConcurrentSessionControllerImpl"> <beans:propert

  • 【新炬网络名师大讲堂】Oracle Database 12c 又一利器–自动化信息生命周期管理

    新炬网络定期推出"名师大讲堂"专业IT技术知识分享,内容涉及Oracle数据库.性能测试.软件自动化测试等,与工作在技术前线的小伙伴们一起探讨实践中出现的技术难题,提供有效解决方案,大家通过交流共同成长! "21世纪是信息化的时代",这句话真不假,当前信息化的程度已经不可同日而语了,信息化给大家带来便捷的同时也会带来一些问题,其中的一个大问题就是数据量的快速增长. oracle 产品管理高级总监Kevin Jernigan提到"2011 年数据量达 180

  • 【软件测试自动化-QTP系列讲座 43】== MTM多脚本执行管理器(二) 自动化模型篇==

    作者:zzxxbb112 时间:2011/10/26 版权所有,侵权必究. 出处:http://blog.csdn.net/zzxxbb112 在上一次的讲座中,我们已经简单介绍了使用MTM这个工具,并且讲解了如何利用MTM的命令行模式来自动化QTP执行自动化测试脚本. 那么这一次主要来讲解如何使用MTM的自动化模型来自动化MTM与QTP. 相信大家都已经了解了什么是QTP的AOM自动化模型,那是qtp安装完成之后所提供的一种自动化组件,如果不清楚的话,可以看一下本讲座的第10篇 那么MTM的自

Tags: