我不会在这里告诉你如何开发软件。我假设你们已经知道一些关于怎样将合理并有效的方法用于开发软件的软件组织中的一员。我只是力促你们同样遵循软件开发的原则作为自己测试自动化的原则。这篇文章由那些我们所有用在软件开发项目的标准步骤组成,并且在专为测试自动化考虑和挑战的地方做了特别的说明。
本文将向读者介绍 IBM Rational Functional Tester 的强大的功能和良好的易用性,以及如何帮助测试人员轻松的完成自动化的功能测试。
手工测试和自动化测试也是很多测试人员争相讨论的两种测试方法。有人对自动化测试趋之若鹜,也有人对自动化测试嗤之以鼻。在做出如何看待自动化测试的决定之前,首先要对自动化测试有一个清晰的认识。
自动化测试的意义,在很早以前就被自动化老手定位在回归测试中,或者说是由于主流的测试工具带来的负面影响,目的在于确保工程质量。因此这个理念也随着时间的推移根深蒂固,很多人不愿意思考,自动化就是回归测试的人力代替品,这样也导致了自动化普及成了一个瓶颈。敢说现在很多公司对自动化的重视远远没有手工测试来得多,在这里与自动化的定位脱不了干系。
为了弥补工具的这一缺陷,需要通过自动化测试设计将测试人员在测试过程中思考的过程加入到脚本中,使得测试工具具备一定的‘判断’能力和‘思维’能力,自动测试设计的主要工作就是通过设计让自动测试工具拥有这种能力。
在微软,自动化测试只是一个工具,做不做、什么情况/时间做,都是全盘分析的结果。就算绝大多数团队都在做,也只是一个结果,而不是原因。独立自主的思考,深入细致的调研,扎实的系统分析能力,代表用户说话,才是微软赞赏的卓越工程。
一旦决定要实施自动化测试,则主要风险来源于维护自动化测试的成本,运行自动化测试的成本,创建自动化测试的成本。而创建自动化测试的质量高低,决定了运行自动化测试的成本高低风险和维护自动化测试的成本高低风险。且项目本身的特性也会影响维护自动化测试的成本风险。
因为软件测试的工作量很大(40% 到60% 的总开发时间),而又有很大部分适于自动化,因此,测试的改进会对整个开发工作的质量、成本和周期带来非常显着的效果。
自动回归测试所面临的最大问题就是退化和过早消亡”,当自动化测试在如火如荼的进行过程中,一个突如其来的软动件变更、重构、开发平台变更、开发 工具变更、关键人员离职可能会导致整个自化测试流程的夭折。听起来有些耸人听闻,但当现实摆在面前的时候,我们不得不思考这样一个问题,如何防止这类现象的发生,当这种现象即将到来时,我们又应该怎样做呢?
少做自动化,多写小工具,读懂程序,是高效省钱的测试方法,除非你钱多得没地方花。下次有谁建议搞什么测试自动化构架,告诉他"That is bullshit".
如果你认为测试自动化仅仅是执行测试,那么你就是在错过一个很大的机会,或者说,你由于失去许多小的机会进而失去一个大的机会。可以这么考虑:不要再把自动化测试仅仅看成需要使用价格不菲的工具去执行自动化,而应该认识到,自动化测试其实是可以在几天内通过并不昂贵或者是手头已有的工具就可以完成的测试。丹尼佛特和詹姆士巴哈提出了一个比较快捷的方式自动化测试方法。
不少介绍微软测试过程的文章都强调大量运用自动化测试,给人一个只要有了自动化测试,整个测试过程就得到保证的印象。不可否认自动化测试的作用,但是对于下面两个问题:“自动化测试总是任何时间内、任何条件下、任何项目阶段中的最佳选择吗?”“进行/不进行自动化测试的决策是怎样做出来的?”
当软件产品转入到软件测试部门开始系统测试之前,开展软件预测试,由软件测试人员验证被测试软件的基本功能是否正常,从而保证系统测试不会由于软件基本功能的缺陷而挂起。软件预测试是软件测试可以正常进行的一种保证手段。
Firefox的市场占有量的上升使得很多网站都针对Firefox有了很好的支持,于是firefox浏览器上的测试也越来越重要,随着Test case的增多,自动化也就自然而然成为了一个课题。我来向大家介绍几种可行的方法。
建立基于关键字的测试设计和测试自动化的前提是:构成任何应用程序的离散功能性业务事件可以使用短文本描述关键字和相关联的参数值对变量进行描述。例如,大多数应用程序要求用户登录;此业务事件的关键字可以是“登录用户”,参数可以是“用户ID”和“密码”。通过设计关键字来描述离散功能性业务事件,测试员开始建立一个可用于创建关键字测试案例的通用关键字库。这便是创建语言(关键字)以描述应用程序内一系列事件(测试案例)的实际过程。