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

既然你已经明确了接口自动化是下一步这个平台需要的功能，建议：
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 这个文件么？

我觉得还有一个很重要的能力，说服别人或者推动事情的能力。

比如一些开发觉得不是 bug 的 bug ，需要有技巧地快速沟通解决。

OK，理解。确实要做完整平台还有比较多配套的东西，而且不见得通用。

建议可以先按 3 的，分享下案例，这样后续大家使用的时候可以少走弯路。

vue3 里，computed 也可以加 setter 了：

https://v3.cn.vuejs.org/guide/computed.html#%E8%AE%A1%E7%AE%97%E5%B1%9E%E6%80%A7%E7%BC%93%E5%AD%98-vs-%E6%96%B9%E6%B3%95

如果你的场景下，计算出来的新属性和原有属性之间并不是强关联（任意一边变了，都需要另一边立即响应产生相应改变），那用 watch 更好，提供的操作会更自由。

挺不错的工具，思路上我觉得很认可，通过工具协助大家熟悉代码细节，挺不错的，而且解决了 jacoco 无法区分调用者，以及远程调试加断点会影响其他人使用的问题。

有几个疑问，想确认下：
1、标题提到有 影子数据库 ，这个正文好像没见到，具体大概是怎么用，原理是怎样的？
2、目前提供的数据，如果不进行二次加工（比如结合代码编辑器着色），其实用起来体验会比较差。楼主有计划后续进一步完善查看数据这部分体验么？
3、楼主在实际项目中应该有进行实践落地吧，后续是否可以分享下这方面的一些案例，方便大家学习下？

从你用过的技能点来说，基本上测开需要掌握的你大部分都有掌握。但在技能点之外，测开的软能力方面没有看到相关的体现。

建议：
1、“丰富的测试经验”!=“很久的测试经历”，可能 1-2 个大型复杂项目的测试经历，就可以给你带来丰富的经验了。

2、代码能力并不是只能用来做开发，也可以用来理解被测应用的实现逻辑。不知道你在测试前是否有花时间去先看看开发整体技术方案是怎么实现的，然后根据你的代码经验，评估什么地方风险比较大需要重点测，什么地方风险不大过一下流程即可，来提高测试效率？有代码能力的前提下去看开发代码，既能帮你熟悉开发逻辑，也能让你了解别人的好代码怎么写的，性价比很高。

3、遇到问题，不要给自己设限。像火影里面的鼬说的 “并不是成为火影的人就会被大家所认可，而是被大家所认可的人才能成为火影。” ，不是因为是测试领导所以可以打通整体测试开发，而是能打通整体测试开发所以能当上领导。可能具体工作上确实不需要你去做打通整体测试开发的事情（这里面会有利益问题在，有时候水会比较深），但在视野和思考上，不需要给自己加这些限制。