robot framework 框架 5 年前很强大，现在互联网技术迭代了很多次了，继续用 robot framework 个人感觉有点原始，总不能几年后还在 robot framework 为主吧，老项目可以用，新项目还是建议用新的主流框架。现在大部分还是 pytest、playwright（高级一点的可以用 playwright MCP）等

太赞同了，先学会怎么提问再提问，生活中、工作中均如此

RPA 类的平台、MeterSphere 类的平台，现在有很多了，都是低代码，只有内置组件不满足才会需要写组件

一定要去一线历练，历练个 4、5 年再考虑是否回来，回武汉的同行全方面综合能力强的人，大部分都可以找到工作

跟当前城市薪资水平挂钩的，20K 以上就必须得去北上深，并且进入一个赚钱的公司，技术就那些常用的，再就是 5 年以上的开发或者测试经验

to int、to bigdecimal、to float 、to double，计算完后的结果 to String

集成电路行业不一样，各种工具、检测仪器、工程软件需要大量的自动化。纯软件行业的自动化没有说一定需要多少占比，有专门的测试开发组自动化程度就高，没有专门的测试开发组，自动化就是用空闲时间做，比例非常低。如果你们终端产品是 ToC 的，除了软件 APP 外，有时间的话硬件应该都可以做，要学 C 系列编程或者 shell 命令去控制终端产品运行，这些基本上硬件测试都可以做

我们现实情况是测试做好本职工作就行，多找有数据支撑的理由脱开自己的责任关系，坚决不背锅，只要不垫底就行，整个团队烂了，一个人的力量再强也无法独善其身，最后都是连带责任一起完蛋

都不是闲着没事干才上这？谁忙的不可开交还有时间在这评论回复？我是人，又不是 AI 智能体，为啥要上下文联系来思考和回答社区里的评论？来这评论就是扯扯蛋，仅此而已

别阴阳新人了，我们期望这社区能一直存在下去，没了新鲜血液，我们可能没法在社区吐槽、发牢骚，我可不想少了一个测试同行自己的社区。编辑器这个问题怎么说呢？只能靠社区活跃的人或者友谊合作的企业，出钱或者出力做好，但是现在的大环境下，很难很难

ide 工具、输入文件编码、输出文件编码全部换成 GBK 试下，如果没报错那就把 ide 工具、输入文件编码、输出文件编码，全换成 utf-8

接口自动化可以低代码全部搞定，测试报告如果内置的不符合公司要求，就需要二次开发。压测支持导入 jmx，压测过程、结果、报告跟 jmeter 基本一致

上面都已经说的差不多了，实际效果最好的还是得联合研发部制定开发绩效奖惩制度，BUG 少的并且提测准时的开发，年终奖多发一个月，你看质量、提测时效绝对蹭蹭上涨，没有奖惩制度，推啥措施都没用，开发都是本着事情能少就少来工作的，这个是人之天性，除非给真实的大饼。

测试方案都没有量化指标，把 prd 扔给 AI 让它生成测试方案？这个 AI 使用场景就有问题了。如果说测试用例让 AI 输出 80% 以上不需要计算能用多少的话，调个大模型接口，让它多返回几次，然后往测试用例表格塞，绝对不止 80%

2 个都是

华为鸿蒙生态的临时工外包测试和技术支持，到处出差，项目做完散伙

震惊，XXX 既然....
又炸了，XXX 发现...
赶紧自查，有这个的....
又有一大波工程师要失业了，赶紧看过来...

反正我们小团队，在 MeterSphere 上进行接口自动化测试、进行接口测试、维护测试用例，其他的没有调研过

MeterSphere 呀，快速上手、代码都不用写

华为 OD，听起来比常见外包岗好，实际上在公司过的不如常见外包岗，为了那每年少的可怜的转正机会，进去的人一个比一个卷（一般大厂真没像华为 OD 这么卷的），卷完进不去正式岗还是得撤，并且华为领导已经有严重的类国企毛病，35 岁当不了领导或者做不了技术专家，被辞退就是华为产物，现在为了当个校领导和技术专家，那领导的马屁拍的一个比一个想，没几个真正干活的正式工。

我们也是采用的项目外包，自己人又搞绩效，末尾淘汰，绩效好又不能涨薪。考虑到项目外包便宜，然后外包人员越来越多、项目管理越来越稀烂、项目研发周期越来越长，现在都到了平均 delay2 周的地步，总部都快放弃这边的研发团队了，让研发团队自生自灭。

很多场景需求文档没有，这个是需求文档在软件研发全生命周期内维护不过关，在外包项目这个是通病，找负责人沟通太难，经常因为层层沟通造成项目进度停滞或者重复工作。作为合格的乙方外包方，只能从自身进行改进，恰恰从业务流程出发进行面向经验的测试设计和测试执行能规避很多问题。

引用文本：公司人员经历了比较大的变化：
产品部门：
原本 5 人（1 个经理、1 个产品定义设计、1 个助理、2 个 UI），1 年前因为业绩不佳被高层认为 “不重要”，整个部门被撤掉。最近又开始重建产品部门。
研发部门：
从原来的 30 人左右，缩减到现在只剩 10 人。
测试部门：
从原来的 10 人，缩减到现在只有 2 人。
在这种变化下，整个产品线运作极度混乱，跨部门协作阻碍非常大。

在这种情况下，产品线运作不极度混乱才是不正常的，因为人人都开始自危，生怕下一个就是自己，然后有选择性的开摆，配合度上会大打折扣。我们就经历了一次，当时所有人开始摆烂。直到公司人员直接减半，最后公司趋于稳定后，跨部门协作上就慢慢变好了，因为所有人都偷偷用 1 年多时间尝试过骑驴找马，找到好的马走了一部分，最后剩下的还是发现苟着更好。

引用文本：你们公司产品线/测试流程的关键节点是怎样的？

小公司没啥测试流程可说，时间充足就加一个测试用例评审、UAT 做做性能测试。时间不够就用 AI 生成测试点，用例都不写，直接开测、测完上线。

引用文本：在小公司里，最实用的流程改进方法有哪些？

小公司测试流程改进？不如提高跨部门沟通能力、前后端技术理解和研发能力、甩锅能力、跟领导打好关系能力。

引用文本：有没有成功的 “轻量级” 流程管理经验可以分享？

这个除非测试在项目中说了算，采用并落地测试左移、测试右移隐秘点的改进用法，测试说了不算还是好好跟产品、项目负责人打好关系，期望线上万一出问题他们能帮你。

我们很早就要求测试用例按照业务逻辑进行编写了，一是 UI 输入输出类的写的太多浪费时间也发现不了很多问题。二是发现的问题在业务流程相关的点呈线性聚合，分析问题发现大部分是业务逻辑在测试用例体现上不足，业务流程覆盖度不全。核心还是测试人员对测试的系统、专业的业务不够了解。三是现在的 UI 自动化结合 AI 技术，基本可以做到非业务流程的全覆盖，不需要去人工走查，这个也是后面想做的实现非业务流程 UI 自动化。

2020 年前，测试会自动化、会代码、会开发工具还是很好找工作的，直到 2022 年的经济萧条和 AI 的横空出世。。。