造数工具 取数工具 (解析文本数据源或从网站爬)

自动化脚本自动生成工具 版本对比工具

excel 转 word 工具 还有各种流程机器人 总之就是怎么能偷懒怎么来。。

上一份工作，测试管理后台需要导入稍微正式的数据（excel 模板），后面用 Faker 和 xlrd xlwt typer 弄了个根据配置填充 excel 模板数据的库，后端使用了 graphql，借助 graphql-core typer 弄了 解析 graphql 文档的库，生成前端可用的 query 语句，sqlmap 支持的 http 扫描文件，burpsuite 录制文件（用于 sqlmap 批量扫描），
主要还是觉得一条条找稍微正式的数据填到 excel 费时间

1、接口数据 libsodium 加解密
2、HAR 一键解析出关键数据
3、redis 集群操作
4、其他业务造数能力

协议、压测、配置
检查配置，确保配置不出问题
协议的话覆盖功能测不到的点
压测就看性能、并发了

jmeter 为满足一些性能场景
yapi 修复一些 bug 一件新加一些功能
burpsuite 新增一些功能扫描高亮显示敏感信息

版本比较工具，各种数据库或 nosql 或接口或配置数据操作工具，api 测试的数据制造、驱动和校验工具，发消息，mock 工具，日志分析工具

MOCK 工具，数据库监控（针对数据变化快无法记录的情况）

测试工具还是比较初级的玩法，直接拿开源的东西，针对你们的业务做定制化开发就好了。一般都是做测试平台，形成一体化的测试体系，或是从降本提效的角度出来，在项目流程中解决遇到的各种问题，并能形成闭环！

对应不同的路径吧。

工作中发现有个很蛋疼的问题 -> 简单的脚本来提高效率降低难度 -> 发现周边大家都有这个问题 -> 把简单的脚本做得更加工程化，从脚本变成工具 -> 发现大部门也有这个问题 -> 把工具扩展成平台

上述情况一般在早期的阶段更多见，问题太多，大家各干各的，没有明显的测试中台概念。

调研业务线了解共性痛点 -> 针对内部具体痛点并参考业界做法来设计方案 -> 将方案平台化服务化 -> 在业务试点落地验证平台对问题的解决效果 -> 获得业务反馈，迭代平台 -> 平台更大范围的推广

上述情况是比较标准的中台做事方式，也是更加体系的做事办法，至少在逻辑上来说，上级会更加少挑战。

至此，已经回答了【你们会去尝试开发工具吗？都开发过哪些工具？一般是通过哪些方面思考？】第一个和第三个问题。

具体开发过哪些工具，这个看痛点，一些常见的列一下（只是我知道的，不代表是我做过的）：接口测试框架（且需要平台化）、度量大盘、监控平台、压测平台、造数平台、mock 平台、UI 自动化框架、云真机、遍历测试工具、各类测试能力平台、发布卡口平台…… 这里说的各种各样的平台它是没有固定形式的，要结合公司的研发体系才能决定它应该长什么样子。

适配业务的一套完整的质量保证体系所需的工具平台，不建议自己闭门造轮子，早期基于开源工具快速构建并落地，然后开始有针对性的开发相关插件和源码二次开发增强能力。当这套工具平台的用户使用量和使用时长已成为必选项且无法支撑业务的需要，再开始考虑重新的架构设计与升级