作為軟件測試工程師日常工作里接觸最多、也最容易繞不開的就是 MySQL 查詢命令。不管是功能測試要造數據、接口測試要驗證落庫結果還是排查線上問題時要去查一條訂單的狀態SQL 能力直接決定你的測試效率。這里說的不是讓你像 DBA 一樣做運維優化而是把最常用的查詢命令整理成一套能夠直接上手、直接執行的實戰手冊。這篇文章會把 MySQL 查詢命令按測試實際使用場景重新組織從連接數據庫、單表查詢、條件過濾、聚合統計、多表關聯到測試數據造數和清理、常見連接報錯排查全部用可復制的 SQL 示例展開。讀者如果是剛轉行做軟件測試、或對 MySQL 半生不熟的開發轉測人員可以直接把本文當成一份速查手冊。1. 測試工程師必備的 MySQL 查詢能力速覽測試和開發看數據庫的視角不同。開發更關心寫接口、調業務邏輯測試更關心數據是否按預期寫入、狀態字段是否流轉正確、測試環境的數據是否干凈。圍繞這個目標測試工程師最常用的 MySQL 能力可以整理成下面這張表。能力項典型測試應用場景使用頻率SELECT 單表查詢查用戶表、訂單表的基本數據每天使用WHERE 條件過濾按訂單號、用戶 ID、時間范圍篩數據每天使用ORDER BY 排序驗證列表接口的排序邏輯高頻LIMIT 分頁查詢驗證分頁接口的返回結果高頻LIKE 模糊查詢搜索功能測試、按名稱關鍵字查數據高頻CASE WHEN 條件分支把數據庫字段值轉成業務含義再核對中頻聚合函數 COUNT/SUM/AVG驗證統計報表、列表總條數高頻GROUP BY 分組統計驗證按狀態、按品類分組的統計接口中高頻JOIN 多表關聯跨表核對業務數據完整性高頻子查詢復雜的多條件過濾、嵌套統計中頻UPDATE 數據訂正測試環境數據訂正、狀態復位中頻DELETE 數據清理清理測試臟數據中頻掌握以上能力之后再去應對數據庫相關的測試面試題也會從容很多。MySQL 面試題里常問的SELECT執行順序、WHERE和HAVING的區別、LEFT JOIN和INNER JOIN的差異本質上就是這些基礎查詢命令的延伸。2. 環境準備測試工程師怎么連接 MySQL寫查詢命令之前先確認你能連上 MySQL。測試環境通常有開發或者運維提供的數據庫賬號你只需要拿到三樣東西數據庫地址、端口、賬號密碼。連接方式常見有兩種。第一種是命令行客戶端MySQL 安裝后自帶mysql命令。Windows 下需要先把 MySQL 的bin目錄加入系統 PATH或者直接在 bin 目錄下打開終端執行。Linux 和 macOS 一般可以直接執行。mysql -h 192.168.1.100 -P 3306 -u test_user -p執行后按提示輸入密碼看到mysql提示符就說明連接成功。這里的-h指定數據庫主機地址-P指定端口默認 3306 可以省略-u指定用戶名-p表示需要輸入密碼。如果本地安裝的是 MySQL 8.0默認認證插件是caching_sha2_password某些老版本客戶端或者工具連接時會報認證失敗后面常見問題部分會專門講。第二種是圖形化工具比如 Navicat、MySQL Workbench、DBeaver。新建連接時填主機、端口、用戶名、密碼即可。圖形化工具適合需要頻繁看表結構、導出數據、可視化編輯的場景但對測試工程師來說命令行永遠是兜底方案因為線上排查時不一定有圖形化工具。連接后先看當前數據庫列表。SHOW DATABASES;再切換到目標數據庫。USE test_db;查看當前庫下的所有表。SHOW TABLES;查看某張表的結構。DESC test_user;這套命令是測試環境查數前的固定熱身動作。每次拿到新庫我都建議先跑一遍SHOW DATABASES和SHOW TABLES確認環境沒有連錯、表存在再開始寫具體查詢。3. 基礎查詢命令SELECT、WHERE、ORDER BY、LIMIT3.1 SELECT 查詢指定字段測試工程師查數據時最忌諱SELECT *一把梭不是說不能用它而是當表字段很多、數據量很大時SELECT *會把無用字段全部撈出來輸出內容太多反而看不清關鍵數據。更推薦的做法是只查自己關心的字段。SELECT id, user_name, mobile, status FROM test_user;這條命令查詢test_user表中的四個字段。從執行效率看只查必要字段也能減少網絡傳輸的數據量。3.2 WHERE 條件過濾查詢測試數據時絕大多數情況都需要帶過濾條件。比如只查某個訂單號的數據、只查狀態為 1 的用戶、只查某個時間段內的記錄。SELECT id, order_no, amount, status FROM test_order WHERE status 1;多條件組合時用AND和OR。注意AND優先級高于OR如果條件邏輯比較復雜建議加括號明確優先級。SELECT id, order_no, amount, status FROM test_order WHERE status 1 AND amount 100 AND create_time 2025-01-01;3.3 ORDER BY 排序列表類接口測試時前端展示的數據往往有排序規則。測試人員需要對照數據庫確認排序結果是否符合接口文檔。排序用ORDER BY默認是升序ASC需要降序時用DESC。SELECT id, user_name, create_time FROM test_user ORDER BY create_time DESC;多字段排序時先按第一個字段排相同再按第二個字段排。例如先按狀態升序再按創建時間降序。SELECT id, user_name, status, create_time FROM test_user ORDER BY status ASC, create_time DESC;這里有一個測試中容易踩的坑字符型字段排序不是數字排序。比如mobile字段如果存的是字符串排序結果和按數字排序可能不一致。驗證排序邏輯時要先確認字段類型。3.4 LIMIT 分頁查詢分頁接口測試是軟件測試工程師的高頻工作。前端傳page和pageSize后端返回對應分頁數據。數據庫層一般用LIMIT實現。SELECT id, order_no, amount FROM test_order ORDER BY id LIMIT 0, 10;上面這行表示從第 0 條開始取 10 條對應第一頁。第二頁就是LIMIT 10, 10第三頁是LIMIT 20, 10。MySQL 的 LIMIT 語法也可以簡寫成LIMIT 偏移量, 行數。在 MySQL 8.0 中還可以用LIMIT 行數 OFFSET 偏移量的寫法兩種等價。SELECT id, order_no, amount FROM test_order ORDER BY id LIMIT 10 OFFSET 10;測試分頁接口時要注意邊界值是第一頁、最后一頁、頁碼超過總頁數、頁碼為 0 或負數。數據庫層面對應驗證的是LIMIT偏移量計算是否正確以及偏移量超過數據總量時返回空結果但不會報錯。3.5 DISTINCT 去重查詢測試中需要確認某張表中不同取值的數量時可以用DISTINCT去重。例如查看訂單表中存在哪些狀態值。SELECT DISTINCT status FROM test_order;也可以統計去重后的數量。SELECT COUNT(DISTINCT user_id) FROM test_order;這行命令可以快速判斷某個用戶是否下過單也是造數時檢查重復數據的常用手段。4. 條件過濾實戰LIKE、IN、BETWEEN、CASE WHEN4.1 LIKE 模糊查詢搜索功能測試時前端輸入關鍵字后端一般使用LIKE做模糊匹配。數據庫層面的驗證就是看LIKE查詢能否返回符合條件的數據。SELECT id, user_name FROM test_user WHERE user_name LIKE 張%;%代表任意長度的字符_代表單個字符。張%表示以“張”開頭%張%表示包含“張”張_表示以“張”開頭且后面只有一個字符。測試搜索接口時需要關注大小寫敏感問題。MySQL 默認的排序規則utf8_general_ci是不區分大小寫的LIKE abc%也能匹配ABC。如果業務要求區分大小寫需要使用utf8_bin排序規則或者BINARY關鍵字。SELECT id, user_name FROM test_user WHERE user_name LIKE BINARY Abc%;4.2 IN 和 BETWEENIN用來匹配多個值等價于多個OR條件。例如查詢狀態為 1、2、3 的訂單。SELECT id, order_no, status FROM test_order WHERE status IN (1, 2, 3);BETWEEN ... AND ...用來查詢一個范圍內的值常用于時間范圍和數值范圍。SELECT id, order_no, amount FROM test_order WHERE amount BETWEEN 100 AND 500;時間范圍是測試中更常見的使用場景。注意BETWEEN包含邊界值。SELECT id, order_no, create_time FROM test_order WHERE create_time BETWEEN 2025-01-01 00:00:00 AND 2025-01-31 23:59:59;這里需要特別提醒如果只寫BETWEEN 2025-01-01 AND 2025-01-31而create_time是datetime類型2025-01-31 00:00:00之后的數據不會被包含進去。正確做法是結束時間寫到23:59:59或者把結束時間寫成下一天的零點再用比較。4.3 CASE WHEN 條件分支CASE WHEN可以在 SELECT 語句里做條件判斷把存儲層的數字狀態轉成業務含義。這在核對業務數據時尤其有用因為很多表的狀態字段是 0、1、2 這種數字直接看數字效率低。SELECT id, order_no, status, CASE WHEN status 0 THEN 待支付 WHEN status 1 THEN 已支付 WHEN status 2 THEN 已發貨 ELSE 未知狀態 END AS status_name FROM test_order;這里的AS status_name是給結果列起別名。測試人員核對時一眼就能看出數據處于哪個業務環節不用再翻字典表。CASE WHEN還可以和聚合函數結合做條件統計比如統計已支付和已取消的訂單數。SELECT COUNT(CASE WHEN status 1 THEN 1 END) AS paid_count, COUNT(CASE WHEN status 4 THEN 1 END) AS canceled_count FROM test_order;這個寫法在驗證統計報表類接口時很實用不需要寫多條 SQL 再手動相加。4.4 多條件組合的綜合示例實際查詢中很少只有一個條件下面給一個組合條件示例覆蓋表中大部分測試場景。SELECT id, order_no, user_id, amount, status, create_time FROM test_order WHERE user_id 10086 AND status IN (1, 2) AND amount 50 AND create_time 2025-01-01 ORDER BY create_time DESC LIMIT 20;含義查詢用戶 10086 在 2025 年之后創建、金額大于等于 50、狀態為已支付或已發貨的最新 20 條訂單。這條 SQL 是典型的測試環境數據核驗模板。5. 聚合查詢與分組統計COUNT、SUM、AVG、GROUP BY、HAVING5.1 常用聚合函數聚合函數用于對一組數據做統計計算返回一行結果。測試工程師最常用的幾個函數如下。COUNT(*)統計行數COUNT(字段)統計某字段非 NULL 的行數SUM(字段)求和AVG(字段)求平均值MAX(字段)最大值MIN(字段)最小值統計訂單表總記錄數。SELECT COUNT(*) AS total_count FROM test_order;統計已支付訂單的總金額和平均金額。SELECT SUM(amount) AS total_amount, AVG(amount) AS avg_amount, COUNT(*) AS paid_count FROM test_order WHERE status 1;這里有一個容易混淆的點COUNT(*)和COUNT(字段)的區別。COUNT(*)會統計所有行包括字段全為 NULL 的行。COUNT(字段)只統計該字段不為 NULL 的行。如果字段有 NULL 值兩個結果可能不同。5.2 GROUP BY 分組統計分組統計通常對應報表類接口。例如按訂單狀態統計每種狀態的訂單數。SELECT status, COUNT(*) AS order_count, SUM(amount) AS total_amount FROM test_order GROUP BY status;按天統計每天的訂單量是測試數據校驗和報表驗證的高頻操作。SELECT DATE(create_time) AS order_date, COUNT(*) AS order_count FROM test_order GROUP BY DATE(create_time) ORDER BY order_date DESC;這里的DATE()函數把datetime字段轉成日期格式然后按日期分組。MySQL 還支持DATE_FORMAT()做更靈活的格式化。SELECT DATE_FORMAT(create_time, %Y-%m-%d) AS order_date, COUNT(*) AS order_count FROM test_order GROUP BY DATE_FORMAT(create_time, %Y-%m-%d);5.3 HAVING 過濾分組結果WHERE是在分組前過濾行HAVING是在分組后過濾組。這個區別是 MySQL 面試題常客也是測試中容易用錯的地方。例如只查詢訂單數大于 10 的狀態。SELECT status, COUNT(*) AS order_count FROM test_order GROUP BY status HAVING COUNT(*) 10;WHERE不能直接過濾聚合結果所以需要聚合后的條件只能寫在HAVING中。5.4 SELECT 執行順序理解執行順序對排查查詢結果異常很重要。SQL 的邏輯執行順序大致如下。FROM確定數據來源WHERE過濾原始行GROUP BY分組HAVING過濾分組結果SELECT選擇輸出字段ORDER BY排序LIMIT限制行數測試中遇到“為什么查出來的條數和預期不一致”的問題時按這個順序排查先看是不是WHERE過濾掉了數據再看GROUP BY分組邏輯是否正確最后看HAVING和LIMIT是否截斷了結果。6. 多表關聯查詢INNER JOIN、LEFT JOIN6.1 INNER JOIN 內連接測試場景下業務數據經常分散在多個表中。比如訂單表只存用戶 ID用戶姓名在用戶表中。要查詢訂單同時展示用戶姓名就需要關聯查詢。SELECT o.id, o.order_no, o.amount, u.user_name, u.mobile FROM test_order o INNER JOIN test_user u ON o.user_id u.id WHERE o.status 1;INNER JOIN只返回兩張表中匹配成功的行。訂單表中的user_id在用戶表找不到對應記錄時這條訂單會被過濾掉。這里給表起了別名o和u后續查詢和 ORDER BY、LIMIT 中可以直接用別名引用字段。6.2 LEFT JOIN 左連接LEFT JOIN返回左表全部記錄右表沒有匹配時右表字段為 NULL。測試中常用于查詢“有訂單但用戶可能已刪除”的數據。SELECT o.id, o.order_no, o.user_id, u.user_name FROM test_order o LEFT JOIN test_user u ON o.user_id u.id;如果test_user表中沒有對應的用戶數據u.user_name會顯示為NULL但訂單記錄仍然保留。這個特性非常適合排查臟數據、孤兒訂單問題。測試時可以通過WHERE u.id IS NULL找到沒有匹配用戶的訂單。SELECT o.id, o.order_no, o.user_id FROM test_order o LEFT JOIN test_user u ON o.user_id u.id WHERE u.id IS NULL;這條 SQL 很有價值它能快速定位測試環境中因為用戶被刪除、數據被清庫導致的孤兒數據。6.3 多表關聯的綜合寫法業務系統通常不止兩張表可能是訂單表、用戶表、訂單明細表三張表關聯。測試核驗時需要按業務邏輯逐步拼裝。SELECT o.order_no, u.user_name, od.product_name, od.product_count, od.product_price FROM test_order o INNER JOIN test_user u ON o.user_id u.id INNER JOIN test_order_detail od ON o.id od.order_id WHERE o.order_no TEST202501010001 ORDER BY od.id;這種查詢在核對訂單詳情接口、導出報表數據時非常有用。如果前端展示的訂單明細和數據庫對不上用這條 SQL 可以直接定位是哪張表的數據有問題。7. 子查詢嵌套查詢與 EXISTS 判斷子查詢是嵌套在外層查詢內部的 SELECT 語句。測試中用于解決“先算出一個結果集再拿這個結果集去過濾主查詢”的場景。7.1 WHERE 條件中的子查詢查詢下單金額大于平均下單金額的訂單。SELECT id, order_no, amount FROM test_order WHERE amount (SELECT AVG(amount) FROM test_order);括號里的子查詢先執行得到平均值外層查詢再取大于該值的訂單。7.2 IN 配合子查詢查找下過單的用戶信息。SELECT id, user_name, mobile FROM test_user WHERE id IN (SELECT DISTINCT user_id FROM test_order);這條 SQL 在測試中常用于驗證“哪些用戶實際產生了訂單”。子查詢先返回所有下過單的user_id外層查詢再返回這些用戶的完整信息。7.3 EXISTS 子查詢EXISTS只關心子查詢是否有返回行。它的寫法和IN不同適合判斷關聯關系。SELECT id, user_name FROM test_user u WHERE EXISTS ( SELECT 1 FROM test_order o WHERE o.user_id u.id );這個查詢和上面的IN寫法結果類似。區別是EXISTS是逐行判斷是否存在IN是先算出子查詢結果集再匹配。數據量大的場景下兩者性能可能有差異但測試階段首先保證邏輯正確。測試 IN 子查詢時有一個經典坑如果子查詢結果集中包含 NULLNOT IN會返回空結果。例如WHERE id NOT IN (SELECT user_id FROM test_order)當test_order.user_id存在 NULL 時整個查詢不會返回任何行。排查這個問題的常用手段是把子查詢改成WHERE user_id IS NOT NULL或者改用NOT EXISTS。SELECT id, user_name FROM test_user u WHERE NOT EXISTS ( SELECT 1 FROM test_order o WHERE o.user_id u.id );這條 SQL 能查出來從未下過單的用戶測試數據清理時比NOT IN更穩妥。8. 測試工程師實踐造數、查數、驗證、清理8.1 造測試數據接口測試和功能測試經常需要準備指定狀態的數據。手工在頁面點擊生成太慢直接往數據庫插入是效率最高的方式。插入一條用戶數據。INSERT INTO test_user (user_name, mobile, status, create_time) VALUES (測試用戶A, 13800138000, 1, NOW());按批量方式插入多條數據。INSERT INTO test_user (user_name, mobile, status, create_time) VALUES (測試用戶B, 13800138001, 1, NOW()), (測試用戶C, 13800138002, 0, NOW()), (測試用戶D, 13800138003, 2, NOW());如果需要造大量數據可以用循環或者存儲過程。注意批量造數時要控制數據量避免給測試環境數據庫造成過大壓力。8.2 修改測試數據狀態狀態機流轉是業務測試的重點比如訂單從待支付改成已支付。正常通過頁面操作可能很慢直接更新數據庫狀態字段是測試圈常用的“捷徑”。UPDATE test_order SET status 1 WHERE order_no TEST202501010001;執行 UPDATE 后可以再用 SELECT 確認修改是否生效。SELECT id, order_no, status FROM test_order WHERE order_no TEST202501010001;這里有一個重點UPDATE 和 DELETE 都要先 SELECT 確認條件再執行更新。直接寫 UPDATE 語句一旦條件寫錯可能批量修改誤傷大量數據。更穩妥的做法是先把 WHERE 條件放到 SELECT 里查一遍確認命中數據后再改成 UPDATE 執行。8.3 清理測試臟數據測試完成后需要清理插入的臟數據避免影響后續測試。清理用 DELETE 命令。DELETE FROM test_user WHERE mobile LIKE 13800138000%;清理數據要注意外鍵約束。如果訂單表有外鍵指向用戶表直接刪除用戶可能報錯。需要先清理子表數據再刪除主表數據或者按業務要求先確認沒有依賴。DELETE FROM test_order WHERE user_id IN (SELECT id FROM test_user WHERE mobile LIKE 13800138000%); DELETE FROM test_user WHERE mobile LIKE 13800138000%;執行 DELETE 后檢查影響行數確認刪除的范圍正確。8.4 事務控制造數、修改、清理數據時建議先開啟事務確認無誤后再提交。MySQL 默認是自動提交但測試中手動控制更安全。START TRANSACTION; UPDATE test_order SET status 1 WHERE order_no TEST202501010001; SELECT id, order_no, status FROM test_order WHERE order_no TEST202501010001; COMMIT;如果發現數據修改不對可以用ROLLBACK回滾不產生實際影響。START TRANSACTION; DELETE FROM test_user WHERE mobile LIKE 13800138000%; -- 發現問題回滾 ROLLBACK;事務控制是測試操作數據庫最重要的安全機制之一比任何命令都值得養成習慣。9. MySQL 查詢常見問題與排查方法問題現象可能原因排查方式解決方案連接時報 ERROR 2059MySQL 8.0 默認認證插件不支持老客戶端確認 MySQL 版本和客戶端版本升級客戶端或修改用戶認證插件為 mysql_native_password連接時提示 Access denied賬號密碼錯誤或沒有遠程訪問權限確認賬號密碼和授權范圍使用正確賬號或在服務端授權該賬號遠程訪問中文亂碼客戶端字符集和數據庫字符集不一致查看連接字符集和表字段字符集執行 SET NAMES utf8mb4; 或修改連接字符集查詢很慢沒有索引或走了全表掃描使用 EXPLAIN 查看執行計劃根據查詢條件優化索引避免 SELECT *執行 UPDATE 一直卡住存在鎖表或鎖行沖突查看SHOW PROCESSLIST和鎖等待等待事務結束排查死鎖或長時間未提交的事務查詢結果和頁面不一致存在緩存、事務未提交、或多個環境庫確認查詢的是哪個環境哪個庫切換正確環境確認事務已提交ORDER BY 排序結果不符合預期字符串排序和數字排序差異確認字段類型是 varchar 還是 int轉換類型后再排序或調整業務邏輯插入數據提示字段過長字段長度限制查看字段類型和長度調整測試數據長度或修改表結構這里重點說一下 2059 連接錯誤。MySQL 8.0 安裝后默認創建的用戶使用caching_sha2_password插件而 Navicat 早期版本或者 MySQL 5.x 客戶端默認使用mysql_native_password雙方認證方式不兼容就會報Authentication plugin caching_sha2_password cannot be loaded。解決方法有兩種。一種是升級客戶端到支持 MySQL 8.0 的版本另一個是用管理員賬號登錄后修改用戶認證插件。ALTER USER test_user% IDENTIFIED WITH mysql_native_password BY 你的密碼; FLUSH PRIVILEGES;鎖表問題也值得單獨說。測試環境經常有人開著事務不提交或者后臺任務執行時間過長導致你執行 UPDATE 或者 DELETE 時一直卡住。遇到這種情況先看當前進程列表。SHOW PROCESSLIST;找到State為Waiting for table metadata lock或者Locked的連接確認是哪個會話持有鎖。如果是自己開的線程可以把這個會話殺掉。KILL 12345;這里的12345是SHOW PROCESSLIST結果中的Id字段值。生產環境執行 KILL 要格外謹慎測試環境可以放開操作。用 EXPLAIN 分析慢查詢也是排查索引問題的常用手段。EXPLAIN SELECT * FROM test_order WHERE user_id 10086 AND status 1;關注type字段和rows字段。type為ALL說明走了全表掃描rows數值很大則說明掃描了大量行。測試階段發現查詢慢最直接的建議是核對 where 條件的字段是否建了索引。10. 測試工程師建議養成的 MySQL 使用習慣本文最后一部分給出幾條實戰層面的建議。第一條操作數據庫前先確認環境。測試環境、預發環境、生產環境的庫可能長得一模一樣但數據完全不同。連接前看清楚 host 和數據庫名避免連錯環境。日常操作中把不同環境的連接信息分開存放不要混用。第二條UPDATE 和 DELETE 前先 SELECT。先把 WHERE 條件放到 SELECT 語句里執行確認命中的數據就是你要改的數據再把它改成 UPDATE 或 DELETE。這個習慣能避免大量誤操作。第三條寫完 SQL 先格式化。MySQL 命令不區分大小寫但項目和團隊一般有規范的寫法關鍵字大寫、表名字段名小寫、縮進對齊對排查問題更有幫助。自己維護一份常用 SQL 片段庫下次直接復制改條件。第四條多表查詢優先用 JOIN而不是在 WHERE 里寫逗號關聯。JOIN 寫法更明確ON條件把關聯關系表達得很清楚可讀性更好排查問題時也更容易定位。第五條查數據時要有“結果導向”。不要為了查而查先想清楚要驗證什么業務邏輯再決定查哪些字段、加哪些條件。這樣既能提高效率也能加深對業務的理解。第六條不要在生產環境隨意執行 UPDATE、DELETE。如果確實需要必須經過審批并盡量使用事務控制確認影響行數后再提交。11. 總結與下一步軟件測試工程師的 MySQL 查詢命令實戰核心就是把 SELECT、WHERE、ORDER BY、LIMIT、聚合函數、JOIN 和子查詢用熟。這些命令本身不難難的是在不同測試場景下知道自己該查什么、怎么查、怎么驗證結果。建議按照下面的順序做一輪實戰練習。第一步連上測試環境數據庫用 SHOW DATABASES 和 DESC 熟悉表結構。第二步抄寫本文第 3 節的單表查詢示例改成你項目里的真實表名和字段名跑通一遍。第三步找一張有狀態字段的業務表用 GROUP BY 加 CASE WHEN 做一次狀態統計驗證和前端報表數字是否一致。第四步找兩張有關聯關系的表用 LEFT JOIN 查一次包含 NULL 的數據判斷是否存在孤兒數據。第五步把 UPDATE、DELETE 放入事務中執行練習 COMMIT 和 ROLLBACK。完整跑完這幾步日常測試中涉及 MySQL 查詢命令的基本場景就都能覆蓋了。后面再遇到數據庫相關的測試任務可以直接翻這篇文章按圖索驥。建議收藏備用。