自动化测试的前提及过程

上一篇 / 下一篇  2015-03-12 09:56:55 / 个人分类:自动化测试

自动化测试注意的问题:

    适当的自动化,不要追求100%(界面美观如何自动化?),手工测试很重要
自动化测试的前期需要高投入(而不是降低成本,节省人力)
要获得测试工具服务商的售后服务及相应培训,才好保证自动化的动力(光有D工具,是很困难的)
对自动化测试要有计划,要有测试流程图,模块组织图等,自动化是一种类业务流程“软件开发”,自然也要有软件开发过程
不要盲目追求自动化,根据产品目标按时完成测试任务,保证质量才是关键(测试小组成员,可以一部份做自动化,一部份做手工测试,把自动化测试后期效率与手工测试当时效率结合起来,互补完成任务)

1)完善手工测试流程(自动化测试与手工测试,思想上是一致的,自动化基本是代替手工,进行操作,手工完善了,自动化只是工具如何使用的问题)
2)完善测试用例(在完善的过程中,你会产生使用自动测试工具的想法,这时去运用最有效;如测试用例非常齐全,有大量数据输入,你就会想要有什么工具代替我输入就好了;)
3)将所有工作中的特定部分作为应用自动化的候选对象(比如软件各组件自动安装过程)
4)从高度冗余的任务或场景开始考虑 (比如:大量的数据输入,验证翻页)
5)将乏味且人工容易出错的工作进行自动化 (比如:结果比较或计算值,核算数据等)
6)首先关注开发**、理解透彻的用例或场景(比如:测试用例足够测试一个功能)
7)优先选择应用中相对稳定的部分,而非易变的部分(比如:回归测试时,不仅要验证bug,测试新的功能,还要测试已经稳定的功能,这时对这稳定的功能就可以进行一定程度的自动化)

----------------------------------------------------------------

    自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程。通常,在设计了测试用例并通过评审之后,由测试人员根据测试用例中描述的规程一步步执行测试,得到实际结果与期望结果的比较。在此过程中,为了节省人力、时间或硬件资源,提高测试效率,便引入了自动化测试的概念。

1. 自动化测试的前提条件

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

1) 软件需求变动不频繁。

    测试脚本的稳定性决定了自动化测试的维护成本。如果软件需求变动过于频繁,测试人员需要根据变动的需求来更新测试用例以及相关的测试脚本,而脚本的维护本身就是一个代码开发的过程,需要修改、调试,必要的时候还要修改自动化测试的框架,如果所花费的成本不低于利用其节省的测试成本,那么自动化测试便是失败的。

    项目中的某些模块相对稳定,而某些模块需求变动性很大。我们便可对相对稳定的模块进行自动化测试,而变动较大的仍是用手工测试。

2) 项目周期足够长。

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

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

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

    另外,在手工测试无法完成,需要投入大量时间与人力时也需要考虑引入自动化测试。比如性能测试、配置测试、大数据量输入测试等。

2. 自动化测试的过程

    自动化测试与软件开发过程从本质上来讲是一样的,无非是利用自动化测试工具(相当于软件开发工具),经过对测试需求的分析(软件过程中的需求分析),设计出自动化测试用例(软件过程中的需求规格),从而搭建自动化测试的框架(软件过程中的概要设计),设计与编写自动化脚本(详细设计与编码),测试脚本的正确性,从而完成该套测试脚本(即主要功能为测试的应用软件)。

1) 自动化测试需求分析。

    当测试项目满足了自动化的前提条件,并确定在该项目中需要使用自动化测试时,我们便开始进行自动化测试需求分析。此过程需要确定自动化测试的范围以及相应的测试用例、测试数据,并形成详细的文档,以便于自动化测试框架的建立。

2) 自动化测试框架的搭建。

    所谓自动化测试框架便是像软件架构一般,定义了在使用该套脚本时需要调用哪些文件、结构,调用的过程,以及文件结构如何划分。

而根据自动化测试用例,我们很容易能够定位出自动化测试框架的典型要素:

a. 公用的对象。

    不同的测试用例会有一些相同的对象被重复使用,比如窗口、按钮、页面等。这些公用的对象可被抽取出来,在编写脚本时随时调用。当这些对象的属性因为需求的变更而改变时,只需要修改该对象属性即可,而无需修改所有相关的测试脚本。

b. 公用的环境。

    各测试用例也会用到相同的测试环境,将该测试环境独立封装,在各个测试用例中灵活调用,也能增强脚本的可维护性。

c. 公用的方法。

    当测试工具没有需要的方法时,而该方法又会被经常使用,我们便需要自己编写该方法,以方便脚本的调用。

d. 测试数据。

    也许一个测试用例需要执行很多个测试数据,我们便可将测试数据放在一个独立的文件中,由测试脚本执行到该用例时读取数据文件,从而达到数据覆盖的目的。

在该框架中需要将这些典型要素考虑进去,在测试用例中抽取出公用的元素放入已定义的文件,设定好调用的过程。

3) 自动化测试脚本的编写

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

4) 脚本的测试与试运行

    事实上,当每一个测试用例所形成的脚本通过测试后,并不意味着执行多个甚至所有的测试用例就不会出错。输入数据以及测试环境的改变,都会导致测试结果受到影响甚至失败。而如果只是一个个执行测试用例,也仅能被称作是半自动化测试,这会极大的影响自动化测试的效率,甚至不能满足夜间自动执行的特殊要求。

   因此,脚本的测试与试运行极为重要,它需要祥查多个脚本不能依计划执行的原因,并保证其得到修复。同时他也需要经过多轮的脚本试运行,以保证测试结果得一致性与精确性。


TAG:

 

评分:0

我来说两句

Open Toolbar