频道栏目
读书频道 > 移动开发 > 其他综合 > 移动App测试实战:顶级互联网企业软件测试和质量提升最佳实践
2.1.2 基于JMeter的轻量接口自动化实践
2015-08-13 14:04:12     我来说两句
收藏   我要投稿
《移动App测试实战:顶级互联网企业软件测试和质量提升最佳实践》由三位国内顶级互联网企业软件测试工程师联手打造,根据移动产品的特点,深入讲解了移动App测试的最佳实践,从移动互联网产品测试的准备工作到产  立即去当当网订购
有了上面这些基本的功能,接下来需要考虑如何整合成一套完整的方案,包括考虑用例的可复用和可扩展。
 
实践中我们的基本思路如下:
 
1. 用例的分层
 
为了更好的复用和管理,我们对用例的层次进行一些划分,并给出名称的定义。单次接口请求是一个最小粒度的操作,比如下面示例中的一次HTTP请求,在以下我们称之为CGI。
 
CGI这个词的本意是通用网关接口,由于习惯的原因,常常用来代称单个业务接口。
 
Function是一个对外有逻辑意义的请求组合,比如提交订单、审核订单。TestCase是一个成品,TestSuite是一个用例的集合。基本的组织方式如图2-9所示。
 
通过这样的分层,整体逻辑就比较清楚了,CGI对于一个具体的接口是最小粒度的元素,如果接口变化了,只需要修改对应的CGI用例。Function层面是一个有逻辑意义的功能,可能需要多个CGI共同完成,相当于做了一层封装,为后面构建用例打下基础。
 
 
每个子系统的目录结构如图2-10所示。
 
 
这里有个需要注意的小地方,为了部署的时候更灵活,希望脚本中互相引用的文件是相对的路径,但是JMeter支持不太好,默认的根目录是bin,所以简单的做法是把整个自动化用例的目录复制到JMeter的bin下面。
 
2.完整的自动化用例结构
 
因为我们有多个系统,对应多个测试小组,大家各有专注,而整个业务又是一个长链条。Function层就是我们复用的基础,里面包含了对CGI层接口的调用。注意一点,JMeter 2.10开始建议用TestFragment来组织,而TestFragment是不能直接执行的,只是些积木,到了TestCase层面再用ThreadGroup线程组才可以执行。图2-11是一个Test Fragment的示例。
 
 
图2-12所示是一个完整的TestCase,包含了本系统和其他系统的一些Function步骤。
 
实际多人协作的过程汇总,用例细节有很多需要规范的地方,比如命名规范,这样便于多人协作。
 
3. 数据的输出
 
JMeter里面配置和编写用例执行完了之后,需要拿到输出的结果,外层的自动化框架才能进行解析和结果的输出。这里我们通过添加一个“察看结果树”的监听器,将所有的执行结果输出到一个文本文件里面,如图2-13所示。为了解析方便,通过变量指定了一个确定的文件名,数据结果方面选择了所有的列,便于得到完整的结果并处理。
 
 
4. 自动化的报告
 
基于上述步骤输出的文本结果,可以编写一个解析器,把结果解析成比较易于阅读的方式。然后生成对应的报告,每次执行完成之后自动地发邮件报告出来。图2-14是一个自动化测试报告的例子。
 
 
5. 用例执行细节查询
 
除了上面汇总之后的结果报告,还需要一个地方能看到用例执行的细节,帮助定位问题。实际中我们构建了一个Web平台,测试人员可以在上面看到每次测试的结果,以及每个用例的执行细节。
 
为了更好地定位问题,需要把每个接口执行的细节也暴露出来,点击详情可以看到调用的情况,包括request和response的数据,如图2-15所示。
 
到这里为止,一个比较完整的可以在实际项目中应用的自动化框架就完成了。在实际的运作过程中,可以对业务测试人员进行一些JMeter方面的培训,让大家熟悉如何构造接口的请求,以及断言处理等模块,然后就可以编写对应的用例了。当然,如果多个人来准备测试用例,也需要知道哪些CGI和Function级别的封装是已有的,可以复用。
 
 
可见,除了JMeter以外的框架部分的开发工作外,工作量不是很大,很多较小规模的测试团队也可以承受。综合来看,基于这样的方案可以快速地把一个可用的自动化系统构建起来。
 
上述方案在一个项目中实践的情况如下:
 
1)覆盖了4个大的系统,200多个CGI接口,以及100多个功能点。每个系统在构建后快速地通过以上自动化用例来进行回归,并发出邮件报告,框架整体比较稳定。
 
2)整个过程,不算制作用例的时间,我们实际投入的测试开发的人力约为一个人/月。
 
3)大部分业务测试人员都参与到了用例的制作,提升了对业务逻辑的理解,并且对部分人员来说,也学习了HTTP协议等基础知识,并编写了少量的脚本,提升了业务测试人员的自动化和测试开发能力。
 
总体来说,达到了轻量化来构建接口自动化的目标。
 
除了以上好处,也有一些不方便的地方需要指出:
 
JMeter在包含其他的jmx脚本后,不能直接在界面显示加载的内容,所以看不到被包含的脚本里面的步骤,调试的时候不方便。不过JMeter可以支持多个实例同时运行,所以在编写和调试阶段,可以同时打开多个JMeter窗口,一定程度上可以缓解这个问题。
 
最后的测试报告里面,不能控制显示结果的层次,是直接展开成每个接口的结果,当用例的步骤过多时查看起来不是特别方便。
 
除了技术层面的考虑,自动化执行的过程中还有几个建议值得考虑:
 
1)一定要强挂钩到测试和发布的环节。这一点看起来没那么重要,但是如果不希望自动化测试成为花瓶,必须要这样做。互联网产品的节奏非常快,如果自动化不能实际地在项目中发挥效果,就很容易被荒废。目前来看最合适的点是在每次自动部署后快速地把自动化用例执行一遍,这要在手工测试开始之前。这也是持续集成的思路,可以快速地发挥自动化的价值。
 
2)报告也需要自动化地发出来,并且邮件抄送给相关的开发人员、测试人员和团队负责人。这样可以让大家快速地关注到结果。
 
3)非100%成功的都要跟进。宁愿少而精,就像“破窗理论”指出的,如果能容忍一个用例失败,就会有2个、3个,也会让自动化慢慢失去意义。我们的做法是只要有失败,对应系统的测试负责人员需要进行定位并邮件回复出问题原因和处理措施。
 
4)需要关注用例的细节。测试团队的负责人需要去关注用例的质量,而不只是用例的数量和执行情况,比如断言做到什么程度,哪些自动化数据是写死的,哪些参数化了,功能之间的复用情况,这些都是影响整个自动化的稳定性和可维护性的具体方面。
您对本文章有什么意见或着疑问吗?请到论坛讨论您的关注和建议是我们前行的参考和动力  
上一篇:2.1.1 JMeter关于自动化方面的特性介绍
下一篇:2.2 App UI层面的自动化
相关文章
图文推荐
排行
热门
最新书评
特别推荐

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站