005-自动化测试简介

1.什么是自动化测试?     

      维基百科对自动化测试的定义是:自动化测试就是使用软件来控制测试案例的执行。它会将实际测试结果与预期结果进行比较,并提供测试预置条件设定、测试逻辑控制以及生成测试报告等重要功能。通常,自动化测试都是基于已经存在并拥有成熟测试流程的人工测试来实现的。

      尽管人工测试可以发现大量的软件系统缺陷,但它无疑会耗费大量人力以及时间,并且不容易发现某些特定类型的缺陷(例如数个下拉菜单的逻辑组合查询测试)。对测试进行自动化的过程,就是写一段程序来代替人工测试。一旦测试被成功自动化后,它们就可以在任何需要的时候快速执行。对于软件维护周期很长的应用系统而言,这无疑是最高效的方式。因为在漫长的软件维护周期中,一个很小的改动,都可能导致原本正常的功能失效。通过自动化测试可以极大地提升回归测试、稳定性测试和兼容性测试的工作效率,在保障产品质量和持续构建等方面起到举足轻重的作用。特别是在敏捷开发模式下,自动化测试更是必不可少的步骤。

      自动化测试有如下两种常见的方式:

(1)代码驱动测试

      通过大量不同的输入参数和对应的返回结果,来验证类、模块或库文件的公共接口是否正确。使用测试框架(例如xUnit框架、JUnit和NUnit)来进行单元测试,以便判断代码片段在不同配置环境下的表现是否符合预期。“以代码驱动测试自动化”方式测试通过的代码,比传统人工测试通过的代码更可信赖,代码的维护成本也会更低。原因在于“代码驱动测试自动化”的代码覆盖率更高,另外,在整个软件开发周期中,它都可以不断地进行测试,而不必等到测试阶段去修复,这样成本会低很多。

(2)图形用户界面测试

      测试框架产生用户界面事件(例如键盘敲击、鼠标单击等),并捕获事件导致的图形用户界面改变,以便验证可见的程序响应是否正确。很多自动化测试工具都支持“录制/回放”特性,它们允许用户交互地录制自己的操作,在需要的时候进行回放,并将回放的实际结果与期望结果进行比较。这一方式的优点在于,它不需要大量的开发工作,甚至根本没有开发工作量。它可以被用户测试任何拥有图形界面的软件系统,但是如果你依赖于这种方式,就会面临测试可靠性存疑和测试脚本不易维护的问题。有时候一个按钮在窗口中移动了位置,都可能导致测试脚本的重构。“录制/回放”特性有时候还会在测试脚本中加入不相关的用户操作,甚至不能正确录制某些操作。这类自动化测试的一个变种就是Web自动化测试,它的测试对象是Web页面,而非Windows程序接口。它读取HTML文件,而非Windows事件。例如,Selenium和WebDriver。这类自动化测试还有另一个变种,那就是无脚本自动化测试,它并不使用录制和回放,而是去建立待测系统的模型。在这种模式下,测试人员建立测试案例,只需提供测试参数和条件。测试人员无需编写测试脚本,就拥有了测试脚本的基本功能和灵活性。测试案例维护比较简单,因为没有脚本需要维护,待测系统的对象发生改变后,可以很容易地重新识别或者添加。它适用任何基于GUI的软件系统,例如QTP的关键词驱动。

      近年来,测试领域和几年前相比发生许多令人欣喜的变化:

      1)敏捷开发模式的盛行掀起自动化测试的一轮热潮,测试和开发合作越来越密切。

      2)测试工作的技术性越来越强,以往常见的“基于开源软件提升开发效率”的模式也被广泛应用到测试工作中。

      3)组件化、软件产品线开发模式的进一步成熟,开发效率和测试效率随之进一步得到提高。

      自动化测试相较于手工测试的优势在于:

      1)能够支持频繁的回归测试;

      2)能够在软件开发过程中尽早发现缺陷;

      3)能够完成某些手工测试难以完成的工作,如并发测试、压力测试等;

      4)能够提高手工测试的工作效率,如执行具有多个重复步骤的测试用例;

      5)定制化的系统缺陷报告;

      6)更好地支持敏捷和极限开发模式;

      7)避免人为因素导致的漏测。

      实施自动化测试前需要对软件开发过程进行分析,以观察其是否适合使用自动化测试通常需要满足以下几个条件:

      1)需求变动不频繁。

测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁,测试人员需要根据变动的需求来更新测试用例和相关的测试脚本,而脚本的维护本身就是一个代码开发的过程,需要修改和调试,必要时还需要修改自动化测试的框架。如果耗费的成本高于节省的测试成本,那么自动化测试便是失败的。如果项目中的某些模块相对稳定,而某些模块需求变动性很大,可以针对相对稳定的模块进行自动化测试,而变动较大的仍采用手工测试。

      2)项目周期足够长

自动化测试需求的确定、框架的设计、测试脚本的编写和调试都需要相当长的时间来完成,这个过程本身就是一个测试软件的开发过程,需要较长的时间来完成。如果项目的周期比较短,没有足够的时间去支持这样一个过程,那么自动化测试变成为笑谈。

      3)自动化测试脚本可重复使用。

如果费尽心血开发了一套近乎完美的自动化测试脚本,而脚本的重复使用率很低,致使期间所耗费的成本大于创造的经济价值,自动化测试便成为了测试人员的练手之作,而并非是真正可产生效益的测试手段。

      4)手工测试无法完成的测试工作。

某些测试采用手动的方式无法完成,或者需要投入大量时间与人力,此时就可以考虑引入自动化测试,如性能测试、配置测试、兼容性测试、大数据量输入测试等。

      自动化测试虽然有如此多的优势,那是不是意味着自动化测试就是“包治百病”的软件“银弹”呢?有些人可能会有如误区

      1)自动化测试是一种比人工测试更先进、更高级的测试手段。

自动化测试既有自身的优点,也有其局限性。例如对于需求不明确,或者界面经常发生变动的产品就不适合使用自动化测试。自动化测试与手工测试的关系应该是相辅相成,互相弥补各自的局限性,相互促进。

      2)所有的手工测试都应该被100%的自动化。

一味片面地追求自动化率,不仅软件的质量得不到提高,而且还会让测试人员疲于奔命,投入和产出的性价比很低。有不少负面测试就只能通过手工测试的方式完成并进行验收。自动化测试不是万能的,需要根据实际情况引入并有的放矢地设定其覆盖率。

      3)自动化测试能够发现大量的缺陷,它比手工测试更有效。

实际情况是,自动化测试只能发现30%以下的软件缺陷,而手工测试反而能发现更广泛且很深层次的问题。自动化测试在回归测试时可以节省很多时间并快速验收,但这并不意味着其发现问题的能力比手工测试更强。单从发现缺陷的角度而言,自动化测试的效率低于手工测试。

      4)即使一次性的软件项目也应该采用自动化测试。

自动化测试的投入成本,至少要在好几个发布版本之后才能体现其价值。因此对于一次性的软件项目,应该避免采用自动化测试方案。

      5)自动化测试只是测试工程师的事情,与开发人员没有关系。

在软件开发过程中,首先要考虑软件本身的可测试性。如果开发人员一开始就不把软件的可测试性考虑进来,会导致开发的软件难以测试,甚至无法实现自动化测试。

      6)商业自动化测试工具更靠谱,一定要选用商业自动化测试工具。

就自动化测试工具而言,测试团队应该根据自身实际情况来选择自动化测试工具。商业自动化测试工具有技术团队进行支持,遇到问题也许能尽快得到支持。但是如果有特殊的需求,这类软件往往没有自由的可定制功能。而开源自动化测试工具由于源代码都是开放的,如果团队有特殊的定制需求,可以由测试团队自行修改开源自动化测试工具来满足团队需要。

2.Web自动化测试

      当前绝大多数企业应用都是基于Web的应用系统,人们可以通过Web浏览器便捷地访问它们。现在炙手可热的“云计算”大潮也将这一趋势推向了高潮。很多组织和公司采用持续改进的开发模式来应对这种趋势,并采用自动化测试来适应这种高强度的持续开发的模式。相较传统桌面软件的自动化测试,Web自动化测试指的是Web应用系统从用户界面层面进行的自动化测试,通过用户界面测试内部的业务逻辑。Web自动化测试的自身特点下:

      1)Web页面上出现的元素可能具有不确定性。

      2)不同操作系统上不同Web浏览器之间的兼容性。

      3)Web应用的高并发性和容错性。

      4)移动设备上的Web客户端兼容性、旋转性和各种触摸特性。

      Web自动化测试一直都不是一件容易的事情。尤其是在研发团队广泛采用UI框架和敏捷开发来提升交付效率的今天,Web自动化测试变得愈发困难;未来随着Web组件式开发技术和云计算技术的逐渐成熟和落地,又会对Web自动化测试提出怎样的挑战?Web开发过程中UI框架的广泛采用极大提高了开发效率和用户体验,也从技术的角度保障了敏捷开发的蓬勃发展。然而UI框架自动生成的海量页面源码却让原本就举步维艰的Web自动化测试变得雪上加霜:测试脚本的维护成本更大、回放稳定性更差、断言更困难。Web组件式框架的采用可以让用户非常容易地卸载、替换软件的部分模块。原本是个“整体”的软件被“分解”之后可支持灵活组装。我们又该如何保障按照模块依赖关系组装出的所有软件版本都是可用的呢?云计算又能为Web自动化测试带来哪些机遇呢?关于Web自动化测试,有如此多的问题摆在我们面前,就让我们勇敢地去面对和迎接这些新的挑战吧。

 

posted @ 2015-04-27 10:43  RunningYY  阅读(855)  评论(0编辑  收藏  举报