TA的每日心情 | 奋斗 2024-11-8 12:09 |
---|
签到天数: 547 天 连续签到: 1 天 [LV.9]测试副司令
|
自动化测试中,自动化测试用例是一个重点中的重点,我觉得,到底如何去定位自动化测试用例设计的形式和发展是决定自动化测试成败的关键,根据一些研究和看法,我写了一个自动化测试用例设计的一个大概情况,当然一家之言而已。大家在测试过程中,接触过自动化测试的,肯定就接触过自动化测试用例,其实自动化测试脚本本身也是一种自动化测试用例,看看以下的情况大家遇到过么,大家也可以来讨论。
一、自动化测试用例应用
手工测试用例是针对手工测试人员,自动化测试用例是针对自动化测试框架,前者是手工测试用例人员应用手工方式进行用例解析,后者是应用脚本技术进行用例解析,两者最大的各自特点在于,前者具有较好的异常处理能力,而且能够基于测试用例,制造各种不同的逻辑判断,而且人工测试步步跟踪,能够细致的定位问题。而后者是完全按照测试用例的方式测试,而且异常处理能力不强,往往一个自动化测试用例运行完毕后,报一堆错误,对于测试人员来定位错误是一个难点,这样往往发现的问题很少。所以,根据其各自的特点,需要将两者有很好的定位:手工测试是在软件版本前几轮测试的重点,目的是验证功能,发现问题;自动化测试是应用在后几轮版本,保证软件版本模块修改或者添加新功能后,没有影响开始的功能模块(因为软件中,各模块之间的接口以及类、函数方法等的互相引用,也是容易出问题的地方)。
二、自动化测试用例设计发展
1、自动化测试用例设计发展前期
记得,当时的自动化测试开展是针对测试设备设计一套测试环境系统,用于自动化例行测试,根据此,专门撰写了一套自动化测试用例,并转化成自动化测试脚本。之后整套系统都失败了,失败原因包括:
a、系统太过于庞大,测试用例也过于繁琐,每次测试运行下来,测试结果都夹杂着一大堆各种错误,有可能是产品问题,有可能是脚本问题,也有可能是用例问题,这样下来,测试人员每次运行一遍都要面对大量的问题,维护的几次就放弃了,问题越来越多,根本没办法去定位,这样反而浪费了大量的成本和时间。
b、搭建的一套测试环境系统,各个产品功能模块都互相联系在一起,都互相有影响,容易造成问题。
c、更重要的是,由于是单独搭建的一套测试环境系统,其自动化测试用例与手工测试用例没有太大关系,这样就造成了其自动化测试很难对手工测试进行辅助。 |
|