51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 1259|回复: 1
打印 上一主题 下一主题

自动化测试框架指南

[复制链接]
  • TA的每日心情
    擦汗
    2022-8-30 09:02
  • 签到天数: 2 天

    连续签到: 2 天

    [LV.1]测试小兵

    跳转到指定楼层
    1#
    发表于 2018-6-13 16:50:10 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

    以下只是测试框架的一点设想,需要以后修改;
    这套方案的最终结果是实现测试自动化,但是因为目前人力、实力有限,只能逐步完善设想中的功能;最
    终的目的是要实现define the driver——定义驱动测试。
    本文的自动化测试以MI公司的QuickTest professional 为例
    1定义:
            Services function :业务函数
            TestCase(测试用例):是能够从头至尾独立执行的最小测试单元
            测试框架的设想

    1.1Services Function 的分类及分类原则
    Service Function的颗粒大小需求不一,靠自己来掌握,总之应该是尽量少的Service Function满足所有Case
    Function的需要
            Common level¬——所有项目测试都可以使用的函数,比如验证小数精度、写测试结果到报告等等。
    Common level是公用的函数库,不需要经常修改,因此可以编成DLL文件,供所有的测试脚本使用。
    使用语法可以这样:
    ‘------------------------------------
    Set object=createobject(“”)
    Call object.funciton “”
    ‘------------------------------------

            High level¬——各项目专用的测试用例,是为专门的测试项目而设置的,但是这些Services Function
    不能单独作测试,必须配合更高一级的Test level才能使用
            Test level¬¬——Test level可以这样理解:是对某一个用户来说,为了完成某项工作和业务,时间从
    头至尾相对连续的一组操作。
            Test level并不是测试用例,但是它的颗粒大小却决定了其复用程度,因此需要仔细分析每个TestCase
    的业务逻辑,将相同的Test Level services function 总结出来。
            Test level的组成:
    Function
    Step          ‘测试所要进行的操作
    Validation     ‘验证测试的结果
    Return result   ‘返回测试的结果,validation的验证结果也应该通过这一部分的函数写入到result report中
    End function

    1.2 Test case 和Test suite
            Test Case:测试用例。可以这样理解:是一组人为了完成某项工作和业务,时间从头至尾相对连续
    的一组操作
            Test suite: 是一个相同工作性质的工作部门人员,为了完成某项工作和业务,时间从头至尾相对连
    续的一组操作。
            Test case和Test suite的意义:
    1、大量的Case,肯定是分模块存放的。否则就难以查询和维护、修改。
    2、Test Case和Test level \high level service function的互相调用关系可以通过insight sources这个工具来查询。
    3、Suite相当于一个Case模块,里面包含很多个Case;比如测试用户管理的,都放在一个Suite里,测试设
    备管理的,放在另一个suite里。
    1.3TestCase的分类原则
            一般复杂Case,要牵扯到好多个模块的功能的,但是要看它的主要测试点是什么,然后按这个测试
    点所属模块,来确定这个Case归属哪个模块的。
            有依赖关系的Case,是合并成一个Case,还是保留独立?运行起来有依赖关系,倾向于合并成一个C
    ase,合并的好处是运行方便,但是出错时要再区分是那个小Case的错误;分开的话,就相反,运行不方便,
    但出错时比较明确哪个错了。
            如果A是建10万个用户,要花1小时的时间,那你还会放在一块嘛,肯定是倾向分开成小Case,不然
    B出错了,你还得再重头跑ABCD,测试人员会气死的!所以运行麻烦、容易出错、时间较长的小case,还
    是保持独立,只要跟测试人员写好说明文档,让他们知道正确的运行方法,就可以了
            如果合成一个case,我应该把它放到哪个suite里呢 因为它横跨了几个页面,都是测试点,不好划分
    啊。放在那个Suite里啊,那都可以啊,或者你想独立一个suite也可以啊,无所谓的,只要你运行结果有正

    确记录,不会漏掉丢失就可以了。
            测试环境可以通过重新导入数据来恢复,这样就可以将一部分运行时间长、但是又有依赖关系的Te
    st case分离出来,避免总是要从开头进行测试。
            一个Test suite里的用到的lib和OR都是相同的。




    1.4测试用例和Services Function命名规则
    类型        名称
    Test case        项目名_TC_name
    test level services function        项目名_TL_name
    high level services function        项目名_HL_name
    common level services function        CL_name(不应包括项目名,因为此类函数是公用的)
    2工作方式
    并非所有的测试用例都可以用自动化来完成,因此需要对用例进行挑选,选择合适的用例作为自动化测试用
    例。记住!自动化测试的成本是巨大的,一般来说,一个脚本运行6~7次才算收回成本,因此不可寄予自动
    化测试过高期望。
    2.1选择自动化测试用例
    2.1.1不适合自动化测试用例的情况
            定制型项目(一次性的)。为客户定制的项目,维护期由客户方承担的,甚至采用的开发语言、运行
    环境也是客户特别要求的,即公司在这方面的测试积累就少,这样的项目不适合作自动化测试。
            项目周期很短的项目。项目周期很短,测试周期很短,就不值得花精力去投资自动化测试,好不容易
    建立起的测试脚本,不能得到重复的利用是不现实的。
            业务规则复杂的对象。业务规则复杂的对象,有很多的逻辑关系、运算关系,工具就很难测试。
            美观、声音、易用性测试。人的感观方面的:界面的美观、声音的体验、易用性的测试,也只有人
    来测试。
            测试很少运行。测试很少运行,对自动化测试就是一种浪费。自动化测试就是让它不厌其烦的、反反
    复复的运行才有效率。
            软件不稳定。软件不稳定,则会由于这些不稳定因素导致自动化测试失败。只有当软件达到相对的稳
    定,没有界面性严重错误和中断错误才能开始自动化测试。
            涉及物理交互。工具很难完成与物理设备的交互,比如刷卡的测试等。
    2.1.2适合自动化测试的情况
    自动化测试之所以能在很多大公司实施起来,就是有它适合自动化测试的特点和高的投资回报率。
            产品型项目。产品型的项目,每个项目只改进少量的功能,但每个项目必须反反复复的测试那些没有
    改动过的功能。这部分测试完全可以让自动化测试来承担, 同时可以把新加入的功能的测试也慢慢地加入到
    自动化测试当中。
            增量式开发、持续集成项目。由于这种开发模式是频繁的发布新版本进行测试,也就需要频繁的自动化
    测试,以便把人从中解脱出来测试新的功能。
            能够自动编译、自动发布的系统。要能够完全实现自动化测试,必须具有能够自动化编译,自动化发布
    系统进行测试的功能。 当然,不能达到这个要求也可以在手工干预的情况下进行自动化测试。
            回归测试。回归测试是自动化测试的强项,它能够很好的验证你是否引入了新的缺陷,老的缺陷是否修
    改过来了。在某种程度上可以把自动化测试工具叫做回归测试工具。
            多次重复、机械性动作,将烦琐的任务转化为自动化测试。自动化测试最适用于多次重复、机械性动作
    ,这样的测试对它来说从不会失败。比如要向系统输入大量的相似数据来测试压力和报表。
            需要频繁运行测试。在一个项目中需要频繁的运行测试,测试周期按天算,就能最大限度的利用测试脚
    本,提高工作效率。
    2.2编写Test case和Test level
    分析Test Case的业务,将Test Level services function 的颗粒从Test Case中识别出来,尽量做到用少的Service
    function来实现测试业务。
    2.3搭建测试框架
    依据测试框架,在下一节中提到。依次填入测试框架的内容。
    2.4执行测试并记录bug
    这时就可以开始执行测试。测试结果应该自动被记录在测试报告中,而不应该一遇到BUG就停止——除非必须

    停止。这里注意以下几点
            测试报告功能应该在Common level中实现,这样所有的测试都可以共用。
            测试框架应该具有一定的判断功能,一旦某个测试失败。测试框架可以决定停止测试,或者转入不受影
    响的新测试用例,Test suite分类也应该注意这一点,因为同一个Test suite一般来说是互相影响的。
            测试框架可以具有某种还原测试环境的功能——即测试结束清理的功能,这样就可以自动恢复到不受影
    响的测试环境中。
    2.5维护测试脚本
    这是一项工作量很大的工作。维护脚本的难度很大程度上与团队活动有关,相关信息参考第4节。
    3测试框架的构想
    3.1Test Driver
    测试框架的核心叫Test driver,它具有以下一些东西
            全局参数。
            所要测试的用例集,也许叫Test suite集更合适;包括测试所要用到的参数。
            对于用例的描述。
            lib and tsr。
            能够判断测试结果,并且决定是否调用其它的测试用例,或者停止测试。
            自动生成测试报告。以及需要输出的路径。
            每个测试脚本的初始设置路径
    4团队开展自动化测试要点
    单人自动化测试与团队开展自动化测试有很大不同,因为不同的对象名、不同的函数会造成每个人的测试脚
    本不同,并难以合并成一个完整、统一的脚本。为了解决这个问题,应该注意以下几点:
            团队成员在编写脚本时应该多使用对象库,尽量少使用描述性编程。
            统一对象名称,规定网页元素对象命名的统一规定,这样才可能在合并对象库时统一。
            统一函数命名规定。
            统一函数书写格式。
            统一对同一类型操作的处理方式——应该定期举行会议,沟通各种操作的处理方法,共同提高对系统
    的认识水平。
    5测试配置
    测试配置应该尽量自动完成,减少工作量。
    测试配置包括如下内容:
            测试工具的配置
            测试环境,如数据、数据库结构
    6测试初始设置
    一些测试用例相互依赖,本应该把它们合成一个测试用例;但是如果单个测试用例颗粒很大,那么在回归测
    试或再现缺陷时就会使人发疯,并且浪费了大量的测试时间。最好最可靠的解决办法看来只有一种,那就是
    将颗粒大的测试用例分离出来,同时为这个测试用例预备测试初始设置——将客户端所需要的数据库结构和
    数据库备份,并且作为测试初始设置保存管理。
    这里的测试初始设置并非只针对自动化测试,手工测试也被包括进来。
    6.1测试初始设置的命名办法
    TE+测试用例编号
    如测试用例为TC1.2,则TE为TE1.2
    6.2测试初始设置的保存
    测试初始设置应保存在单独的文件夹内,初始设置的路径被链接到Test driver上。

    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-11 19:33 , Processed in 0.062333 second(s), 22 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表