干了10年测试,最值钱的不是那些高大上的框架,而是这些每天都在用、但很多人没用明白的土办法。
今天整理一份我自己的工具清单:Excel怎么用、自动化怎么起步、测试报告怎么写,全部可以拿来直接用。
很多人觉得Excel是文员用的。错了。测试员每天跟用例、数据、报告打交道,Excel用得好,一天能省两小时。
测试员高频Excel函数速查表
进阶技巧:用数据验证(数据 → 数据验证)给"严重级别""优先级"做下拉菜单,从源头防止填错。报告里再也不用对着"P3还是P4"纠结。
手工统计Bug:先筛选、再分类、再数数,半小时没了。用数据透视表:选中数据 → 插入 → 数据透视表 → 拖字段,3分钟出结果。
我习惯把"模块"放行、把"严重级别"放列、把"缺陷ID"放值,一张表同时看出:哪个模块Bug最多、哪个级别占比最高。
选中通过率列 → 条件格式 → 色阶。红色=低,绿色=高。一眼扫过去,哪里有问题全暴露。
很多人一上来就学Pytest、学Jenkins、学K8s,结果三个月还在装环境。我的建议相反:先找最痛的重复劳动,用最笨的方法解决它。
import requestsresp = requests.get("https://api.example.com/login",params={"user": "test01"})assert resp.status_code == 200print("接口正常,耗时", resp.elapsed.total_seconds(), "秒")
不用框架,不用平台。一个脚本先跑通,你才真正理解"自动化"是什么。之后再加断言、加数据驱动、加报告。
避坑提醒:UI自动化别一上来就全量做。页面改一次,脚本废一半。先做接口和数据的自动化,UI只覆盖最核心的几条路径。

同一轮冒烟测试,三种方式耗时对比(示意图)
测试报告不是写给自己看的,是写给开发、产品、老板看的。写不明白,你的努力就白费。
【模块】操作 + 条件 → 实际结果,预期结果
反例:页面报错了(谁看谁知道在哪)
正例:【登录】输入正确账号密码点击登录 → 提示"系统繁忙",预期应进入首页
第一张:测试范围与通过率。
第二张:Bug分布(按模块 + 按级别)。
第三张:遗留问题与风险,必须写明"影响范围 + 建议上线判断"。
老板只看结论,开发只看归属,产品只看风险。三张表刚好各给一方。
最后一句大实话:
工具不重要,把重复的活变少才重要。
这10年我最值钱的经验,不是会用多少工具,
而是永远在琢磨:这件事能不能少干一遍?
觉得有用,点个"在看",转给正在写报告的测试同行。