自动化测试的见解(引用)

上一篇 / 下一篇  2014-10-12 10:32:47 / 个人分类:测试技术

文章出处:http://blog.163.com/mary_xiaoli/blog/static/136296875201061101618532/

适用场合

  通常适合于软件测试自动化的场合:   (1)回归测试,重复单一的数据录入或是击键等测试操作造成了不必要的时间浪费和人力浪费;   (2)此外测试人员对程序的理解和对设计文档的验证通常也要借助于测试自动化工具;   (3)采用自动化测试工具有利于测试报告文档的生成和版本的连贯性;   (4)自动化工具能够确定测试用例的覆盖路径,确定测试用例集对程序逻辑流程和控制流程的覆盖;   随着测试流程的不断规范以及软件测试技术的进一步细化,软件测试自动化已经日益成为一支不可忽视的力量。能否借助于这支外在力量以及如何借助于这支力量来规范企业测试流程、提高特定测试活动的效率,正是本期所要讨论的话题。   目前,软件测试自动化的研究领域主要集中在软件测试流程的自动化管理以及动态测试的自动化(如单元测试功能测试以及性能测试方面)。在这两个领域,与手工测试相比,测试自动化的优势是明显的。首先自动化测试可以提高测试效率,使测试人员更加专注于新的测试模块的建立和开发,从而提高测试覆盖率;其次,自动化测试更便于测试资产的数字化管理,使得测试资产在整个测试生命周期内可以得到复用,这个特点在功能测试和回归测试中尤其具有意义;此外,测试流程自动化管理可以使机构的测试活动开展更加过程化,这很符合CMMI过程改进的思想。根据OppenheimerFunds的调查,在2001年前后的3年中,全球范围内由于采用了测试自动化手段所实现的投资回报率高达1500%。


方案选型六大原则

   然而存在优势是否就一定意味着选择自动化测试方案都能为企业带来效益回报呢?也不尽然,任何一种产品化的测试自动化工具,都可能存在与某具体项目不甚贴 切的地方。再加上,在企业内部通常存在许多不同种类的应用平台,应用开发技术也不尽相同,甚至在一个应用中可能就跨越了多种平台;或同一应用的不同版本之 间存在技术差异。所以选择软件测试自动化方案必须深刻理解这一选择可能带来的变动、来自诸多方面的风险和成本开销。   以下笔者给出企业用户进行软件测试自动化方案选型的参考性原则,这些原则是从笔者实际工作中凝练而成的,它包括以下六个方面的建议:   ●选择尽可能少的自动化产品覆盖尽可能多的平台,以降低产品投资和团队的学习成本;   ●测试流程管理自动化通常应该优先考虑,以满足为企业测试团队提供流程管理支持的需求;   ●在投资有限的情况下,性能测试自动化产品将优先于功能测试自动化被考虑;   ●在考虑产品性价比的同时,应充分关注产品的支持服务和售后服务的完善性;   ●尽量选择趋于主流的产品,以便通过行业间交流甚至网络等方式获得更为广泛的经验和支持;   ●应对测试自动化方案的可扩展性提出要求,以满足企业不断发展的技术和业务需求。


过程

   自动化测试与软件开发过程从本质上来讲是一样的,无非是利用自动化测试工具(相当于软件开发工具),经过对测试需求的分析(软件过程中的需求分析),设 计出自动化测试用例(软件过程中的需求规格),从而搭建自动化测试的框架(软件过程中的概要设计),设计与编写自动化脚本(详细设计与编码),测试脚本的 正确性,从而完成该套测试脚本(即主要功能为测试的应用软件)。   1) 自动化测试需求分析。   当测试项目满足了自动化的前提条件,并确定在该项目中需要使用自动化测试时,我们便开始进行自动化测试需求分析。此过程需要确定自动化测试的范围以及相应的测试用例、测试数据,并形成详细的文档,以便于自动化测试框架的建立。   2) 自动化测试框架的搭建。   所谓自动化测试框架便是像软件架构一般,定义了在使用该套脚本时需要调用哪些文件、结构,调用的过程,以及文件结构如何划分。   而根据自动化测试用例,我们很容易能够定位出自动化测试框架的典型要素:   a. 公用的对象。   不同的测试用例会有一些相同的对象被重复使用,比如窗口、按钮、页面等。这些公用的对象可被抽取出来,在编写脚本时随时调用。当这些对象的属性因为需求的变更而改变时,只需要修改该对象属性即可,而无需修改所有相关的测试脚本。   b. 公用的环境。   各测试用例也会用到相同的测试环境,将该测试环境独立封装,在各个测试用例中灵活调用,也能增强脚本的可维护性。   c. 公用的方法。   当测试工具没有需要的方法时,而该方法又会被经常使用,我们便需要自己编写该方法,以方便脚本的调用。   d. 测试数据。   也许一个测试用例需要执行很多个测试数据,我们便可将测试数据放在一个独立的文件中,由测试脚本执行到该用例时读取数据文件,从而达到数据覆盖的目的。   在该框架中需要将这些典型要素考虑进去,在测试用例中抽取出公用的元素放入已定义的文件,设定好调用的过程。


脚本的编写

  该编写过程便是具体的测试用例的脚本转化。初学的自动化测试人员均会使用录制脚本到修改脚本的过程。但专业化的建议是以录制为参考,以编写脚本为主要行为,以避免录制脚本带来的冗余、公用元素的不可调用、脚本的调试复杂等问题。


脚本的测试与试运行

   事实上,当每一个测试用例所形成的脚本通过测试后,并不意味着执行多个甚至所有的测试用例就不会出错。输入数据以及测试环境的改变,都会导致测试结果受 到影响甚至失败。而如果只是一个个执行测试用例,也仅能被称作是半自动化测试,这会极大的影响自动化测试的效率,甚至不能满足夜间自动执行的特殊要求。   因此,脚本的测试与试运行极为重要,它需要祥查多个脚本不能依计划执行的原因,并保证其得到修复。同时他也需要经过多轮的脚本试运行,以保证测试结果得一致性与精确性。   自动化测试引入的原因是就把软件测试人员从枯燥乏味的机械性手工测试劳动中解放出来,以自动化测试工具取而代之,使测试人员的精力真正花在提高软件产品质量本身。


实施中的注意事项

   首先,一个企业实施测试自动化,绝对不是拍脑袋说干就能干好的,它不仅涉及测试工作本身流程上、组织结构上的调整与改进,甚至也包括需求、设计、开发、 维护及配置管理等其他方面的配合。如果对这些必要的因素没有考虑周全的话,必然在实施过程中处处碰壁,既定的实施方案也无法开展。其次,尽管自动化测试可 以降低人工测试的工作量,但并不能完全取代手工测试。100%的自动化测试只是一个理想目标,根据笔者的经验,即便一些如SAP、OracleERP等测 试库规划十分完善的套件,其测试自动化率也不会超过70%。所以一味追求测试自动化只会给企业带来运作成本的急剧上升。再次,实施测试自动化需要企业有相 对规模的投入,对企业运作来说,投入回报率将是决定是否实施软件测试自动化的最终指挥棒,笔者建议企业在决定实施软件测试自动化之前,必须要做量化的投资 回报分析。此外,实施软件测试自动化并不意味着必须采购强大的自动化软件测试工具或自动化管理平台,毕竟软件质量的保证不是依靠产品或技术,更多的因素在 于高素质的人员和合理有效的流程。

TAG:

 

评分:0

我来说两句

Open Toolbar