https://blog.csdn.net/sxww_zyt/article/details/129487582 ，看这个

试用了一遍很牛逼，结果符合预期。想试试放 flask 项目中，页面传参，方便推广到组里。逛逛论坛找到宝藏了

没有绝对标准，但一定要说的话应该是游戏了

我看有不少游戏公司，楼主是游戏方向的测试？没接触过游戏测试去这方向好转吗，可以简单介绍下游戏测试的技术和应用吗？

很好奇那个 3 选 2 的是什么岗位

楼主有答案了提点一下我，刚领导丢给我一份《测试用例自动生成.pdf》给我让我关注调研下，打开里面几张截图糊的根本看不清也放大不了，反正今年必须有个像样的东西落地了，汗流浃背 ing

很不幸关于文中提到的三种需求情况都遇到过。更离谱的产品直接复制邮件需求后让开发自行设计，最后和开发商量了一下怎么改动，测完后产品过来找我了解需求

当下的任务只有一个：成长。哪怕每周进步一点点，也比没有进步强一万倍。对绝大多数普通人来说，这几乎是唯一靠谱的方法论了。

下午请假去看了

牙确实越来越不好，一直拖着没去看看。痛起来是真的要命，基本啥也干不了。

是在本地工作吗，能要二宝基础比较稳定吧

到底是环境问题导致失败还是平台不行导致。如果平台稳定性就是差，自身存在问题，就直接上报需要考虑其他解决方案。如果项目自身的问题那就具体分析到底哪些问题导致的。
像你说的用于发版前执行怎么还会因为开发改动导致失败，这样流程中肯定有问题。
如果是脚本误报多，可以考虑优化一下测试脚本，断言优化、等待机制、元素处理这些。或者给脚本瘦瘦身，只做最核心的链路那些，也能减少点负担。
如果说网不好经常失败，测试组要去协调稳定的网络，根据具体场景做调整和优化。

没有人喜欢自己的方案被否，自己冲上去当黑脸也不好。楼主可以整理一下现阶段的问题，写一些解决方案提上去看看领导的反应。有个自动化，述职的时候也能给你刷数据不是

没有订制，现在统一校验 status_code >= 500 就失败。例如，如果接口期望一个字符串，会发送一个整数，空值等，以查看 API 如何响应。只要不报服务异常就通过，主打一个粗暴所以不进行任何业务逻辑校验，通过这里再进行后续的功能测试。

确实叫模糊测试可能更准确吧。这几天刚开始搞，目前发现 Schemathesis 这个库能满足期望，会为你生成各种输入进行测试。至于跑出来的结果校验，我目前只能 status_code != 500，暂时想不到更好的办法。接口业务逻辑的冒烟和回归就还是靠接口自动化用例去覆盖。

是的，这种随机异常参数组合只能验证下接口健壮性，所以我这冒烟就是保证提测的接口初步可用。业务逻辑还是需要自动化针对设计用例。

很受用的参考。第二种可以作为后期目标研究研究。目前第一种作为能力范围内能尽快出结果，年底前也算个绩效

平台任务自动分配出现死锁

有没有实现的项目可供参考一下

杭州关键词：996 之都、双休犯法、互联网卷王