跟楼主一样的年纪，目前公司也在大力裁员，因为怀孕中躲过一劫吧，不过在公司每天都是煎熬，心累，打算把娃生了在寻找新的机会，互联网行业极其不稳定，如果可以的话建议去稳定点的事业单位银行啥的

当我们做的任何东西在业务线都推广不下去的时候，就想着要放弃了，2017、2018 年两年做的东西基本都没有落地，现在是基本走到头了，各方面原因吧，测开搞得真是心累

我目前的见到过的方法都是通过 UI 自动化去点击，不管你用什么技术方案，基本都是要写 UI，然后要适配不同的机器，每台机器的弹框、文案都不一样，更变态的有些手机（OPPO）要输入手机验证码，手机根本不具备自动化性质，大厂的一些云测平台，对外宣传说兼容多少多少台，真正能成功跑下来的能有多少，这个嘛。。。。只有试过的人才知道

我们内部其实有一个云测平台，没人用基本废弃了，因为机器没人维护，现在又要搞遍历，目前在本地机器上跑，不打算适配机房的几百台机器，登陆脚本都不准备写，自己手工登陆，跑线上环境登陆用自动化脚本没法解决，校验没法绕过，还要手机验证码

你们稳定行测试目前适配了多少台机器，安装弹框、登陆这些问题是怎么解决的呢，

楼主这个稳定性专项是如何在公司落地的

设置了五分钟，都十分钟了还在跑，没结束

楼主有计划开源吗

余额宝不是不行了么，怎么还在扩招啊，现在利息贼低，准备把钱撤出来了

楼主自己咋记录哟，没跑完就没数据，难道是自己从外围去不断的获取 activity 数据么，还有你们现在能覆盖多少个 activity？

持续交付方面的资深专家啊

我觉得覆盖率还可以啊，一个小时能跑 80 多个 activity 呢，楼主你这个遍历的 activity 覆盖是最后的日志中解析出来的么？

monkey.jar 的是下发指令执行操作的，那这个 framework.jar 是做什么的用的，他跟原生的/system/framework.jar 有什么区别

可以参照下业内持续交付平台

一个意思

确实很多东西都是结合大厂来看的，在大厂适合，在小公司确实不符合，之所以做了打包平台化是先前从大厂回来的，当时一来这个公司，发现还在 jenkins 上操作，分支很多，job 没法管理，想着搞持续交付平台，所以先把打包这一环节平台化，结合打包做一些自动化测试，覆盖率统计，APM 性能报告啥的，结果大家不还是不习惯在平台上打包（里面还牵扯到一些 KPI 问题，有些人专门维护 jenkins 打包的，不愿意放手交接给我们），因为不在这里打包，这些功能就白费了

有分享哦

对对对，后面这个管理平台就是和业务线达成一致才做的，以前有什么 idea，都是默默无闻的做，最后他们也不关心，落地困难

就是今年一个一个开展的，自己想的自己做的，可能现阶段对只有一个产品的公司来说弄这些并不能提升多大用处把，业务线的同学也都仅限于功能性测试

是的

因为现在上面领导不关心这些，不是技术型领导，不懂业务，所以业务都是我们自己去想，做出来了，业务线的同学们都只是点点点，并不关心工具的使用

其实老板不怎么了解移动端业务，所以他也不知道怎么落地啥的

这个是针对服务端代码，还是针对客户端 Android 代码？听说 Android 代码不支持在线动态插桩