把使用中的问题记录下来，并表述清楚这些问题严重影响效率，然后反馈得领导，借助领导的力量去推动平台维护方解决。当然就算解决确实不及时，也先用一段时间吧。

其实你第一句已经说的很清楚了，领导要强推这个测试平台（都和绩效绑定了，足够明显了吧），不管好用不好用都得用。那你的沟通就应该要先遵循这个大方向，然后在大方向下提问题和寻求解决方案。你提出用开源框架，和团队的大目标不一致，当然会被否决。

这是个开放性问题，更多看的是你的思考高度和对自己任务的理解。不知道楼主面得是什么岗位，如果是中级或以下，我觉得这个回答还算可以，不至于会直接否决。

如果楼主想复盘为啥面试没通过的话，建议还是综合评估，不要只是看这一个问题。对于这个问题，不同级别、不同业务领域、乃至于不同公司文化下，都会有不同的答案，没有标准答案的。就算有，那也不一定适合每个人，这里问的是个人的理解，而不是教科书标准答案。

实在改变不了环境，那就换环境吧。

你单独建个帖子，把你的详细操作步骤也补充贴上来吧。

光这样一个截图和错误日志，不好定位问题。我现在已经很少用 repeater 了，也没熟练到直接看日志就看得出问题的程度。

@A.D console 启动了么？文章顶部 console 相关的配置都配好了吗？

PS：请使用 markdown 排版

入网验收，入的是啥网？可以提供除了这 4 个字之外，更详细的描述么？

我能想到的就只有工信部对手机的入网验收，但不知道你说的是不是这个。

那就把冒烟测试调整一下，改为开发演示。验证的内容还是一样的（测试要提前提供这些场景对应的用例给开发），只是改为由开发操作，产品 + 测试在旁边看，确认流程可以通。

可以辅以允许开发排期里加入自测时间这样的手段进行推进。

自家 app，总归可以找开发弄一个单独的设置语言的菜单吧。

现在比较新的是结合 AI 进行智能化测试。大会上也有相关的分享，甚至有一些游戏的测试已经做到可以自动确认一些任务的主流程是否有问题了。但不知道楼主对 “令人激动的新技术” 的定义是什么？

1.手工点点点
2.写脚本代替手工点点点

你这里只包含执行测试相关的东西，质量保障可不只包含执行测试。

点赞，英文文章或者官方文档都是很好的教材，而且不得不承认，国外大部分的文章写起来条理性很足，前因后果都会交代地很清楚，相对来说国内大部分都是类似随笔那样，只记录个结论，但是为啥会这样，不一定会说。

cookies 一般 web 系统用比较多，自带超时时间等鉴权常用的配置，实现比较简单。
token 一般客户端除了 web 还包含 app 的用得比较多，因为 app 没有内置 cookies 机制，所以用 token 更方便。

大部分情况下，二选一就可以满足了。至于你的系统两个都用了，估计是历史原因吧，比如中途切换后为了保障兼容性之类的所以保留了老的方式。然后没有人继续跟踪把老方式完整下掉，所以老的方式就继续延续了。

额，这个可以变通一下，往多语言文案配置里弄 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

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