这个为啥要匿名呢？

后面找到了另一篇，写得更全，也分享下：
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、遇到问题，不要给自己设限。像火影里面的鼬说的 “并不是成为火影的人就会被大家所认可，而是被大家所认可的人才能成为火影。” ，不是因为是测试领导所以可以打通整体测试开发，而是能打通整体测试开发所以能当上领导。可能具体工作上确实不需要你去做打通整体测试开发的事情（这里面会有利益问题在，有时候水会比较深），但在视野和思考上，不需要给自己加这些限制。

比如查验证码、redis 等中间件常用查询语句（如查当前用户的相关数据）的一键查询、异常场景数据/场景的构造。

不过相比做成小工具，更建议直接内嵌到被测应用中，作为一个独立的调试设置相关模块（类似于 android 的开发者选项这种），这样开发测试都可以很方便地去使用，避免分开维护不同步。

没那么简单，规模比较大的内容类社区，一旦被发现内容违规，会被网警先直接关站的。

去年已经折腾了一遍，社区停止服务了 1 个多月，折腾不起了。

bug 已修复