那不是有 n 种方法，仅一次控制器，if 控制器，或者 2 个线程池一个跑前面 5 个接口一个压后面接口，只有你想不到的姿势没有实现不了的姿势

上市之后加班扩招工资倒挂

写好用例，做好用例评审，等上了线万一有问题大家一起背锅

寓教于乐
https://github.com/juice-shop/juice-shop

测试框架 + jupyter，直接在 ide 上写，jupyter 上跑完事，产品研发测试都可用

那么多开源的弄一个用起来不就完事了，metersphere 都不会，那就用 postman、apifox，安装软件你总会吧？

不喜欢引用就用代码咯，只是个样式问题，或者写个油猴替换样式

嗑药、头悬梁锥刺股、督战队、洗脑喊口号 “提高个人能动性，带动他人积极性”

VirtualXposed

道理大家都懂，给点实战案例、用例模板

看起来是三方提供的授信接口，直接自己 mock，做好异常场景有多离谱的返回都可以，线上只会更离谱

arthas 确实是神器，用火焰图也可以很方便的找到问题

你确定是接口没问题 UI 有问题？这种项目一般都比较垃圾，内部系统 UI 还要处理数据？
我觉着如果是上面这种情况，你应该考虑下给研发提改进需求

TDD 只是个思维模式没啥适不适合的说法，只有推不推的动，要是有不换思想就换人的能耐，啥都合适

卧槽，这也是一种本事
还是乘早跑路，你一个人肯定干不过他的，除非你能拉动其他人一起搞他，不然无解

只用 httprunner 本身提供的功能，那测试平台的缺点他都有，用例结构固定不灵活所以做不了复杂的逻辑判断也就做不了复杂的测试场景。
但是要是二开 httprunner，学习它的模型结构就能和 pytest 互相取长补短，而且 httprunner 提供了非常多现成的工具用

这种分开，先找瓶和盒之间异常，再找盒和箱之间异常，挺不错的题，只能说现实场景比这个复杂得多。
这种异常就可以拿来做告警，有了告警再去反查日志。

测试开发很简单的，只用做到比后端懂前端，比前端懂后端，比开发懂运维，比运维懂代码就够了，遇到啥学啥就对了

airtest 直接 xy 轴定位然后图像识别，大力出奇迹

这种写着玩还可以，复杂的业务场景根本维护不了，还是不要造轮子，用现成的轮子不香吗。
改造下 httprunner 就可以用的很爽

现在不都直接甩给 gpt 吗，三方对接花一天，扔给 gpt 翻译成 python 30 分钟调试完

session: scoped_session = g.hr_db_session
那就定义变量类型

根据实际业务场景来判断啊，有需求成本合适值得做就可以做，比如 openapi、协议开发那测得就是这些玩意肯定得做。
管理用例最好用的肯定是 pycharm

最好写深入一点，都是些水贴

我们公司测试不光看，还在阿里云平台上开发告警规则，配置各种配置。
那你该想想为啥你没权限看