第3章3.2 接口测试实战——京东系统质量保障技术实战(2)

发表于:2017-11-03 16:56

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:商城研发POP平台    来源:电子工业出版社

分享:
  3.4 分层测试的思考
  笔者所在团队一开始做自动化时并没有考虑到分层测试。因为那时候,能够自动化已经不太容易,要么是没有自动化的团队,要么只有不多的自动化脚本产出。这个时候是不需要思考分层的。但是,当自动化发展得越来越成熟时,碰到的问题也越来越多。有一个不可忽视的问题出现了,就是如何让自动化发挥更大的效能。这时分层测试就出现了。
  3.4.1 分层测试的理解
  分层测试的概念很早就被Martin Fowler 提出来了。
  按照他的观点,Unit 单元测试成本最低、收益最高,Service 集成测试成本较低、收益较高,UI 系统测试成本最高而收益最低。为什么这么说?因为Unit 单元测试需要的人员成本很低,测试的点非常细致,可以到方法级别。这样的覆盖是非常全面的。所以,从收益上来说,Unit 测试最高。
  Service 次之。因为Service 集成测试面对的基本上是接口层级,测试粒度上会比单元测试粗些。但是,Service 的测试会针对每个接口进行测试,收益也非常高。因为我们知道,随着系统复杂性的增加,我们都会通过接口方式进行模块间的解耦。这个时候接口测试就非常必要了。而Service 的测试正好对这个层级进行覆盖,所以价值也是非常高的。而且接口的变动会比UI 变动低,所以成本相对较低。
  UI 测试因为UI 的变动非常频繁,成本最高。收益也是根据脚本的覆盖程度有很大的差异。现在,很多团队在做UI 测试时,基本上放弃了脚本覆盖,或者脚本只是覆盖核心的功能。
  所以,总的来说,Unit 测试处于金字塔的底层,价值最大,Service 测试次之,而UI 测试又次之。
  3.4.2 京东怎么做分层测试
  在笔者所在的团队,也是经历了一个探索的时期,才找到了适合团队的分层测
  试方式。现在分享给大家。
  第一阶段,UI 测试的探索。此阶段,团队进行了一个UI 框架的开发。在此基础上,团队进行了UI 脚本的编写。把大部分核心功能进行了脚本的覆盖。当时效果不错。但是,随着时间的推移,UI 改变越来越大,很多核心逻辑也有较大改动。UI脚本渐渐跟不上业务的变更步伐了。
  第二阶段,UI测试加上接口测试。这个阶段,团队引入了接口的测试。针对经常回归的接口,进行了脚本覆盖,效果很不错。因为接口测试的代码量可以很少,并且用数据驱动方式减少了脚本的重复建设。接口的覆盖率一下提升了很多。UI自动化测试比重逐渐下降。
  第三阶段,大部分接口测试覆盖加上少量核心场景的UI 测试。这个阶段,接口测试覆盖程度进一步上升。已经完成了 80%以上的接口覆盖。而且这个覆盖不是简单场景的,是进行了众多场景的接口覆盖。UI 测试渐渐用手工测试去覆盖了。因为接口脚本已经覆盖了大部分场景,所以手工测试只需要关注页面显示和浏览器兼容性等一些页面的问题即可。
  第四阶段,更完善的接口测试。这个阶段,是对一些难以准备测试数据的场景进行Mock 测试。也就是把依赖接口Mock 好,然后构造一些无法构造数据的场景,更好地完善接口测试场景。这样的场景覆盖大大增强接口的覆盖率。
  经过这四个阶段,团队已经从之前的手工测试状态,转变为半自动化的机动状态。当上线一个功能时,团队成员会将核心接口进行自动化测试,然后再辅助以一定的手工测试。这样的测试达到了事半功倍的效果,大大提升了测试效率。让测试人员可以从繁重的测试任务中部分解脱出来,进行更好的质量保障工作。
  3.4.3 收益可视化
  其实,我们在做自动化测试时,有一个困扰一直萦绕在脑海中:如何评估自动化收益。自动化帮助团队解决了回归测试大量的重复劳动问题,但是怎么体现出工作成果呢?
  笔者所在团队尝试了下面的方式展现出工作成果。
  自动化测试通过应用维度的用例总数、用例执行结果、执行用例总数、用例执行通过率、效率提升几个维度展示自动化测试相关数据。
  用例总数 = 本应用下的所有用例;
  用例执行结果 = 已执行用例数量 / 用例总数;
  执行用例总数 = 本应用下执行过的用例总数;
  用例执行通过率 = 用例通过数量 / 执行用例总数;
  效率提升是节省人效的计算,公式是15(分钟)乘以执行用例总数。通过这
  几个数据,就大体可以展示出自动化覆盖情况。
  图3.4.1 就是根据自动化指标内部做的数据可视化页面。我们内部叫商城质量门户。这个系统是商城各测试团队精诚合作、联合打造的展示平台。主要作用是提供一个集中展示各系统质量数据的平台,直观展现各个维度的质量数据,将京东测试团队通过技术驱动提高效率的成果直观量化地呈现出来。
  综上所述,相信读者对本小节所讲述的分层测试已经有一个整体的印象了。分层的金字塔是有助于我们理解并实践的基础。我们在做某一项测试时,首先需要想到的就是成本收益。如果成本大于收益,就需要思考替代方案了,例如可以采用手工测试,而不是一定要自动化。总之,测试越早介入,质量就越可靠。
  3.5 小结
  本章自动化测试实战实际上是围绕着三个主题展开的:WebUI 的测试、接口的测试和测试的收益。其实,这三个主题都有一个共同的宗旨,就是自动化测试减轻手工测试的压力,并且找出更好的质量保障方法。WebUI 测试从用户角度保障系统质量;接口测试从接口层面保障系统质量;Mock 测试则从测试数据的角度保障测试效率的提升。
  分层的思想,是从一个横切面对质量保障的方法进行了归纳。找出最高效的解决方案,按照成本收益的方式,对测试过程进行切割。最终的结果是,花费最小的代价,获取质量的最大收益。
本文选自《京东系统质量保障技术实战》第三章,本站经机械工业出版社和作者的授权。
版权声明:51Testing软件测试网获机械工业出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可,不得对本文内容复制、转载或进行镜像,否则将追究法律责任。
22/2<12
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号