你这里都有提及到一个加密,那加密你是怎么做的?讲一个实际案例来听一下。接口测试嘛?就是,呃,就是看那个接口文档,然后看他的参数和请求方式,然后添加到配置文件,比如说 stp 请求,然后断言,然后那个查看结果数,然后设置一些参数,就是这样去看他那个预测结果和我们需求文档的不符。 我是让你讲一个测试用力,测试用力。对,嗯,这个操作怎么做的?就比如说登录啊,登录,登录的一个接口测试就是根据那个接口文打来,把那个路径啊,点码啊,那些参数啊那些都设置到里面去,然后获取。获取可以后面如果说是有业务流程测试的话,就会获取他的一个头壳,然后到下一个下一个编辑软件那里面去做一个业 务流程,然后然后用那个。呃,这个 f 十二号 只是来查看他的字段的,就是验证一下他的字段前这个入餐和出餐他的字段是否缺失,相当于 f 十二是一个流流。那个 web 端的抓包工具啊,他不是来做机构测试的,然后 jimmy 才是主要用的 jimmy。 做机构测试的就 jimmy。 f 十二呢?只是简单的看一下。 嗯,没问题。这个没问题,是三个接口,不是多个接口的业务总部。呃,一定有多接口的。多接口怎么做?比如说在录录库再把那条把它删掉,你就删掉。呃,我其实更想知道,就是说 你说我,我要不要创建县城组,是吧?因为做接口不外乎就是要界面或者 pos 面吗?嗯,那这个时候我第一次肯定拿到。那你,你刚就你刚说的好一个登录,对吧?那登录的举个例子,登录之后的数据,那你这个定讲一个,比如说我要一个订单数据,那你这个订单数据是不是应该要登录的前提下你才能有数?那你这两个接口怎么通过?比如说创建一个,然后然后里面一个接口里面它会涉及到一些 pos 啊,什么之类的啊?这他就意思就是说 接口依赖嘛,接口依赖就有健全,还就有关联,自己堆东西。对对,获取的就是可以,就是登录成功后就是获取,用那个一个变量来获取一个呃透杆,然后再放到下一个,放到下一个那个呃接口那里去。接口关联的话大概就是这样,用变量去获取那个透杆,呃 登录之后就是获取变量,获取 token, 然后放到。其实你这个说的没错啊。嗯,专业一点嘛,就是我们 可以说接口依赖就是上一个接口啊,怎么它的那个 response 的 参数的值?我们提取用在界面里面把提取成一个呃一个变量,然后再把这个变量呢?就不要用到这个 token 的 话,我们把这个变量传参传进去。 这是接口关联吗?没啥,没啥问题啊。他,他讲完了就讲完了。但是你这解释太过于普通了啊。意思是这个意思。好的, 嗯,接口关联的话大概就是这样,用电量去获取那个托克,你用在密特上面去获取的托克是吗?嗯,可以用那个呃折腾提取器,或者用正则的提取器来提取那个。哦,他可能就是想想的更更加细致的,比如说哪一部用的什么原件,然后 然后最终的结果怎么样?他可能就像你看说什么精神继续接受他就不说了。嗯,应该是你进去了就负责两个项目不固定吗? 算是目前是只有接触到这两个。那个库房方面的话,呃。会什么情况下会使用的?没什么。那个库房方面的话还有什么那个数据库方面的话会在什么情况下使用啊?数据库是吧?哦,这个是 这方面的话。呃。会,还有哈,两年经验。只接触两只接触到两个很正常的呀。你说咱们这个项目是不断迭代的,他就懂了啊,就不断迭代的,就他就懂了。就你如果,如果你告诉他咱们这个项目六个月开发完的,最后就不负责了,他就会很好奇你为什么只做两个项目? 他们这个好像是很多个项目并行的。对,一般啊,如果是不断叠加的项目,不会很多项目并行的。最多两三个吧,最多两个就很多了,一般三四个项目并行的。怎么可能啊?那也太夸张了。我们家会使用的, 比如说验证就是可能我入库新增一条入库单,然后就是保存成功之后我会用一个查询语句去查一下数据库它是否真的存进去了。 你这个是测试环境还是线上环境?测试环境。呃。其实数据库怎么验证的话就是说接口测试的时候会用到, 就是判断他的数据,一次性就判断前端上前端上面的数据是不是从数据库里面来的,以及数据库就是我们前端提交的数据呢?是否成功入库啊?成功落库这就是数据库的一些作用, 其实就是借助测试这块用的比较多,还有一个就是制造测试环,那个制造测试数据这块比较多,就这两个地方。那用什么 bug 管理工具, bug 管理工具来去。嗯,他说是测试环境,现肯定是现场环境。哎,肯定是测试环境啊,现场环境我们测试是没有权限去访问的, 因为现场网易的数据库是专门有,有那个就开发,他是有权限访问的,还有我们的领导负责人他们有权限访问的。下面的普通测试是不允许有这种权限的。三到五年,那就是长期,比如说就多学习一点,然后就是化妆方面的内容。化妆包是哪个岗位? 嗯,你这个这个打的不是特别好啊,虽然说我以前是这样教的。那现在有更好的打法,你下可以下去看一下那个我那个课程上面的一百道预测面试题下面有一个 职业规划,就分为短期的规划和长期的规划,但是你这说的三三到五年的长期规划其实也说的不是特别的好,其实还可以,并不是,并不会,并不是说错了,只是说有更好的打法就。而还有一个问题,就咱们尽量不要往性能安全方面走,你要说你想从你想往自动化 啊,自动化这方面去学啊,自动化如果有时间还能接触一些性能的话,当然最好啊,对这方面可以这样说一下,就不要说,只做性能不要说。哎,我看你直接说了,我想学一些性能相关的,他可能会误误会说你以后想做性能相当于想转行,不想做这个功能接口,好吧。 嗯,这是中高级的。中高级吗?这肯定是比如说自动化啊性能啊还说是可能是自动化和接口。这你看这就说自动化接口了是吧。可以的比如说可以说从 ui 自动化或接口自动化方面去深入的学习啊当这方面的技术都掌握的比较牢固了啊我想进一步提高自己的这个技术站。我也会去学一下性能啊会学一下安全 d i c d 这些 有 c c d 流水线这些。那你知道目前只做了接口吗是吧做一些就是说稳定点的都会有的。由你一个人完成吗还是有。嗯互相学习吧更合适。就是根据一起做就是一起搭建我们的那个框架的话是之前搭建好清楚。那怪不得我刚才听的时候不觉得哈哈哈今天我有点这种确定一下就是按照你最低的标准给你的。 对呀现在行啊。现在行你也有一点要太高啊。对没关系没关系问题不大。嗯 我觉得还是继续面吧你今天跟我说你不想面呢就拿就拿到这个 offer 等着去我就怕他到时候年后他跟你毁约的。这个 offer 已经发下来了吗。 对呀发了邮件发了哦。已经发了是吧发了的话应该一般不至于毁他但我我还是不建议你现在就开始玩我建议还继续再面一两周最后再面两周。 我建议是我是这样建议的因为你之前也就只面了两周啊虽然说可能过程比较坎坷但是两周来说其实现在大多数的人都是面那个三五周 那些好多粉丝来找我就是那些有些半年面的半年都没面上的那些很多的他们一直在坚持,所以我建议再坚持两周就再再坚持两周,如果还拿不到更好的 offer, 那 我就去这家。好吧,那个我挺多都没有回答上来的。对,我也看了一下,很难很难的啊, 他是一个外包。嗯,是的啊,没有规划就希望一直能有工作证。肯定不是的哈,就是三到五年的规划。我我建议是这样说的,就咱们肯定要去学习技术啊,比如说我,我三到五年,哎,我给你打开一下课间看一下打开一下我们的课间看一下。广州的啊广州啊,这个 我这写的很详细啊,三到六年的长期规划到我想持续学习测试相关的技术和知识啊,晋级到高级测试工程师,能够独立负责整个项目的测试工作,能够培养新人,当我有多年工作经验之后能够学习部分的管理知识啊,能辅助这个这个测试组的未来规划。 像我现在没有提到到底要找走性能还是走安全,我什么都没说,我就说一下想持续学习,说比较抽象,就这样说也可以啊, 他他要问的就是到底是做功能还是性能,他要问的就是这个问题,所以后面我才有可能他他问的是你到底做自动化都行,真的是。对对对,因为我说的这个笼统的之后他 那肯定做自动化,那肯定做自动化,就是如果他们的招聘岗位上面写了很多性能相关的,那你说你想做性能,他说我的招聘岗位上面写的自动化,那你就那就是找自动化,就你先得看了解一下他们的公司到底是 走哪个方向啊?如果他们想走安全,你去说你想走性能,他就不要你,因为你不符合他们的要求。如果他们说想走自动化,你说你想走安全,那么也不要你。 嗯,看一般公司啊,百分之九十公司都是自动化,很少有公司想培养性能的,基本上没有很少的。嗯, ok, 这个规划就不说了。然后接下来下一个吧。下一个面对下一个确实比较比较难啊,比较复杂。挺难的。说实话,因为很多关于代码相关的。
粉丝690获赞6008

杰米特里面不同的线程组之间变量是不能互相使用的,比如说线程组一里面登录接口,我们用 json 提取器提取到了它的 token, 这个 token 值是不能在线程组二里面去使用的。那怎么样让它能够在线程组二里面去使用呢? 我们就可以用一个 jsr 二二三这个后置处理器去把这个 token 存到一个全局变量里面, 我们去添加这个后置处理器,我们在县城组 e i 的 去选后置处理器,直接去点击 s r 二二三这个后置处理器,点完之后在这里面我们用这一个方法, 这个 v s r 这句话代表的是我们拿到本县城组的 token 这个变量,然后去放到全区变量的这个变量里面,然后我们在县城组二里面就可以使用了,使用的时候还是 dollar 大 括号里面用这个全区变量的名字。

那你说一下你用 jimita 做接口测试的流程吧?没做过啊。行,第一步啊,通过接口文档或者抓包获取接口的 uil 和参数。第二步,创建县城组,创建 htvp 的请求,根据接口地址设置相关的信息。 第三步,根据测试用力情况修改接口参数,调动接口。第四,对接口的返回值做判断,也就是断言,你明白了吗?

你说一下揭秘的是怎么做接口测试的,然后怎么去测试这个接口的关联的啊?就是通过揭秘的中的 sdb 请求,然后查看结果出来做,至于揭秘和关联,我们这边好像没有做过。好,你这个回答不是很全面啊,那我来说一下。首先的话呢,我们做接口测试流程是根据开发提供的这个接口文章来编写接口测试用力,然后呢,根据用力使用接口来建议测试 啊揭秘图做借口测试的话呢,我们需要添加这个信神助 hdd 请求,然后在 cd 请求当中呢,需设置好地址啊,参数啊,以及要添加这个请求头部信息 啊,然后再添加这个查看结果数,来查开响应的一个结果对比结果是生命当中的预计结果,是不是一致的同步呢?去检查数据库来确认结果数据是否是通过的。 那另外的话,部分数据呢,我们会定义为用户电量来进行调用,那涉及到批量测试呢?会使用 csd 测试原件来读取数据进行批量测试。而至于这个结果关联的话呢,我们是用经历的一个后置处理器, 主要是这个节省提取器和政责表达是提取器,比如说我们要去获取这个 top, 会把这个提取到的 top 值呢复制给一个变量,然后在下个接口来调用这个变量就可以了。

对于需要加密的请求参数, gmail 它是如何处理?那 gmail 呢?是常用的接口测试和性能测试工具。对于需要加密的这些参数请求呢? gmail 它提供内置的函数和强大的扩展能力。一、无需密钥的这些单向加密,比如说参数的签名密码的加密, 直接用哈希加密,比如 md 五或者 sha 二五六,无需写代码,你直接用铭文参数,比如一二三四五六,选择 md 五加密,点击生成,直接就得到了加密的函数表达式 down 下滑线, md 五一二三四五六括号,那注意这里的下滑线,它其实是两格下滑线啊,把这个变量表达式复制到你的接口请求里面,直接就可以使用了。二、选 要密钥的加密场景,比如说金融接口的敏感参数加密手机号,身份证,那可以使用 b n shell 或者是 g s r 二二三的脚本,那推荐使用 guillotine, 它性能其实是优于 b n shell。 那 流程,你先定义一个 a s 加密工具类,对铭文参 参数进行加密,存入加密的变量请求中,直接引用这个变量,那下面呢,是给一个代码的实力。三、如果需要复杂的加密,可以自定义,或者将加密的逻辑打成价包放在 gmail 中,适用于你项目的自研加密算法,比如说金融机构自定义一些签名算法,你复制这个价包到 gmail 的 安装目录 lab 杠 e s t 下面那重击 gmail 或者 g s r 二二三 前置处理器中小本编辑添加文件,选择夹板即可,这个时候是不需要重启。那最后呢,我们可以在查看结果书中看你整个请求和 response, 看下加密的效果是否符合预期。 ok, 如果你还想学习更多的技术,欢迎找我一起交流。

你说一下 tma 是怎么做接口测试的,然后你怎么去测试这个接口之间的关联呢?嗯,就是通过这 mit 中的 stp 请求,然后查看结果数来做,那至于这 mita 关联这边我好像没有做过, 你这个回答很不全面啊,我来给你说一下啊。首先呢我们做接口测试的流程是这样的,根据开发提供的这个接口文档呢,我们要先编写接口的测试用力,然后根据用力呢使用吉米特来进行测试。 那吉米特做接口测试的话,我们需要添加这个现场组啊, httb 的请求,然后在 httb 的请求当中呢,去设置好对应的地址和参数,以及要添加这个请求的头部信息啊,然后再添加这个查看结果数呢,来进一步的去查看一个响的结果, 对比接口中的用力呢?当中的预期呢?是不是符合一致的同步呢?我们还要检查数据过来确认接口数据的返回呢,是否是通过的。那另外的话,部分的数据呢,我们还要定义为用户备量来进行调用,那涉及到批量的测试呢,还要使用 csv 的 是原件的来进行读取数据,进行拆除霸主批量行驶。据这个接口关联的话,我们是用精英式的一个后置处理器,主要是这个接线提出器或者是正则本拿的处理器,比如说我们要获取这个通份,可以把这个提取到通份的值呢,然后呢赋予一个变量,然后在下一个接口来调回这个变量就可以了,这个流程你明白了吗?

想进大厂,这个知识点必须拿下 g m d 不 只是压测工具,接口测试、数据库测试、批量造数据都能干,是测试工程师刚需技能。基础功能, http 请求配断言校验返回结果,支持正则表达式和 g o i 提取验证自断值 进阶功能,参数化批量跑用力 c s v 文件导入测试数据接口串联自动化注册登录上传下载列表获取一套流程自动跑高级功能,性能,压测,模拟一万个用户并发访问聚合报告,分析响应时间、吞吐量、错误率、定位性能瓶颈给优化建议。 实战项目一例,云盘接口测试,从文件上传下载到列表获取全覆盖 jns 接口串联测试 还能写入结果到 excel 生成报告。这些年踩过的坑,总结的经验,我都整理成了一份超详细的文档,观目录就有三页,真的是掏心窝子的干货。

g m meter 压测翻车,现场说不出 g m meter 缺点,面试官直接笑了,哈哈哈。有个同行上周面试软件测试性能岗,被面试官当场敲打 g m meter 压测,他自信满满,脱口而出 g m meter 做接口压测,万能又好用,日常压测全靠它就够了。 面试官一听直接乐了,淡淡反问一句, g miter 本身天生就有短板和硬缺陷,你连它自带的缺点都说不出来,日常压测就敢直接拿来用?随便搭县城组就跑,压测数据能准吗?同行当场一愣,脑子瞬间卡壳,吱吱呜呜半天接不上话,尴尬到脚趾抠地,最后只能草草结束面试, 溜的比下班跑电梯还快。如果你最近也在备战软件测试面试不知道高频考点怎么打?我整理了能让面试官沉默的必考题库,包含测试理论功能、测试自动化、测试接口、测试性能、测试数据库项目等等。只要是我粉丝,点个赞,评论六六六,直接打包带走, nice! 其实做性能测试的人人都会用 g meter, 但真正吃透它短板懂底层局限的没几个。听我给你讲透 gm meter 好 用不假,但它天生自带硬缺点,不是无脑搭线成组就能跑压测,不懂这些很容易压测数据失真,结果完全不准。先讲核心原理, gm meter 是 java 进程级压测工具,本身跑在 jvm 之上,它开的每一个虚拟用户线成本质都是 jvm 普通线。这就带来第一个致命短板, 单机并发上限低,单机开几千虚拟用户很容易出现 jvm 内存一出现程上下文切换飙升,不是被测系统先崩,是 gm meter 自己先扛不住压测,结果直接失效。在第二个硬伤,高并发下,有资源开销抢占 gm meter 自身要占用 cpu、 内存、网络资源。 单机压测量大时,工具本身就吃掉大量性能资源,相当于裁判自己下场抢跑道,测出来的响应时间, tps 完全居高不准。还有第三个关键缺点,不适合超高并发长连接场景。 g m meter 线程模型笨重,长连接十万级以上,超高并发支撑能力弱,比起专业压测工具,线程损耗大,延迟偏高,大流量场景很容易产生线程堵塞。再给你打个通缩,比方, 你拿小水桶去抽大河的水,不是河水流量小,是你水桶本身容量,抽水速度就有上限,再怎么使劲也达不到真实大流场景。但面试官还会接着追问,知道缺点了,那工作中怎么规避?很多人只会傻傻加机器,其实根本不对。正确做法,单机控并发上线,分布式压测,拆分压力, 单独部署 g m t。 试压机和备测服务,隔离资源,调整 g v m 参数,优化内存长连接场景,改用专业压测方案互补。最后给大家总结三句金句,面试直接背下来反杀 g m t。 受 g v m。 现成限制,单机并发有天花板 量大,避字号工具自身占用软硬件资源,单机压测易数据失真。超高并发长连接复杂场景又短板, 必须分布式压测加资源隔离规避缺陷。记住这三句话,面试官再问 g m t。 缺点,压测怎么避坑,你直接从容应答,再也不会面试,翻车做性能测试。 g m t。 压测就这点底层逻辑,别再只会用不会原里面试被面试官考打哑口无言。

很多学软件测试的小伙伴自学 jmeter 是 不是特别迷茫?没有规划,死记硬背,盲目瞎练,学了很久,还是只会简单发个请求?真正的性能压测完全不会,面试工作全都用不上。 其实学 jmeter 根本不用这么费劲,只要吃透这四个核心学习阶段,普通人也能快速玩转性能测试,求职上岗直接少走九成弯路。第一阶段就是基础认知,新手先不用钻研高阶功能,先搞定软件安装部署,搞懂 jmeter 各大核心组建的作用, 比如线程组、取样器配置、原件监听器,分别是用来干什么的?熟练搭建 http 接口请求,搞定最基础的 get post 请求发送,能独立完成简单的接口调试基础就算过关了。第二阶段是核心进阶实操,这也是工作中用的最多的内容, 重点吃透四大核心技能,参数化接口、关联、断言较验,还有 gucci 绘画,熟练掌握动态参数提取批量请求的数据较验,能够完成多接口串联业务场景, 适配企业真实的项目测试需求。第三阶段就是核心的性能压测实操,学会根据业务场景设计合理的并发方案,掌握阶梯加压、持续稳压的压测方式,灵活调整现成数、加压时长和循环次数,看懂聚合报告数据, 通过 pps 响应时间、错误率这些核心指标,精准分析系统存在的性能瓶颈。第四阶段是高阶企业级落地。想要高薪进阶,就要学会分布式压测,各类定时器、逻辑控制器的使用,掌握压测脚本优化技巧,能够独立编辑专业的企业级压测脚本, 对接 ci 持续集成自定义生成标准化性能测试报告,真正实现项目全流程自动化性能测试。 我把这四个阶段所有的实操技巧、知识点、避坑细节全部整理成了全套干货文档,从零基础入门到高阶项目落地,每一个操作步骤都拆解的清清楚楚,新手也能直接跟着练,快速上手。想要这套完整 j m t 学习文档的小伙伴成为我的粉丝,三个六直接安排!

在做接口测试过程中有没有发现过一些影响测试的 bug? 嗯,在做接口测试,像在做仓库管理系统的时候呢,它就有一个新建入库的一个单嘛,就是在它新建入库单号嘛,它是以当前的时间段自动去生成的,是必填的嘛?嗯,然后呢,在它它也可以在前端页面当中去显示,然后呢在做接口测的时候呢,它这个 壁贴是可以绕过它的,可以设置为非壁贴吗?然后呢也可以去成功的去创建好这个入股单,然后呢,但它呢在前端页面显示时候是为空的,这样呢会影响一个后续的查询和出库的一个流程,然后就提到有 bug, 然后呢原因就是因为开发没有对这块进行一个壁贴的敲印。哦,好, 那平时是怎么去判断接口的前后端?就比如说一个 bug, 你 是怎么判断它是前端的 bug 还是后端的 bug? 你 是如何去定位的? 嗯,定位的话首先可以通过拍一个接口来判断吗?就是从前的页面当中吗?我们去传到数据,看他有没有传到有快速的情况参数当中,然后呢再通过去数据库他返回这个结果吗?有没有在前端页面中显示?如果没有的话,那么就是前端的 bug, 然后呢再通过它呃请求数据嘛?就是呃传入到快捷的请求当中,然后看它是否成功的传到数据库当中,然后呢再从数据库它所反映的一个结果看它有没有传到 response 中,如果没有的话,那么那么就是后端的 bug, 也可以从 bug 的 范围来进行判断,像我们前端页面当中对它,呃就是页面的交互以外的展示, 然后呢,后端有问题的话,然后在后端对数据的处理和存储的话,没有问题,那么就是前面的 bug, 反正这就是后端的 bug, 也可以去查看日期码,像从 linux 去查看日期的话,如果有报错,一般来说就是后端的 bug, 前端的话我们可以从 f 十二码去查看,它有控制台,如果有报错的话,那么就是前端 bug 也可以通过,呃,因为做接口测试完成,它有一个相应的状态码,如果是四开头的话,那么就是后端的 bug, 就 从这方面去进行判断。好的, 嗯,当你定位出来假设是后端问题,然后开发他觉得不是一个 bug, 这种情况怎么处理?嗯,这样的话呢,先仔细去对照需求文档,看看是梳理逻辑吗?看看是否是因为自己一些错误的低级错误导致的吗?要先排除和业务不一致的情况,然后呢,如果他是个 bug 的 话,那么就, 嗯,去记录下 bug 的 危害,还有他一些证据呢,像截图和视频。然后呢要求领导和开发区进行沟通,如果在这样情况下,开发还是认为不是 bug, 那 么就要去找人,那么这时候就需要领导和产品去进行介入。嗯,好的。这一连串问题啊,就是一个组合拳啊,只要问到这个 bug, 他 就一套全部问完了, 当然这个功能测试有可能会问你怎么定位前端问题啊,如果遇到 bug, 不是 bug 怎么处理啊?这种当然还有可能会问到一些难以复现的 bug, 你 怎么解决啊?难以复现的 bug, 嗯,在我的面试题里面有写到,可以看一下。好的。

测试过程中多个接口有关联,你如何测试?那首先呢,我们要了解整个关联的关系,比如说业务逻辑中多个接口调用的业务流程,它是在 用户下单还是整个用户登录所有的接口,获取令牌,商品查询接口,获取商品信息,订单创建接口、提交订单等等。多个接口我们需要确保这些接口之间它是存在先后顺序和数据的传递关系的,这个数据可传 关系必须要明确且不能断。第二就是关联的数据,通常我们前一个接口响应的某些字段,它是可以作为后一个接口请求的参数的,比如说用户登录接口返回的用户的 hash 令牌以及订单的 id, 它在后续订单查询的这种接口中是需要使用的。那我们需要把这些公共参数以及前后有关联的这些 参数先去提取出来,然后再用做后面的接口的入参。那第二呢,我们就进行整个场景列入的 case 设计,比如说正常场景,我们需要去按接口的调用顺序编辑,在前一个接口执行成功后,从你响应里面拿到关键的一些数据,然后用 simpass 或者其他的工具去提取这些数据,放到下一个参数里面,我们确保整个接口的响应状态和内容是正确的,以及整个业务流程它都能顺利的完成。第二就是看一些异常的情况,比如说接口的调用顺序,或者说前序接口失败之后,或者说登录太 丢失,权限丢失等等这些情况,那整个接口的串联是否还能正常进行?第三个就是密等,这个是非常重要的,之前很多同学呢,也发现过类似密等的一些问 问题。一、业务上因为密登也产生过线上的事故,那前序的接口成功之后,后续接口如果多次就会严重,比如这样支付或者说其他的一些接口,这种只有第一次是能成功的,后面是不能成功的。如果他已经支付成功,他的状态机是必须发生变化的,他能支持这种密登的调用和叫验。我们不能进行重复的支付, 否则的话可能会造成一些订单的报错以及财务的损失。那第四呢,就是一些权限和业务限制,比如说你没有登录,那我后续的接口是不能进行下单的,以及我后续查询订单信息也是查询不到的。 还有就是我们的月全, a 用户是不能看看到 b 用户的一些订单或者信息的,那 a 和 b 同时去购买,但是库存不足的时候,我们也是需要进行校验的。第五呢就是数据一致性,整个接口调用顺序 使用的业务数据必须是一致的,比如你下单接口的订单号和你订单列表的订单号,它必须是保持一致的,不能用 a 的 订单号查 b 的 订单,也不能用 b 的 订单去查其他用户的订单,这些都是需要有一致的,而且你数据库和 database 值也是一 致的,不能你同一个用户第一次查,查到的订单和数据是一个,那过了两分钟之后查又是另一个,这样会给用户造成非常大的困扰,所以我们要保障数据库和 read 的 值是一致的,而且它是有一些时效性的。那 最后一个呢,就是性能测试,我们整个链路维度的接口性能是非常重要的,如果串联到整个链路,那就是全链组压缩,我们需要木桶原理找到它整个系统的瓶颈,这样我们再进行针对性的优化。 ok, 如果你还想学习更多关于接口测试的,欢迎大家找我交流。

g m t 做接口性能测试,怎么设计测试脚本?你说你会用 g m t 做接口性能测试,那你知道怎么设计一套稳定可用,企业能直接落地的测试脚本吗?刚面了一个三年经验的软件测试,我问他项目都是长链路接口, 带加密签名,多用户高并发场景。用 jmeter 做接口性能测试,怎么设计一套稳定不崩可附用易维护的专业测试脚本? ai 能快速生成基础脚本,普通测试也会简单录接口改参数,看起来接口都能跑通,请求也能发出去, 那你该如何判断脚本是否规范可靠?能不能直接拿来压测上线做性能评估?完整设计思路和落地标准是什么?他想都没想直接回答。打开 jmeter 录制业务接口, 改下参数,加几个线程组,调好并发数,直接跑压测就行。我顺着他的话继续问,这个基础操作谁都会,但我再问你,接口 token 订单 id 这类动态参数怎么关联提取? 加密接口签名时间戳怎么自动生成?适配多环境域名地址怎么一键切换管理?长链路业务怎么拆分模块做到附用维护高并发下?怎么避免脚本报错?请求重叠?数据缓存失真, 压缩出来的 tps 响应时间不准,怎么排查是脚本问题还是系统瓶颈?我补充到很多人写的 gm 二脚本,看似能跑通,实则杂乱无章,硬编码斜死参数,没有分层设计, 处理不了加密和关联,一到大病发多轮迭代就频繁报错,结果失真,完全没有参考价值。针对企业复杂业务场景,你有没有一套标准化的脚本?随便改改?没专门做过规范设计?电视到这里基本就可以结束了。 如果这道题你也没把握打好,我整理了一套能拿捏面试官的必考题库,包含测试理论功能测试、自动化测试、性能测试和 ai 测试的内容。只要是我粉丝留下,六六六直接带走 nice! 很多测试从业者都有一个误区,觉得 jammer 只要能录制接口,发起请求跑出数据,就代表脚本合格能用。但大家忽略了一点,脚本能跑通和脚本稳定可用企业及落地完全是两个不同的技术维度,不能混为一谈。 一个能胜任企业接口性能测试的高级测试工程师,必须具备以下三层核心认知,缺一不可。第一层, j m t。 脚本模块化分层拆解与避坑核查。新手写脚本最容易出现各类问题, 所有接口堆在一个县城组,硬编码写死账号域名,接口杂乱无章,无法复用,看似能跑通业务流程,实则后期极难维护,迭代一次就要改变所有脚本。 j m t。 擅长简单单接口压测,但面对复杂场景,短板很明显。 登录 token、 动态关联上下由接口参数、依赖、接口加密、签名校验、多环境切换、长链路业务流程秒杀、瞬时高并发、弱网间隔模拟。这些场景随便录制的脚本根本适配不了,还容易出现请求重复数据,脏数据压测结果失真。所以绝对不能直接用原声录制脚本 要先做模块拆分归类,划分为公共基础模块、独立业务模块、压测场景模块三大类,逐一梳理接口依赖关系、动态参数、加密规则,确保脚本贴合真实业务流程,不做无效用于设计。第二层, jim meter, 脚本规范化、量化设计,拒绝凭感觉写脚本 设计稳定脚本,绝对不能随手添加组件、乱配参数,而是要建立标准化设计规范,重点把控这几个核心要点,脚本分层附用率、接口关联覆盖率、 参数化、数据多样化、加密接口适配率、压测场景匹配度、脚本报错故障率、多环境兼容适配能力。同时要对照需求文档 接口文档线上真实业务流量复刻用户常规操作、异常操作、峰值操作场景,参考过往线上性能故障,验证脚本能否覆盖高病发、超时限流、溶断等核心场景。除此之外,还要对脚本做分级管控,基础可用脚本需优化调整脚本逻辑错误,废弃稿本, 做到精准优化,而不是录完直接拿去压测,盲目出性能报告。第三层, gm e t 脚本落地优化方案,建立性能脚本质量准入标准。想要真正设计出稳定可用的性能测试脚本,首先要搭建标准化脚本规范,统一现成组命名原件层级 变量命名注视规范,用测试片段模块儿控制器实现公共脚本全局复用,减少重复开发。其次,核心场景重点适配,针对登录健全支付、下单商品、秒杀用户中心这些核心高并发模块儿,单独做加密处理, 集合点加压定时器模拟用户思考间隔,规避瞬间流量冲垮系统压测数据不准的问题。最后,把项目接口规则、加密算法、环境配置、常用压测参数整理成固定模板,沉淀企业专属 g m t 脚本规范,形成模板出使化模块拆分配置 关联参数化加密适配场景加压结果分析的完整流程。坚决杜绝随手录制、随意改身的粗放写法,建立明确的性能脚本质量准入标准,守住性能测试结果的真实性和可信底线。 说到这里,大家应该明白这道面试题的核心考察点了,它考察的是你能否从只会简单录脚本跑并发的基础层面,升级到能做脚本工程化设计、复杂场景适配、稳定性把控、性能瓶颈分析的高级层面。普通测试工程师只要脚本能发请求跑出数据就觉得万事大吉。 而高级性能测试工程师清楚 gm meter 工具操作只是基础,能否设计出易维护、可附用适配加密、长链路、高并发下稳定可靠的脚本,能否保证压测数据真实有效、精准定位系统瓶颈,关键在于你对脚本分层设计、 接口关联场景加压规范落地的深度理解,以及对性能测试全流程的标准化把控能力。最后想问大家,你们平时用 jimmy 写脚本有没有踩过脚本混乱、无法维护、加密接口跑不通、高迂发频繁报错、压测结果失真的坑?欢迎在评论区一起交流探讨!

讲一讲你用这个金妮头是怎么来做这个接口措施的吧。首先添加一个测试计划,然后添加一个现成组,然后再建一个而且 gdp, 然后再添加一个查看结果数,选择一下他的请求的方法,还有他的借口的一呃地址,还有看一下编码,看一下参数。那你怎么去对借口去进行判断他到底有没有知识?很稳啊。 去看一下他的返回的结果,做测试用力里面的预期的这个结果,做下一个对比时候,也会去检查一下数据库,看一下是不是跟数据库里面的数据一致的。