在团队内尝试引入一些新鲜技术,让大家分别选择进行调研和实践,然后推动大家在项目中落地
参与调研的同学,调研完成都进行课题分享
也可以自行申报课题分享,经常分享的同学,给与考核加分支持
缺失了公司名称、联系方式哦,补充 一下吧 楼主
上面明明说的是:
要学哪种语言,没有什么好纠结的,主要在于你要干什么?你的目标是什么。
不知道哪个说法引起了歧义
没太懂,但最终你一直在说的是走上层还是下层好,对应的不就是所谓的技术体系嘛?
每个公司核心技术体系都是不一样的也是事实吧?最终决定于公司从事哪个方向、哪些个领域吧?
但硬说是行业发展趋势?完全不搭边呀。。。
没测试过,从网图来看像那种集成电路板,应该也是通过控制板子来进行对应的功能操作。
应该也类似于将这些板子或图装在一个盒子里,通过点击盒子上面不同的按钮,会导致板子某些连接点变更之类的,从而达到执行不同的事情。
如果是首次接触,直接问领导或研发 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 敢说,必须上线这句话了。
我觉着问题原因就是公司缺失了测试流程规范的内容,建议规范项目上线标准,测试排期规范。正规的公司一定是有一个内部发布周期的,建议敲定版本上线周期。
哥,现在这个大环境咱就不卷了吧
整体大环境都不太好,波及的其他不只有测试,社区非常多类似帖子了,暂不审核通过了
只能一起加油打气了
建议根据经验先协助研发梳理一些接口通用错误,与领导沟通形成接口开发规范。
在开发规范基础上,再和研发确认好接口问题拆分,具体到哪些类型错误由前端还是后端进行处理。
基于明确的接口规范进行接口测试,要求研发进行通用错误处理,其余的异常一般是要通过测试来进行验证的。结合每次结果汇总分类后,完善接口开发规范
先不审核通过了,测试同仁们只能共勉了,一入测试深似海。。。
基础都不愿意自己看一下?不知道你发的意义是什么,请不要随意水贴子
这个要从另一个层面来看,自动化其实也是向业务服务的
这个同事,在公司应该是类属于业务专家角色了,对公司现业务了解是应该是非常深入的
这类型的人员,对于业务功能敏感度、痛点、处理能力,各环节的把控度应该也是比较强的,老板喜欢这点,看来应该有了一套自己的业务处理、 业务挖掘的成熟经验
自动化是要回归于业务的,最终主导团队的一定也是偏业务的,很多公司内的各业务负责人,一般也是精通业务先上,再综合考虑技术经验等等
术业有专攻,精通业务测试的,公司其实也是非常欢迎的
当然如果会自动化,能够解决效率问题,公司在招人的时候,肯定是要综合考虑的