还在维护的，已更新二维码

线下大会，暂无线上入口，MTSC 大会今年开始，调整为 1 天

有的
，我找他们更新个

高产博主

没有发现兑换记录呀，之前是 7 月份的，那个要在公众号回复下，那个是异步的会员，现在过期了

这个周未刚发出 注意查收~

加油

这个她是谁，要先确认好。
如果你们同属一个上级，直接找上级就可以了，直接确认录制任务是如何安排的。
非同一个上级，其无职取进行工作安排

每天强制自己想办法将自己手头的测试的内容做自动化处理。前期可以不用管是否合理，就是强制想办法转自动化方式。
逼迫自己去查找和学习如何自动化，这样最快速了
当然要先确定一个技术，然后不停的尝试就好了

https://testerhome.com/topics/34956

觉着多个方面考虑吧，一方面是公司对于用人诉求可能模糊，另一方面可能找工作的同学不再看岗位匹配度，全量海投。

对所谓脏数据进行追述分析吧，确认下不可用的原因是什么，在不同的功能段，使用的同一条数据链里的数据不太一样，所以是有可能存在某段功能可用，某段功能不可用。

虽然分段测试，但出现不可用就是说明之前功能存在遗漏，这个就要具体分析，哪个环境接口数据未对应上了。

如果是通过接口造的测试数据，那就是构建的数据，不规范导致的。数据链路太长的情况下，确实会只构建当前功能可用的数据，可能当前功能所需数据没有分析清楚。

…你这个就是要离职的节奏….

同意 1、2 楼观点，先根据公司情况制定和梳理流程规范，其他的内容在这个规范下进行

挺全面的

感觉是提前通知你，公司有可能要进行缩编，让你提前做团队优化准备
可以直接找领导沟通确认下，各部门、各团队缩编比例，提前进行人员锁定以及 HC 争取活动。
测试裁的少，别的就裁的多，裁员多少是可以争取的，做些活动还是有希望的~

需求迭代，我理解的是一个新的需求文档，并不会复用吧
而且这种情况下，每个版本的需求都不一样，本身只是简单的用例维护，现在会变成需求及用例维护，但需求维护方并不在测试，最后一定是混乱的
这样也不利于维护，由于需求而产生影响 的用例

需求是迭代的，如果没有完整的用例库，后面就没办法整体维护。

我感觉 ，这个副业可以转成主业，肯定比现在主业强啊。。。

做一个资源排期表，维度为日期、资源。
通过资源排期表，实时调整每个资源情况，也可以拿 着这个数据，与各项目进行周旋。
资源就是这么多，能做的事情也就是之么多，要么串行，要么增加资源。用数据说话

扒代码分析接口逻辑或与前后端研发确认接口规范，明确关键参数，以及参数对应的业务处理逻辑

• 根据具体业务逻辑来确认需要覆盖的参数场景
• 根据前端调用规范，构造参数场景

接口 20+ 参数，一般都是数据采集类型吧？确认下接口用途，采集类型 的话，只需要关注关键参数逻辑，确保所有参数都能采集就完事了

我们打个补丁去

大环境是一方面，新技术的接受度也是一方面，比如：前些时候百度、蚂蚁的干货分享

还有一方面，老同学上升了，新鲜血液少了