软件测试必备：每天5分钟掌握SQL查询与INSERT数据操作-北京尧图网络

做软件测试尤其是功能测试和接口测试的早晚会遇到一个躲不开的场面你刚提交了一个bug开发回复“数据是正常的你再去库里看看”。这时候你打开数据库管理工具面对一张表却连“查出来给我看看”都做不到空气就会突然安静。所以哪怕每天只花5分钟SQL语句里的表查询和增加命令也值得测试人员认真过一遍。这篇内容就把SQL里最简单的两类命令拆开讲查SELECT和增INSERT。不是要你变成数据库专家而是把测试工作中最高频用到的写法讲透再配一套每天5分钟的训练安排让基础薄弱的人几周内就能写对查询、做好数据验证甚至能自己造测试数据。适合刚入行软件测试、准备面试、或者做了几年功能测试但一直靠“复制别人SQL”过日子的朋友。1. 测试为什么要先学查询和增加两条命令撑起半个日常1.1 查询命令是测试的“眼睛”功能测试做了半天页面上的提示都正确你真敢说这个功能没问题吗我见过不少新人注册流程跑通了就报“通过”结果开发一查库手机号字段存错了或者时间少了8个小时。这类问题在页面上根本看不出来必须靠SELECT语句去表里核实。注册功能来自是测试人员最常遇到的一类场景页面提示注册成功这只是第一步。真正的断言往往要落到数据库——打开用户表执行一句SELECT确认username、phone、create_time这些字段是否和测试数据对得上。只有这一步过了用例才能算真正通过。所以我一直觉得查询命令就是测试人员的“眼睛”。学会SELECT你在项目中就有了独立的判断力不会开发说什么就信什么也不会对着一个异常数据干瞪眼。很多线上问题排查到最后其实就是一句SELECT看数据的事。1.2 增加命令让你从被动等数据变成主动造数据测试过程中还有一个高频痛点没有合适的测试数据。想测“已实名用户才能购买”的流程翻遍测试环境找不到已实名账号想测列表分页表里只有3条数据根本凑不出第二页。这个时候如果你只会问开发“能不能帮我插一条数据”节奏就完全被别人拿捏了。而INSERT语句就是解决这个问题的钥匙。自己往表里加一条符合前置条件的数据被测流程立刻就能跑起来。这不是什么“偷懒技巧”是测试人员该有的基本能力。你在测试环境自己造数据、自己清理数据本来就是工作的一部分。说实话我从功能测试转到自动化测试、再到带测试团队最明显的感觉是那些能自己造数、自己查数的人遇到问题从来不会干等。他们先自己去库里看看实在看不出来再找开发。这种主动性几乎就是测试工程师分水岭。1.3 测试岗位对SQL的真实要求层级我面试测试候选人时从来不要求对方能写多复杂的多表关联SQL。但下面这四件事至少得会三件能读懂开发写的SQL排查问题时能理解对方在查什么。能自己从一个表里查出需要的数据加条件、排序、限量。能自己构造测试数据用INSERT把前置数据准备好。能验证数据是否正确落库一般就是把INSERT和SELECT搭配使用。看清楚测试岗位要的从来不是“数据库开发”水平而是“够用且准确”。你不需要背所有函数不需要懂存储过程优化但你要能流畅地把“查出来看看”和“造一条数据”这两件事做对。这就是本文标题里“每天5分钟”能成立的原因——学习范围本就是有限的。2. SELECT 查询命令测试岗位最常用的几种写法和为什么2.1 最基础的查询长什么样SELECT 指定列还是 SELECT *先说语法骨架SELECT 字段1, 字段2 FROM 表名 WHERE 条件;测试同学的新手期最常写的是SELECT * FROM 表名;把整张表所有列都拉出来。这个写法用于快速看全貌没问题但日常验证数据时我并不推荐你一直用它。原因很简单一张业务表动辄几十个字段SELECT *会把不相关的列全甩在你面前真正的关键字段反而被埋没。比如你要验证用户注册关心的就是username、phone、status、create_time四个字段那就明确写出来SELECT username, phone, status, create_time FROM user WHERE username test_001;结果干净、清晰一眼就能核对。另一个隐藏好处是当你对着一张列很多的表时写清字段名能逼自己想清楚“我到底要验证什么”这对测试用例设计是有帮助的。还有一个比较冷门但很实用的写法SELECT 1;。它不查任何表只用来确认数据库连接是否正常。测试环境切换数据库、排查连接问题时先跑一句这个能快速排除连错库的可能性。2.2 WHERE条件不只是“等于”测试更常用这几类运算符WHERE是用来过滤数据的它解决的场景是数据太多我只想精确看某一条或某一类。测试里最常见的条件有这么几类。精确匹配用的就是等号和不等号SELECT * FROM order WHERE order_no SO20240601001; SELECT * FROM user WHERE status ! 0;模糊匹配用LIKE这个在测试里出现频率很高。你只知道订单号前缀是“SO2024”想把这批单子都拉出来就可以写SELECT * FROM order WHERE order_no LIKE SO2024%;%表示任意字符放在前面就是“以什么结尾”放在两边是“包含什么”。在集合里匹配用INSELECT * FROM user WHERE status IN (0, 1, 3);范围查询用BETWEEN检查金额、时间区间的时候最顺手SELECT * FROM payment WHERE amount BETWEEN 100 AND 500;组合条件就是AND和OR连用但这里有一个几乎所有人初学都会踩的坑AND优先级比OR高不加括号的话查询条件会被拆得很奇怪。比如你想查“状态为1且金额大于100或者状态为3”的记录如果写成SELECT * FROM payment WHERE status 1 OR status 3 AND amount 100;实际执行的意思就变成了“status为1或者status为3且金额大于100”和你的预期完全不同。正确写法要给OR条件加括号SELECT * FROM payment WHERE (status 1 OR status 3) AND amount 100;测试人员写条件查询一定要自己在心里翻译一遍逻辑别把条件堆上去就以为万事大吉。再说一个NULL的判断这个坑十个人里九个踩。查询某个字段为空的数据写成WHERE status NULL永远查不到结果因为NULL不参与等值比较。正确写法是SELECT * FROM user WHERE status IS NULL; SELECT * FROM user WHERE status IS NOT NULL;你在测试环境明明看到某条数据该字段是空的用等号一查却是空白多半就是写错了这个地方。2.3 排序、去重、限量让查询结果更像一份测试报告拿到查询结果之后你经常还要做二次处理。比如看最新的一条记录、看金额最大的记录、看有没有重复数据这时候就要用到排序、去重和限量。排序用ORDER BY配合ASC升序和DESC降序。测试中检查最大最小、最新最旧时很实用SELECT order_no, amount FROM payment ORDER BY amount DESC; SELECT * FROM user ORDER BY create_time DESC;去重用DISTINCT。比如你要确认商品表里SKU是否出现了重复记录SELECT DISTINCT sku FROM goods;限量在MySQL里用LIMIT在SQL Server里用TOP。这一点很多跨数据库学习的测试人员会记混。MySQL写法SELECT * FROM user LIMIT 5;SQL Server写法SELECT TOP 5 * FROM user;在功能测试中LIMIT最常用的场景就是分页验证。页面每次展示10条数据你就用LIMIT 10看前10条核对顺序和字段内容。这三样技能组合起来你就能写出像样的测试查询了。下面这个语句是功能测试中很典型的“组合拳”先过滤掉无关数据再按时间倒序最后只看前10条。SELECT order_no, amount, create_time FROM payment WHERE status 1 ORDER BY create_time DESC LIMIT 10;执行顺序是先定位到表然后通过WHERE过滤行再按指定字段排序最后限制返回条数。SQL的书写顺序和执行顺序不一样但测试阶段你只要记住“先过滤、再排序、后限量”这个口诀就够用了。2.4 查询语句在测试用例里的典型用法光会写语法还不行得知道什么时候用。我挑几个测试用例里最常见的查询场景。第一个是数据落库断言。注册一个新用户后去用户表验证脚本页面上显示成功不重要重要的是user表里真的多了一条记录且字段内容正确。这种场景就是“INSERT完之后SELECT出来比对”这也是为什么标题里把查询和增加配成一对的原因。第二个是状态流转验证。订单支付后订单表里的status字段应该从1变成2。执行SELECT status FROM order WHERE order_no SO20240601001;返回结果是你期望的2用例才算通过。页面上的“支付成功”可能写死了只有数据库里的状态才是诚实的。第三个是列表数量核对。页面显示“共有5条记录”接口返回的total是5数据库里实际有多少用COUNT(*)最直接SELECT COUNT(*) FROM user WHERE status 1;COUNT(*)返回的是行数这是测试人员常用的聚合函数面试也经常考。它不查具体内容只回答“到底有几条”这个问题做数量断言正好。3. INSERT 增加命令两种写法的差别与测试场景下的正确姿势3.1 完整字段写法最稳妥任何时候都推荐聊完查接下来聊增。INSERT的作用就是往表里增加一行数据。最基础、也最推荐的写法是把字段名列出来再一一对应写值INSERT INTO user (username, phone, status) VALUES (test_001, 13800138000, 1);这句SQL的意思很直白在user表里新增一条记录username字段填test_001phone字段填13800138000status字段填1。这个写法在测试工作中几乎可以覆盖所有造数需求。为什么我一直推荐完整字段写法因为它明确表达了“我要给哪些列赋值”即使表结构有几十个字段你只写了三个其他没写的字段就会用默认值或NULL。这个行为是可预期的、可控的。这里有几个细节必须注意。字符串和日期类型的值一定要加单引号数字类型可以不加这是新手最容易翻车的地方。自增主键不要出现在字段列表里一般让数据库自己生成你写进去反而容易报错。字段顺序和VALUES里的顺序必须一一对应这个顺序是可以打乱的只要你前后对应就行。比较隐蔽的一个坑是有些测试同学从开发同学那里抄了一段INSERT没看字段就直接用结果写出来的数据其实被放到了错误的列里。因为数据库在字段类型匹配时比较宽容比如两个字符串字段你把username和phone的值互换了位置它根本不报错。所以每写完一句INSERT我都建议你紧跟着回头看一遍字段对应关系。3.2 省略字段写法省事但暗藏隐患第二种写法是省略字段列表直接把所有值按表结构顺序列出INSERT INTO user VALUES (test_002, 13800138002, 1);这种写法在表结构简单、字段顺序明确的时候确实省事但它有三个隐患测试环境里我一般不建议用。第一个隐患是它要求你把表的所有列都写出来包括自增主键。如果表有8个字段你VALUES里也必须写8个值少一个都会报错column count doesnt match。表结构越复杂这种写法越容易出错。第二个隐患也是更严重的是它不是“列名对应”而是“位置对应”。表结构一旦调整了字段顺序你的老INSERT语句不会报错但值会全部插到错位的地方。这种错误特别阴险因为数据表面看是“进去了”实际上全是脏数据后面用SELECT查的时候会被带偏。第三个隐患是如果你不清楚表里还有哪些列省略字段写法很容易漏掉那些有默认值或非空限制的字段执行时直接报非空约束错误或默认值不符合预期。所以我的建议很简单测试环境自己做数据坚持用完整字段写法。别图省事省下的几秒钟可能换来半小时排错。3.3 一次插入多条数据测试造数的高效手段功能测试里经常要造批量数据比如测分页需要三五十条记录一条一条INSERT能点到手软。这时候可以一次性插入多条INSERT INTO user (username, phone, status) VALUES (test_001, 13800000001, 1), (test_002, 13800000002, 1), (test_003, 13800000003, 1);这个写法在MySQL、PostgreSQL、SQL Server里基本通用只是个别老版本SQL Server可能不支持具体以你们项目实际库为准。实测下来一次插几十条完全没问题效率比逐条执行高很多。如果碰到要造几百条的极端场景我会在测试工具里写个循环脚本不断拼这种多行INSERT或者用存储过程生成。不过这是后话了初期你先把三五行的手工多行插入用熟已经能解决80%的分页测试需求。有一件事必须放在心里在你执行INSERT批量造数之前先想清楚这些数据后面用不用得到。测完之后最好自己清理掉别在你的测试库留下大量垃圾数据。这也是为什么我说测试人员对数据库的操作边界感要强——不是所有数据都能随手乱加的。3.4 数据插入后如何确认没插错结合SELECT验证INSERT和SELECT从来不是孤立使用的。我自己的标准工作流是三步走。第一步插入前先查询同条件的数据是否存在。万一测试环境里已经有一条相同username的数据你再插一条主键冲突直接报错或者因为唯一索引原因插不进去。就算不是唯一索引造重复数据也会污染后续查询结果。所以先跑一句SELECT * FROM user WHERE username test_001;确认结果为空再执行INSERT。第二步插入后立刻回查SELECT * FROM user WHERE username test_001;看到这条数据实实在在出现在表里字段值也正确这次INSERT才算真正成功。第三步如果回查查不到不要慌按顺序排查几个常见原因是不是插入语句执行报错了是不是当前事务没提交是不是连错库了有些测试环境配置了触发器或默认值插入后数据被自动修改了也有可能。这时候把SELECT的条件放宽先按字段值模糊查再看是不是被触发器改了状态。“插入后回查”这个习惯是我带新人时反复强调的。很多测试同学执行完INSERT看到“Query OK”就以为完事了等用例跑挂了才发现数据根本没进去或者内容不对。多花三秒钟回查一下能省掉后面一长串排查时间。4. 每天5分钟的训练安排从只会看数据到独立完成验证4.1 先准备一张练习表和十几条数据空谈语法不如动手练。学习SQL最好有一个能随便折腾的练习环境。我建议你三条路选一条本地装一个MySQL或SQL Server都行或者用测试环境里一张你熟悉的表再不然用SQLite这种免安装的轻量库起步。关键是有一张表、有数据、有执行窗口练错了也不心疼。为了练习方便可以建一张简单的用户表包含这几个字段字段名类型说明id自增整数主键username字符串用户名phone字符串手机号status整数状态1正常 0禁用amount小数账户余额create_time时间创建时间往里插入十几条不同状态的数据有正常用户、有被禁用的、有余额为0的、有余额上千的数据越杂练习越有效果。之后每天的5分钟训练都在这张表上进行。这里多说一句如果公司测试环境没有自己的练习表你就找实际业务表练但只做SELECT别随便INSERT。做增操作之前先找leader确权拿到可写权限再用。4.2 第一周只做SELECT把基础打牢第一周的目标是不看任何参考能独立写出基础SELECT。第一天SELECT * FROM user;看全部数据熟悉表结构。第二天SELECT username, phone FROM user;学会只取需要的列。第三天SELECT * FROM user WHERE username test_001;精确查找一条。第四天SELECT * FROM user WHERE status 1 AND amount 50;组合条件过滤。第五天SELECT * FROM user ORDER BY create_time DESC LIMIT 5;按时间取最新几条。五天下来你已经能应对“查数据”的基本需求了。每天5分钟其实只够写三条SQL、看一遍结果但坚持一个星期手感和肌肉记忆就建立了。这比周末花三小时死记硬背语法要有效得多。4.3 第二周加入去重、统计和模糊查找第二周开始加入函数和运算符目标是能回答“有多少条”“哪几个状态”“名字像什么”这类业务问题。第一天SELECT COUNT(*) FROM user WHERE status 1;统计正常用户数量。第二天SELECT DISTINCT status FROM user;看看表里一共有哪几种状态。第三天SELECT * FROM user WHERE username LIKE test%;模糊匹配用户名。第四天SELECT * FROM user WHERE status IN (0, 1) AND amount BETWEEN 10 AND 100;组合IN和BETWEEN。第五天把你工作中真实遇到过的“想查但不会查”的需求列出来逐个匹配语法。第五天这个练习特别推荐。你在项目里一定有无数个瞬间想着“这个数据如果我能查一下就好了”把它们记录下来就是最贴合你工作场景的练习册。SQL不是你学会语法再去套业务而是业务倒逼你把语法用熟。4.4 第三周上手INSERT并养成回查习惯第三周开始做增操作目标是能独立造数并且造完能自己确认。第一天用完整字段写法插入一条用户数据然后用SELECT回查。第二天一次插入3条数据回查确认3条都在。第三天故意把一个字符串的引号去掉观察报错信息理解引号的作用。第四天尝试插入一条status为空的数据然后查一下NULL显示效果。第五天模拟一个场景——先造一个状态为1的已支付用户再查询他的订单列表前提是相关表有关联数据。我特别鼓励你第二天和第三天。很多人学INSERT只学“怎么写”不学“写错了怎么办”。而实际工作中你的INSERT一定会报错报错信息才是你最好的老师。把常见报错都遇到过一遍以后就不会怕了。4.5 第四周综合挑战和面试题自测第四周开始做综合题把前面积累的能力串起来按状态分组统计用户数量。查出余额最高的用户。查出用户名重复的用户记录。先造10条测试订单数据再按订单状态查询并排序。自己给自己出一道“验证注册功能”的题插入一个新用户立刻回查核对字段。这五天做下来你已经具备了独立完成“数据验证”和“测试造数”这两项核心能力。一个月后回头看你会发现之前连数据库工具都不太敢打开的自己已经能自信地在群里回复开发“数据我查过了确实有问题这条记录在这里。”5. 容易写错的SQL细节和测试面试常见考法5.1 测试人员高频写错的三处语法第一字符串漏写引号。这是新手报错率最高的点。WHERE username 张三会直接报列不存在因为“张三”被当成了字段名。正确的做法是用单引号包裹字符串WHERE username 张三。注意有些同学习惯用双引号在MySQL严格模式下双引号也会被当成字符串但为了兼容性统一用单引号最稳。第二中英文标点混用。从Word、微信聊天记录里复制SQL时最容易把括号、逗号、分号复制成全角符号数据库直接报语法错误。你盯着看半天都看不出问题因为肉眼分辨不出来。我的习惯是SQL一律手敲不复制复制来的先检查一遍符号再执行。第三表名或字段名和关键字冲突。user、order、status、desc这些词在有些数据库里是保留字直接使用会报错。MySQL里用反引号括起来可以解决SELECT * FROM order WHERE status 1;SQL Server则用方括号SELECT * FROM [order] WHERE [status] 1;这个问题在老系统里尤其常见所以看到order表别惊讶加上反引号就好。5.2 面试中考的SQL题其实万变不离其宗软件测试面试特别是银行、金融、电商类项目SQL几乎是必问项。我见过的面试题来来回回就是这几个套路统计数量SELECT COUNT(*) FROM user WHERE status 1;去重统计SELECT COUNT(DISTINCT username) FROM user;按状态分组统计SELECT status, COUNT(*) FROM order GROUP BY status;取最大金额记录SELECT * FROM payment ORDER BY amount DESC LIMIT 1;查找重复数据SELECT username, COUNT(*) FROM user GROUP BY username HAVING COUNT(*) 1;注意上面的HAVING是用来过滤分组结果的它和WHERE的区别是WHERE过滤的是原始行HAVING过滤的是分组后的结果。这个区别面试官很喜欢追问你能一句话说清分就拿到了。面试官真正想看的不是你会不会背语法而是你能不能把一个业务问题翻译成SQL逻辑。比如他问“每个状态下的订单数量分别是多少”你脑子里先想按状态分组然后数每一组有多少行然后写GROUP BY COUNT。这个翻译过程比默写重要得多。至于SQL注入这类安全相关的问题面试偶尔会问“什么是预编译”“为什么不能拼接SQL”测试同学理解到“SQL拼接会导致安全风险参数化查询可以避免”这个程度就够了不用往深处钻。先把最基础的查询写对安全话题属于加分项不是必选项。5.3 从“每天5分钟”到真正上手下一步还能学什么把查询和增加练熟之后SQL的下半程通常是三件事UPDATE改数据、DELETE删数据、JOIN多表关联。UPDATE在测试中的典型用途是修改状态流转数据比如把一个订单直接改成“已取消”用来测试取消后的展示逻辑。DELETE主要用于清理自己造的测试数据但执行前一定要确认WHERE条件足够精准不然误删全表就是重大事故。我见过不止一次因为少写条件把整张表清空的案例所以个人建议测试环境也要养成先SELECT确认范围、再执行DELETE的习惯。JOIN则是多表查询的入口。比如订单表里只有user_id你要在结果里同时显示用户名就得关联用户表SELECT o.order_no, u.username FROM order o JOIN user u ON o.user_id u.id WHERE o.status 1;掌握了JOIN你排查数据问题的能力会再上一个台阶很多“开发说数据没问题但页面就是不对”的疑难问题最后都是靠JOIN拼出完整链路才定位到的。但请记住贪多嚼不烂。先把查询和增加这两类命令用成本能再往外扩。试想一下你连最基础的SELECT都没跑熟就开始研究JOIN和存储过程遇到报错根本不知道是基础语法问题还是关联逻辑问题排查起来会非常痛苦。我个人带新人的经验是能把单表的增查用对、用稳就已经超过相当一部分测试从业者了。很多人工作了三五年遇到要查数据库还是只会截图给开发甚至只会在界面上点点点。你每天花5分钟一个月后就和他们拉开了差距。SQL没有想象中那么神秘它就是你和数据之间的对话而对话的第一步就是敢开口问一句“喂表里到底有什么”

软件测试必备：每天5分钟掌握SQL查询与INSERT数据操作

相关推荐

2026前端面试题大全：核心原理、工程实战与AI时代出路解析

电压基准芯片国产替代实战：零改板PIN TO PIN替换与选型验证指南

二次元角色技术拆解：从建模、骨骼动画到数据可视化实战

更多资讯

试验机控制器高分辨率模拟前端：从应变电桥到ADC的低噪声设计

OpenClaw小龙虾 Windows版部署教程：解压即用，把 settings 改到 TaoToken

把上下文讲清楚，Claude Code 才能少走弯路：CLAUDE.md 与 subagent 配置实战

【Bug已解决】Windows Codex Desktop 连接 Windows OpenSSH 远程项目：把 auth.json 改到 TaoToken 的完整配置

产品更新丨谷云 AI Agent 智能体版本更新：MCP 与 OpenAPI 接入 TaoToken 实践

微信匿名投票小程序制作全流程：从班干部选举到员工互评

今日更新

开源模型端侧落地实战：量化、推理加速与Agent上下文管理

AI Evals实战指南：从零搭建LLM应用评估体系与CI/CD集成

Java采购管理系统实战：从数据库设计到事务一致性

本周精选

如何彻底离线使用 Laya-CoreML：Hugging Face 下载、缓存机制与 local_files_only 详解

基于1Panel 部署MySQL MCP 服务：TaoToken 统一 Key 接入与 config.toml 配置实战

崇州园区营销网站建设避坑指南：5大注意事项保备案安全

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？