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

如果是首次接触，直接问领导或研发 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 依赖

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

你这个感觉就是为了做而做，做的如何，效能提升如何？ 是随便写个 excel 调用下就平台了还是什么？自动化解决了什么，这才是要关心的。当目标发生偏离，工具一般应该也是失败的。

其实还是挻想看下 ，觉着得无事可做了，所产出的各种平台是什么样子的，建议分享下这些平台和工具。

有些公司靠一个平台就能赖以生存，现在低代码，AI 智能化、性能测试平台、精准测试、CICD、线上整体监控什么的等等非常之多，平台、工具都是源于业务的，应该深耕业务，发掘业务诉求，解决业务难题，自己要做什么，是非常清楚的，高高在上的工具和平台注定就是被团队和业务所抛弃的。

后续我们严格卡一下

样式是真的丑，优化处理下嘛~~~~~

这块怎么说呢 当前公司应该没有流程管理相关的内容，看起来应该也不只有项目乱
这种情况下，说实话推进事情和改变事情其实还是挺难的，不过和测试数据、自动化之类的也没啥关系，这些也是解决不了这种 问题的。

只能建议试试了，成不成和领导们也是有关系的。

• 整理所有线上问题，追述问题根源，对问题进行定性。每一类问题全部给出具体原因，以及解决方案。
• 把这些问题放到明面上，拉会与大家进行讨论。参会人员建议向上覆盖，不只是单纯的研发、测试、PM。（从表述来看项目经理没有起到很好的把控作用，项目现在各种问题，最大原因也是在他）研发经理，业务负责人最好到位。
• 根本目的，与多方明确说明，具体是什么原因导致的线上问题多。测试不到位？时间太赶？项目上线频繁？
• 借助参照物，比如行业内是如何做的，我们现在是如何做的，基于哪些点从根本上改进这些问题

像这种 “这个问题阻塞客户使用了” 就必须得马上改，改完还得当天上线。
项目经理如果再说这话，就问他每次线上问题每次这么多，做为项目经理有没有考虑过具体的解决方案，功能虽然一直上线，但是用户满意度这么低，用户投诉量又这么高。如果现在我们谈的解决方案不行，请给出具体解决办法。

理论上讲，功能上不上线不是项目经理说了算的，而是由测试负责的，测试结论就是不具备上线条件，上线后，出任何问题全部由项目经理负责 ，我不相信 PM 敢说，必须上线这句话了。

我觉着问题原因就是公司缺失了测试流程规范的内容，建议规范项目上线标准，测试排期规范。正规的公司一定是有一个内部发布周期的，建议敲定版本上线周期。

哥，现在这个大环境咱就不卷了吧

整体大环境都不太好，波及的其他不只有测试，社区非常多类似帖子了，暂不审核通过了
只能一起加油打气了

建议根据经验先协助研发梳理一些接口通用错误，与领导沟通形成接口开发规范。

在开发规范基础上，再和研发确认好接口问题拆分，具体到哪些类型错误由前端还是后端进行处理。

基于明确的接口规范进行接口测试，要求研发进行通用错误处理，其余的异常一般是要通过测试来进行验证的。结合每次结果汇总分类后，完善接口开发规范

先不审核通过了，测试同仁们只能共勉了，一入测试深似海。。。

基础都不愿意自己看一下？不知道你发的意义是什么，请不要随意水贴子

这个要从另一个层面来看，自动化其实也是向业务服务的

这个同事，在公司应该是类属于业务专家角色了，对公司现业务了解是应该是非常深入的
这类型的人员，对于业务功能敏感度、痛点、处理能力，各环节的把控度应该也是比较强的，老板喜欢这点，看来应该有了一套自己的业务处理、 业务挖掘的成熟经验

自动化是要回归于业务的，最终主导团队的一定也是偏业务的，很多公司内的各业务负责人，一般也是精通业务先上，再综合考虑技术经验等等

术业有专攻，精通业务测试的，公司其实也是非常欢迎的
当然如果会自动化，能够解决效率问题，公司在招人的时候，肯定是要综合考虑的

你的群号不对，标注个正确的群号吧

https://testerhome.com/topics/32970

大数据这本书已经没有了哦

不太 get 你的点，我理解 上面非常清楚 了
例子自己随便参考补充一下就可以了，如果内容都没办法扩展填充，真的没折，放弃吧

• 对事不对人，不定性，下结论；

本次 BUG 共 XX 个，经过分析共几类缺陷，各自占比，其中主要来源哪个模块哪个功能 之类的，模块缺陷分析

• 分析问题原因，进行归类总结，测试本职工作（如果涉及此类问题的研发，难沟通、配合度低，可以重点标注此类问题，要求研发重点关注，具体是改进和提高，归属于研发经理职能）

缺陷原因初步分析，什么原因导致，需求分析原因？代码逻辑原因？上层服务原因等等，每个公司都有自己的定义，根据定义进行统计汇总，没有的话就借这个机会生成这些定义。

问题原因也可以归属为：产品、研发、测试

• 短期、长期数据整理，用于佐证各类风险。（基于数据可以开展各类自动化相关活动）

拿多次版本数据，根据现阶段情况结合个人经验给出风险建议。
XXX 功能一直未提测，影响 XX 项目整体测试进度，如果在 xx 之前未能提测，项目有可能无法如期进行上线
由于 XXX 功能需求变更，研发重新调整开发计划 ，导致 XXX 功能还未进入开发， @ 产品 建议 XX 功能下个版本上线
XX 模块问题较多，质量较差，上版本由于功能需要，强制上线，导致用户投诉较多，本次版本建议延期上线此功能，待重新完整测试后，再进行上线

从各种角度去说明，由于问题而引起的问题啊。我们能解决的，我们不能解决的，都可以向上抛啊