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

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

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

我们打个补丁去

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

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

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

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

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

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

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

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

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

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

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

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

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

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