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

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

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

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

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

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

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

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

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

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

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

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

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

我是觉着不妨，往大了整 ，触达的覆盖范围大一些，这样测试阶段才更通畅一些，像：

• 版本需求确认（结合研发、测试初步预估排期，提前确认本次能上线的功能）
• 排期收口（除了测试排期，把研发排期也纳进来，结合上线日期、测试方案，统一协调）
• 范围收口（与研发达成共识，针对某些特定功能，影响范围收紧，测试无法进行的测试可以移交到研发进行）
• 版本收口（针对上线的内容，制定版本准入策略） 不过还是要结合业务实际情况进行，建议全流程 ，测试毕竟偏向于后面阶段，需求产出的阶段开始把控，后面阶段才能更通畅

建议重点考虑关联节点的约束和流程，配合这些节点，调整测试规范和流程
其实就是约束各个协同节点，尽量减少测试繁琐度，提升测试流畅度

行业通病吧，大家只关心自己负责的部分，一般讲到自己负责部分的时候，关注度最高
还有一种情况是，真的在处理问题，工位的时候都没有时间看消息，处理问题，开会的时候抽时间解决问题，这种也是非常常见的
不过在讨论 kpi 呀 OKR、奖金相关的时候，大家一般都是厮杀状态

在团队内尝试引入一些新鲜技术，让大家分别选择进行调研和实践，然后推动大家在项目中落地
参与调研的同学，调研完成都进行课题分享
也可以自行申报课题分享，经常分享的同学，给与考核加分支持

缺失了公司名称、联系方式哦，补充 一下吧 楼主

上面明明说的是：
要学哪种语言，没有什么好纠结的，主要在于你要干什么？你的目标是什么。
不知道哪个说法引起了歧义

没太懂，但最终你一直在说的是走上层还是下层好，对应的不就是所谓的技术体系嘛？
每个公司核心技术体系都是不一样的也是事实吧？最终决定于公司从事哪个方向、哪些个领域吧？
但硬说是行业发展趋势？完全不搭边呀。。。

没测试过，从网图来看像那种集成电路板，应该也是通过控制板子来进行对应的功能操作。
应该也类似于将这些板子或图装在一个盒子里，通过点击盒子上面不同的按钮，会导致板子某些连接点变更之类的，从而达到执行不同的事情。

如果是首次接触，直接问领导或研发 PLC 是什么，一般是运用于什么东西上，如何进行测试比较好，测试哪些内容？这些应该都是正常的沟通问题，没有什么开不了口的，程序总有提供方，程序也一定有使用说明。

上面分配的工作，我理解你是没办法拒绝的，但可以进行良好的正常沟通，除非一种特殊情况，故意恶心你走人。。。

技术路线是跟着公司技术路线进行的，什么方便什么来
为什么测试很多都走的 python，是因为较 java 来讲好上手一些
你可以了解下目前市面上大部分的质量类平台，都是 java 系的

python 学好，也可以直接转向 python 开发工程师，要学哪种语言，没有什么好纠结的，主要在于你要干什么？你的目标是什么。

三方支付都有对应的测试接口，真实的支付动作不会太频繁
我们一般情况下：
1、能够正常接起三方支付，确保参数正确
2、使用三方约束回调参数，回调支付完成接口
3、如果必须要真实支付，研发配合允许进行改价，允许通过一些特殊手段进行金额调整

日报只要体现当日重要关键数据就可以了

----------------------------------XX 工作日报-----------------------------

上一工作日遗留问题及解决情况：

当日工作总结：

进度、风险问题总结：

XXX 项目由于 XXX 导致进度延期 XX 小时。
由于 XXX 导致 xxx 功能无法正常进行测试，将调整至 XXX 号进行测试。
由于 XXXX 功能一直提测，导致项目进度严重滞后，xxx 上线存在风险。（可以提出自己的解决方案）

具我了解，很多公司 RF 还是主流的

看下依赖包关系试试？

mybatis-spring-boot-starter 这个有嘛？升下版本试试？

java.lang.ClassNotFoundException: org.springframework.transaction.ReactiveTransactionManager

添加 spring-boot-starter-jdbc 依赖

个人资料设置 我的积分 那里