个人觉得，大部分情况下测开的开发能力，广度上接近于全栈开发，但深度上和专业开发还是有差距的。

主要还是岗位需求引起，测开由于人力有限，基本要自己包办完整系统，所以技能相对全栈；但由于内部系统相对复杂度、性能要求等都比较低，所以深度上其实比较难钻下去，也没太大的需要。当然部分比较前沿的测试还是有需要的，比如 java 字节码增强等。

相比之下，开发一上来就是要面对高复杂度、高性能需求的对外业务系统，而且分工比较细（基本上专精 1 个端），所以深度上会深不少。比如 Spring 原理、各种常用中间件的原理及最佳用法、高性能场景下的系统设计及实现等。

还是术业有专攻吧，千万不要觉得测试开发什么都比开发强，那是因为大部分从外面看，基本都只关注到广度上的差异而已。

做到什么程度，能过面试拿到一份测试开发工作 offer 呢？

首先，这个事情没有标准答案。实际测试开发里面也有细分，一种是在业务团队里的测试开发，核心是熟悉代码，可以在业务团队里基于自己的代码技术能力做很多技术型工作，比如一些小工具开发、专项测试的主导等；另一种是在整个质量大部门下专职开发测试工具平台的测试开发，核心是平台开发技术以及对需求分析把控能力。所以，建议楼主：

1、以终为始。既然目标是找到 offer ，那就先去分析这类型 offer 的 jd ，找到你目标行业测开岗位 jd 中出现频率最高的技能点，去专项学习和掌握。做这个事情本身就可以通过爬虫等技术手段去做，这也是本身测试开发需要具备的能力之一：随时可以通过自己的代码能力去提高自己工作效率。
2、尝试去投一些简历和参加一些面试。jd 有时候和实际用人要求还是会存在出入的，所以最好还是去面试一下，校准一下。
3、增强自己业务上代码能力的使用。比如去看看开发的源码，了解下现在这些功能用到了那些技术框架，你在界面上点一个按钮到界面产生反应，背后到底发生了什么，涉及到哪些系统的哪些逻辑。
4、想办法找到已经在做测试开发的同学交流下，说说自己的现状及计划，听听对方的建议。大部分测试开发是业务测试转的，会有一些这方面的经验。

最后，保持耐心。现在行情不是太好，而且大厂出来不少人，你要找到好的测开 offer 会更难，甚至可能好几个月都没多少面试机会。建议你可以设立一些相对可控中间目标（如能独立绘制出自己目前测试的产品的架构图、核心流程时序图等），逐步达成，避免找 offer 这个目标进展缓慢，失去激情。

./sandbox.sh -p 4005 -X

看了下这个命令，和我之前文中有出入。我之前文中用的是

sh ~/sandbox/bin/sandbox.sh -p `ps -ef | grep "target/gs-rest-service-0.1.0.jar" | grep -v grep | awk '{print $2}'` -P 12580

我换成变量含义再写一遍：

sh ~/sandbox/bin/sandbox.sh -p ${需被sandbox attach的java进程PID} -P ${sandbox服务通讯端口号}

虽然根据 sh ~/sandbox/bin/sandbox.sh --help说明，如果不提供 -P ，默认会用随机端口号，但看了 shell 里实际实现，默认会填充的是一个固定值 0 ，而非自己生成一个暂时没被使用的随机端口号。

所以，你可以试下加上 -P（注意是大写 P）参数试试。

主要还是看从业者人数。芯片或者 sdk 的测试人员人数上就比前两类少，所以自然讨论分享的少。

而且这类有些时候容易分享时带上了一些不能对外的东西（如 sdk 的内部实现细节，芯片的一些参数等），风险也高。所以可能是在公司内部分享为主吧。

看了下，没达到加精的水平。

加精主要是一些比较前沿，或者比较独特，让人眼前一亮的内容，加精是为了让更多的同学去了解进而获得进步。这篇总结内容是比较全面，但其他地方也有挺多同类型的文章，不算特别前沿或者独特，所以没达到加精水平。

基本开发技能从你上面说的看，基本都掌握了。剩下的应该主要是具体功能设计了。

既然你已经明确了接口自动化是下一步这个平台需要的功能，建议：
1、看看同类型其他项目的功能设计，乃至代码实现。尽量多看几个，了解下大概的套路。
2、结合自己的情况，把自己当做产品，通过前端画一下大概的原型（数据写死，只是出个大致的排版和能跳转交互就好）；如果前端不够熟悉画得慢，可以直接纸和笔或者找一些在线原型工具画。
3、画完原型，可以给未来的用户评审下，看大家有没有啥意见。评审没问题后，继续设计下技术方案，比如页面大概拆成哪些组件，服务端要有哪些接口、哪些表等。

设计完基本就是写代码了。

一般技术掌握了后，最容易出现的问题就是没想好就开干，干出来可能用起来很别扭，也很难推。模块化可能也比较差，扩展难。

因为你对这类型内容不感兴趣，哈哈。

现在社区会员人数也挺多，这类文章可能会有其它同学比较感兴趣，所以直接屏蔽删除也不大合适。我一般对不感兴趣的文章，基本就直接跳过。

瞎猜下，可能问这个问题之前，面试官是看到你简历/你的回答里有提到你有压力测试的经验，所以才问你当时是怎么做的。

这么问其实也挺常见的，可以看出回答者是否真的有做过（没做过的话，会讲得很宽泛，毫无细节），以及视野情况（是只关注具体某一小块，还是懂得从全局方案去考虑，甚至已经形成自己的固定套路），然后确定是否有继续追问深挖的必要。一般做结构化面试，核心是考察冰山下的能力（思维方式、学习能力、沟通能力等，或者叫潜力。有的公司会直接固化为公司内部的通用能力项），冰山上的能力（具体某个工具的概念或者用法之类的），一般是连带的。问冰山下能力一个很常见的方式，就是看如何总结阐述自己做过项目的经验（可以一次性考察到思维能力、沟通能力）。

一般对应回答，建议用 STAR 这种套路，先说明当时为啥要做压测（Situation，场景），具体压测内容是什么（Task），然后你是怎么一步一步去做压测的（Action），最后压测结果如何，有没有发现什么问题以及做什么优化（Result）。一般我面试的话，我会尽量把问题拆成这 4 个子问题分别去问，避免面试者没 get 到浪费时间。

面试官不是你同事，不知道你当时的场景，没有场景直接说细节，面试官会满脑子疑问，也会觉得不完整/太细节。

load jvm failed : Non-numeric value found - int expected

报错提示需要 int ，但发现非数字型的参数，和你之前给的貌似又不是同一个问题了。我搜了下我以前的帖子，好像启动姿势和你这里用的不大一样。我以前用的：

# sandbox attach
sh ~/sandbox/bin/sandbox.sh -p `ps -ef | grep "target/gs-rest-service-0.1.0.jar" | grep -v grep | awk '{print $2}'` -P 12580

要不你单独发个帖子，把你的操作步骤以及报错，都详细说明下？

这个为啥要匿名呢？

后面找到了另一篇，写得更全，也分享下：
https://github.com/LoganZy/AndroidTotal/blob/master/android%20%E8%BF%9B%E7%A8%8B%E4%BF%9D%E6%B4%BB%E6%9C%BA%E5%88%B6.md

我觉得这个思路也是很有用的，线上线下监控都可以用得到。

可以按设备做每个设备的心跳埋点时间间隔情况的统计，时间间隔大于 xx 次心跳间隔的视为保活失败一次。然后通过统计看各设备的保活失败率了解各系统版本的保活情况，再对失败率高的，做针对性测试和处理。

关于 Android 后台保活这个，搜了一下，找到了这篇：https://juejin.cn/post/7003992225575075876 。保活的难点主要在于在不同厂商系统和不同的场景下，各个保活机制确认有生效。

不知道你现在对于 android 后台保活这个，是否已经有相对固定且完善的测试场景用例（比如在各厂商的操作系统下，针对优化助手清理、针对用户自行清理、针对打开多个 app 后系统后台自动清理等，是否都能保活）？如果没有，可以先设计下这些用例；有的话，那把用例翻译成对应的自动化脚本就好。

建议可以简单点，先别关注太多框架层面的东西，先把最核心的 1 个流程的自动化用例写出来、跑起来用先吧。

框架、方案、流程什么的都是正式立项时的事情了，而立项涉及到领导以及其他团队成员，有比较多不可控因素。所以我觉得，从实际落地角度，其实自己一个人先写起来、用起来是最简单可控的。有一定成果后再去立项，比从零立项，要容易得多。

没明白你的保活具体是啥意思。可以先详细说一下么？

没遇到过，而且你这个看起来不像是错误，只是一个 dump 动作日志。

你把报错日志截全贴上来？

没有吧，一般就等编译的时候，随手点开社区瞄一下消息通知而已。

我和你的观点不大一样。我觉得对于刚入行的朋友，这篇文章可能会引发误导。

有的功能测试报告是开发人员编写的，有的测试机构做的

这个和业内常态差异较大（业内大部分是测试人员写的，少部分是测试机构做的，更少是开发人员写），容易引起新同学误解。

详细功能测试报告方案模板

...

第二部分：功能测试过程

1、测试方法；介绍本次功能测试过程中用到的测试方法，常用的方法有等价类划分法、边界值分析法、错误推测法、判定表法、正交实验法。

2、测试环境；介绍测试环境配置。

3、运行测试；检查测试结果是否符合业务逻辑。

4、测试结果；进行多次测试，进行错误登记划分，列出相关图表阐述测试结果。

这个划分很奇怪。首先测试报告和测试方案应该是分开两份文档，报告是测试完后出的，重点说结果和风险点；方案是测试前出的，重点说测什么和怎么测。这里把两个混在一起了，不大对。

你们这个确实快不起来，需要多人协作。

倒不会只适用于 web 端，采集的时候客户端和服务端可以一起采集，也有助于开发辅助定位是哪个端的问题。

只是这背后对基建有一定要求，比如得弄个工具持续录制操作视频，记录客户端日志（接口请求及返回记录可以在日志里直接打印，就不用额外搞抓包）；服务端得有链路跟踪工具方便知道涉及什么服务、ELK 日志聚合方便获取全部相关服务的日志信息。

之前 MTSC 21 年深圳大会，腾讯有同学分享过类似的东西。

大概 8 年前第一家公司用的 testlink 写用例，写的就是这种有比较明确操作步骤的。然后每次功能有变动要加/改用例，1 天写 30-50 条用例基本是极限了。而且基本上写用例的人也是执行测试的人，其实执行的时候也不怎么细看当时写的用例的。

现在大部分是互联网行业，测试的基本是公司自己用的系统，不需要第三方审查必须出用例报告啥的。加上测试时间紧，需求变更频繁，所以基本都改成用脑图了。脑图写的测试点，基本上一天可以写几百个，效率高很多。

补充一个我觉得很有用的，一键报 bug 。工具自动附上前 1 分钟操作视频（如果有），以及所有相关日志。测试只需要写下哪个位置不符合预期就足够，不用花那么多时间去写 bug 描述和找日志，也杜绝一句话 bug 的问题。

但这个可能超出 “小工具” 范畴了。

这个调试姿势有点怪怪的，如果依赖模块多，你得加不少临时代码解决这个依赖模块问题，调完还得删掉。

直接按正常入口来启动 web 应用，做断点调试不会更香么？

功能测试报告主要是对功能测试过程及结果的记录，有的功能测试报告是开发人员编写的，有的测试机构做的。

还有开发人员写功能测试报告？

截图里的 api 是在 im_controller 的上一级目录，但你引入的时候是在 im_controller 文件的本级别直接引入，所以找不到是正常的。要引入上一级目录的模块，只能通过 sys.path.append 将上一级目录加入到 module 搜索路径中。

看起来你这个是个 web 项目，有可能是因为你程序入口不对导致出现了引用上一级目录模块这种情况。你确定这个项目启动入口就是 im_controller.py 这个文件么？