我理解这段文字意思是 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 自动化这些。

还没怀上

work life balance，很赞

拿到这么多 offer ，厉害。加油，继续追逐你的 dream 吧~

客气啦，和大牛比还差得远。

感谢大家支持

嗯嗯，也在内部争取一些管理的机会，不过也要看机遇。项目 owner 也是我的目标，但这个对业务的熟悉度和把控度会有更高的要求，还需要加把劲。

以前关注用户体验的公司，会要求研发团队的同学自己日常也需要用自家公司的产品，在用户角度去使用、感受自己测试产品的用户体验。这种情况下，其实比只是测试过程使用，能更容易感知和发现用户体验问题。

但现在好像越来越少了。

幸存者偏差吧。不见得每个人都会写，写了都会发出来。有时候愿意发出来，一般都是觉得写得不错的。

确实每一年不一定都有很多收获，也可能原地踏步，波澜不惊，甚至自己觉得在倒退。但写下来至少能让自己正视一下过去一年的自己，知道什么做得好（你会有自豪感）可以继续做，什么做得不好（你会很犹豫写不写甚至不想写），是突破还是避让。吾日三省吾身，做一下自省，会有助于你更清晰自己的现状，顺道思考下自己想要什么，接下来这一年可以做什么来达到自己的目标。

1.比如登录接口我是需要把 ” 登陆成功 “，” 密码错误 “，” 账号不存在 “这三种情况的接口都写一遍吗，有多少种异常就写多少次

看用例优先级，一般成功用例是必须要有的，异常的一般会需要造数据啥的，会复杂一些。建议先保障主流程，按主流程顺序调用各个接口并保证成功，再在这个基础上加上每个接口的异常场景。

2.前几天跟别人聊，人家说他们的自动化是，接口 UI 合在一个代码里。想问下那种是怎么做的？

既然都是代码，用不同的函数就可以调不同的库，进而做不同的事情吧。

3.我这种方法是不是不如测试平台好啊，是不是找个开源的测试平台我这些问题就都能解决啊？

个人也更建议你搞个开源的平台，写代码好处是方便，但缺点是对于没经验的新手，需要额外学习很多框架使用方式之类的知识才能用好。你现在应该最需要的应该还是快速出成果，哪个上手快、能满足就直接用，而不是从零建设。开源的接口测试平台挺多的，有些背后还是公司有专门团队维护的（比如 meterphere），可以找几个比较流行的试一下，找到一个好用的就开始用起来。反正代码开源，后面真的想改，也有办法改。