大概 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 已修复

听起来有点像埋点，有多个数据入口，最终数据汇聚到少数几个出口进行查看。

然后你和开发争论的 “用例没闭环” ，具体你的用例大概是怎样的，开发期望补充的用例是怎样的？

这个要看具体情况吧。

如果流程不算复杂，但很重要，可以有少量用例去过一遍全流程，看是否能完全走通。这有点类似于单测和集成测试的区别，每个模块单独测试都没问题，但连在一起可能就会出问题。

如果流程很复杂很长，那就基于这次的改动范围设定好起点和终点的，只走一遍改动范围涉及的流程。

这么说可能比较抽象，你可以分享下你们的完整流程以及本次改动涉及的模块情况不？这样可以给到更有效的意见。

第一次听到说用例要闭环这个概念。

我觉得你们开发想表达的，是缺少联通起来的完整业务流程测试吧？只是用词可能不大准确。

Android11 获取不到屏幕流，原因是 stf 官方未维护 Android 28 以上版本的 minicap.so

解决：

1. 手动下载对应版本的 minicap.so
   https://github.com/varundtsfi/Android12Support_withso/tree/main/aosp

2. 推送到手机

   adb -s 设备id push 下载路径 /data/local/tmp/
   

俗话说抛砖引玉，楼主不先把自己的砖抛一下？

经排查，原因是因为匿名用户这个虚拟用户没有实名认证造成的。

现在已经调整逻辑了，改为验证操作人真实用户是否有实名认证，有的话就可以发布。

这些接口的请求参数也都变了

可以具体说下参数是怎么变吗？具体解决办法需要看变化规律决定。

如果变化是 1:1 的（比如 a 值变为 b 值，或者 key a 变为 key b），结构不变，可以考虑把值抽离到全局配置变量里，每次更新变量即可。
如果变化是固定 1:n 的，那也可以采用类似上面的结构，只是变量值变化会大一些
如果变化是不固定、无规律的（比如接口数量可能会变，参数结构也可能完全不一样），可能参考 2 楼的说法，基于日志或者代理进行录制，想办法降低编写成本比你拿老脚本适配更有效。

这个是语言特性造成的。

python 不是强类型语言，没有强要求指定每个变量的类型。实际上每个变量的实际数据类型都是可以随时变化的。比如可以随时把一个原来存储对象的变量改为存储 int。

这种情况下，按你图 1 里的写法， ide 是推断不出来你这个变量是什么类型的东西，自然无法做方法提示。能推断出来的方法，要不是在程序运行时（毕竟里面有具体的值了，instanceOf 一下就知道类型了），或者是熟悉变量实际类型的人。

python 3.5 开始提供了类型注解支持 来让 ide 可以推断出实际的变量类型。你这种类似字典取值的写法，实际内部调用的是 __getitem__ 这个魔法函数，要做到类型提示的话，可以试试自己想办法重写 wb 这种数据类型里的这个魔法函数，加上类型注解支持。

学习了。

看了下，这是个应用了 page object 后比较常规的写法，没啥大问题，用例数量少的情况下基本够用了。后续用例数量多了或者执行多了后，可按需补充更多的能力。比如：

错误排查相关：
1、失败允许自动重跑
2、失败时自动截图及 dump 控件树，便于排查失败原因。有全程录屏最好。

长期运行维护相关：
1、全局配置管理。比如用户名、密码、执行设备、appium capibility 参数这些。这些参数最好既支持读取配置文件，也支持命令行乃至环境变量传入，比较灵活。
2、appium 实例管理。比如后续放到 jenkins 上，可能会一个节点同时多个自动化在跑。而 appium 目前暂时不支持并行多 session ，所以需要自行管理多个 appium 实例，包括自动启动、自动分配空闲端口号、自动关闭进程、自动记录日志。
3、框架与项目分离。多个项目使用时会存在多个仓库，此时升级框架部分的公共能力会非常困难。必须要把框架的能力独立出来单独的包中，项目通过依赖的方式进行引入，这样才能具备更好的维护性。

看了下原文，感觉有点啰嗦。。。

一、如何重现 （操作步骤、预期结果、实际结果） 

二、环境说明（机型、账号、网络） 

三、现象截图或视频 

四、请上传日志附件

内容上，我觉得基本有这几个就差不多了。至于优先级、分配人、bug 状态这些，基本上大部分缺陷管理系统都有，不大需要特别强调。

我觉得最基本的，是提供足够让开发本地自行重现此问题所需的信息；进一步的可以通过日志甚至具体代码逻辑等，提供有助于开发定位及解决问题的信息；终极的话，直接附上修复 MR 给开发 review 。

最痛恨那些啥也不写，一图流的。除非有另外沟通过开发知道怎么回事，否则真的是一脸懵逼，别人想协助回归验证下，都看不懂是啥 bug 。