• 空间首页
• 空间管理
• 51Testing软件测试网
• 站点论坛
• 添加我的日志

我的最新日志

• 我所接触过的自动化工具

  2008-6-29

  因为我个人对技术的偏爱，所以尽管我所从事的是功能测试，但是测试领域中我最感兴趣的一块还是自动化测试。从最初接触过的基于httpunit的公司内部的自动化测试工具，到后来的sliktest、watir、selenium、testcomplete，以及我所开发的基于perl和excel的小型数据驱动自动化测试工具，我所接触的自动化工具主要针对web应用程序、eclipse rcp程序以及soap/rest等web服务的测试。
  
  这些工具可能有些大家并不熟悉，这里我大体介绍一下，以便相关的测试同行们参考。在以后的日志中应该会有更详细的针对一些工具的介绍和经验分享，敬请期待 =)
  
  基于httpunit的自动化测试工具
  

  这是我们公司内部的一款针对web应用程序的开源自动化测试工具。功能比较强大，支持record&replay，支持参数传递，并且提供一定程度的测试用例管理，但是它也有着无法支持JS和AJAX这些在Web 2.0时代所必需技术的致命弱点。
  
  

  silktest
  

  在我刚接触的时候，这一商用产品应该还未被Borland纳入旗下。它对.net程序的支持以及当时相对较低的费用促使我们公司早期使用它来强化我们的自动化测试能力。而使用它来实现eclipse rcp程序的测试完全是我尝试后发现的意外之喜，可惜我们公司仅仅使用的还是当年买的老版本，bug一堆。
  
  

  watir
  

  这是我个人接触的最早的一款针对web应用程序的开源自动化测试工具。它是一个ruby的gem（类似库文件）。早期不支持record&replay，但是可以依赖强大的ruby实现模块化设计以及复杂的逻辑。另外虽然它早期不支持IE以外的浏览器，但是由于其使用ActiveX控件技术控制IE，所以相当稳定。针对web应用程序的自动化测试之所以要提及稳定性，这是由浏览器以及web程序本身的特殊性决定的：像ie，ff等浏览器为防止恶意代码往往会有很多安全机制，它的副作用就是限制了自动化测试工具对它的控制；而且web程序本身往往也难于精确判定页面加载的完成，比如由客户端JS所写的简单时钟程序，它本身就没有一个静止的页面，更何况Web 2.0时代花哨的JS和AJAX。
  
  

  selenium
  

  这是我使用最久的以及二次开发力度最大的一款针对web应用程序的开源自动化测试工具。selenium本身的产品线十分丰富，包括：selenium core, selenium ide, selenium rc，及其官方近期推出的一些管理工具。社区涉略最多的当数selenium rc，可惜我们公司用的最多的是selenium ide及其背后的chrome模式，以及早期使用的selenium core。selenium支持record&replay，通过javascipt写成的引擎支持多种浏览器（selenium core的hta模式及selenium ide除外），但这一优点也是它的命门所在，举个例子，如果你的测试用例需要浏览器禁用js，selenium就爱莫能助了（这个时候考虑watir吧=））。另外，js的操作权限往往仅限于本域名，如果你不能把你的测试用例部署在同一域名下，这就需要你绕过浏览器的the same origin policy。在ie下面，你可以通过hta方式解决，不过bug一堆；在firefox下，chrome模式是一个好选择，尽管也有些问题，但是通过二次开发基本上都可以解决。
  
  

  testcomplete
  

  相对价格比较便宜的商用工具。据说针对flex应用程序有奇效，当然还有待证实。但我接触它的目的本是为了eclipse rcp自动化测试的更新换代，可惜论证下来，还不如原来的老版sliktest。
  
  

  基于perl和excel的小型数据驱动自动化测试工具
  

  这算是我个人基于数据驱动测试理论设计的一款工具。其应用方向主要是soap和rest的自动化测试。由于这两种web服务测试比较简单，仅仅是期望输出和实际输出的正则匹配，所以十分适用于这种数据驱动的工具。
  
  

  下期预告：web应用程序开源自动化测试工具的选择
  
  （BTW，51testingblog回退之后不保留表格数据，实在是令人痛苦啊，今天在小小的笔记本键盘上的几次误操作害我重写了N多遍=(，以后看来不能在线编辑了。）
  

  查看(333) 评论(1)

• 我所接触过的测试类型

  2008-6-27

  盲人摸象，各有各的说法。测试类型就是这么一头大象，而我们则是其中的某类“盲人”。从程序是否需要执行的角度来看，有静态有动态。从代码是否对测试者透明的角度来说，有黑盒有白盒。从测试流程上而言，则有unit testing, smoke testing, feature testing/function testing, end 2 end testing, regression testing，还有鉴于公司和职位特殊性我接触比较少的integration testing, system testing和L&P testing，另外还有屡建奇功的ad hoc testing。
  前两个分类角度，其区分很明显，刚刚接触测试的人其实也很容易想明白。而流程上的分类，如果没有在测试岗位工作一段时间的话，个人感觉其实很难明白分类的背后原因以及它们的存在价值。这里我把对熟悉的几种类型整理了一下，如果有理解的偏差，大家一起探讨。
  
  顺带一提的是，流程上的分类，我个人觉得也可以理解为测试目的（motivation）上的分类，它们尽管都有保证质量的大前提，但是实现的价值是不一样的。
  
  熟悉的几种基于流程分类测试类型：
  
  unit testing （单元测试）：
  
  实例：一个积木（团圆出品）搭建的城门，每块积木质量的好吗？
  
  开发往往是建积木完了搭积木的过程，而每一块积木建好后就需要测试，这一测试往往都是白盒测试，而这一测试阶段一般是开发人员直接介入的，也有部分公司会投入具有编程经验的测试工程师在其中以期取得更好的测试效果。它的测试目的，其实就是积木本身质量的检测，还无直接关乎积木搭出来的作品的效果。
  
  smoke testing （烟盒测试）：
  
  实例：一个积木搭建的城门，搭建好后，吹口气，倒了吗？
  
  刚接触时，觉得这个名字很有意思，并未理解其背后含义，只是朦朦胧胧感觉这是测试前的测试。其实烟盒测试最早应该源于管道测试或电子产品测试，前者是通烟以检查泄露，后者则是通电以检查引起电路起火冒烟的短路。从这一术语来龙来讲，烟盒测试就是最基本的检查，是测试前的基本测试。对于软件测试，它往往是对整个产品由代码编译形成新版本可执行程序之后的一次基本检查，以便后期测试工作的展开。比如图形化的计算器程序，那么起码你双击程序的图标之后，计算器界面就应该出来了，至于数目加起来对不对，我就不管了。但其实对于软件测试而言，smoke testing的程度往往取决于测试者自己的判断，并未框定。所以我们明白它的目的即可，为了以后测试成功展开而进行的测试。
  
  feature testing/function testing （功能测试）：
  
  实例：一个积木搭建的城门，搭建好后，它是个城门吗？
  
  这个是我接触最多的一类测试，却也可能是我最难界定的一类测试。从字面理解，其实它便是实现主体功能测试的一个阶段。但真正理解它，可能还要结合后面的回归测试来说，因为它的测试目的，只是为了确保当前这个项目所提出的一些功能的测试，而不包含原有平台或者说原来项目所涉及的各种功能。从一个侧面来理解，它的测试很有可能针对的是版本控制系统里的一个branch编译后的可执行程序。
  
  end 2 end testing (端端测试---个人翻译的术语，仅为理解）：
  
  实例：用建好的城门，连上其它人建好的护城河等等等等，能变实实在在的城堡么？
  
  一个积木搭成的城堡，它的搭建往往不是由积木与积木直接搭建而成，而是由基于积木搭成的一个个小功能模块组成，譬如城门，譬如护城河...而端端测试正是为了把这些小功能模块最终互相接上而进行的测试。它存在的时间往往介于功能测试和回归测试之间。它的测试目的为的就是看看各个功能模块是否连通。
  
  regression testing （回归测试)：
  
  实例：一个积木搭成的城堡，你给它换了个城门，一它还是个城门吗？二它影响了城堡的其它地方吗？
  
  无论从英文还是中文字面上去理解这种测试，一开始似乎都不会很清晰，其实它说白了也是功能上的测试，但区别于功能测试，它是对既有功能的测试。好的产品服务一般都会有后续的版本更新，这便给了回归测试诞生的可能性，新的更新除了符合它标注的新功能外，有没有给老的其余功能带来影响。回归测试的目的便在于此。
  
  ad hoc testing （随机测试）：
  
  实例：一个积木搭成的城堡，你随便的挑个细节查查看。
  
  随机测试字面上很好理解，就是随机进行的测试，无指定目的的测试，测到哪儿是哪儿。但是随机测试找的问题往往是以上任何一种测试方式难以发现的，比如说，当你浏览了一个页面之后，你又手工输入URL进了另一个与该页面无直接关联的页面，发现该页面工作不正常，这种测试用例在以上的任何一种测试类型中都不可能出现，但却是有可能存在的问题，背后原因可以是原来两个页面背后不同的开发小组碰巧用了同一个cookielet来实现不同的功能。所以随机测试的目的可以说其实就是没有目的，但对于有经验的测试者来说，他们的随机测试往往相当高效，背后应该存在一些用例的设计模式，可惜测试领域还没有类似GOF出品的针对测试用例的设计模式。
  
  （下期节目预告：我所接触过的自动化工具）
  
  

  查看(261) 评论(2)

• 51testingblog记录我的测试历程

  2008-6-26

  作为一年实习和一年正式工作的软件测试工程师，终于在理论和实践上都有了一些积累，现在开通此处blog专为记录我的测试历程。

  查看(70) 评论(0)