平平庸庸

自动化测试最佳实践

上一篇 / 下一篇  2011-06-16 23:54:34 / 个人分类:概念问题

正确的自动化测试可以给测试团队带来许多好处,而遵循以下这些自动化测试的最佳实践能提升自动化测试成功的可能,使自动化测试的工作获得更大的回报率。

    1。决定对哪些测试进行用例自动化
    2。尽早的并且经常性的执行
    3。选择合适的自动化测试工具
    4。将自动化测试的工作进行合理的分配
    5。创建高质量的测试数据
    6。建立能够抵抗UI变化的自动化测试(相对而言)

Peter Sun 2011年6月17日,~大肥宝健健康康的长大~

1。决定对哪些测试进行用例自动化

  首先第一件要做的事情是决定对那些用例进行自动化,因为我们不可能把所有的用例都做自动化。100%的自动化是不现实,也是不经济的。
  很多公司对自动化效益的评价指标是给定的测试被自动化执行的次数或者实践,其实质是自动化所带来的手工劳动时间的节省,测试执行效率的提升。所以,那些做不了几次的测试最好还是保留在手工执行,因为对其实现自动化的成本可能就超出了其自动执行所带来的收益。所以合适自动化测试的用例是那些运行频繁的,和需要大量的数据来执行相同的动作的测试用例

通过将以下这些测试实现自动化能获得最大的好处:

    a、不同的build运行重复的测试。
    b、可能导致人为错误的测试。
    c、许多测试数据的重复测试。
    d、常用的高风险的测试。
    f、不可能手工执行的测试。
    g、不同软硬件平台和不同配置的重复测试。
    h、手工测试难度很高,需要花很大力气的测试。

  想要获得成功的自动化测试需要做好计划和设计工作。先做个计划,识别出初期能够进行的自动化测试集合。首先,定义好自动化测试的目标,并识别出对那些类型的测试进行自动化。测试有不同的类型。单元,接口,性能,ui自动化。当然这里我们先把着眼点放在ui自动化测试上。

  确定了目标之后,回答如何行动起来实现自动化。最好吧脚本分成几个逻辑层次,把用例,页面对象,测试数据,和业务流程分割开来,而不是全都写在一起,这能带来的好处是测试代码更易管理和协调,把脚本切的更小来提升起易维护性和可执行性。这种方式才能比较适应大型项目的自动化要求。另外,在小功能实现后即可完成自动化的覆盖,而不是等整个项目完成之后(这个看起来还是需要按实际情况来看的,如果小功能并不稳定,页面元素时常调整,那么我觉得还是算了)

  在创建脚本时,尽量让他们小一些,并只正对一个单独的被测对象,小一些那执行单独一个脚本的所花的时间更少,针对单独的被测对象也就是减少对其他功能的依赖,通过这两个来提升测试执行的效果,不会一个用例跑半天看不出效果,或者由于其他功能的问题导致大部分测试无法执行。

  在创建了一些单独的测试脚本之后,你可以把这些脚本用套件(组)的概念管理起来(suite)。一个套件就是一组测试的集合。划分的时候可以更具不同的功能块,或者重要级别的主次等维度来分。如果测试之间存在依赖的话,需要手段来指定这些测试的执行顺序。

2。尽早的并且经常性的执行

  为了获得最有效的自动化测试,测试应尽快开始,并且经常的跑。更早的测试者更深的融入整个项目的生命收起中,越多的测试发现越多的bug。越早发现的bug修复的成本越低廉。

3。选择合适的自动化测试工具

   工欲善其事必先利其器,开始前选择一个合适的工具。考虑以下问题:

    a、测试工具支持项目所使用的平台和技术,比如java or .net. linux or windows?
    b、合适不同技术水平的工作人员?
    c、功能丰富,开放性强,使用简单。能满足自动化的各种需求,录制回放,数据驱动,检查点,等等。
    d、能创建可重用的维护性好的测试。

4。将自动化测试的工作进行合理的分配

   当然,做自动化测试需要技术保证。这就要求对测试团队的人员有一个技能的评估,并根据不同的能力分配不同的工作,比如将编写框架,编写重用脚本,组织重用脚本形成用例这些工作做一些划分。当然这是一点。另外一点要求自动化框架更易用。不需要使用者对具体语言有深入的了解遍可以上手去完成自动化脚本。

5。创建高质量的测试数据

  构造良好的测试数据对数据驱动测试来说极为重要。测试测试中使用的测试数据最好存储在外部的文件上,比如excel文件,数据表,csv文件,等等。自动化测试用具会迭代的读取这些数据源的数据,然后驱动测试脚本的执行。这样添加新测试只需要在数据源中添加新的记录即可,不需要变更测试脚本本身。创建数据可能是个单调的工作,但尽早的创建数据,做数据驱动可以更好的结构化自动化测试,使扩展现存测试变得简单。这是很值得的。

6。建立能够抵抗UI变化的自动化测试(相对而言)

  ui自动化测试脚本肯定是依赖于ui的。所以ui的变动势必会影响脚本执行的结果。比如脚本依赖于title来定位一个页面,页面的title变了,那么脚本就找不到了,项目初期这种情况很常见。所以这里所说的抵抗ui变化是相对的降低脚本对ui元素的依赖,把ui元素建立统一的封装,提供的方法供具体脚本调用,这种结构的拆分把脆弱的ui对象从用例脚本中拆分出来。包装成page object。那么当页面元素变化时,只需要修改page object,所以依赖于这个page的脚本都不要另作改动。通过这种方法来提升脚本的可维护性。


TAG:

 

评分:0

我来说两句

Open Toolbar