軟件測試項目里的MySQL到底要怎么用這篇把場景、語法和面試點一次說透很多剛入行軟件測試的同學都有個困惑學SQL的時候覺得挺簡單select、insert、update背得滾瓜爛熟可真到了測試項目里面對一個真實的業務系統卻不知道數據庫操作到底該用在哪。這很正常。我在帶新人時經常說一句話測試人員學MySQL不是為了當DBA也不是為了寫復雜的存儲過程而是為了“用數據驗證邏輯”。你的核心任務是發現問題而數據庫操作是你發現問題、定位問題、復現問題的最強輔助工具。這篇內容不搞虛的直接圍繞“軟件測試項目中的MySQL操作場景”來講包含環境準備、高頻SQL、項目實戰案例、常見報錯排查以及面試和簡歷里怎么體現這部分能力。不管是剛入門準備找工作還是已經在項目里干了一段時間想補短板都值得收藏一份慢慢看。1. 測試人員為什么要熟練操作MySQL三個最直接的場景1.1 造數據沒有測試數據功能根本跑不起來做過功能測試的都知道一個模塊能不能測很大程度取決于有沒有合適的數據。比如你要測一個電商系統的訂單列表前端界面需要登錄、加購、下單一套流程走下來可能要幾分鐘而且涉及多個接口的依賴。但如果你直接在MySQL里往訂單表插幾條記錄再配好對應的用戶ID和商品ID前端刷新就能看到數據測試效率直接翻倍。我在實際項目里最常用的一個操作就是造“邊界數據”。比如某個字段設計的是varchar(20)我就往里面插一條20個字符的數據再插一條21個字符的看系統在界面上有沒有做長度校驗、數據庫有沒有報錯。這種測試不通過頁面操作很難觸發但通過SQL直接操作數據庫可以精準命中。還有一種情況是“并發數據”比如秒殺場景要模擬多個用戶同時搶一個商品。這時候直接在數據庫里把庫存改成1然后讓腳本并發請求比在頁面上人工操作要可控得多。1.2 數據校驗頁面看到的數字不一定等于數據庫里的真實數據功能測試的驗證不能只停留在“頁面上顯示正確”更關鍵的是“數據庫里的數據是否正確”。這是很多初級測試容易忽略的點。舉個例子用戶注冊后前端提示“注冊成功”你以為就完了不行你得去數據庫的user表里查一下確認這個用戶名確實insert進去了密碼字段是不是加密存儲的狀態字段是不是默認值。再比如訂單支付成功頁面顯示已支付那支付流水表里有沒有對應的記錄訂單狀態有沒有從待支付變成已支付支付回調有沒有重復寫入這些校驗邏輯光靠看界面是看不出來的必須通過SQL去查庫比對。說白了界面是表象數據庫才是真相。學會通過MySQL驗證數據流轉的正確性你的測試深度就不一樣了。1.3 清理臟數據和高危操作測試環境的“善后工作”測試過程中不可避免地會產生大量垃圾數據。今天注冊了50個測試賬號明天下單了80個訂單后天把商品庫存改成負數測了一把——如果不清理下次測試的時候你會發現頁面數據混亂接口返回奇怪的結果排查半天才發現是臟數據干擾。我自己的習慣是每輪測試結束前都會通過DELETE或TRUNCATE把相關表的數據恢復到基線狀態。但這里要特別提醒操作前必須確認影響的表范圍最好先SELECT查一下再刪萬一手滑把公共測試環境的數據清掉了影響的是整個團隊這個鍋背起來很重。還有一類操作必須謹慎直接修改線上或準生產環境的數據。就算你有權限也得先確認操作影響范圍最好先在測試環境演練一遍再提交變更申請。測試人員可以在測試庫里“為所欲為”但面對共享環境或生產環境必須按流程走這一點沒有任何商量余地。2. 環境準備從MySQL安裝到客戶端連接新手最全避坑指南2.1 MySQL版本怎么選8.0還是5.7現在新項目基本都用MySQL 8.0功能更全性能更好默認字符集是utf8mb4對中文和emoji的支持更友好。不過有些公司老項目還在用5.7甚至5.6這就要看你們項目的實際情況了。我的建議是個人學習直接用8.0因為大勢所趨面試時聊起版本特性也有優勢。如果公司環境是5.7那你就在本機裝5.7保持一致避免開發環境和測試環境行為不一致導致誤判。說到下載千萬不要去某些來路不明的網站下“破解版”或“綠色版”直接去MySQL官網下載社區版Community Server就行免費、安全、更新及時。官網有時候下載速度不穩定但耐心點等一等比裝了個帶病毒的“精簡版”強一萬倍。2.2 安裝時最容易踩的坑安裝MySQL其實不難最常用的就是自定義安裝Custom選好安裝路徑和數據目錄設置一下root密碼基本就完成了。但有幾個點很容易出問題第一個是端口沖突。默認端口3306如果本機已經裝過舊版MySQL或者有別的服務占用了3306安裝時就要改成3307或其他端口。安裝后如果連接不上第一步就是檢查端口。第二個是服務名重復。Windows下安裝多個MySQL實例服務名不能相同否則后裝的會把先裝的頂掉。我遇到過有人裝了5.7又裝8.0兩個服務名都是MySQL導致其中一個怎么都啟動不了。第三個是環境變量。安裝時如果勾選了“Add MySQL to PATH”命令行里就能直接敲mysql命令省去手動配環境變量的煩惱。沒勾的話要么去系統環境變量里加要么每次都用完整路徑比較麻煩。2.3 圖形化客戶端Navicat還是MySQL Workbench命令行確實是測試人員的必備技能但日常工作中也不可能每條SQL都在黑框框里敲效率太低。圖形化客戶端是剛需。Navicat功能很強大支持連接管理、數據可視化、導入導出、定時備份用起來非常順手。不過它是個商業軟件要收費。如果你不想花錢MySQL官方的Workbench是免費替代建模、查詢、管理都能干就是界面稍微臃腫一點。還有DBeaver免費開源跨平臺對測試人員來說也夠用。我個人在項目里用得最多的是Navicat因為它的數據對比和查詢結果導出太好用了非常方便寫測試報告時貼證據。但我的建議是工具用哪個都行SQL本身一定要熟練因為面試的時候可不讓你打開Navicat邊點邊答。2.4 命令行鏈接MySQL這個技能必須會圖形化客戶端用多了會有人產生依賴。但到了服務器上排查問題別說Navicat了可能連桌面環境都沒有只有黑乎乎的終端。這時候能不能流暢地用命令行操作數據庫直接決定了你的排障效率。最基本的幾組命令# 連接本地MySQL mysql -uroot -p # 連接遠程MySQL指定IP和端口 mysql -h192.168.1.100 -P3306 -uroot -p # 查看所有數據庫 show databases; # 切換數據庫 use testdb; # 查看當前數據庫下所有表 show tables; # 查看表結構 desc user;這些命令看著簡單但在服務器上排查問題時是最常用的。我建議每個測試人員都養成“先在命令行里跑通再上圖形化客戶端”的習慣對自己的基本功提升很有幫助。3. 測試項目里最常用的SQL一條一條給你拆解3.1 SELECT查詢測不完的邊界條件都靠它SELECT是使用頻率最高的語句但真正寫好、用到位的沒幾個。測試人員寫SELECT不是為了炫技而是為了準確拿到自己想要的數據去驗證功能。最常見的基礎用法就不多說了直接上實際場景。比如查用戶表里狀態正常的賬號SELECT id, username, phone, status FROM user WHERE status 1;再比如查訂單表里今天新增的訂單數量SELECT COUNT(*) AS today_order_cnt FROM orders WHERE create_time 2024-01-01 00:00:00 AND create_time 2024-01-02 00:00:00;這里要注意一個經典坑如果用create_time BETWEEN 2024-01-01 00:00:00 AND 2024-01-01 23:59:59可能會漏掉最后1秒的數據。因為如果create_time帶毫秒2024-01-01 23:59:59.500就比23:59:59大不在范圍內。所以我習慣用和的組合雖然麻煩一點但結果更嚴謹。排序也是高頻用法。測試列表頁的排序功能時比如商品按價格升序頁面看到的結果和數據庫里的排序結果是否一致SELECT product_name, price FROM product WHERE status 1 ORDER BY price ASC;然后你再去頁面上對比這個序列看有沒有錯位。曾經我測過一個列表頁數據庫里排序是對的但頁面上第三頁和第四頁的數據出現了重復就是因為分頁查詢的ORDER BY字段沒有唯一性約束。這個Bug完全是通過SQL對比發現的所以你不僅要會寫SQL還要會用SQL去尋找Bug。3.2 JOIN聯表查詢驗證數據關聯的正確性真實項目里幾乎沒有單表查詢就能搞定的需求訂單要關聯用戶商品要關聯分類支付要關聯訂單所以JOIN是必須掌握的。內連接查訂單和用戶信息SELECT o.order_no, u.username, o.pay_amount, o.status FROM orders o INNER JOIN user u ON o.user_id u.id WHERE o.create_time 2024-06-01 00:00:00;左連接查所有用戶以及他們的訂單數包括沒有下過單的用戶SELECT u.id, u.username, COUNT(o.id) AS order_cnt FROM user u LEFT JOIN orders o ON u.user_id o.user_id GROUP BY u.id, u.username;我遇到過一個很典型的數據問題一個用戶已經注銷了但歷史訂單記錄里還關聯著這個用戶。用LEFT JOIN查的時候發現關聯用戶的username是NUll頁面訂單詳情直接報空指針。如果沒有SQL做數據校驗這個Bug很難發現。JOIN還有一個非常容易踩的坑關聯字段的字符集不一致導致查不出數據。比如A表的user_id是utf8mb4B表的user_id是utf8兩條記錄看起來一樣但JOIN就是關聯不上。遇到這種詭異問題時記得檢查兩邊的字符集。3.3 INSERT/UPDATE/DELETE測試數據的關鍵操作在對測試庫做數據準備和數據清理時增刪改是主力。但這三個操作都要非常小心尤其是UPDATE和DELETE少寫一個WHERE條件后果不堪設想。造一條測試用戶數據INSERT INTO user (username, password, phone, status, create_time) VALUES (test_user_001, e10adc3949ba59abbe56e057f20f883e, 13800138000, 1, NOW());注意密碼字段一般不會存明文所以造數據的時候最好用MD5或其他加密值免得造出來的數據在頁面上登錄不了。模擬一個訂單狀態流轉-- 先把訂單改成待支付 UPDATE orders SET status 0 WHERE order_no TEST20240601001; -- 模擬支付成功更新狀態和支付時間 UPDATE orders SET status 2, pay_time NOW() WHERE order_no TEST20240601001;我常用這種手法來測試不同狀態下的頁面展示不用走完一整套業務流程直接在庫里造狀態效率非常高。刪除某張測試表里的數據-- 如果要清理全部數據且不在乎自增ID復位 TRUNCATE TABLE test_log; -- 如果只刪除部分數據用DELETE DELETE FROM test_log WHERE create_time 2024-01-01 00:00:00;這里說明一下TRUNCATE和DELETE的區別TRUNCATE是DDL執行后無法回滾自增ID會歸零速度極快但不能加WHERE條件DELETE是DML可以加WHERE條件刪部分數據也可以放在事務里ROLLBACK。新手最容易犯的錯就是把TRUNCATE當DELETE用結果把不該清的數據全清了。建議清理數據之前先SELECT COUNT(*)看一下要刪的行數心里有數再動手。提示任何UPDATE和DELETE操作前先寫SELECT用相同WHERE條件確認影響范圍這是我在團隊里強制要求的習慣。3.4 子查詢和聚合函數多一層視角多一份保障子查詢在測試數據校驗里的作用很大尤其是在“數據一致性校驗”這個維度。比如查出哪些用戶下了單但沒有支付記錄SELECT o.user_id, o.order_no FROM orders o WHERE o.status 2 AND NOT EXISTS ( SELECT 1 FROM payment p WHERE p.order_no o.order_no );這條SQL能在短時間內找到“訂單已支付但支付表無記錄”的數據異常對對賬測試來說非常實用。聚合函數GROUP BY也是必會組合。測試報表功能時比如按分類統計商品數量SELECT category_id, COUNT(*) AS cnt FROM product GROUP BY category_id;做數據統計類模塊測試時我會先用SQL算出一份“期望結果”再和頁面上報表展示的“實際結果”比對。如果兩邊數字對不上說明報表有問題或者SQL寫錯了總之一定有一邊是錯的需要繼續排查。3.5 存儲過程的應用場景以及為什么測試人員要了解存儲過程在測試項目里用得不算特別頻繁但并不意味著可以不學。有些業務場景的數據準備邏輯比較復雜比如批量造1000條訂單數據如果用單條INSERT要寫半天這時候用存儲過程循環插入就高效得多。一個造批量訂單數據的存儲過程示例DELIMITER // CREATE PROCEDURE batch_insert_orders(IN max_num INT) BEGIN DECLARE i INT DEFAULT 1; WHILE i max_num DO INSERT INTO orders (order_no, user_id, pay_amount, status, create_time) VALUES (CONCAT(TEST, DATE_FORMAT(NOW(), %Y%m%d), LPAD(i, 6, 0)), 10001 i, 99.90, 0, NOW()); SET i i 1; END WHILE; END // DELIMITER ; -- 調用存儲過程生成1000條訂單 CALL batch_insert_orders(1000);注意DELIMITER命令是為了臨時把語句分隔符改成//不然MySQL會誤認為分號處已經是一條完整語句。這個細節很容易被忽略初學者在這里報錯很常見。面試如果問到存儲過程不一定是要你現場寫一個復雜的而是看你了不了解這個機制、能不能說出適用場景和優缺點。在項目里如果你能主動提到“數據準備我用存儲過程批量處理”會是一個很加分的點。4. 測試項目實戰從登錄到訂單的完整數據庫操作流程4.1 項目背景設定假設我們要測試一個簡化版電商系統的訂單流程。核心表結構大概有這幾張user用戶表、product商品表、orders訂單表、order_item訂單明細表、payment支付流水表。在不依賴前端頁面的情況下我們需要通過MySQL直接操作這些表來完成造數、驗證、清理的完整閉環。這個流程你在面試中完全可以直接復述出來會非常有說服力。4.2 第一步初始化測試數據開始測試前我會先確保基礎數據到位。-- 查看商品表當前數據 SELECT id, product_name, price, stock FROM product WHERE status 1; -- 如果商品數據不夠手動插入 INSERT INTO product (product_name, price, stock, status, create_time) VALUES (測試商品A, 19.90, 100, 1, NOW()), (測試商品B, 29.90, 50, 1, NOW());再準備一個測試用戶INSERT INTO user (username, password, phone, status, create_time) VALUES (test_buyer_001, MD5(123456), 13812345678, 1, NOW()); -- 拿到該用戶的ID SELECT id FROM user WHERE username test_buyer_001;這個階段的核心是“可控性”。你造的數據必須知道每個字段的值這樣后續驗證才有依據。如果你直接找一個已有用戶來測可能這個用戶的手機號被多個訂單關聯排查問題時就會很混亂。4.3 第二步模擬下單并驗證數據落庫頁面上操作下單后不要馬上斷言成功。立刻去數據庫驗證訂單是否生成、狀態是否正確、金額是否和頁面顯示一致。-- 查出最新訂單 SELECT order_no, user_id, pay_amount, status, create_time FROM orders ORDER BY id DESC LIMIT 5; -- 查出訂單對應的明細 SELECT oi.order_no, oi.product_id, oi.product_name, oi.price, oi.quantity FROM order_item oi WHERE oi.order_no 最新拿到的訂單號;這里我有一個習慣記錄下頁面下單的時間點然后用create_time 下單時間去查能非?？焖俚囟ㄎ坏叫略鲇涗洝Ｈ绻椴坏秸f明訂單沒落庫或者落到了別的庫/表這就已經是一個值得深挖的Bug了。還要注意一個細節訂單金額的精度。頁面顯示的商品總價可能是19.9但數據庫存儲可能是19.90也可能因為浮點運算變成19.900000000000002。通過SQL對比時不要直接等于要用ROUND(pay_amount, 2)做一下處理。4.4 第三步模擬支付成功并檢查數據流轉支付成功后的數據流轉是測試的重點也是最容易出現Bug的環節。我通常直接在數據庫層把訂單狀態改成已支付來測試界面的狀態刷新。UPDATE orders SET status 2, pay_time NOW() WHERE order_no TEST20240601001; -- 插入對應的支付流水 INSERT INTO payment (order_no, pay_amount, pay_type, pay_time, status) VALUES (TEST20240601001, 19.90, 1, NOW(), 1);然后去頁面驗證訂單詳情是否顯示已支付、支付時間是否顯示正確、支付方式是否展示、優惠金額是否計算正確。這些如果都過了再考慮走一遍真實支付回調的邏輯。這里最值得關注的是“冪等校驗”。如果支付回調接口被重復調用比如網絡超時后重試數據庫里的支付記錄會不會重復插入訂單狀態會不會被覆蓋錯要驗證這個我常用的手段就是手動執行兩次UPDATE和INSERT看第二次執行后數據是否發生變化。這也是接口測試里必須覆蓋的場景。4.5 第四步測試清理與數據恢復每輪測試結束必須把數據恢復到初始狀態。我的習慣是先記錄一張“數據基線表”把關鍵表的初始行數和關鍵記錄的主鍵記錄下來測完了比對著清理。-- 查詢基線之后產生的訂單 SELECT order_no FROM orders WHERE create_time 2024-06-01 10:00:00; -- 清理測試訂單先刪子表再刪主表避免外鍵約束報錯 DELETE FROM order_item WHERE order_no IN (TEST20240601001, TEST20240601002); DELETE FROM orders WHERE order_no IN (TEST20240601001, TEST20240601002); DELETE FROM payment WHERE order_no IN (TEST20240601001, TEST20240601002);注意刪除順序先刪有外鍵依賴的子表再刪主表。如果表結構里有外鍵約束順序反了會報錯。當然很多測試環境為了性能可能不會真的建外鍵約束但養成好習慣沒壞處。清理完成后建議再執行一次SELECT COUNT(*)確認行數確實回到了基線值。千萬別刪完就完事了后面同事跑數據時發現缺了一批回來找你的時候場面很難看。5. 高頻面試題MySQL在測試崗位里怎么考5.1 面試問你“會數據庫嗎”到底在問什么軟件測試面試里問數據庫通常不是問“你會不會寫復雜的存儲過程”而是考察三件事。第一你懂不懂SQL基礎語法第二你能不能把SQL實際用到測試工作中第三你有沒有踩過數據相關問題的坑有沒有自己的排查思路。你在回答的時候不要只回答“我會寫SQL”而是要說“我會用SQL做測試數據準備、數據校驗和結果比對并且在之前的項目里通過SQL定位過XX Bug”。有具體案例支撐比什么都強。5.2 經典面試題TOP盤點第一類基礎語法題。比如查出每門課成績排名前N的學生、找出重復數據、統計每類商品的銷量Top3。這類題考察的是SELECT、JOIN、GROUP BY、窗口函數的熟練度。第二類測試場景結合題。比如“如果在頁面上注冊了一個用戶你如何驗證注冊成功”“訂單支付成功后如何從數據庫層面驗證數據一致性”這種題沒有標準答案但回答得越具體越能體現實戰能力。第三類優化與原理題。比如索引為什么能加速查詢、MySQL有哪些存儲引擎、事務的ACID特性是什么。這類題目測的是你對底層原理的掌握程度不需要答得太深但一定要知道基本概念。我整理了一份高頻題目清單可以直接對著練SELECT查詢去重、WHERE和HAVING的區別、CHAR和VARCHAR的區別、內連接和左連接的區別、事務的四個隔離級別、索引失效的場景、分頁查詢優化、樂觀鎖和悲觀鎖的區別、臟讀和不可重復讀分別是什么。這些題目看著多但本質上都是圍繞“數據操作”展開的。你如果能在項目里把SQL用熟這些題目根本不用死記硬背。5.3 簡歷里怎么寫MySQL相關的技能簡歷寫“熟悉MySQL”太單薄聰明的寫法是“熟練使用MySQL進行測試數據準備、數據校驗和結果分析能獨立編寫復雜SQL語句定位數據類Bug”。在項目經歷中可以加一條“負責訂單模塊的測試通過MySQL多表聯查和聚合統計驗證訂單金額和支付流水的一致性發現XX問題”。這樣寫面試官一看就知道你不只是會“select * from user”這種基礎語句。提示面試時如果讓你手寫SQL一定先問清楚表結構別拿到題就悶頭寫。先理清需求再動筆是職業素養的體現。6. 常見報錯與排查技巧這些年我踩過的坑都在這里了6.1 報錯“Unknown column”或“Table doesnt exist”這個問題多半是表名或字段名打錯了。MySQL在Linux環境下表名是區分大小寫的在Windows下默認不區分但為了兼容建議全都用統一的小寫命名。出現這個報錯第一件事就是執行SHOW TABLES;或DESC 表名;確認現場別急著改來改去。6.2 中文亂碼問題在插入或查詢中文數據時出現亂碼大概率是字符集設置不對。MySQL 8.0默認是utf8mb4基本不會亂碼如果是老庫或者建表時指定了latin1就會出問題。排查思路是查三處數據庫的字符集、表的字符集、連接的字符集。# 查數據庫字符集 SHOW CREATE DATABASE 庫名; # 查表字符集 SHOW CREATE TABLE 表名; # 查當前連接字符集 SHOW VARIABLES LIKE character_set%;最直接的解決辦法是統一改成utf8mb4。如果已經存進去亂碼數據了一般很難完美恢復只能清洗或重造。所以在造數據的時候就要把字符集檢查清楚別等到界面顯示亂碼才來排查。6.3 連接不上MySQL排查順序很重要連接報錯無非幾種情況。第一MySQL服務沒啟動Windows下到服務管理器看一下第二IP或端口不對用telnet測端口通不通第三用戶名或密碼錯誤第四賬號沒有遠程訪問權限。遠程權限這塊是個大坑。MySQL默認只有localhost訪問權限用遠程工具連接之前得先給賬號授權CREATE USER tester% IDENTIFIED BY password; GRANT ALL PRIVILEGES ON testdb.* TO tester%; FLUSH PRIVILEGES;在測試環境里授權范圍可以寬一點但生產環境千萬不要這么干安全風險太高了。6.4 慢查詢定位SQL性能問題的第一步測試過程中如果發現某個頁面打開很慢很有可能是SQL性能問題。排查思路很簡單先開啟慢查詢日志再復現操作最后分析那條慢SQL是不是缺少索引。-- 查看慢查詢日志是否開啟 SHOW VARIABLES LIKE slow_query_log; -- 查看慢查詢時間閾值 SHOW VARIABLES LIKE long_query_time;我遇到過最典型的案例是一個列表頁數據多了以后加載特別慢用慢查詢日志定位到一條全表掃描的SQL加了個聯合索引之后查詢時間從2秒降到30毫秒。這個優化過程如果出現在面試里是很亮眼的項目經驗。6.5 事務回滾失效注意存儲引擎和自動提交有人可能會遇到“我執行了BEGIN插了一條數據然后ROLLBACK但數據還在”的情況。第一懷疑對象就是存儲引擎只有InnoDB支持事務MyISAM是不支持的。所以建表的時候默認存儲引擎一定要是InnoDB。第二個懷疑對象是隱式提交。像DDL語句CREATE、ALTER、TRUNCATE等執行后會自動提交事務所以你在執行完TRUNCATE再ROLLBACK是沒用的。還有一個是確認下客戶端是不是開了自動提交執行SELECT autocommit;如果是1那每條DML都會立即提交。測試階段可以SET autocommit 0;關掉更保險。7. 實戰心得MySQL在測試項目中的幾條獨門經驗說得有點多了最后分享幾個我平時帶團隊時反復強調的實操心得。第一個養成“先查后改”的習慣。不管你是要UPDATE還是DELETE永遠先寫SELECT確認影響范圍。這句話我重復多少次都不嫌多因為一次誤操作可能就讓全團隊的測試環境癱瘓。我在團隊里甚至要求所有人在測試庫執行非SELECT操作前把SQL貼到群里面過一遍雖然看起來繁瑣但真的能避免很多事故。第二個把常用的SQL沉淀成自己的“測試工具箱”。比如數據初始化腳本、清理腳本、校驗腳本都可以保存為.sq文件隨用隨取。我電腦里就有一堆.sql腳本按模塊分目錄存放換項目直接改改表名和字段名就能用效率提升非常明顯。第三個多練多寫沒壞處。SQL這個東西光看不練等于零。哪怕是每天花15分鐘寫幾條查詢堅持一兩個月你寫SQL的手感絕對不一樣。LeetCode上的數據庫題、?？途W的面經、各類SQL練習網站都是很好的刷題渠道比刷短視頻有意義多了。第四個遇到“詭異”的數據問題先懷疑數據本身再懷疑代碼。很多時候頁面展示不對不是代碼邏輯錯了而是臟數據導致的。比如某條記錄的時間字段為NULL頁面上排序就亂了。這時候你用SQL把這條特殊數據揪出來比讓開發查半天的接口效率高得多。MySQL對軟件測試人員來說不是一門孤立的技術而是和功能測試、接口測試緊密咬合的工具。掌握好它你的測試深度會明顯提升面試和工作中都會更有底氣。如果這篇內容對你有幫助強烈建議照著里面的SQL語句在自己的測試庫里實際跑一遍動手親自造一遍測試數據、跑一遍流程體會一下我在項目里遇到的那些場景。測試這行只有自己親手操作過、踩過坑才會真正變成能力。