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

https://testerhome.com/topics/34956

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

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

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

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

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

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

挺全面的

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

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

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

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

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

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

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

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

我们打个补丁去

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

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

有两种情况：
1、非常熟悉业务对应接口，对于接口数据源也非常了解（经常负责的对应业务接口，理论上应该是完全能够掌握，数据来源了，从上层接口还是数据库进行获取数据，心里有数的）

• 在需求出来后，第一时间就可以和研发一样，结合需求同步进行初步接口分析和用例设计
• 研发接口文档出来后，结合自己的分析情况，进行查缺补漏。研发分析的不代表是全的、对的
• 要求前、后端开发对接口文档达成一致后，完善用例

2、能进行接口测试，没办法自行分析接口伪开发需求，比如现有接口是否能满足？新的需求用到的数据，需要从哪里获取之类的

• 梳理业务点
• 研发接口文档出来后，结合业务点，确认接口是否满足
• 编写接口测试用例

在创新或 KPI 设定时，针对这块内容要进行完整性规划的， 比如前期调研、后期维护、使用期间的各种问题解决、指导相关、工具或平台的推广，各阶段对应的是长线成本还是短期成本，工具或平台最终目标，预计成果。

KPI 或创新的完成与实践成果挂钩，最终只考核落地效果，与实际收益进行挂勾，达不到预期效果的扣除绩效、奖金。达到预期的提升绩效、奖金。

当为了做而做，无意义时，就没有人再去做门面了

当然一个有意义的工具或平台，在后面投入成本进行维护，也是有必要以及公司认可的行为，这也是属于工作内容的一部分

两个类型是不一样的吧,一个是数组,一个是字符串

实施和客户对接：
测试是最熟悉环境部署相关的，在很多传统企业实施也是可以由测试进行的，产品上线后，经常是测试进行演示以及实施部署

测试同时是最接近客户的群体，本身就代表着客户，可以借这个机会放大自身优势，和客户一起来探讨产品设计，逆推功能有效性以及适用性，可以尝试配合产品一起挖掘新功能，新产品

测试环境和生产环境虽然是隔离的，但既然被攻击到，还是有必要看一下的，确认线上是否做好了安全防护。
但应该是针对线上环境，一般情况下，测试环境和线上环境一定是有拓扑差异的。

如果是转行或准备培训入行，建议直接考虑研发体系，很多人公司质量效能平台也都是研发在负责
上岸的话，也是个好去处
但是测试行业未来还是有发展的，只是卷罢了。。。不是卷开发就是卷运维，都是卷