可能我背景解释说的不清晰。整理的一个目的不是为了开发自测，而是项目人员进行测试阶段的设计和执行工作。我也清楚开发做测试时的实际情况，但是为了降低项目对测试的依赖，只能用测试基础知识普及的方式来提高开发人员的测试意识，对文档的实际作用也有一定的向下预期。
文档更大的目标还是在测试流程的规范说明，为公司测试人员 (为 kpi) 提供一个具体依据，也是对自己的一次锻炼

应付类会议主要是给上面看的，陪听的不放飞也没啥事。评审类的如果还放飞的话，大多是内容与自己无关

多谢大佬
约束主要就想到了需求分析和开发转测时的标准要求，但是因公司研发环境问题又难以实际落地，后面考虑还是加入具体的节点流程要求。
大佬还有没有其他节点的约束分享

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

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

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

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

有测试的发下吧

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

这个 bug 留给产品宣讲吧

还是等 m3 吧

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

钱再多些好了

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

打卡 28

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

打卡 27

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

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

打卡 26

打卡 25 号

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

DAKAZHOUYI

造数，监控，性能等

打卡周日