测试前先理清楚需求
很多人一接到任务就急着点开工具开始测，结果测到一半发现理解错了功能逻辑。比如你朋友让你帮忙测试一个登录页面，说是支持手机号和邮箱登录，结果开发只做了手机号。如果你没提前确认需求，测出“邮箱不能登录”反而成了无效缺陷。所以动手前花十分钟看看文档，或者直接问一句“这个功能到底要实现啥”，能省下不少返工时间。
环境配置别图省事
测试环境不干净是常见坑。比如你在公司内网测得好好的，一上生产环境就报错，可能只是因为DNS没配对。还有人用自己电脑测移动端H5页面，忘了关代理，结果所有请求都走不通。建议每次测试前检查浏览器版本、网络设置、账号权限这些基础项，尤其是涉及支付或权限的功能，别等到最后一刻才发现没权限操作。
数据准备要有边界感
测试不是随便填个数字就行。比如测一个年龄输入框，除了正常值18、30，还得试试0、-1、999甚至字母符号。有些系统对空格或特殊字符处理不好，用户一输个单引号就崩溃。数据清理也得注意，别测完一堆测试账号堆在数据库里，影响后续统计。可以建个表格记录用了哪些测试数据，方便回溯。
别忽略日志和错误码
页面弹个“操作失败”就截图提交，这是很多新手的做法。但真正有用的往往是后台返回的错误码。比如HTTP 400可能是参数格式不对，500才是服务端炸了。打开浏览器F12，看看Network里请求到底卡在哪一步。有时候前端没反应，其实是接口根本没调通，这时候光说“按钮没反应”就没法定位问题。
复现步骤写具体
提bug时写“点几下就崩了”等于没说。应该像教人做菜一样：第一步进哪个页面，第二步点哪里，第三步输入什么内容，第四步看到什么现象。比如：“1. 进入订单列表；2. 点击‘导出’按钮；3. 勾选全部100条记录；4. 点确定后页面白屏，控制台报内存溢出”。这样开发才能快速还原现场。
关注非功能性表现
除了功能能不能用，还得看用起来顺不顺。比如一个页面加载超过3秒，用户早就关掉了；上传文件时不给进度条，会让人以为卡死了。还有些细节，像密码框能不能复制粘贴，验证码有没有大小写提示，这些体验问题往往比功能缺陷更影响使用。
保留原始证据
截图别只截错误提示，要把整个页面上下文拍下来，包括URL和时间戳。必要时录个短屏，特别是那种一闪而过的弹窗。日志文件如果太大，至少截取关键段落。曾经有人提了个“偶尔登录失败”，但没留日志，等开发去看的时候问题已经消失了，最后不了了之。