• 现在有 AI,除了这些:
    1、熟练掌握黑盒测试 、白盒测试 、自动化测试技术,擅长运用等价类划分 、边界值分析等方法设计精准测试用例。
    2、会 Fiddler 抓包,会使用 Postman、JMeter 执行接口测试 ,并用 JMeter 进行基本的压测。
    3、熟悉软件测试全流程,从需求分析到缺陷跟踪闭环管理,具备软件测试技术实训项目经验能高效定位软件缺陷,保障系统功能稳定性与可靠性。
    4、会 AirtestIDEA 自动化工具,熟练使用禅道管理系统,jira 缺陷管理工具。
    其他的 AI 都能指导你一步步完成,以前没有 AI 时,你写的技能有很多东西确实不错,如果刚入行,还是从测试最核心的业务方向发力吧。

  • 大部分 web3 发币、对私转账是基操,要小心鉴别,别被免费当苦力,最后拿不到钱

  • 如果想了解清楚业务接口调用链路(比如:有些接口调用日志会有内部接口请求,内部接口是做什么的为什么需要这个,就需要去看执行的 sql 了),做全链路接口自动化,sql 是必会的,脚本会涉及到 sql 读写

  • 测试 BUG 究竟要怎么提? at September 08, 2025

    那标题不能超过 25 个字要保证开发能通过标题看懂什么问题,BUG 详情:前置条件、操作步骤、实际结果、预期结果必填,后端问题必须附接口请求、响应信息和日志文件,前端问题必须附 url 和截图这种怎么说😂

  • Author only
  • 现在的大环境下,专职做效能是最先被赶走的,我自己的经历:
    2017 年入行是专职业务测试。2019 年开始接触效能平台、自动化平台效能与业务比例差不多 2:8,在同一个公司完整上完一个合同周期的班。2021 年年初跳槽专职效能平台和工具开发,2022 年年初几个专职测开的人过完年就被干掉了。现在的公司业务测试占比 90%。以前做专职效能平台的同事,后面的新公司又被干掉了。

  • 先了解接口的结构、工作原理、状态码,再结合业务看一个完整的业务流接口调用步骤和接口关联关系,学好 SQL 语法

  • 不能只做效能,只做效能那淘汰率高的离谱,测试开发的核心还是以技术手段做好软件的业务测试,其他公司我不知道,我待过的公司常见的比例是 3:7 或者 4:6,工作量还是以业务测试为重心

  • 以前经常出技术干货的人都在大厂吃 AI 红利呢,哪有时间写文章。
    近几年失业的人太多了,首选并且更容易转行的就是搞培训。
    各大论坛以前要花钱请写手,需要丰富论坛知识和范围,现在有了 AI,从成本因素考量,简单的知识 AI 生成,不用花钱请写手了,只有精选知识还需要人手写。

  • 猜测可能原因:
    1、有比你年轻、便宜的人;
    2、有比你更好用、更专业、薪资跟你差不多的人;
    3、有比你更卷的同行,最低 996 强度的加班;
    4、甲方自己都快没分包项目给外包做了,提前开源节流;
    5、你的外包公司与甲方合作不愉快,存在争议和纠纷,甲方做出相应的调整;

  • 外包进行第二个项目 at September 02, 2025

    很多垃圾外包公司都是这德行,外包岗还天天义务加班一小时,最后一个下班,这个真没必要,拿多少钱干多少活就行。但是有比较强点的外包公司,加班至少算调休,周末不强制加班,就是到手工资没多少。下份工作注意甄别,过了 3 个月试用期就赶人,估计下份工作不好找,得找个信服的理由跟下家公司解释

  • 我们是部署了 3 台 211-Master,便宜好用,自思考模式比市面上最强大 AI 还要更像人的思维😂

  • 抱好原组长的大腿,自然会告诉你怎么做

  • 😂 测试组内复盘什么?写了多少用例?花了多少测试时间?提了多少问题?然后闭门造车似的决定后面版本怎么测试?
    测试复盘针对的是整个项目组,针对本次版本的问题进行讨论,结合历史版本进行比较,哪些有改进、哪些无改进、哪些是新问题,并对出现的高频问题、顽固问题、历史问题,和整个项目组一起讨论解决方案,在下版本我们要做到什么目标,同样下个版本发布后再做一次复盘,确定之前的方案哪些可行、哪些不可行,一次一次的修复改进,最终的方案成为项目组迭代规范存档。

  • 好资源、好项目、好技术都像真实下属倾斜,名义上的下属自己想参与,那主动过来找我,不主动过来的不想配合的就顺其自然,给一些边边角角的杂活扔一边自己玩去,只要保证项目正常发版就行,擦屁股的活比教育他容易多了,这个是没有淘汰制的公司的无赖做法。有末尾淘汰制的公司就好办多了,直接找数据,或者找理由让他绩效最低就行,我从来不做热脸贴名义下属的冷屁股超过 3 次的事情。不过偶尔还是会暗示:想成长、延长职业生涯就跟着我一起搞事情,不想的话就在那摆烂等 SI。名义下属毕竟是少数,招人的时候第一关面试的是你,又不是你的领导,只能怪自己识人不清,吃一堑长一智。

  • 可能是 Random 出来的😅 ,我还寻思着搜 ITP 是什么工具,合着是作者自研的平台,现在市面上的同质化平台太多,还是挺佩服作者的这份坚持,不知道作者有没有在本公司落地?有没有参考数据?没有实际数据支撑,没经过市场检验的平台还是持谨慎态度,并且还没开源

  • 深入了解新能源储能的业务和生态,学好 java、python,再就是等储能概念爆发,抓住机会进大厂

  • 仅用 AI 成本是 10 元,有效解决 AI 幻觉成本 90 元😅 ,砸钱买企业级服务器,私有化部署满血版大模型,做模型微调,做企业级知识库,自己训练模型

  • 快 50 了

  • 看样例,这是把下一步想到的所有可能的异常都列出来,看执行这一步会不会命中预置的异常?感觉有点穷尽测试了,怎么确保预置的异常能够覆盖所有异常操作?

  • 一年测试经验就不要写具体的量化的指标,一年能有多少经验?量化指标结合你的 1 年工作经验,可能我会觉得一眼假,1 年经验就说你做这个的起因,怎么实现的,用了什么技术就行,搞这些量化指标随便追问下你就懵了

  • 为什么要做这个?解决了业务中什么问题?相对于传统的 xpath 定位,采用 AI 准确率提升了多少?落地效果怎样?

  • 社招测试一点困惑 at August 26, 2025

    赞同,想做测试还是得重回业务组,除非转开发。测试的核心是业务,技术是为业务服务的,测试开发这个角色被大多数人曲解,都认为做质量监控平台、自动化平台、工具开发平台才是测试开发,业务的基础上做工具是测试工程师

  • 对的,很多因素都会影响测试的时间,所以第 4 点就会有一个区间范围为 4 天的高风险

  • 嗯嗯,大多数情况下都是开发一周测试 3 天,上线 1 天,刚好 2 周一个版本,估算测试工时,其实就是给上面人看测试工作量,为什么需要这么多天,然后反向推开发的提测时间。