测试前的准备要到位
很多人一接到任务就急着点“运行”，结果测到一半发现环境没配好，数据不对，或者版本压根不是最新的。比如上周我们组有个同事测登录功能，跑完才发现用的是上个月的测试包，白忙活一场。测试开始前先把环境确认清楚，数据库是不是清空了，配置文件有没有改对，网络条件是否符合场景要求，这些细节省不了。
另外，测试用例也要过一遍。别以为文档写好了就能照着点，实际执行时经常会遇到用例描述模糊、步骤缺失的情况。提前和产品经理或开发对齐关键路径，避免中途卡住。
执行时别只盯着预期结果
很多新手测试员只关心“能不能通过”，按钮点了有没有弹窗，接口返回是不是200。但真实项目里，问题往往藏在边角里。比如用户上传头像，功能是能传，但上传过程中页面卡了三秒，这种性能问题容易被忽略。还有日志有没有打，异常情况下的提示语是不是友好，失败重试机制有没有生效，这些都得留意。
有一次我们上线前做回归测试，所有用例都通过了，结果上线后用户反馈注册收不到验证码。查下来是测试环境的短信网关配置成了模拟模式，根本没走真实请求。从那以后，凡是涉及第三方服务的，我都得确认实际调用链路通不通。
数据隔离和清理不能偷懒
多个测试并行跑的时候，数据混在一起很容易出问题。比如两个同事同时测订单流程，共用一个测试账号，一个删了订单，另一个的后续步骤就断了。建议每人用独立账号，或者用自动化脚本动态生成测试数据。
测试结束后的数据清理也得跟上。特别是涉及支付、用户信息的场景，测试数据留在系统里不仅占资源，还可能泄露敏感信息。我们现在的做法是每个测试批次结束后自动触发清理脚本，把临时用户、测试订单批量清除。
记录问题要具体
提 bug 的时候别只写“登录失败”，这种描述等于没说。要说清楚什么时候、在哪个页面、输入什么数据、点击哪个按钮、出现什么现象，最好附上截图或日志片段。开发看到“安卓14，小米13手机，输入正确密码后点击登录，提示‘网络异常’，但Wi-Fi正常，抓包显示请求未发出”这种信息，排查效率立马提升。
关注非功能性的表现
除了功能能不能用，还得看响应速度、内存占用、多设备兼容性。比如同一个H5页面，在旗舰机上流畅，在千元机上卡顿严重，这就是问题。我们之前做过一次压力测试，模拟500人同时提交表单，结果服务器直接502，赶紧让后端加了限流和队列处理。
还有界面适配问题，横屏竖屏切换时按钮错位，输入法弹起遮挡表单，这些在小屏幕手机上特别常见。光在模拟器上看不够，得拿真机试试。
自动化测试别盲目追求覆盖率
有些团队为了指标好看，拼命写自动化脚本，结果维护成本极高。页面元素一变，几十个用例全挂。真正稳定的模块才适合自动化，比如登录、注册这类基础流程。频繁变动的功能，还是手动测更灵活。
写脚本时也注意别把断言写得太死。比如验证文本内容，不要直接判断“必须等于‘操作成功’”，万一哪天改成“已成功完成操作”就报错。可以用包含判断：
assert response.text.contains("成功")