业务数据构造

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

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

内嵌到被测应用得开发配合，这个思路在我们这很难实现，一个业务场景涉及 5 6 个团队，每个团队只负责自己的服务。

有考虑这个点，看来还是得针对构建数据痛点去考虑

我巴不得所有的都是一键搞定。。。

感觉可以来个造数据小工具，一些操作不便的测试场景都可以试试能不能做成工具。（拿社交软件举例子）

1. 模拟大批量的数据（大批量用户关注/大批量用户私信/增加账户金币）
2. 模拟快速清除数据（从已注册变为已注销，从已经实名认证变为实名认证）

常用场景吧，每次都得手工重复的，是很多场景的前置条件，总结总结，提炼一下，做成工具后，能明显感觉到提效成果。

从业务出发，能解决手工重复执行的操作，都可以实现成小工具。
一定要解决业务问题。有很多通用的小工具是不需要再造轮子的，比如有些测试平台喜欢做一个解析 JSON 的小工具，实际上工作中很多人习惯用 json.cn。

1. app 相关的 需求挺多，好多命令老忘 2.测试用例生成录制
2. 业务数据构造 大致
3. 提升 kpi 的，哈哈

提升 kpi 这个确实有

我整理了下评论，大多数建议大同小异，基于构建数据痛点去写小工具，大数据量、请求数据多层转换或加密、多个业务接口请求造单个数据、复杂的命令、客户端/app 机制一键点击。

补充一个我觉得很有用的，一键报 bug 。工具自动附上前 1 分钟操作视频（如果有），以及所有相关日志。测试只需要写下哪个位置不符合预期就足够，不用花那么多时间去写 bug 描述和找日志，也杜绝一句话 bug 的问题。

但这个可能超出 “小工具” 范畴了。

这个做出来不小，相关日志还得配合抓包但没法精确获取到出问题的接口，否则只是找前端 bug，大多数 bug 提交平台都有模板提交、复制 bug，重复性工作主要是这些。而且做出来只适用于 web 端，对于移动端、服务端测试没啥帮助。

倒不会只适用于 web 端，采集的时候客户端和服务端可以一起采集，也有助于开发辅助定位是哪个端的问题。

只是这背后对基建有一定要求，比如得弄个工具持续录制操作视频，记录客户端日志（接口请求及返回记录可以在日志里直接打印，就不用额外搞抓包）；服务端得有链路跟踪工具方便知道涉及什么服务、ELK 日志聚合方便获取全部相关服务的日志信息。

之前 MTSC 21 年深圳大会，腾讯有同学分享过类似的东西。

还得看提 bug 单的元素，我这边完全不适用，一个 bug 得写几分钟，还得经过研发、小组长审批，确认是否单测逃逸 bug、该阶段发现是否正常、严重程度也有硬性要求等，工具实现出来也得手写挺多东西，看不出明显的提效

你们这个确实快不起来，需要多人协作。

比如常用的 adb 操作，手机性能的监控，主要还是看自己公司的具体场景，从实际出发，解决痛点

一键自动提 bug 的确是好主意，对于自动化测试，由于操作步骤与预期已明确，测试执行失败的记录保持，自动上传即可

对于人工探索测试提 bug 还需要写明重现路径，否者开发人员不好定位

从减少重复工作，减少数据核对归纳整理，等方面考虑