多谢大佬，也有考虑过分开，可是发现分开后流程可写，规范却难以脱离流程分开说明，所以现在基本是按照流程阶段划分节点，在流程说明的基础上添加各节点规范，在讲解流程内容的同时给予标准

主要做数据服务的，关注点在交付环节，所以不关注线上场景，此处也不做过多扩展。公司是类敏捷开发，半吊子的那种，考虑现实情况也不选择对其作出建议，只做测试范围及对接前后环节的分享

当外行掌握了你的岗位生死，你该如何抉择

测试目标是数据库本身或者说是数据库内核测试，不是做数据库校验测试

有测试的发下吧

看大佬说的就晕了，没接触过，溜了溜了

这个 bug 留给产品宣讲吧

还是等 m3 吧

不懂就问：分布式部署时脚本设置线程组或者说压力是预设值 * 压测机个数吗？

钱再多些好了

加油，今年确实太难了，这个期望也可以看看周边城市的 JD

打卡 28

你是不是使用方式上有差错啊，将多个查询接口都进行异步调用的话不就实现并发了吗，你没达到并发的场景是怎样的

打卡 27

除了上述所说方法外，还可以在捕获到未登录的异常时进行一次登录接口调用

没深入了解，浅谈下楼主的场景：同时查询场景下多线程相比较异步是更佳的选择，我理解的异步的适用场景是异步接口调用或者接口处理时间较长的情况下，以异步的方式来避免此接口对整体流程的阻塞

打卡 26

打卡 25 号

静候破解，我的企业微信需要他！

DAKAZHOUYI

造数，监控，性能等

打卡周日

打卡周六

打卡 21 号

马叉虫