友情提示,fiddler 自己学倒是没啥,公司或者企业使用有可能被发律师函~
供参考哈,仅个人思路。
下架报异常导致的下架失败,是真失败还是假失败,这条数据还展示的 c 端商品列表,是应该展示,还是不应该展示。
如果下架接口报异常,但是实际是成功的,比如数据库状态发生变更等,理论上 c 端商品列表不应该展示,那就结合代码或者开发人员去定位问题,此时应该要去定位三个问题,a.下架接口报异常的问题 b.下架接口报异常,但是却成功下架的问题 c.下架接口报异常,但是成功下架,C 端商品列表还展示的问题
如果下架接口报异常,实际也是失败的,这条数据应该展示在 c 端商品列表,那么就需要看下架接口为什么报异常。是环境问题还是需要定位的缺陷
从得到的信息看,是接口自动化测试,那么以上场景应该划分到下架接口,还是展示的 c 端商品列表接口(比如下架失败,展示商品列表接口的用例),应该有明确的规范,避免用例重复覆盖。
另外,这条用例失败后,会不会影响自动化测试稳定性,自动化到这里就不再执行了,还是说就是普通的一个用例失败,也是需要考虑的。
自动化测试用例,很多时候因为各种原因,不会覆盖异常、失败的场景,此时是否需要把这些场景支持或者用手工测试覆盖,也是需要考虑的。
研也匆匆 测也匆匆 恨不能想疯
改也匆匆 上也匆匆 一切都随风
狂测一轮 延期一轮 快上一轮
背锅一轮 谁与我生死与共
有,如果看不了代码,会给工作增加很多困扰和不确定性
窮
只要不被裁,蒙着眼走
一杯茶的功夫,你就被优化了
没管理者乱来谁愿意搞这些鬼名堂
有目标有行动的苟着
最大的作用是代替了以前需要查的工具书。
AI agent 基本都长这样
个人觉得还是有必要的。
新入行的有个系统的认知。
老家伙可以对自己的知识结构进行一定梳理。
主要是钱不多也不难
AI 写的用例可以帮你做出好看的数据,比如领导 PPT 上 XX% 的用例已经用 AI 编写,反正他们又不看用例质量的。
具体实际效果如人饮水,冷暖自知。叫得越凶的,往往是离一线越远的。
以下是问的 AI,我觉得没啥毛病(学习内容可能少了点,毕竟安全什么都要懂)。
学习安全测试是一个系统的过程,以下是一个为期三个月的学习计划,可根据个人情况进行调整:
了解安全测试概念
学习基础网络知识
掌握操作系统基础
学习常用安全测试工具
进行静态和动态分析
学习渗透测试基础
进行模拟测试
参与线上 CTF(Capture The Flag)竞赛
总结与复习
希望这个学习计划对你有所帮助!如需进一步细化某部分内容,请告诉我。
除了 tesseract、PaddleOCR、EasyOCR 等,还可以直接调用 LLM~
先搞清楚测试目的,测试范围、测试场景(负载?容量?疲劳?or 其他)、业务指标等
确定这些才能弄清楚有几个事物,然后放到事物控制器下。
至于线程组,一般根据你测试需求来,比如你对同一个事物做负载测试和疲劳测试,参数肯定是不一样的,就弄多个线程。
类似以下格式:
/线程 1_负载/事物查看首页/news 请求
/线程 2疲劳/事物_查看首页/news 请求
银证转账都给干异常了。。。可怕
呔!倒反天罡,反问是你来面试我的吗,you out!
其实很多技术面试官并不是管理者,这么问有些时候不是很适合。
学到了学到了,真·干货
赚钱么,不寒碜。行业如果领域知识门槛高,你自己写挺好的。
做点自己喜欢的,热爱的并花大量时间在上面
一个月强制改一次密码且不能与历史一样才叫痛苦,逼我在密码里加了时间戳
我来说点我实际工作中的:
无论功能大小,能不写测试用例就不写。
测试用例一般没时间严格和完整的执行。
长期的项目,测试用例也没有持续维护。
压根儿不使用版本控制软件对测试用例进行版本控制。
一切为了统计需要。
测试点列列就差不多了,规则穿肠过,用例心中留。
能录制就不代码,能代码就不再写一遍用例。
根据优先级和风险应对紧急发布。
承包地之后,从打工人变成给自己打工了,我觉得只要不想着赚大钱,还是不会像现在这么焦虑