项目上线前的测试阶段，总能看到测试人员在埋头点系统，而开发则在一旁改代码。有人觉得测试是测试人员的事，开发只要写好代码就行。但在实际工作中，尤其是数据库相关的应用里，这种想法很容易踩坑。
测试不是点点页面就完事
比如一个订单系统，测试要验证下单后库存是否正确扣减。表面上看是前端操作，背后却涉及数据库事务、触发器、存储过程。如果开发写的SQL有逻辑漏洞，比如没加锁导致超卖，光靠测试点界面很难第一时间定位问题根源。
开发懂底层逻辑，能更快排查
当测试发现数据不对时，开发可以直接查数据库日志、分析执行计划。比如一条更新语句没生效，测试可能以为是接口问题，开发一看才发现是WHERE条件用了NULL判断，而字段允许空值。这种细节，不熟悉代码的人容易绕远路。
有些测试必须开发动手
像数据库迁移脚本的验证，往往需要写临时SQL比对新旧数据。这类工作交给测试，既不现实也不高效。更别说性能压测时，需要调整索引或分库分表策略，没有开发介入根本推进不了。
SELECT o.order_id, i.stock
FROM orders o
JOIN inventory i ON o.item_id = i.item_id
WHERE o.create_time > '2024-04-01'
AND i.stock < 0;协作比分工更重要
理想的状态不是开发写完丢给测试，而是双方一起设计测试用例。比如开发知道某个字段在特定条件下会触发异步更新，就会提醒测试注意延迟场景。这种信息同步，能避免很多“我以为没问题”的尴尬。
数据库操作不像普通功能那么直观，数据一旦出错，修复成本很高。开发早点参与测试执行，不是添乱，而是把问题拦在上线前最有效的办法。