额，这个可以变通一下，往多语言文案配置里弄 2 门特殊语言，一门长度和最短的一致，一门和最长的一致，就好了。

这样测试的时候，排版方面的通过这两门语言就可以完成。

这也不是我想出来的，以前 MTSC 看到有个分享多语言测试的议题里提到的。

楼上这个建议很好，保持耐心是第一位的。能力不足的情况下做一些挑战性事情，效率低甚至磕磕碰碰基本是必然的。保持耐心，坚持学习和总结记录，随着你解决的问题越多，你的经验就积累起来了。

我在楼上的基础上，补充一个点：要选择性解决问题，不要选择解决所有问题。

比如正文里提到的 pycharm 里两种执行界面的差异，这个有阻碍你什么吗？如果没有，可以记着，但不要花太大精力去弄懂它。这属于次要问题，不重要也不紧急，记录下来，等你操作多了，pycharm 用得熟练了，你自然就找到答案了。

新人学习，会对一切东西都很好奇，喜欢问十万个为什么。这本身不是坏事。但在没有导师或者资深专家随时解答的情况下，很多好奇心引起的、不阻碍自己学习的问题，解决效率其实并不高（因为不重要，所以大部分人并不会特意去研究，相关资料也少），反而容易舍本逐末，影响学习热情。这个工作中也是一样的，不是所有问题都需要解决的，解决核心问题，能办成事，这个才是最重要的。 Done is better than perfect

最后，针对你提出的两个问题，解答一下第一个问题：为什么表现形式不同
答：选择的运行配置不同，所以不一样。在 pycharm 的 run configuraion 里，有多种运行配置可选：

选择 python ，是通用性最强的，所以界面也是最简单的，直接展示 console 输出内容。
选择 pytest ，是定制型最强的，所以界面针对测试这个场景有更适合的展示方式（如分别展示每个用例的运行结果）

你点击 if __name__ == "__main__" 前面的运行按钮，pycharm 自动会当做通用的 python 脚本去运行（印象中是），因为他没法判定 main 里面跑的是啥。
你点击用例方法前面的运行按钮，pycharm 会自动用 pytest 去运行，因为它已经识别出这是个 pytest 用例了，所以才给你便捷的一键执行按钮。

排版问题，核心主要和文本长度有关吧？

从多语言里选最短文本、最长文本，两个都能 hold 住，应该就不会有太大问题。

额，为啥会这么问呢？先不说这涉及到私人账号信息不方便给，就算给了你也用不了，因为不是同一个应用，不通用。

OpenID 是此网站上或应用中唯一对应用户身份的标识，网站或应用可将此 ID 进行存储，便于用户下次登录时辨识其身份，或将其与用户在网站上或应用中的原有账号进行绑定。

https://wiki.connect.qq.com/%E8%8E%B7%E5%8F%96%E7%94%A8%E6%88%B7openid_oauth2-0

从正文看，楼主其实已经选择了写真的了。剩下的只是怎么写的问题。

建议：
1、项目经历里，重点写你在 IT 行业期间的经历，其他行业的放在末尾略写，让看简历的人专注看 IT 的经历。工作经验也如实写你在 IT 行业的年限。
2、如果担心别人会因为你中途转行淘汰简历，可以加一段文字专门说明下。

基本上招聘的目标是找到能力匹配、薪资匹配的人。至于是不是中途转行，不纠结的自然不纠结，纠结的你也改变不了什么。

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

主要还是岗位需求引起，测开由于人力有限，基本要自己包办完整系统，所以技能相对全栈；但由于内部系统相对复杂度、性能要求等都比较低，所以深度上其实比较难钻下去，也没太大的需要。当然部分比较前沿的测试还是有需要的，比如 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 年深圳大会，腾讯有同学分享过类似的东西。