哇塞小刘-优快云博客

原创不间断的AI消息刷屏一点所感

好事不出门，坏事传千里”，如果没有能力应对现代信息传播的发达，因为所见所闻而无法自处，就算是回到闭塞的山沟里，结果不会有什么不同。随着AI技术的蓬勃发展，不同行业不同人群对它的看法喜乐参半，开心的人更多的是从日常使用的角度出发，觉得它可以方便生活，减少工作，提升效率等；更有甚者脑洞大开，会觉得随着AI的不断发展，最后会如电影《宝莱坞机器人之恋》中扮演的那样，原本为人类服务的机器人，最后觉醒自我意识，又因情感程序失控和对创造者的嫉妒，发动大规模的反叛刺杀创造者，更严重的直接由机器人统治人类。

2025-03-09 21:16:24 266

原创【DS版本】AI时代软件测试角色转型分析

需要同时具备技术深度（AI、数据、编程）和业务广度（用户体验、伦理合规）。测试团队的核心价值将从“发现缺陷”转向“预防风险”和“赋能质量”，成为企业数字化转型中不可或缺的战略角色。适应这一变革的测试人员，不仅不会被淘汰，反而会在AI时代获得更大的职业发展空间。

2025-03-09 13:38:55 795

原创提效赋能利器：数据工厂

在日常功能测试中，我们需要创建测试数据；在自动化测试中，我们也需要创建测试数据；在不同环境中，也需要分别去创建不同的测试数据；在链路测试中，不仅底层应用需要创建测试数据，上层应用场景测试也需要创建测试数据。创建测试数据这件事情本身并没有错，但是有没有更高效的处理方式呢？比如同一个场景，但是因为所属业务线不同，导致大家测试的关注点是不一样的，为了不干扰彼此的测试结果，基本都是各自创建各自的测试数据，这带来了很大的资产，资源浪费。

2024-10-30 10:00:00 798

原创再识用户中心

其实不管开展何种业务，都离不开人，有了人就有了角色，角色背后映射的又是不同的权利，每一个权利背后都对应的不同的技能点，每一个技能点背后都映射的是需求。为了更好的开展业务，我们需要把这些需求实现转换成技能点，并把技能点上蕴含的权利分配给不同组织角色对应的用户，以此让他们更好的完成它们的业务。我们日常接触的电商系统，比如淘宝，京东，拼多多等，为了使用它们，我们第一步需要做的就是注册，因此接触到了电商系统里面最基础的一块内容：用户中心。现在请你细细品一品，是不是这个理呢？所以用户中心是干嘛的呢？

2024-10-29 10:00:00 354

原创再识商品中心

另一方面因为平台有一部分内容是基于供应商展业开拓出来的，这里为了简化供应商的操作成本，会诞生一系列的便捷功能，比如设置免审数据，比如商品复制功能，这样可以提高供应商商品上架的效率。一切皆可售卖的都可称之为商品，即使技术也不例外，皆可沿用上面的逻辑，只不过不同的行业领域需要遵守的法律法规的不同，导致产品的形态不同，底层知识可迁移使用。：商品的身份证，一个商品的品质优劣，首先品牌就能识别出来，加上用户会有自己的品牌偏好，这个会是一个妥妥的金字招牌。：就是仓储，货存放的地方，这个地方会存在一定的管理成本支出。

2024-10-28 10:00:00 915

原创质量漫谈一

但是随着市场的变化，这些固化下的流程不足以应变当下的环境，测试这边需要聚焦最终可交付的价值产物，而非过程产物，这个时候的测试就需要从单一的职责里面跳出来，往外辐射，对兄弟角色进行赋能，比如产品，比如开发，比如运维。从上面的演变过程中，大家其实可以看出来，测试这个活动一直是有的，但是测试这个职能是后续演变出来的，到后面整个项目型团队组织的演变，让测试更多的是以一种角色的形式而存在，淡化了职能的概念。我个人理解测试这个活动会一直存在的，只是形式会发生变化，而我们需要做的是不断提升自己的能力去适应变化。

2024-10-27 10:00:00 840

原创关于浏览器的小发现

这种模式，可能大家使用后，也会发现，这种模式相比较上一种模式来说，增加了窗口管理的功能，但是窗口多的这个还是没解决，那怎么办呢？就一个窗口，不用开很多tab页，也不担心多tab页tab头挤压不方便查看和查找，也不担忧各种身份session乱串，更不需要在多个窗口中间找来找去，节省了很多上下文切换的成本呢😏，让我们的注意力更聚焦。这种模式下，如果我完成B时，发现信息不对，我需要回退到A时，这个时候我又需要重新输入A地址登录A账号，然后完成A的更新，这种操作模式会非常繁琐，那有没有办法提示一下呢？

2024-10-26 10:06:49 1356

原创从安全事故谈信息透明化的重要性

不论是任务分派与接收，还是上下级信息传达，或者需求/方案评审、日常沟通，我们经常会遇到一方以为自己表达清楚了，实际上他只表达了显性化的那部分内容，和它相关的它没说，但是他希望接受方收到的是他显性化表达的部分 + 他没有说但是他以为对方知道的内容；接收信息的人以为自己听清楚了，实际上他接受的信息和表达方希望的信息是不一致的，这就造成了“误会”。今天早上坐班车的时候，司机师傅在听驾驶安全课程，正好讲到晚上行车时，车主记得打灯，让路上的来往车辆能识别，知道这里有一辆车在行驶，减少事故的发生。

2024-10-25 10:00:00 574

原创项目提测质量不高导致延期何解？

隐藏信息需要显性化，即你以为大家都知道的，其实大家不知道（比如有的人只能看到当前需求点，有的人可以看到需求点背后的影响面）对到以上问题，逐个拆解破局，是事没做到位，那就抓事，定节点，追过程，是人没做到位，那就辅导人，把能力提升上去。- 有方案，但方案很粗，看不出来服务具体逻辑，全靠脑补，但是每个人脑补的结果根据对需求理解的不同，结果也不同。- 任务拆分粒度粗，常见的是按照需求粒度去拆解，但是需求粒度不代表实现粒度，一般实现粒度比需求粒度要细。- 任务工时预估不准，低估需求复杂度，高估自己的处理能力。

2024-10-24 10:00:00 433

原创低代码平台的过去、现在与保障思路

最后，从需求/场景来说，为了保证交付效率，使其在建设过程中就能发挥它的价值，导致它诞生的路径就是为了需求服务的，所以当场景类似时，这部分的价值体现就会很明显，但是当场景差异过大，就需要研发人员赶制。，因为同一个功能，存在不同的实现方案，且有的依托于公司内部的基建，可能跨多个应用，涉及数据同步等隐形问题，这一类的问题基本都是出了问题，影响面大，所以需要特别关注，因为它的风险偏高。随着降本增效如火如荼的推进，不管最终是降本增效，还是降本增笑，过程中还是有一些好的产品形态出来，如低代码平台。

2024-10-23 10:00:00 395

原创场景实练｜直播课程怎么测？

这里说的【明特性】是第一时间需要明确区分出，直播客户端这类的测试和过往的web 系统测试是有差异的，因为直播客户端对硬件资源的依赖会很重，是否会阻塞业务流程及影响直播稳定性，这个要有警觉，不然很容易出现客户事故。而后续的三步走是在第一步认识的基础上，补齐当前的信息，以便于后续我们可以更好的验证。第三步是在前两步获取的信息基础上，按照真实的业务场景去测验，比如主播 A 在直播，游客 B 去观看，看是否有影响及整个回归的过程是否可通过其他手段覆盖，提高验证效率。以上是我最近的想法，共勉。

2024-10-22 10:00:00 372

原创场景实练｜缓存测试关注点

本文会在大家熟知的通用测试方案的基础上，结合笔者最近遇到的一些新场景，主要是多环境下的兼容性问题，补充一些新的关注点。一个项目需要适配不同的环境，有的环境缓存是单节点配置，有的环境是集群配置，可类比web 系统对浏览器的兼容测试，这个就要求工程里面使用的方法必须具有普适性，不然换个环境就没办法运行了。一个项目需要适配不同的环境，有的环境缓存是单节点配置，有的环境是集群配置，可类比web 系统对浏览器的兼容测试，这个就要求工程里面使用的方法必须具有普适性，不然换个环境就没办法运行了。但是巧妇难为无米之炊呀。

2024-10-21 10:00:00 878

原创关于Jmeter聚合报告Aggregate Report的认识偏差

这份聚合报告，相信很多同学都不陌生，单纯看这个结果，相信不同的人对这里average， 90% line， 99% line 指标的理解也会不同？比如这里的 99% line，有的同学会理解成：99% 的接口 RT是这个值，其实并不是的，这里的 99% line指的是 99% 的请求RT 在这个值以内，注意是。剩下的样本至少需要这么长的时间。剩余的样本至少需要这么长的时间。剩余的样本至少需要这么长的时间。- 99%的样本所需时间不超过这个值。剩余的样本至少需要这么长的时间。- 同一标签样本中的最长时间。

2024-10-20 10:00:00 1013

原创 JSONPath，一个事半功倍的查找取数工具

日常在书写用例断言的时候，经常会遇到这样的场景：从结果中提取关键属性用于后续业务或者断言。一般遇到这类情况，处理方式基本都跟剥洋葱一样，遇到数组/集合，一层层循环读取，遇到对象套对象，一层层对象点属性点出来。对于要从复杂的结果里面提取关键数据，要写的解析代码很多，有没有办法精简这种提取操作呢？群众的智慧是强大的，所以结论肯定是有的，而且已经出现很久了，它就是 jmeter 自带的后置处理器之JSON提取器里使用到的库：JSONPath。

2024-10-19 10:00:00 1127

原创 JMeter 动态参数赋值实践

日常接口测试/性能测试使用 jmeter 实现动态参数赋值，常规用法都是配置 csv 文件，然后接口直接从 csv 文件里面去获取，但是这种方式有一个弊端，就是脚本文件迁移的时候，必须一起带上 csv 才行，不然脚本位置变了，里面 csv 的文件路径没有同步更新，脚本执行就会受影响了。但是除去 csv 的方式，尤其是小数据量的情况下，是可以通过用户自定义变量或者用户参数来实现的，接下来使用他们来做演示，看各自不同组合配置产生的结果如何。测试计划 (顺序执行: true)

2024-10-18 10:00:00 2167

原创 JMeter 用户参数控件大对比，让你用的更明白

作为经常使用 jmeter 来做接口测试的人，肯定对各类用户参数元件不陌生，常见的有两大类：一类是依赖外部获取，如 CSV Data Set Config元件；二类是元件自存储的，如用户自定义变量、用户参数。他们都是用来存储和传递变量值的功能组件，但它们在作用范围、初始化时机以及是否动态获取值等方面存在区别。接下来就让我们从「类型」、「位置」、「作用域」、「功能」、「使用场景」、「初始化」、「动态性」来分析比对。用户自定义变量类型：配置元件位置。

2024-10-17 10:00:00 430

原创 JMETER｜压测参数组装的秘密魔法

一个参数值都这么大了，那么整个接口参数化文件肯定不会小。此时大家有没有想过当一个参数化文件大小过大时，对到压测的影响又会是怎样的呢？

2024-10-16 15:18:46 1040

原创注解之好｜一个注解可解万种惆怅

ConditionalOnProperty(prefix = "配置前缀", name = "配置属性", havingValue = "true", matchIfMissing = true)实现方式有很多，比如每一个环境一个应用工程单独维护；又或者把能力拆小，分成多个小应用，独立去部署等。参考：https://springdoc.cn/spring-conditionalonproperty。比如一个多模块的应用，在不同的环境中需要启用的能力不同。这里提供一个通过注解+配置的方式来实现这类效果。

2024-10-15 10:00:00 212

原创降本提效｜基于 JMeter 完成一个 MVP 测试平台搭建

这里设置为 true，就不需要再生成报告，直接拿到 xml 文件，解析请求上下文及结果，自定义展示效果。设置为true时，如果脚本执行没有错误信息，此时 jtl 文件里面除了基础的内容格式外，无其他结果，设置为false，结果可以正常输出到文件。输出由两部分组成：结果和报告；另外实际场景中，肯定是多人使用，所以需要支持批量执行，且一份脚本可以同人同时执行，且报告隔离。runTest()则专注于执行测试的核心逻辑，常被run()内部调用，但在某些定制化的应用场景下，也可能直接被外部调用来执行测试的核心部分。

2024-10-14 10:00:00 359

原创降本提效｜JMeter二方包开发体验

具体步骤：通过创建一个 maven 工程，打包成 jar 包，然后丢到 jmeter 的 lib/ext 目录下，全局访问，这部分就不再重点赘述了，这里重点说下如果这个 jar 包里面依赖了其他包，怎么处理呢？改之前需要 5 步，才能完成，且参数变化后，会发现需要调整的步骤也多；我们优化的方向是希望过程更简练，修改更集中，减少缺漏的概率。，信息更集中，更改更方便，为了使其生效，直接将这里的二方包放在了 jmeter 目录下的 lib/ext 下。一步参数，一步执行，一步断言。

2024-10-13 10:00:00 281

原创降本提效｜JMeter插件二开完成 100-10-1 脚本的优化体验

但是这样也带来了大量的维护量，比如现有 1 个应用含 10 个接口，需要部署到 10 个环境中去，后续服务每新增了一个接口，这 10 个环境10 份脚本都需要完善，做的都是重复性工作，每天疲于奔波其中，也没啥成就感。背景是这样的，针对底层通用服务，比如文件服务、文档服务等，同一份代码，会部署到不同的云岛(本地化)环境中去，提供的服务是统一的，基于不同环境配置参数的不同走不同的执行路径。目标行提取出来后，需要和脚本执行路径契合，不存在提取出来第三行的参数，结果执行的时候依然走的是第一行的参数(按照顺序执行)

2024-10-12 10:15:00 1380

“ 把自己活成一道光，因为你不知道，谁会借着你的光，走出黑暗。”