没有绝对，看你们实际情况。

从你们接口自动化的技术栈来看，只要 request 改为 appium 就是一个 UI 自动化框架的技术栈了，从这些共性内容方便维护的角度来看，合起来比较好，也便于你们有时候写一些结合接口自动化造数据的 UI 自动化用例。

但如果你们框架内部除了这些基础技术栈，还有比较多针对接口自动化定制的功能，而且这些功能在 UI 自动化上是无法直接复用的，意味着可能会有一定的兼容成本，那 UI 自动化单独弄可能更好。

个人理解，圆点代表采样数据。这个图不是每一刻都有新数据采集的，每次采集就会多一个点。然后前后的点连线就成为了看到的曲线了。

至于为啥后面会没有，看你的图像是活动线程数，你结合看看后面这段时间是不是有类似 sleep 或者服务器响应比较慢之类的操作？

一般著作权好弄点，一个平台甚至一个模块就可以搞一个。专利的话看看有没有什么比较特殊的测试方法或者技术方案，然后查下有没有已有专利，没有的话可以申请下？

金融领域业务知识还是非常有价值的，并不见得比技术地位低。28 还年轻，加油！

PS：现在 活期 +Plus 也基本售罄了，活期里面收益还是算很高的。大额存单 + 也曾经想过，20w 起步劝退。N 年前的智能存款 + 被坑了，变成了存满 5 年才有 4.5% 收益，提前取变成 0.3%，还好钱不多继续放着，但不敢再放那么多钱进微众的产品里了

我们之前用的 ones ，基本就是需求产品负责记录和管理，然后开发和测试排期估时用任务（通过把任务拆细到最大预估完成时间不超过 6h 来进行排期），测试时有 bug 就记录缺陷。是会比较割裂，不过大部分情况除了领导大家也没啥要把这些东西串起来的需要，而且好像也可以自定义设置，给表单里加上关联某某需求/任务/缺陷之类的字段。

最近顺应公司换飞书的节奏，换了新出的飞书项目，思想差异挺大，比较偏向于快速看到某个需求的研发流程全貌及各节点进展情况。需求内部拆分为多个节点（如需求评审、ios 开发、android 开发等），每个节点又可以建子任务啥的，而且有自己的生命周期，还在适应中。

说实话，除了 jira 是可以非常自由定制工作流和各种任务类型外，其他大部分项目管理类工具都是基于自己的项目管理思想来建立的，不见得可以很自由地设定工作流，有时候甚至要反过来团队的工作流去适应系统。所以选系统的时候就相当于已经选择了工作流了。

你这个问题核心是视野受限，可以多出来和同行交流，参加下当地的沙龙或者社区组织的 MTSC 大会啥的，看看外面的世界。视野开阔了之后，你会发现你现在已经习惯的很多做法，其实还有很多可以简化或者提效的空间。

另外，java 是工具，工具的目的是解决问题。

建议你定一些解决工作中问题的目标，比如让你测试报告里的统计数据从自己从系统里算变成自动生成之类的，然后这个小脚本或者小 web 平台可以用 java 这个工具来实现；或者通过学会 Java ，看懂开发是怎么修复那些比较关键的 bug 的，并把自己的理解告知开发，确认和开发思路一致。

再深入或者熟练点，可以通过看代码理解开发实际实现逻辑，分析是否有漏洞（代码也是文档的一种，能通过分析需求发现漏洞，那也能通过分析代码发现漏洞），以及引入一些基于 java 的工具（如字节码增强技术，可以做到不改动任何开发代码的前提下直接插入/修改代码逻辑，性能 apm 类和 “无埋点” 采集用户行为数据很多都基于这个）来让你能更自由高效地去伪造各种异常场景，确认异常兜底逻辑是否有效。

你提到的这个平台，除了缺陷，有其他测试日常用的工具在上面吗？

按完整研发周期来走，比较常见会需要的功能包括：

提测前：测试用例管理（特指手工测试的，便于沉淀用例，以及让开发记录自测情况）、需求管理（有需求管理平台也可以忽略）
提测动作：提测管理（方便自行设定提测单格式、准入准出准则和快速统计测试的任务量，如果项目管理工具有相关功能也可以直接用）
测试中：接口测试、性能测试、UI 自动化测试等各种专项测试工具、造数据平台及各种杂七杂八的业务提效工具、持续集成流程（有 jenkins 也可以先用着，不一定要重复造轮子）、各种代码扫描工具、测试环境管理（有不止一套测试环境，或者并行需求比较多的一般都会有这块需要）
测试结束：测试报告（包括结论、各项数据图表）、测试产物（如 app 的话要给出测试确认通过的 app 包给发布人员）
上线后：线上故障管理（故障报告、待办项跟踪、数据图表等）、线上监控大盘等

简单点说，不一定只有自动化测试才是测试平台，测试日常需要用到且有多人使用或者协作需求的，都可以成为平台的内容，为测试服务。

哈哈，第一行代码我也有看。很适合入门的一本书。

如果想快速进阶，那需要先遇到需要更高阶技术的场景，这时候你去学习、去实践，效果是最好的。

而业务没有复杂到一定程度或者公司规模没有达到一定程度，很多时候是没有这种场景的。我觉得你遇到现在这个天花板，主要两方面因素：

1、环境因素。你所在的公司或者团队没法明确给你一个需要更高阶技术的方向，直白点说就是你现在的技术方面能力已经超出团队对技术能力的需要了。
2、个人因素。楼主也坦言自己目前这些技能学习还在入门阶段，基础还不是很牢固，也提到在某些性能测试方面自己也不大了解怎么做这方面的测试方案。可能说句不好听的，处于成长曲线里的 “愚昧之巅”。

个人建议：

1、对于环境因素，不想换公司就想办法扩大自己的负责范围产生上升空间，愿意换公司就可以换个更大和更完善的团队（不过你现在 1 年左右经验且基础不扎实，不是很建议现在换）。比较常见的进一步的测开实践有：建立集中的测试平台（30 人以上测试团队一般会需要，对于降低工具入门门槛、统一一些测试方式和测试用例沉淀等都会比较有效）、测试左移（建立持续集成流水线并在流水线加上稳定且快速的自动化测试节点、深入开发技术评审环节并能给有效的意见建议，需要和开发深入合作）、测试右移（建设/借助各项线上监控/检测手段，快速发现线上问题并组织修复、复盘，保障线上不出故障，需要和开发 + 运维 + 产品深入合作）。

2、对于个人因素，不知道对于接口测试，你目前除了会测接口，是否会使用和开发类似的技术栈去写一个接口？对于 UI 自动化，除了会写 UI 自动化脚本，是否有学习过 android/ios/web 开发的基础知识，做一个简单的 todolist 或者个人博客的应用？测一个接口比写一个接口简单得多，但写一个接口你才会发现原来还有很多测试点是你测的时候没有考虑到的（比如一次请求分别写入多个表时的是否有做事务处理避免中途异常导致脏数据、高并发时的用到的各个数据存储类是否都线程安全、一些全局数据存储存储会不会放在内存里导致在生产环境多节点部署时会有问题）。去学习一下被测系统是怎么开发的，自己动手写个麻雀虽小五脏俱全的系统，你才会真正掌握某项技术的闭环，这个过程中你才有机会从底层开始建立自己对被测系统原理的认知，才能依赖这个认知在未来更快速上手新技术新系统，并找到各种另类或者偏底层场景的测试方法。

至于开发技术怎么学习，看看初级开发怎么入门之类的资料或者买本开发的入门书，或者直接看某些流行框架的官方教程也可以，只要目标定了，相信以你的自学能力，总归能想办法达成目标的。

我理解这段文字意思是 modal 的 mock 你啥都不用写，默认就会 mock 掉了。你在 minium 里面通过 handle_modal 就可以处理。

你要不直接执行官方的小程序 + 自动化用例 demo 试试？里面也有 modal 处理的示例。
https://git.weixin.qq.com/minitest/minitest-demo

modal 处理的函数在这里：https://git.weixin.qq.com/minitest/minitest-demo/blob/master/testcase/cases/test_native.py#L238

PS：我看官网的示例用例里面，就有操作弹窗（小程序里貌似称为 modal ，属于原生控件）的用例片段：

https://minitest.weixin.qq.com/#/minium/Python/introduction/sample?id=%e5%8e%9f%e7%94%9f%e7%bb%84%e4%bb%b6%e7%a4%ba%e4%be%8b

也有完整可直接执行的用例：
https://git.weixin.qq.com/minitest/miniprogram-demo-test/blob/master/nativetest.py

你有尝试过吗？

信息太少啦。。。提问请不要一图流。。。请像报 bug 一样提供足够的上下文信息方便阅读，我们不是你同事，压根不知道你在研究啥。比如你这个到底是个啥应用，我如果不百度 minium 发现是个微信小程序自动化框架，都没法看出这是个小程序。。。

微信开放社区里面有解决方案 ，你把相关文章地址也搬过来吧，这个文章至少能说明更多问题细节。同时也说下对哪些部分（术语？名词？）看不懂，方便了解的同学针对性进行解释？

另外，也把你做过什么尝试也发一下，越详细越好，把代码、日志都附上来。尽量把你做过的尝试说明清楚便于有经验的同学快速看出哪里有问题，直接回复存在的问题和解决思路，这样降低回答者成本，也便于你收到更多有效的答复。

有时候看得越多，越容易看到自己的不足，而且现在已经不在 pp 啦。

额，既然选择了开发，那你就做好长期做开发的准备吧。如果没做好 3-5 年长期在新赛道里沉淀的准备，你这个转岗很容易进退不得（测开会觉得你是不是开发能力不行才回来的，而且也容易在技术广度上不满足；开发会觉得你这 2-3 年的经验我还不如招年轻人）。

另外，不知道你转岗的原动力或者说出发点是什么，建议先思考清楚，特别是自己对转岗后的长期规划是什么要想好，确认下是否有坚定的决心。

看完后的个人观点：

1、你的顾虑前两点都是对第三方的顾虑，这些再怎么想也没法解决的，直接提出，并且做好沟通和表达出你的决心、能力，总归有办法争取到机会。

2、第三个顾虑是没做过开发，且对自己学习速度能否跟上没信心。那建议你先和后端领导了解下现在后端用的技术栈是什么，日常做性能测试啥的也可以趁机拿下后端的代码权限，自己尝试快速学习下里面的逻辑和写法，试着写些小接口，重拾一下你的自学能力。

3、开发的上限会比测试高一些，但不见得高很多，而且开发因为人多，有可能会比测试竞争更激烈、更卷。如果你在测试领域已经积累了 7-8 年，那不管你转什么领域，都要想办法让自己这 7-8 年的积累能在新领域里用得上并成为你的亮点。除非是个新的风口大家都是从头起步（比如 n 年前的移动端 app 开发，大家都是重新学习，最多就 java 后端有一丢丢语言优势而已），否则你的年龄和经验不匹配，会成为你一个特别尴尬的点，特别在你后面换工作时，会让你被具备类似经验但年龄更小的同学淘汰掉。

成长很大的一年哦，点赞~

对于培养人员这个，逐步逐步来吧，第一次带徒弟会很珍惜，不想随便放弃真的很正常，毕竟不给转正甚至开人是需要下比较大的决心的。后面经历多了，这个度会越来越容易把控的了。

不过倒是反推出你们内部转正审核机制有点简单，正常转正的时候这些缺点团队大部分人应该都感知到了，其他评委或者领导应该也会给出不能转正之类的意见，这块后续可以看看，怎么多获得其他人的评价意见，避免太受个人视角局限。

我意思并不是说滞后到了具体用例设计才考虑策略，而是测试策略呈现的成果浓缩到了用例设计里。

一般这个风险和测试验证点考虑，其实在需求评审和技术方案评审的时候就会考虑的，只是基本很少会再单独弄一份文档或者文字来记录，而是直接融入到用例设计里，在用例评审的时候一并进行评审。至于测试策略会涉及到的其他事情（比如你提到的规划排期、需要其他人协助），一般会在估排期的时候就做，成果也会融入到排期和人力投入信息里。

测试策略还是很重要的，只是这个概念慢慢弱化到测试用例设计的过程中了，很少再单独提出来。

这个没有绝对数值，要具体看公司情况，有功能测试和工具开发 8:2 或者 5:5 的，也有直接纯工具平台开发不怎么做功能测试的。

如果只是因为 python 的开发工作少，可以考虑转 java 开发，不见得必须转测开。测开也不见得就固定用 python 的。

然后测试开发的发展路线，这块没有系统整理过，个人经历是先做业务测试，对测试领域和测试痛点有一定了解；然后做一些自动化，以及小的提效框架/工具开发，逐步涉猎开发；最后逐步变为专职的测试工具平台开发。

metersphere 就是基于 jmeter 封装的，推荐试试。

暂时没有落地，之前也只是预研学习。

过誉了，没那么厉害。。。只是打的久熟练一点而已。

目前还是以 ToC 为主，ToB 暂时还没涉及到。

完整方案可能不是很方便分享，大致思路是通过 atxserver 占用设备和连接设备，然后在对应的 jenkins job 里面通过指定设备的方式来执行 monkey 、ui 自动化这些。