• 这文章有 AI 自动生成的那味了。

  • 接口抓包,直接调接口不是更省事,前提是你们的 APP 安全性得不算太高。

  • 可以单独弄一个文件,里面写一些通用的 SQL,每条 SQL 或者多条 SQL 打上标识,在其他的数据文件通过标识引用这些通用的内容。

  • 中年人的出路在哪里 at March 29, 2023

    还有时间来焦虑,说明你还是很闲。没有非常忙的工作,也没有女朋友家庭孩子啥的,趁着有时间,多去学习一些自己感兴趣的东西,或者完整系统的学习下测试相关的知识。
    把时间花在提升自己上,你就不会那么焦虑了。
    真正焦虑的是哪些工作忙的很,然后家庭事也一堆,个人时间也没有的真正的中年人。

  • 我觉得选择去外包还是继续找工作,决定在于你是否有一定的经济压力。就算先找一份外包慢慢干,再去找其他工作也未尝不可。
    切记不要眼高手低,先牢固自己的技术能力最重要。

  • 我怎么感觉你这个回答像是 chatgpt 的口吻

  • App 测试的啥文档都没么?

  • 后端屏蔽微信接口就行了。
    如果你们的业务逻辑完全都是调的微信接口(就是纯粹的转发接口),那我觉得其实压测意义不大。

  • 小白入职记 1 at February 27, 2023

    mentor - 导师 ,Jira - 相当于禅道,提 BUG 的,Scrum - 项目管理平台。
    变成英文咋就成高端的呢?

  • 现在讨论这个没有意义。到时候自有解决的方法。

  • 浅谈业务型测试开发 at February 22, 2023

    但是不否认的,如果一开始开发技术都很过关,你觉得你是会选择直接走开发这条路还是走测试开发这条路吗?
    虽然,真的有一些测试开发的水平和薪资是高过开发的,但是这些都是少数,同样工作年限,同样学习能力,同样的努力付出,我相信一定是开发路线会走的更好(我这里单指薪资待遇,毕竟干啥谁都不是为了那点钱呢?)。
    我面试过很多学过开发或者有点开发技术的人,他们给我的回答就是觉得自己面不过开发觉得测试门槛低,先先从测试入手。
    我知道,工作没有高低之分,但是每份工作对应的那份薪水一定有高低之分。我所有的选择都是为一点碎银罢了,那个能赚钱我就愿意干哪个。

  • 浅谈业务型测试开发 at February 21, 2023

    如果纯做工具开发,那就是纯开发了。这样的人,如果开发能力足够强,他其实没必要干啥测试开发,直接走专业的开发路线不是发展更好?
    所以所谓的纯工具的测试开发其实就是那些之前干测试的后来学了点开发技术又不想继续干测试的人。但是和纯开发卷又卷不过,只能捣鼓些所谓测试平台。

  • JAVA 熟练之后,上手 Python 真的很容易,认真去 B 站找个视频从头开始看完之后,就可以开干了。
    当你会了两门语言之后,在解决问题的选择上会更多。觉得哪种语言更适合解决当下的问题就用哪种吧。没必要纠结什么自己的主力开发语言,毕竟我们不是开发,语言只是工具,能快速有效率的解决问题才是关键。

  • 这个只要做过 UI 自动化的不是基本常识吗?

  • 这个不单单是测试的活吧,网络,运维,开发,测试,安全都得参与吧。
    这样的专家就不是测试技术专家了,而是架构师级别的。

  • 这是团队能拿到的吧?
    单论这个岗位职责和要求,看不出来哪里值 150W!

  • 需要考虑需求的测试难度?用例的执行难度吗?

  • 社区不是实名了吗?谁敢乱搞直接报警处理。

  • 还是直接跑吧。跑之前让公司补上之前降薪导致少发的工资,如果不发并且钱很多就起诉吧,钱少就算了吧。

  • 到底是干摄影的还是干测试啊?

  • 人力成本降低 90%,那我想问,开去的另外 9 个人的工资都给你朋友了吗?如果没有,那他这么做的意义何在?

  • 直接去数据库查询,一两条 SQL 不就搞定么?

  • 我大概明白楼主的意思 ,大概就是开发那边没有专门的需求分析人员,开发人员不想自己看需求文档开发,所以就直接对照测试的用例来开发了,等于你们测试给开发做了前期的需求分析工作呗。

  • 我觉得 8/9 楼这个说的很正确,怎么降低上手门槛,让不同类型的测试人员,包括开发人员都能够去使用它,比如功能测试人员可能技术能力较弱,人家可能会先从数据库查询一批数据,然后通过文件导入这种方式,自动化测试人员可能会使用 SQL 语句去查询,性能测试人员可能会使用模板造数(因为需要大量数据),开发人员可能就直接写 jar 包或者写脚本了。所以在构造数据这块,要提供尽可能多的方式以对应不同类型的使用者。这样对平台的推广比较重要。
    另外就是与功能测试,自动化测试,性能测试,开发调试要更加无缝的集成使用,无需其他繁琐的操作就能享受造数工厂提供的能力,比如自动化脚本不管是平台化还是没有平台化,都能通过简单的方式接入造数工厂,开发在自己的单元用例中,是否可以通过引入你们提供的 SDK 快速接入造数工厂,这块都可以研究下。

  • 这个逻辑方面我确实没有考虑到,可能但是更多的是希望在脚本里面对数据进行精细的处理,其他类似数据库查询,接口查询等只是抓取数据的方式,最后加工出来的数据是符合数据池数据结构的还是想依靠脚本去处理的。