从事软件测试工作五六年,虽是外包,但进的都是业界出名的公司中较大的项目。每个项目都将测试自动化做为很重要的目标,也都有尝试,但没有一个项目是能够让功能自动化测试真正为软件质量做出较大贡献的。充其量就是跑一堆脚本,然后证明一些已经很稳定的功能没问题,另外可以很自豪地向人宣称:我们的项目已做到了自动化测试,仅此而已。

目前市场上各种自动化工具很多,有些对测试人员技能要求较低,如QTP等一些录制类工具,但测试脚本复用率极低,后台一个很小的改动,就可能导致一批脚本都要重新调试甚至重新录制,这当然是不划算的,也许我重新调试重新录制的时间,用手动测试的话,早测完了。况且项目开发中,你不可能要求开发人员说,我某某模块已经做了自动化脚本,你不许随便修改这里的代码!这样会导致开发在修改bug或写新功能时掣手掣脚。连测试人员都认为不可行的!

还有一些工具是需要测试者具有开发技能的,自己写测试脚本或测试工具。这种情况首先测试人员很难做到,另外web页面的一些功能测试这些做不了。顶多就是测下数据,测下流程之类,远远达不到功能测试的要求。(这方面我了解不多,如有说错,敬请谅解)
如此看来,似乎自动化测试成了一个无甚用处的高高挂起的展览品。那么如何解决呢?我认为目前最好的办法:

1.首先是单元测试自动化,由开发人员或有开发技能的测试人员写代码,加强单元测试自动化使用率。打个比方,我如果要制造一个手机,首先,手机的每个零件比如外壳,比如芯片主板,比如屏幕在生产时肯定要经过严格测试。而目前的软件开发领域,这些前期测试做得远远不够。好比做手机的,对每个零件不加测试或只随意测下,而把主要质量保证放在手机组装完成之后。这显然是不合理的。所以说,软件开发的质量保证流程,跟硬件相比,尚处于童年阶段。既然单元测试重要,自然要花费大量时间精力,然后当然自动化很重要而且很可行。

2.其次是成品中部分测试项自动化。这个是可以由测试人员通过使用robotframework等工具来实现,当一个需求被细化并设计成测试用例后,从用例中挑出那些自动化后可以大大减少人工测试的部分进行测试。比如一个系统中有十几个web页面,每个页面都有文本输入框、下拉框、富文本框需要测试。那么可以将每一类页面元素的不同输入项做成脚本,自动执行并记录结果。当然元素名称,输入项等都要做成变量。另外若是流程类验证,可以将相似的流程自动化,比如一个系统中有多类产品,购买流程的后台业务是一样的,那么可以将购买流程做成自动化脚本(需将产品名称、购买时的参数)。

3 2 收藏


直接登录
最新评论
  • Kenneth hired worker 03/09

    Hey beauty

    Good !! But I don’t understand what ur point is. ^^!!
    You should be know robot-framework, selenium, and python very well, right?       May I know what else you know?
    3. Do you have any experience to build an automated testing framework before?

    I want to learn it. ^^

     

     

  • 萧艾遥 孤独的跑者 03/10 精华评论

    对你说的两点,我说说我的看法:

    #1 单元测试

    UT这个事儿,不是没提过,而是一直在提,反复在提,但是效果并不好。为什么?原因归根结底就是一点,成本太大

    现在做产品的,做互联网的,做app的,有不少是敏捷开发快速迭代吧,允许有bug,但主功能至少是可用的,这里的“保证主功能至少可用”也就是你所说的“把主要质量保证放在手机组装完成之后”。但是有时进度push too hard,反映到开发这边,就只好删繁就简,保证开发流程走下去,有问题的话,出patch或等新版本。

    你这里举的和硬件对比的例子,道理大家都懂,但是两者的工作量是天壤之别的。就还拿手机举例:

    1)你所说的外壳、芯片、主板、屏幕,甚至说是每一个螺丝,确实有质量测试,但是里面不少工作量,都是由下游的配件厂商质检并保证的,而不是手机厂商。手机厂商会做些必要的测试,但远不是做软件的人写UT的测试密度和强度,甚至很大牌的厂商(比如被举例都举烂了的Apple),还会直接对下游供应商提时下来看最高的要求,类比到做软件,就好比把某个功能模块外包给其他公司,并且给外包公司规定很苛刻的标准;

    2)除了任务下放之外,硬件零件毕竟种类有限、数量有限。而软件就不一样了。代码是可以极具想象力的,你可以用别人的零件(既有的库),也可以自己造轮子,你的每个功能,每次调用,甚至写的每个方法,都可以用UT来保证;每个UT又有自己的case集合;并且这个集合也可以说是没有边界的(这个边界,我举个稍有些不恰当的例子,现实中有绝对零度,但是软件中没有);并且每个case,也要判断结果是否正确。

    至于你说的UT自动化,我不太理解你是指“写UT”的自动化,还是“执行UT”的自动化,如果是写UT的自动化,难,上面原因也说过了;如果是执行的话,还是可以的,哪怕是包括改测试参数、出测试report。

     

    #2 成品中部分测试

    感觉你测试UI比较多,因为你反复提到测试脚本。测试脚本确实能做到一定的自动化,但是,一个完整的workflow,并不能代表就没问题了,用户不一定会按照划定的路走。比如有四个输入框,ABCD,按照ABCD逐个输入没问题,不代表我按照CABD输入就没有问题,再拿手机举例,ABCD是固定玻璃背板的四颗钉子,按照正确的顺序拧没有问题,但是可能按照某种方式,就会因为受力不均整个背板碎掉,那你说,出现这种情况,是在用户,还是在手机厂商,还是在背板玻璃的供应商呢,是不是不好判断,甚至是倾向用户的责任。如果这个case类比到软件,是不是铁定是软件开发者的问题呢,用户是没有错的。

    如果不是UI测试呢,如果是对服务、对功能的测试呢,这种情况更甚,自动化更是没有边儿的事。

     

    上面的解释有些可能极端了,但是我感觉意思都传达到了。

    如果测试真的能做到自动化,也算是一种小小的AI了呢。

    如果测试自动化实现了,下一步就是开发自动化,饭碗都要不保了呢。

  • 萌狮 Python 03/10

    请问我怎么也才能把英文说得这么6呢

    • 萧艾遥 孤独的跑者 03/10

      讲真的,上面的英文,我看得我尴尬症有点儿犯了……

      • 萌狮 Python 03/10

        你是说上面的英文语法有问题吗,哈哈

        • 萧艾遥 孤独的跑者 03/13

          不少问题……就比如 @Kenneth 的第一条评论里的英文……

          You should be know robot-framework, selenium, and python very well, right?

          should后面该跟动词原形是没错,但是这个be是怎么回事呢。这句应该是:You should know robot-framework…very well, right?

          May I know what else you know?

          典型中式英语直译。这句应该是:May I ask what else do you know?

          Do you have any experience to build an automated testing framework before?

          没有have experience to do的用法。这句应该是:Do you have any experience in building an … before?

          上面是比较明显的语法错误。除此之外,还有第一句

          But I don’t understand what ur point is.

          这句应该说成这样更地道些:But I didn’t get ur point.

           

          下面的就不逐一解释了。

          如果只是以让别人明白意思为目的的话(比如一般朋友聊天的时候),那么,不太在意语法也可以接受。但是,对于一个用英文回复的中国人来说,并且是给别人的评论,我个人感觉,还是注意一些为好,地道不地道就不提了,但至少不要出现特别明显的语法错误。