• 前端点击某个按钮提交请求,F12 看接口一直没有响应,这个通过查日志是可以找到问题的,但是你说开发查日志查不出结果就尴尬了:
    1、你们是微服务吗?如果是微服务,这个流程可能涉及多个服务调用,有没有可能是日志排查方向错了;
    2、接口没有响应多半是接口代码报错,比如空指针,项目日志打印级别调整一下,再不行 log.info 隔几行打印一次;
    3、接口没有响应还有种可能就是,代码不报错,但是这个操作涉及大量的数据导致一直在处理,或者数据库表出现死锁;
    4、项目方面没有问题,那就是服务器资源问题了;
    这种问题可以针对出现未响应按钮接口,用 jmeter 压测,这个压测不要一上来就大批量,可以呈阶梯式增加,一定会在某个阈值出现这个问题的


  • 讯飞的这篇文章可能会给你提供思路

  • 1、整个测试团队除了产品了解整个项目流程,就只有测试了,平时工作中不能埋头工作,还要利用点时间学习需求分析、市场调研、竞品分析怎么弄,学会 Axure 原型工具的使用,所以测试转产品也是一个很好的备选。产品我个人觉得只要你对这个系统的规划和把控能力强,比测试吃香。我们部门刚招的一个产品 82 年的,早就过了 35 岁的坎;
    2、在平时项目开发过程中,其实测试对项目进度起着关键的作用,稍微上进心能力强点,性格开放点的,我觉得考个 PMP 转 PMO 岗位也是很不错的,我们部门招的 PMO 岗位 79 年的

  • 如果你有驾照,驾驶经验还可以,可以搞代驾;
    如果你有驾照还有车,可以跑滴滴;
    如果你既没有驾照又没有车,但是有个小电驴,可以跑外卖;
    如果你既没有驾照又没有车还没有小电驴,但是有个手艺啃吃苦可以摆摊;
    如果你既没有驾照又没有车还没有小电驴还没有手艺,但是你有好的脸蛋和身材,可以搞短视频搞流量;
    如果你既没有驾照又没有车还没有小电驴还没有手艺还没有好的身材和脸蛋还又不肯吃苦,但是你有个局长老爸,可以躺平;
    如果你既没有驾照又没有车还没有小电驴还没有手艺还没有好的身材和脸蛋还又不肯吃苦还不能啃老,那就提前回家养老,种点小菜园自给自足,记住千万不要提前过渡消费!


  • 我们目前还是操作本地编写用例,导入系统。最终的目标就是方便领导,就是领导想看测试组某段时间归档了什么用例,进入系统看就可以了;再就是测试组做做月度统计时候,提供了一些数据支撑


  • 左右结构,左侧选择项目系统,在左侧按照系统功能模块建立分级,可以细分到按钮,鼠标几点左侧点击,在右侧操作用例,这样用例和模块、用例都绑定了

  • 1、目前在使用过程中,一个用例经历了长达 3 年的版本迭代更新,用例分支很多,采用一次性加载,导致每次打开有点慢,不知道针对这个问题大佬是怎么处理的呢?

    为了减缓这个问题,我在点开用例脑图详情时候,增加了一个弹窗,并且给出按照用例 或者按照节点,如果是按照用例则展示整个用例的脑图,可能用例内容多会慢,但是给出了提示语,让用户有个心理预期;按照节点就是,我们用例第三级别基本都是功能点,你可以选择只打开,某个功能点的用例脑图,这样就减少脑图数据的展示了;

    2、目前我们没有实现在线协同的功能,最理想的情况是我希望能实现腾讯文档那种在线协同编辑的功能,但是人家鹅厂一个团队弄的事情,我们一个小小的测试开发投入成本相当大,并且很多技术问题不能得到保证,比如突然服务挂了 断电了用例编写的是否能自动保存,总不能测试人员辛苦写的用例就因为你系统的问题,

  • 技术很强,30K 么得问题,不像我 30 岁了还只会点点点

  • 往往这种人更难相处,估计也是个小组长之类的,这种平时工作中就很难相处了

  • 那位已经注销账号的 “面试官” 说了一堆,无非就是两个方面:1、用例设计的粒度问题,就是我们在设计用例时候要能把握好这个粒度,这个粒度是能够可以执行或者评估的,不能够直接说检查某个功能是否正常,要细分到具体的正常元素;2、我们点工通常是针对界面去操作和设计用例,比如说一个输入框的校验,可能前端校验了,后端接口没有校验,这种情况如果我绕开前端直接通过接口调用可以规避这个限制,针对前后端校验的问题,如果条件允许情况下可以单独使用 postman 等工具调用后端接口,不过这个比较花费时间,我平时都是直接拉去项目代码找到这个调用的接口的 controller,看下代码中有没有这种校验逻辑,一般来讲这种校验逻辑放在最开头的地方实现,可以把利用 AI 工具 输入需求进行检查,这样甚至还可以发现这个接口的一些隐藏的 BUG
    最后我还想补充一点: 前面说的 1 和 2 是针对功能界面 和接口,其实还有就是最好在测试的过程中,跑完一条流程,去看下这个功能涉及到表的数据存储记录是否正常,表设计是否合理。我就遇到过 BUG,就是表的主键 id int 类型长度设置的比较短,然后这个业务量又是巨量增长的,随着时间推移以后这个主键 id 一定会超过限制报错,后面提了 BUG 改数据类型
    最后还想再补充一点,论坛是个交流的地方,大家都是相互学习,论坛里面有大佬也有小白,也许你的经历很丰富,你觉得人家回答的不好,你补充就行了,不想回答绕过就可以了,没有必要去诋毁,真的是没有必要。

  • 4 年多经验,何去何从 at November 21, 2024

    只能说羡慕 20+,做梦都不敢想

  • 如果有冲突还是还要找开发

  • 要的就是这种效果

  • 是的

  • 你写到的是追踪到了代码有抛异常,还有一种 BUG 是业务流程上的 BUG,就是代码没有报错,但是某一个数据的处理逻辑有问题,比如有个地方原本需求是 A B 两个字段相加,结果开发是 B C 两个字段相加,导致计算结果出错,这种能追踪到吗?

  • 可以借助精准测试,看看哪些模块的代码有改动,重点回归改动的功能模块 和 使用到这些改动模块的流程;如果这个达不到的话,只能增加人力 + 请外包

  • 如果公司能混到养老就继续混,前提是公司不管什么岗位的氛围都还可以,但是如果说整个公司的文化不行,你对你现在的岗位不喜欢,你就算转岗还是坑

  • 1、我点小疑问,站在测试的角度什么情况下需要去在 nginx 层面实施 mock?比如现在提测了某个功能,这个功能前端操作后会调用 A 服务,A 服务会和 B 服务的某个接口获取拿数据然后处理后返回给前端,如果此时说因为 B 服务没有开发完,需要测试去 mockB 服务的接口给前端,此时流程就基本没有跑通,就是算你现在使用 mock 数据把当前流程验证完了,等 B 服务开发完成了,最后你还是要重新把全部流程跑一边,浪费时间;
    2、从项目管理风险角度讲,在人力资源充足的情况下,遇到 1 中的情况,测试提早介入能提前发现问题,这个是好事情。这种情况我通常是把项目代码拉到本地,在本地运行进行白盒走查,构造前端 API 请求然后再本地惊醒 debug 断点,本地断点的话你想要什么模拟数据可以设置,最后检查 API 返回的数据;
    写在最后: 目前还没有搞过在 nginx 层面实施 mock 1、还不如直接点点点 2、浸入式的东西不能把控有什么风险,项目经理也不会同意你这么搞
    如果后续研究到好的方案,请大佬分享一下,谢谢

  • 有些厂试用期 6 个月

  • 一个恒温 一个小黑子,你们可是我崇拜的偶像,很喜欢看你们说教,讲的都是肺腑之言,谁敢造次

  • 没有什么所谓的 “大佬”,只有适合岗位要求才是最好。
    古语云:“顺势而为”,选对赛道才是最重要的,把握住了风口,猪都能飞起来。一个公司赛道处于衰退阶段,哪怕你技术再牛逼,还是逃不过市场经济不好,难逃被裁员,相反一个公司赛道属于热门,公司盈利了,你才有苟活下去机会,你学习的所谓技术才能有用武之地。
    在赛道的基础上深耕业务,业务才是安身之根源,只有业务了解透彻,如果走技术路线,你才能在业务中发现痛点解决痛点,在解决过程中你会发点有很多不会的技术,然后想方设法去解决,技术慢慢就掌握了;如果你非技术路线,业务了解透彻了,你才能比产品更懂业务,此时哪怕你是个点工,也可以在公司混的很好,不比干技术差

  • 1、学会使用组件,但是组件是能给你提供大的框架,好处在于你不用从 0 开始,哪些路由拦截等一些都使用现成;
    2、不是说用了组件就不用管理前端三件套了 JS、CSS、HTML 还是要掌握,遇到一些有个性的需求还得自己去实现;
    3、前端 3 件套是基础,遇到一些比较新的组件还用的 TS ES6 语法呢,前端也是很卷的
    这个列表自动合并单元格,我当时就搞了半天,我们用例使用 xmind 写的,层级每个人好不固定,每个节点层级是一列,还要根据 xmind 的节点层级自动生成列,把相同父级节点的列合并单元格,当时弄死我了.

    哎~ 不说了,刚才为了截图演示无意之中发现个 BUG,列表上部的用例信息返回为空
    顺便把 BUG 原因说下,当这个模块只有一个用例,就是说还没有迭代的时候,是关联不出其他版本的用例的,是 NULL,如果强制为 0 查询会导致查询不出数据,要将兼容

  • 1、不能因为在 BOSS 上看到性能测试待遇高就要去培训,才工作 1 年半,先给自己规划好职业路线;
    2、性能测试不是一蹴而就,需要积累,不是简单的找个工具 jmeter loadrunner 之类的工具压抑一下,看下报告指标,然后报告显示指标高了,直接提 BUG 给开发,不是这样的。站在产品或者高层角度对性能要求就是反映时间,但是你要基于现有项目架构去做方案,比如说中途经过了什么中间件,比如 MQ Redis,网关转发等,还有服务器配置,Linux 命令是否熟悉,遇到性能瓶颈知道怎么去排查,搞不懂项目架构和服务器真的没法搞;
    3、如果没有学习思路,培训班也是不错的途径,但是要注意甄别,还有就是你不要指望培训班能教你什么核心的东西,无非就是工具的介绍和使用,各种性能指标的定义,简单的内存 I/O 监控命令,我看 XX 机构宣传图上海写了 jemter + XX 东西性能报告在线展示。但是这些说实话买本书 + 百度就基本会了,接下来项目架构就要你要多和开发请教学习,实在不行把项目拉取到本地,自己弄个虚拟机服务器试着把项目部署跑起来,比如 nginx 的配置 内存的分配 mysql 部署等等,这些都是可以的
    4、还有啊,并不是说一定要做性能测试 薪资才能上到 20K,做功能测试,点点点,只要手速够快,上 20K 还是很轻松的

  • 有点意思,先点个赞再说

  • 你是什么学历啊,现在深圳 12K 左右的都很难找么,这么卷