最近在系统梳理测试基础的时候我给自己排了一个每天学一点的计划。Day6这一天的任务是Linux和数据库。说实话刚开始我对这个安排有点疑惑——测试不是点鼠标、写用例、搞自动化吗为什么非要碰命令行和SQL直到后来在实际环境里被反反复复卡住我才明白这两门课不是“选修课”而是测试人员的“生存课”。这一天的学习目标也很明确不追求像运维一样精通Linux也不要求像后端一样写出复杂SQL而是要做到四件事——能看日志、能查进程、能连数据库、能写查询验证数据。这些能力才是测试工作里每天都会用到的基本功。这篇文章就把我Day6学的内容整理出来包括命令、场景、思路以及我踩过的坑希望能给同样在补基础的同学一些参考。1. 为什么测试的第一门“环境课”是Linux和数据库很多测试同行都有过这样的经历用例设计好了测试数据准备好了结果环境起不来或者接口一调就报错前端只给一句“服务器错误”剩下的全靠自己查。这时候手里只有Windows的图形界面连服务器都登不上去工作根本没法推进。1.1 测试工作里最常见的场景不是写用例而是先能跑起来测试环境并不总是稳定的。服务挂了要重启配置改了要刷新端口被占了要找出来日志报错了要去截取文件。这些操作几乎全部发生在Linux服务器上。哪怕你所在的团队有专门的运维测试人员在日常测试中也绕不开下面这些情况提交一个缺陷开发回复“环境正常你看下日志”你得自己去服务器上看。联调时接口报了500需要从后端日志里找到堆栈信息提供给开发定位。测试环境的数据要重置需要连到数据库里清掉脏数据。压测或者功能测试后要把日志文件打包发给开发分析。这些事不会写在用例里但却是实实在在的日常工作。如果连tail和grep都不会遇到问题就只能干等别人帮忙效率会低很多。1.2 数据库在测试中的三大用途数据库对于测试来说主要有三个用途。第一个是造数据。比如注册功能要测手机号唯一你需要准备一条已经存在的手机号这时直接往用户表里插一条记录比手工走一遍页面流程要快得多。第二个是验证数据。接口执行完返回结果看起来是成功但数据到底有没有写进库里、状态字段改对了没有必须去数据库里查一遍才能确认。第三个是清理和恢复。测试环境被测试数据污染了需要把数据恢复到初始状态或者把多出来的记录清掉避免影响下一轮用例。这些都是SQL的基本功。数据库操作本身不难难的是在业务场景里知道查哪张表、怎么写条件、怎么判断结果是否符合预期。1.3 我给自己划的重点边界这次先学到哪标题里带了一个“1”说明当天内容不可能一次讲完。我给自己划的范围是这样的Linux部分只学测试日常最常用的命令包括目录、文件、查看日志、进程端口、权限、压缩和远程拷贝不碰特别复杂的Shell编程数据库部分以MySQL为例学连接、查询、条件过滤、排序、分页、聚合统计和多表关联不碰繁琐的存储过程和触发器。把这些学会已经能覆盖测试和联调阶段90%以上的日常操作。2. Linux命令按测试场景分组而不是按命令手册我学Linux的方式比较笨不把命令按字母排列挨个背而是按“我在测试中会用它来做什么”来分组。这样学完之后遇到问题第一反应是“这个场景我知道用什么命令”而不是“这个命令我背过但不知道什么时候用”。2.1 目录与文件的基本盘pwd、ls、cd、mkdir、touch、cp、mv、rm这组命令几乎天天用。pwd看当前路径ls看目录内容cd切换目录mkdir建目录touch创建空文件cp复制mv移动或重命名rm删除。刚开始最需要养成的习惯是多用绝对路径少用相对路径。因为测试环境经常多个人共用切来切去很容易迷路。pwd确认自己在哪里再执行操作这是避免误操作最简单的方法。比如查看应用日志目录下的文件pwd ls -l /data/logs/ls -l会显示出文件的权限、属主、大小和修改时间。测试中经常要根据文件大小判断日志是否在持续写入或者根据时间戳找到最新的日志文件。另一个要养成习惯的是删除命令要格外小心。尤其是rm -rf这个组合是递归强制删除一旦路径写错或者变量为空会把不该删的目录全部清掉。我在练习环境里就干过一次本来想删临时文件夹结果因为路径写错把整个测试目录清空了。从那之后我给自己立了一个规则先ls确认路径再执行删除重要目录优先用mv改名而不是直接删。2.2 查看日志的三板斧tail、grep、less查看日志是测试用得最多的高频操作。日志文件经常很大动辄几百兆甚至几个G用编辑器直接打开根本不现实所以必须用命令行工具来查。tail用于查看文件末尾内容默认显示最后10行。tail -f会进入实时跟踪模式文件有新内容就自动滚动出来。这个命令在排查接口问题时特别实用——让服务端日志保持实时输出然后你再去页面上操作一次报错信息会立刻打印出来。grep用于按关键词过滤。比如要查登录接口相关的日志grep login /data/logs/app.log实际测试中我通常配合-n和-i参数使用。-n显示行号方便后续用行号定位-i忽略大小写避免因为字母大小写问题漏掉日志。更常用的组合是配合tail一起用tail -1000 /data/logs/app.log | grep ERROR这条命令的意思是先取出日志最后1000行再从中过滤出包含ERROR的行。用管道符把命令串起来是排查日志的基本姿势。less适合打开大文件并快速定位。进入less后输入/关键词可以搜索输入G跳到文件末尾输入q退出。这比grep更适合在大文件里来回翻看因为退出后不会刷屏而且可以随时上下翻页。2.3 进程、端口与网络排查环境为什么起不来服务启动失败这是测试环境最常见的问题。排查思路一般分两步先看进程在不在再看端口通不通。查看进程用ps命令通常配合grep使用ps -ef | grep java这条命令会列出所有Java相关进程可以看到进程ID、启动时间、启动命令等信息。如果服务没起起来那可能是根本没有进程或者进程卡死了。此时可以结合服务日志进一步判断。端口是否在监听用netstatnetstat -tlnp | grep 8080-tlnp的意思是查看TCP、显示监听状态、不做域名反解、显示PID和进程名。如果这个端口既没有在监听又没有进程占用那就要继续排查是不是服务还没启动完成或者启动即崩溃。还有一种情况是端口被占用了。之前遇到过一次测试环境应用起不来排查半天发现是另一个遗留进程占用了同一个端口。解决办法就是定位到占用端口的进程ID然后确认是否可以结束kill -9 进程IDkill -9是强制结束进程这个命令也要慎用先和团队确认是不是可杀的进程再执行。之后可以用curl做接口连通性检查。比如要确认一个服务是否正常返回curl -v http://127.0.0.1:8080/api/health如果返回HTTP 200说明服务基本正常如果连接被拒绝说明服务没起来或者端口不对。2.4 权限、压缩与远程拷贝日常用得到但容易被忽略的“边角料”测试环境经常要解压测试包、传文件、改权限。这些操作不像日志和端口那样天天用但遇到一次就会发现不会的话真的很麻烦。修改文件权限用chmod。比如给脚本添加可执行权限chmod x run.shLinux的文件权限分为读、写、执行三类。不同用户角色拥有不同权限测试人员一般不需要做复杂的权限管理但至少要会看ls -l输出里的权限位以及给文件加执行权限。打包和解压用tar。测试中经常见到.tar.gz格式的安装包解压命令是tar -zxvf app.tar.gz打包则用tar -zcvf logs.tar.gz /data/logs/这个操作在要把一堆日志文件带回来给开发分析时非常有用。压缩完再用scp传到本地一气呵成。远程拷贝用scp。比如把服务器上的日志文件下载到本地scp 用户名服务器IP:/data/logs/app.log ./这里的./表示当前目录。反过来把本地的安装包上传到服务器也可以用scp这比各种带界面的工具要稳毕竟命令行操作在写自动化脚本时也通用。3. 实用度最高的两个操作查看日志与定位错误分组学完命令之后我特意花了半天时间专门练“看日志”。因为日志是测试和开发沟通的桥梁也是定位问题最重要的线索来源。3.1 一个完整的日志排查小案例接口报错到找到报错行我把一个真实的排查过程简化成了练习案例过程非常典型。场景是对一个登录接口发起请求前端一直提示“服务器错误”HTTP状态码是500。排查步骤如下第一步登录服务器进入日志目录ssh 用户名服务器IP cd /data/logs/第二步用实时模式观察日志。在另一个终端窗口发请求或者直接在页面上操作一次tail -f app.log第三步复现请求。此时终端会滚动输出日志出现了一行带时间戳的异常信息。但实时日志非常快可能一闪而过所以我改用grep在完整日志文件里精确定位grep -n Exception app.log | tail -20这时它会显示包含Exception的最后20行每行前面有行号。找到最新一条记录的行号之后再用sed查看该行附近的完整堆栈sed -n 1250,1280p app.log这个命令的意思是连续打印app.log的第1250行到第1280行。堆栈信息完整出来之后就能看到具体是哪个类的哪个方法报错以及具体的异常类型比如空指针还是连接超时。整个过程的实用价值在于不是拿一整个大文件去让开发帮忙看而是直接把“哪一行报什么错”找出来自己心里先有个底和开发沟通的效率也高很多。3.2 日志里必须会看的几个关键字在日志里看到下面几个关键字时基本可以判断问题的方向关键字问题方向我的处理方式Exception / Error代码异常或系统错误尽量找到完整堆栈关注Caused by部分Timeout超时检查上游接口是否正常、网络是否通、数据库是否慢OutOfMemory内存溢出看是哪个服务结合内存监控判断是否要重启或扩容Connection refused连接被拒绝检查目标端口是否监听服务是否启动NullPointerException空指针检查传入参数或查询结果是否为空当然这些关键字只是线索不一定是根因。但看到之后能快速反应出“该往哪个方向查”已经能让排查效率提升不少。3.3 我踩过的日志坑乱码、时间不对、日志权限不足日志方面有几个坑限我记忆深刻。第一个是中文乱码。日志文件本身是UTF-8编码但用tail直接查看时中文变成了乱码。这是因为服务器终端默认不是UTF-8。解决方法是执行export LANGzh_CN.UTF-8或者改用tail -f之后按CtrlL重绘。更多时候我会依赖grep过滤出的英文关键字不受乱码影响。第二个坑是时间对不上。日志里记录了请求时间但我看到的时间比实际请求时间晚了8小时。这是服务器时区设置问题。排查时要先确认服务器时间和本机时间是否一致否则对日志会产生误解。第三个坑是日志目录权限不足。有时使用普通账号登录服务器查看日志会提示“Permission denied”。这是文件权限的问题不代表服务器有故障。可以尝试sudo提升权限或者让管理员给你加到对应的用户组。自己千万不要随意去chmod 777特别是在生产环境可能引发安全问题。4. 数据库SQL入门测试人员的第一批查询Linux说完接下来是数据库。测试人员写SQL不要求像开发一样熟练但要能做到想查什么能查出来查出来的结果看得懂知道数据是否符合预期。我以MySQL为例来讲因为它在测试环境里最常见。4.1 从连接数据库开始mysql客户端与常见参数连接MySQL的命令是mysql -h 127.0.0.1 -P 3306 -u root -p-h是主机地址-P是端口注意大写-u是用户名-p表示需要密码。回车后会提示输入密码。不建议在命令行里直接把密码写在-p后面比如-p123456因为命令历史会记录明文密码存在安全隐患。连接成功后会进入mysql命令提示符先查看有哪些数据库SHOW DATABASES;然后选择要操作的数据库USE test_db;再看这个库里有几张表SHOW TABLES;很多测试新人卡在第一步因为不知道测试库地址、用户名、密码去哪里问。这个只能找组内人或者看环境配置文档但连接命令本身很简单。另外强烈建议在测试环境操作绝对不要连生产库尤其是执行数据修改类操作之前一定要确认切换的库和表是正确的。4.2 最常用的四类查询SELECT、WHERE、ORDER BY、LIMITSELECT的使用率是最高的。最简单的查询是查某张表的全部列SELECT * FROM user;但实际工作中我不太推荐一上来就SELECT *因为表列可能非常多输出结果密密麻麻反而不方便看。更常见的是只查需要的字段SELECT id, phone, create_time FROM user;加条件就用WHERE。比如查今天注册的用户SELECT id, phone, create_time FROM user WHERE create_time 2025-01-01 00:00:00;排序用ORDER BY默认是升序加DESC变成降序。比如查最新的几条注册用户SELECT id, phone, create_time FROM user ORDER BY create_time DESC LIMIT 10;分页用LIMITLIMIT 10表示只返回前10条。这个习惯在测试中很重要查询大数据量表时不加LIMIT可能会等很久甚至把数据库拖慢。我自己的习惯是只要是查大表都会先加LIMIT 50确认查询结果符合预期再决定是否扩大范围。4.3 让数据“说话”COUNT、GROUP BY、HAVING、聚合函数在测试中除了查单条数据还经常要统计数量。比如验证一个接口影响的数据量对不对或者确认某类数据是否被正确生成。统计记录数用COUNTSELECT COUNT(*) FROM user;统计不同状态的订单数量用GROUP BYSELECT status, COUNT(*) FROM order GROUP BY status;这条SQL会按订单状态分组然后输出每个状态有多少条记录。这是测试中非常常见的一个需求造完数据后确认每个状态的数据量是否符合预期。如果状态字段的值不对那就说明测试数据的准备环节出了问题。如果要过滤分组后的结果使用HAVING。它与WHERE的区别在于WHERE在分组前过滤原始行HAVING在分组后过滤分组结果。比如只想看订单数量超过100条的订单状态SELECT status, COUNT(*) AS cnt FROM order GROUP BY status HAVING cnt 100;常用的聚合函数还包括SUM、AVG、MAX、MIN。例如统计所有订单的金额总和和平均金额这些查询在核对测试数据时很有用。还有个操作我经常用就是DISTINCT去重比如统计当前有多少种订单来源渠道SELECT DISTINCT source FROM order;4.4 多表关联与子查询当验证结果不再只是一张表测试数据往往分布在多张表里。单查一张表满足不了业务验证需求就需要进行表连接。最常见的连接方式是INNER JOIN只返回两张表能匹配上的数据。比如要查每个订单对应的用户名和手机号SELECT o.order_no, u.phone, u.username FROM order o INNER JOIN user u ON o.user_id u.id;这里o和u是表的别名写起来更简洁。测试人员的场景通常是查订单信息的同时顺便确认用户信息是否正确。另一种常用的是LEFT JOIN返回左表的全部记录右表没有匹配则填充NULL。这个在验证“数据缺失”时特别有用。比如查“有订单但用户却不存在”的数据这是一个异常数据检查的典型场景SELECT o.order_no, o.user_id, u.id FROM order o LEFT JOIN user u ON o.user_id u.id WHERE u.id IS NULL;如果查询结果有记录说明存在脏数据可能是数据清理不彻底导致的需要单独处理后再继续测试。子查询用得相对少一些但在某些场景很方便。比如查“下单金额大于所有用户平均订单金额的订单”SELECT order_no, amount FROM order WHERE amount (SELECT AVG(amount) FROM order);子查询会把括号内的结果作为外层查询的比较条件逻辑上比较直观。写SQL时的安全习惯和Linux命令一样重要。更新和删除数据之前我会先执行一遍SELECT确认影响范围再执行UPDATE或DELETE并且一定带上WHERE条件。例如SELECT * FROM user WHERE phone 13800000000; UPDATE user SET status 1 WHERE phone 13800000000;这样做能避免把整张表的数据都改掉。如果执行了不带WHERE的DELETE全表数据就没了在测试环境里很难恢复。5. 动手练习我用一个模拟订单系统把这些命令串起来了理论学习是一回事能独立操作是另一回事。Day6最后我给自己设计了一套练习用一台本地虚拟机和一份模拟订单数据把前面学的内容全部串了起来。5.1 练习环境准备一台Linux虚拟机加一个MySQL示例库我没有用远程服务器而是用本地虚拟机装了一个最小化Linux系统然后在上面用容器方式跑了一个MySQL实例。为了练习命令行我特意没有装图形化面板全程都用终端操作。准备的模拟数据包括两张表用户表和订单表。用户表里有id、手机号、用户名、注册时间、状态字段订单表里有订单号、用户id、订单金额、订单状态、下单时间。数据量不需要太大几百条就够练习了。5.2 练习任务一部署一个小服务再用Linux命令看日志我在虚拟机上部署了一个自己写的最小Web服务监听8080端口日志输出到指定目录。部署完成后先启动服务然后用之前学的命令做检查ps -ef | grep确认服务进程在运行。netstat -tlnp | grep 8080确认端口监听正常。curl -v访问健康检查接口确认返回正常。tail -f观察服务启动日志确认没有异常堆栈。如果某个环节失败就按照“进程、端口、日志、权限”的顺序逐步排查。这个练习做完之后我对Linux命令的掌握程度明显比只看笔记要深因为每个命令都在真实场景里用了一遍。5.3 练习任务二写SQL完成5个测试数据校验问题我在模拟数据上设计了5个题目每个题目都对应一个测试验证场景序号问题考察点参考SQL1查最近一天注册的用户按时间倒序SELECT、WHERE、ORDER BY、LIMITSELECT * FROM user WHERE create_time CURDATE() ORDER BY create_time DESC LIMIT 20;2统计订单表中每个状态的数量GROUP BY、COUNTSELECT status, COUNT(*) FROM order GROUP BY status;3查下单金额最高的前5笔订单ORDER BY、LIMITSELECT order_no, amount FROMorderORDER BY amount DESC LIMIT 5;4查注册超过30天但没有下过单的用户LEFT JOIN、IS NULLSELECT u.id, u.phone FROM user u LEFT JOINordero ON u.id o.user_id WHERE o.user_id IS NULL AND u.create_time DATE_SUB(NOW(), INTERVAL 30 DAY);5查每个用户的订单总额只显示总额大于1000的用户GROUP BY、HAVINGSELECT user_id, SUM(amount) AS total FROMorderGROUP BY user_id HAVING total 1000;这里稍微注意一下第3题和第5题的order表名我加了反引号因为order是MySQL的保留字直接使用会报语法错误。这个细节在实际环境里也很容易踩坑如果表名报错第一时间就该怀疑是不是撞了保留字。5.4 练习后的自查清单哪些必须快哪些可以查手册练习结束后我给自己做了一张“熟练度自查表”。有些命令或者语法用得很少允许现场查手册但以下几项必须达到“不用想直接打出来”的程度目录切换与文件查看cd、ls、pwd、tail、grep进程端口排查ps -ef | grep、netstat -tlnp | grep数据库连接mysql -h -P -u -p最常用SQLSELECT ... FROM ... WHERE ... ORDER BY ... LIMIT聚合分组COUNT、GROUP BY、HAVING其他相对低频的比如tar的打包参数、scp完整写法、sed的打印范围只要知道“能用哪个命令解决”再现场用--help或者手册确认具体参数即可。我的经验是高频操作要形成肌肉记忆低频操作只要知道关键词就能快速检索没必要追求全部背下来。6. 这一天的收获把命令变成习惯把查询变成思路Day6学完最大的感受是Linux和数据库对测试人员来说不是“额外技能”而是“基础生存技能”。以前遇到服务起不来我第一反应是找人问现在会先自己查进程、看端口、翻日志。以前验证数据只能靠接口返回现在会主动去数据库里确认结果是否真实正确。再分享两个小建议。第一个是建立自己的命令速查笔记。不用抄书就记自己在实际测试里用过的命令每个命令配一个真实场景和备注。这样积累几天就会形成一套专属于自己的工具箱。第二个是数据操作一定要双确认先确认当前在哪个实例哪张表再确认SQL里有没有精确的WHERE条件。尤其是UPDATE和DELETE多花10秒钟检查能省掉一整天的返工时间。下一步我打算继续往后学Linux部分补一下环境部署和Shell脚本基础数据库部分看索引和慢SQL分析后面再结合自动化测试工具去做更完整的测试场景。Day6只是开始Linux和数据库这两块值得反复练练到像呼吸一样自然测试工作才会真正顺畅起来。