51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

测试开发精英班,通向高级软件测试工程师论坛测试积点免费获取渠道攻略什么样的人才需要实战项目?横扫BAT,Python全栈测试开发技能大全
【113期】:Web安全测试你来问我来答!中国软件测试行业现状调查报告新鲜出炉! 【杂志】做测试行业不偏科的尖子生! 自学软件测试那点事
查看: 1881|回复: 6

[转贴] 互联网业务测试团队如果快速构建轻量级的自动化

[复制链接]
  • TA的每日心情
    奋斗
    2020-6-22 16:56
  • 签到天数: 501 天

    连续签到: 1 天

    [LV.9]测试副司令

    发表于 2016-5-18 11:14:25 | 显示全部楼层 |阅读模式

    做测试,自动化是一个绕不开的主题,而且也是非常值得去做的事情,无论是对测试质量和效率的提升,还是对人的能力的锻炼,都是非常的有帮助。就目前个人观察到的情况,一些负责基础性组件测试的团队,比如底层平台、SDK等,或者是负责功能通用性高的产品,比如防火墙、邮件系统等,都可以做到比较高的自动化率,而且自动化测试开发的过程通常也没有那么纠结。相比而言,强应用层业务相关的测试团队,通常在自动化方面的开展要困难很多。我这里说的是比较全面的功能的自动化,不是指写几个简单的脚步覆盖几个功能,大的思路是接口层面,不涉及UI的,而且可以制作大规模的用例。

    主要有几个问题:

    1. 首要的问题是版本的节奏,互联网的产品版本的节奏非常快,一个20多人的测试团队一周发布上百个功能特性是一件很普通的事情。团队成员有非常多的精力消耗在这些功能版本上,需要快速的理解业务,构建测试环境,bug验证回归,以及发布上线等等,留给业务测试同学构建自动化用例的时间非常少。

    2. 功能非常的庞杂,而且有负责的业务流程,难以标准化。

    3. 说到自动化,大家会想到自动化框架,需要有一个比较好的自动化框架。自己开发或者维护过框架的同学可能都深有体会,这绝不是一件容易的事情,其工作量和持续的时间往往会超出我们的预期。我们是否有足够的测试开发人力能做自己的框架,以及业务能否承受这样的等待时间?

    互联网行业的变化很快,线上功能变化按天算,业务调整和组织架构调整按月看,做一个大的框架如果在部门层面还有可能,到了业务测试团队来说比较奢侈。很多方案是环境和需求逼出来的,细想下来,有两条路,一是看部门的框架,二是有没有轻量级的方案,可以快速的应用。

    这里结合我们自己的一些实践来看看,也是一点浅显的经验。

    部门有一些平台,但是有一些局限,主要是针对HTTP协议,另外对数据的准备支持不太好,也不支持DB的数据检查等功能,另外就是不太方面去定制和扩展,相比而言更适合外网的监控,评估下来准备想想别的办法。

    很多时候,过去的成功经验往往会让我们想复用,所以一开始的时候准备参照在以前公司做过的keyword driven的框架,把功能点封装成一个个的步骤,然后通过配置文件来构造用例,实现自由的组合和数据驱动。这条路验证过,而且看起来对现在的业务来说也没有什么问题,能走通,但是就目前团队的情况来看,开发一个这样的框架的代价无法承受。

    考虑了很久,于是有了现在更轻量点的做法,写出来给那些测试开发资源比较少的业务测试为主的团队参考。

    如果想要快速,但是又功能丰富,最好的办法就是抱一条粗腿,这里我们选的是JMeter。从2.2版本到最近的2.11,一直在关注和使用,发现JMeter的进步很快,版本活跃程度也很高,另外,它早就超出了一个HTTP性能测试工具的范畴,自动化测试其实是它另一个很大的主打,官方文档也提到。

    选中JMeter简单来说有几点:

    1. 接口大部分HTTP协议,而JMeter对HTTP支持非常全面,毕竟是做这个出身的。如果有些接口不是呢?我们的做法是用写adapter转换,这里不详述,所以写用例这边还是按HTTP协议走。

    2. 对数据提取和断言非常多的支持。还可以支持直连DB,可能需要补充额外的驱动jar包,但是没有技术障碍。

    3. 可以图形界面,极大的方便了用例制作和调试。以前的经验,我们做了命令行的功能点,后面为了大规模制作用例,还开发过web console,现在完全没有必要,这一部分也省掉了。

    4. 可以命令行执行,这就意味着可以方面的被粘合到我们的脚本里面。

    5. 输入和输出都是文本,jmx和存成的csv都是文本,极大的方便了脚本的处理和结果的parse。

    还有更多细节的点不多说了,有了这些基本可行性就很高了。想要独自开发上面这些功能得很大的代价,这也是轻量级能做到的主要原因。

    有了上面这些基本的骨架有了,但是要想想怎么整合成可复用和扩展的用例。

    基本的思路如下:

    1. 用例的分层,为了更好的复用和管理。CGI是最小的粒度,对应一个HTTP请求,完成一个很细节的操作。Function是一个对外有逻辑意义的历史,比如下订单,审核订单。TestCase是一个成品,TestSuite是一个用例的集合。

    每个子系统的目录组织如下:

    这里有个小的tricky的地方,为了部署的时候更灵活,希望脚本里面互相引用的文件是相对的路径,但是JMeter支持不太好,默认的根目录是bin,所以简单的做法是把整个自动化用例的目录copy到JMeter的bin下面。

    2. 因为我们有多个系统,对应多个测试小组,大家各有专注,而我们电商的业务又是一个长链条。function层就是我们复用的基础,里面再包含对CGI层接口的调用。这里有点JMeter的技术细节,2.10开始建议用TestFragment来组织,而TestFragment是不能直接执行的,只是些积木,到了TestCase层面再用ThreadGroup现场组,才可以执行。

    下面是一个完整的TestCase,include了本系统和其他系统的一些function座位步骤。用例细节其实还有很多需要打磨的地方,比如命名规范,执行起来不容易。

    3. 自动化的报告,每次执行完了之后自动的发邮件报告出来。

    为了更好的定位问题,需要把每个接口执行的细节也暴露出来,点击详情可以看到调用的情况,包括request和response的数据。

    除了好处,也有一些不方便的地方:

    1. JMeter在include其他的jmx脚本后,不能直接在界面显示加载的内容,所以看不到被include的脚本里面的步骤,调试的时候不方便。不过好在JMeter可以一套binary启多个,并着看。

    2. 最后的结果报告里面,不能控制展示的粒度,是直接摊开成CGI层面的步骤,显得比较杂。

    目前我们执行的情况

    1. 目前覆盖了200多个CGI接口,以及100多个功能点,初步有4个系统挂接到了自动部署后的执行。用例还在进一步的扩展中,框架不需要改动。JMeter本身的稳定性还是不错的。

    2. 整个过程,不算制作用例的时间,我们实际投入的测试开发的人力合起来不到一个人月。

    3. 大部分业务测试同学都参与到了用例的制作,提升了对业务逻辑的理解,并且对部分同学来说,也补了HTTP协议等基础知识的课,实际动手比听听培训效果要好。

    从实际的效果和投入来说还是比较满意的。

    除了技术层面,自动化执行起来有几个核心的要点:

    1. 一定要强挂钩到测试和发布的环节。

    这一点看起来没那么重要,但是如果不希望自动化成为花瓶,就必须要这样做。像互联网产品这样快的节奏跑起来,任何花哨的环节会逐渐被洗掉,因为人员的配比和版本的数量,不是必做的东西慢慢就坚持不下来。所以自动化如果要能发挥效果,目前来看最合适的点是在每次自动部署后快速的刷一遍,在手工测试开始之前。而且如果要人工去点,这事儿时间长了也不靠谱,一定要把这个过程也自动化,版本在测试环境部署好了之后,自动化自动跑完,这就是强的挂钩。

    2. 报告也是要自动的,并且邮件抄送给相关的开发,测试和团队的负责人。我们现在的做法是跑完了脚本解析后自动的发邮件报告。

    3. 非100%成功的都要跟进。

    宁愿少而精,这个也类似broken window理论,如果能容忍一个用例失败,就会有2个,3个,也会让自动化慢慢失去意义。目前的做法是只要有失败,对应系统的负责同学要邮件reply all跟进原因。

    4. 关注用例的细节

    团队的负责人要去看用例的质量,而不只是用例的数量和执行情况,比如断言做到什么程度,哪些是写死的哪些参数化了,功能之间的复用情况。其实这个和所有的事情一样,如果真的重要,就应该要跳进去关注细节。

    其实说起来上面没有什么高深的地方,道理也浅显,可能是工作久了会变得更加务实,最怕做了没有用的东西。

    1. 关于技术含量的问题,不纠结。当然,有能力和精力做到技术含量很好。但是没有技术含量但是有价值 > 有技术含量效果不好。

    2. 尽可能的复用好的组件,核心的引擎不一定要自己做,特别是业务测试团队。用开源组件,自己开发特点需求,并把它们粘合起来。

    以上粗略的整理,希望给那些想要做功能自动化,但是又受限于非常快得功能版本节奏,也没有大量测试开发人力的业务测试团队一点参考。


    回复

    使用道具 举报

    该用户从未签到

    发表于 2016-5-18 11:56:56 来自手机 | 显示全部楼层
    适合安卓应用吗?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2016-5-18 15:58:08 | 显示全部楼层
    找不找工作啊,私聊。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    发表于 2016-5-20 00:17:05 来自手机 | 显示全部楼层
    哇  这个测试报告比我的好看多了   还有这个jmeter管理中心也很不错!可否分享一二  在此感谢了:handshake
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2014-12-25 11:52
  • 签到天数: 3 天

    连续签到: 1 天

    [LV.2]测试排长

    发表于 2016-5-31 14:42:44 | 显示全部楼层
    赞一个,慢慢研究。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2020-7-5 14:35 , Processed in 0.073322 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2020 Comsenz Inc.

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