个人免费网站建设模板,呼市做开发网站的公司,成都网站建设开发公司哪家好,黄页网络的推广网站有哪些类型为什么选择这个话题#xff1f;
一是发现很多“点工”在转型迷茫期都会问一些自动化测试相关的问题#xff0c;可以说自动化测试是“点工”升级的必经之路#xff1b;二是Google一下接口自动化测试#xff0c;你会发现很多自动化测试框架相关的文章#xff0c;但是大部分…
为什么选择这个话题
一是发现很多“点工”在转型迷茫期都会问一些自动化测试相关的问题可以说自动化测试是“点工”升级的必经之路二是Google一下接口自动化测试你会发现很多自动化测试框架相关的文章但是大部分文章都有一个通病就是只告诉读者how(怎么做)很少介绍why还有框架开发完成之后的事情例如如何推广、维护等。那下面就聊一聊我的接口自动化测试框架建设的一些经验和教训吧希望能给大家一些借鉴。
工作多年第一次听说接口测试是在《软件测试的艺术》的书上面那时候校招复习软件测试理论当时没有体感甚至不知道什么是接口。第一次接触接口测试并非来源于项目需要而是来源于团队KPI需要。当时校招刚入职没多久团队内部有测试相关知识与技能培训虽然只是测试工具的使用当时接触的第一个接口测试工具是 JMeter。还记得我同事通过一个word文档给我介绍它的一些常用组件然后就给我安排上了一个任务 - 将团队 xx 平台接口代码覆盖率提升至40%以上。当时还不知道代码覆盖率是什么但是只晓得通过 JMeter 开发更多单接口/业务场景组合的用例就是了于是乎就开始通过针对单接口的入参类型、边界、是否必传做各种组合而场景组合用例就做接口间的笛卡尔积生成不同的业务流。第二份工作老板想打造一个团队内部使用的接口测试平台当时就给我这个机会负责接口测试框架的建设。这也是第一次实践接口自动化测试框架。今天聊的故事就从这里开始。。。
一、为什么要自建测试框架
1.1先谈谈接口测试
何为接口通俗来讲生活中常见的电灯开关就是接口它接收开、关默认指令值输出对灯泡的控制结果亮、灭。接口测试是测试系统组件间接口的一种测试。测试的重点是要检查数据的交换传递以及系统间的相互逻辑依赖关系等。
1.接口测试“套路”
根据我举的例子可以知道对接口测试从功能上可以把接口当做黑盒进行输入以观察其输出根据不同的输入去测试其内部的逻辑我们可以借助边界值分析、等价类等方法设计用例。非功能上要测试接口性能、安全、幂等。此外如果所测接口存在上下接口调用的依赖则还需要进行全链路联调测试不部分接口不是独立存在的都是和其他接口相互调用的联调测试是为了保证上下联路接口之间契约的准确性。 2.为什么适合自动化
根据分层测试思想可以将系统测试分为单元测试、接口测试以及界面测试。一般来说单元测试就像一座房子的地基地基打得好房子也就比较稳固接口测试就像房子的架子决定房子的形态而界面测试就像房子的装修体现房子的外观。诚然地基以及房子架子是比较稳定的变化不大的而房子的装修是可以根据心情不断更换的。大家都知道变化和成本是成正比的变化越大成本越高根据ROI产出/投入分子不变分母越大ROI越小这也是界面测试不适合自动化的主要原因。当然不代表所有项目都不适合做UI自动化如果UI比较固定也是可以做自动化的。 当然大公司在这方面已经走在了前列了。就拿行业标杆Google来说《How Google Tests Software》书中也有提到70%自动化在单测20%自动化在接口测试10%自动化在UI测试。
3.常用的接口测试工具
介绍下我使用过的JMeter、Postman这两工具。
总体而言JMeter更适合作为接口自动化工具的虽然官网将其定义为压测工具The Apache JMeter™ application is open source software, a 100% pure Java application designed to load test functional behavior and measure performance.因为JMeter几乎能满足接口自动化测试的所有诉求有丰富的函数类似utils例如生成个随机数、uuid等这些都是测试过程经常用的能力而且还支持自己扩展、断言丰富、结合Jenkins做持续集成、有测试报告、有丰富的插件库可供下载等等非常适合技术感不强的测试团队。Postman也是可以做自动化但是我还没有实践过平常更多将其作为接口调试的工具不做过多赘述。
现在我也找了很多测试的朋友做了一个分享技术的交流群共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源没人解答问题坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化性能安全测试开发等等方面有一定建树的技术大牛
分享他们的经验还会分享很多直播讲座和技术沙龙
可以免费学习划重点开源的
qq群号110685036【暗号csdn999】 1.2自动化测试目的
本来这个小标题是“接口自动化测试目的”提笔写的时候发现所有自动化目的貌似是公途的。我先抛出来两个论点发现缺陷提高测试效率
大家可能觉得实现自动化的话这两个目的是自然而然的。当然我不否认但也不完全赞同。那我为什么要把这两个论点拿出来讨论下呢因为自动化测试是一个有计划的过程不同的目的可能会有不同的实现过程有不同的实现侧重点。
如果目的是 发现缺陷那么自动化测试用例就要覆盖的比较全面且细致业务层面、断言层面这无疑会加大自动化测试用例的开发成本所以投入过程需要重点分析业务以及多排期些开发时间。
而提高测试效率呢当然这里的提效不仅仅体现在测试过程而且还体现在测试者的日常工作中类似造数据等工作内容。因此如果以提效为目标那么自动化测试用例开发要重点分析哪些业务流是调用比较频繁的而在断言层面也没有必要太过细致以造数为例毕竟提效的目的在于获得结果只要结果符合预期就是OK的。当然这些都是笔者个人看法大家可以各抒己见。 1.3为什么需要自研框架
上文也说道做接口自动化测试当下有现成的开源工具 JMeter、Postman等可以选择也有一些开源的自动化测试平台。但是这些开箱即用工具也有弊端
测试工具开发的测试用例往往不易于维护试想一下当你维护JMeter生成的各种JMX文件场景。大量的测试用例可重用性差例如登陆模块每个接口调用前都要获取cookie而登陆则是前置模块使用JMeter开发用例需要每个JMX文件都要包含登陆重复度太高。无法满足自动化平台诉求短期内确实可以快速实现自动化但是这些工具对于平台非自动化能力的拓展成本较高毕竟改动开源工具的成本比自研高很多。使用开源工具不利于提升团队在自动化技术方面的成长。自动化能力的提升离不开编程能力的提升使用开源工具能提升工具学习使用能力最终你的成长无外乎又掌握了一个测试工具的使用。无法最大化提升自己解决问题的能力。 1.4接口测试框架选型
关于语言
语言建议和负责项目的系统语言保持一致如果被测项目语言是Java测试框架就选用Java语言开发结合Spring boot框架搭建。
关于扩展性
扩展性是非常重要的因为框架不是一蹴而就的是一个需要基于业务的迭代不断“更新”的良好的扩展性可以让你更高效的开发所需的feature。这点可以参考JMeter的架构设计。
关于实现方案
确定使用的技术后务必要将的实现思路整理出来写一个实现方案就像项目的系分文档一样这样对你来说具备指导意义。仔细想想测试框架的开发就是要求自己兼顾产研测的角色条件可以的话可以让产品/UI帮你设计平台草图。 二、经验沉淀
1.计划的重要性
万事预则立不预则废。对于测试来说计划尤为重要。一方面测试框架建设的任务并不会允许你100%工作时间去做因为你还有业务测试工作要负责和跟进。另一方面老板要看结果制定每个阶段的里程碑是非常重要的当然计划这些会在OKR里体现的。
以我的经验可以制定按照feature数量给自己排期例如每周实现x个feature这样就可以大概推出完成测试框架开发需要的周数尽量周报里有所体现实现的进度以及下周的todo。 2.文档必不可少
为什么文档这么重要文档其实是另一种“自动化测试框架”的实现方式。代码实现框架本身文字为框架“穿上衣服”。再者文档可以节约你未来非常多的“客服”时间。文档内容范围不限总的来说有三类技术实现文档、使用说明文档以及问题记录的文档。
技术实现文档用于描述框架实现的技术手段以及编码规范可以在系分文档上继续补充。使用说明文档用于介绍使用方法最好是先以快速入门为例教大家如何利用测试框架开发一个测试用例。再详细介绍如何使用调用某些公共组件工具。当然建议录制操作视频。问题记录文档 用于协作开发的时候供其他小伙伴参考使用毕竟你踩过的坑别人也有可能踩过。这样可以减少同类问题排查和定位时间。笔者曾经在帮助小组同学排查问题方面就耗费了不少时间。 3.多人协作下的开发模式
自动化框架最终的是推广给大家使用它去开发接口测试用例以替代JMeter这些接口测试工具。在平台化实现之前就避免不了多人同时提交开发好的用例代码。针对这个我建议使用master\dev分支每日的自动化用例运行使用master分支代码而dev分支用于大家提交各自分支的代码。这就需要经常dev分支的代码合到master分支。 4.做好代码review工作
正如经验3一样确定好开发模式之后同样不能避免有些同学在提交代码时“乱来”不规范开发和提交例如随意修改别人的代码等导致代码冲突。而作为项目的负责人就像一个门神要做好代码review工作。这样可以在一定程度上降低代码冲突的概率。总之尽量不要将宝贵的时间消耗在这些代码管理的问题上。 5.推广小组试用
框架开发好后不建议急于大批量推广建议先“小流量”灰度试用。我们大团队下面分了很多小团队基本上业务owner带一些外包保障项目质量。而管理者注重框架的结果。框架开发者是全职员工框架的使用者主要是外包和偏业务测试全职同学。当时搞定框架开发之后算是1.0版本已经可以使用就在我的小组进行使用。这样可以先搜集一下使用效果和反馈的问题先做一版小迭代把他们觉得比较影响使用的问题先解决掉。 6.分享和培训
先给大家做了一次分享演示框架操作原理如何开发接口测试用例。为了让大家好理解我就拿postman 的使用步骤和框架测试一个接口做类比。即使如此 大家刚使用测试框架时候仍遇到了不少问题也是意料之中大多数外包几乎 0 编程经验包括接口测试用例开发成本高外包同学代码能力差遇到问题解决不了不会debug代码开发好的用例上传gitlab经常搞出冲突需要解决每个同学用例的写法千奇百怪等等。还记得当时那段时间的内容除了做手上的业务就是帮忙看大家在写用例遇到的各种问题。为了解决这些问题我也挤时间编写测试框架使用说明书对大家进行git使用培训debug培训等鼓励大家多学点Java多读读《Java编程思想》。 7.注重大家的使用反馈
使用反馈是非常重要的。因为它是你进行版本迭代的驱动力。其实就和产品做项目一样每个版本都要分析用户的使用反馈根据反馈进行版本优化和迭代。可以和使用者沟通发现一些他们使用过程的痛点。当然这只是第一步更重要的是要有解决方案。 8.考虑代码生成
针对用例开发成本高的问题我通过在测试用例开发过程总结到HTTP不同请求方法对应的接口测试写法不一样同方法的测试接口写法几乎一致突然想到可以使用模板freemarker自动生成接口测试用例然后我就整理几种接口测试用例生成模板post、get等这样大大降低测试用例开发成本大家更多在于测试数据的准备和断言。
个人觉得代码生成是每个测试框架设计的必须考虑的点因为像postman、jmeter等这些工具本质上和你开发测试框架是雷同的如果做到用例之间可以相互转化可以提高用例的可迁移性和复用性。
三、教训总结 1.缺乏自动化效果的统计度量
上文说了相比过程老板更看重结果。如何体现结果那就是要有数据统计与度量。记得被开发挑战过你们搞得自动化发现了多少缺陷、节约了多少时间等问题。这块当时做的不好。
1是框架本身还没有平台化当时实现的功能是测试用例开发模块的实现统计数据没有落DB这块需要靠人工统计比较费时间当时为了统计自动化用例运行结果数据在Jenkins服务器上捞日志简直是痛苦。 2是当时没有明确的度量目标像节约了多少时间这类确实难以衡量。
现在我觉得当时的框架设计之初是遗漏了这个问题的建议后来者可以将测试数据都落DB。 2.没有对测试进行测试
这个主要是没有对测试框架本身进行测试特别是多人协作开发模式单测尤为重要单测在一定程度上是保障代码质量的手段可以有效避免部分同学“乱改”别人的代码。当然如果时间充足建议对测试框架写单测。 3.自动化用例开发计划没有突出侧重点
这个也是教训1的一个原因。框架完成之后我们就在okr里计划xx完成接口100%自动化覆盖刚开始阶段没有对被测接口重要性做分析导致没有将时间花在核心的接口用例开发上也间接导致产出不高。
现在想想其实是计划不明确且没有突出重点的问题颗粒度还不够现在的建议是大家要优先实现核心接口这些接口流量大更容易有产出。不要为了追求覆盖率而本末倒置。 4.断言的不完善
当时的框架没有开发DB checker所以断言全靠http 响应其实这样的用例是质量不高的也就是测试预期不全面可能会存在漏网之鱼遗漏缺陷。
建议大家一定要断言模块重点考虑到。包括http层面响应时间、响应码、key字段断言、状态码等、DB层面key字段值比对等。
END今天的分享就到此结束了 点赞关注不迷路
