學習軟件測試的第十二天(接口測試)

一.如果一個接口請求不通,那么你會考慮那些方面的問題?

如果一個接口請求不通,我會像“排查水管漏水”一樣一步步定位問題發生在哪一段,主要從這幾個方向去思考:

當一個接口請求不通時,我會從以下幾個方面進行排查:

  1. 接口地址與請求方式是否正確:確認 URL 是否拼寫正確,是否使用了正確的 HTTP 方法(GET、POST 等)。

  2. 網絡連通性檢查:使用 ping、curl 或 Postman 檢查接口是否能訪問,是否存在 DNS 或代理等網絡層問題。

  3. 請求參數合法性:檢查必傳參數是否缺失,格式是否符合接口規范。

  4. 服務端狀態排查:查看服務是否部署正常,接口是否已上線或存在異常(如500錯誤)。

  5. 權限與鑒權問題:確認是否傳遞了正確的 token 或 API key,是否有權限訪問該接口。

  6. 跨域限制(前端場景):檢查是否存在 CORS 跨域問題導致請求被瀏覽器攔截。

通過從客戶端、網絡、服務端三個層級依次排查,可以快速定位接口請求失敗的根本原因。

在實際項目中,我遇到過因為 token 過期導致接口返回 401 的問題,通過日志定位并添加自動刷新機制解決了問題。

二.如何設計接口測試用例,請列舉關鍵步驟

1.通俗易懂解釋

設計接口測試用例,就像你要驗證一個自動販賣機是否工作正常。你需要:

  1. 確認輸入是否正確處理(比如投幣+按鍵,能買到飲料);

  2. 測試異常輸入會不會報錯(比如投假幣);

  3. 看看它穩定性如何(快速多次操作會不會崩);

  4. 驗證權限(是不是管理員才能開機);

  5. 驗證邊界情況(最多能買多少瓶);

這些就是接口測試要覆蓋的邏輯。

2.面試術語

設計接口測試用例通常包括以下關鍵步驟:

1. 明確接口需求和文檔

  • 理解接口的功能、輸入參數、請求方式(GET/POST等)、返回格式、狀態碼等。

2. 劃分測試維度

主要包括:

  • ? 功能測試:驗證接口是否按預期返回正確結果(如正常輸入返回 200 和期望數據);

  • 🚫 異常/負面測試:如缺失參數、參數類型錯誤、非法輸入等,檢查返回是否符合預期錯誤(如400/401等);

  • 🔐 權限測試:是否需要鑒權?Token 缺失/無效是否能攔截?

  • 🔁 邊界測試:如字符串最大長度、數組最大值、分頁邊界等;

  • 📶 兼容性和穩定性測試:高并發、大數據量、重復請求、請求順序等;

  • 🕒 超時與性能測試:模擬慢響應或超大請求,看系統是否穩定處理;

3. 設計具體測試用例

每個維度下撰寫用例,通常包括以下字段:

  • 用例編號

  • 測試目標

  • 請求方法/URL

  • 輸入參數

  • 預期返回結果(狀態碼+響應內容)

4. 構造測試數據

  • 區分正常值、邊界值、非法值、空值等組合情況,覆蓋不同場景。

5. 使用工具執行測試

  • 如 Postman、JMeter、Python 腳本或自動化框架(如 pytest + requests)來執行與驗證。

三.如何驗證接口的安全性?

1.通俗易懂解釋:怎么理解接口安全性驗證

可以把接口安全性理解成給“出入口加防盜門+監控”,防止別人:

  • 偷看(信息泄露)

  • 偷用(越權訪問)

  • 搗亂(注入攻擊、篡改數據)

所以你要做的,就是模擬“壞人”常用的幾種攻擊手段,驗證系統有沒有防住。

2.面試術語

當驗證接口的安全性時,我主要從以下六個維度進行系統性測試:

  1. 身份認證與權限控制

    • 確認接口是否正確校驗用戶身份(如 token、API key),并防止未授權或越權訪問。

    • 重點測試未登錄、低權限用戶訪問敏感接口的行為。

  2. 參數校驗與防注入

    • 驗證接口是否對輸入參數做了格式校驗,能否抵御 SQL 注入、XSS、命令注入等攻擊。

    • 會構造惡意 payload,如 ' OR 1=1 --、HTML 標簽等,進行黑盒驗證。

  3. 敏感數據保護

    • 檢查接口是否啟用了 HTTPS,傳輸過程是否加密;

    • 響應中是否有明文密碼、身份證號、token 等敏感信息泄露。

  4. 防刷與限流機制

    • 測試接口是否具有限速、IP 限制、驗證碼等防刷設計,防止接口被惡意調用或攻擊。

    • 通常使用并發腳本測試限流閾值和響應策略。

  5. 防重放與簽名機制

    • 檢查是否使用時間戳、nonce、簽名等方式防止請求被截獲重放;

    • 對關鍵接口進行重復請求驗證。

  6. 接口暴露與錯誤信息控制

    • 驗證是否存在未授權的調試接口、Swagger 文檔泄露;

    • 檢查異常返回是否暴露堆棧信息或系統路徑。

四.什么是接口斷言,如何設計接口斷言?

1.通俗解釋

可以把斷言理解成驗收標準
我們不是只發出請求,而是要檢查接口返回的結果是不是“對的”

比如你點外賣后,收到的不是奶茶而是漢堡,你當然要投訴 —— 接口斷言就是“檢查你點的是不是你要的”。

2.面試術語

接口斷言是指在接口測試中,對接口返回的狀態碼、響應體、字段內容、結構等進行自動化校驗,以判斷接口是否返回了預期結果。

例如,購物系統的訂單狀態查詢接口測試中,設計斷言,狀態碼是200,表示響應體中的訂單狀態字段值與數據庫一致。

確定斷言維度(設計斷言類型)

? 1. 狀態碼斷言

確保接口響應狀態正確
例:assert response.status_code == 200

? 2. 字段值斷言

驗證返回中關鍵字段值是否為預期
例:assert response.json()["code"] == 0

? 3. 字段類型與格式斷言

確保字段類型正確,或符合正則、格式標準
例:assert isinstance(response.json()["data"]["id"], int)

? 4. 字段存在性斷言

驗證返回體中是否包含預期字段
例:assert "userId" in response.json()["data"]

? 5. 列表/分頁數據斷言

校驗數組長度、分頁邊界、順序
例:assert len(response.json()["data"]["items"]) <= page_size

? 6. 業務邏輯斷言(核心加分項)

如余額變更是否正確、訂單狀態是否符合流程等
例:assert response.json()["data"]["orderStatus"] == "PAID"

五.如何處理接口依賴?

1.通俗解釋

接口依賴就像做飯時要先洗菜、切菜,才能炒菜。

比如你要測試“下單接口”,但它依賴“登錄接口”和“添加購物車接口”先執行,才能成功下單。

所以你要想辦法:

  • 把前置接口先跑一遍;

  • 把里面的關鍵數據(比如 token、order_id)提取出來;

  • 用在后面的接口請求中。

2.面試術語

在接口測試中,若某個接口依賴前置接口提供的數據(如 token、user_id、訂單號等),可以通過以下方式進行處理:


1. 通過接口調用獲取依賴數據

  • 先執行前置接口(如登錄),提取響應中的關鍵字段(如 token、id);

  • 使用該數據動態傳入后續接口的請求參數中,實現數據鏈路閉環。

🧩 示例:從登錄接口響應中提取 token,添加到下單接口的 header。


2. 利用測試框架的數據傳遞機制

  • 使用全局變量、fixture(pytest)、環境變量或數據上下文對象,在多個接口間傳遞數據;

  • 自動化框架如 Postman、pytest、HttpRunner 支持變量引用與參數提取機制。


3. 設計前置步驟或數據準備函數

  • 將依賴數據的創建邏輯封裝成 setup 方法或前置腳本,在測試執行前自動調用;

  • 確保測試環境干凈、數據可控、可復現。


4. 使用 Mock 或數據庫初始化(降低強依賴)

  • 若接口過于復雜或依賴不穩定,也可使用 Mock 接口模擬返回數據;

  • 或通過 SQL 語句直接初始化測試數據,提高執行效率與穩定性。

總結:我處理接口依賴時,通常會通過執行前置接口并提取關鍵字段(如 token、id),結合自動化測試框架的變量機制傳遞到后續接口中。如果依賴關系復雜,也會將前置數據準備邏輯封裝成 setup 方法,或者通過數據庫初始化和 Mock 減少對上游接口的依賴,保證測試流程的穩定性和可復現性。

六.在多接口業務流程測試中,如何確保接口之間的調用順序正確

1.通俗解釋

可以把多接口測試流程想象成“網購流程”:

  • 先登錄 → 再加購物車 → 再下單 → 再支付 → 再查訂單

如果順序錯了,比如還沒登錄就去下單,就會失敗。

所以你要做的就是:

  • 每個接口按業務順序執行

  • 上一個接口的返回值要正確傳給下一個接口

  • 并且中間出錯時,整個流程要能及時終止或報警

2.思考流程?

? 1. 明確業務流程與依賴關系

先分析接口間的上下游依賴,比如必須先登錄再下單、必須先創建資源再更新等。

🧩 建議繪制接口流程圖或寫成步驟列表,幫助理清順序。


? 2. 按順序設計測試步驟

測試用例中接口調用應嚴格按照業務流程順序執行,每一步成功后才執行下一步。

例如:Step 1:調用登錄接口 → 獲取 token Step 2:使用 token 調用創建訂單接口 → 獲取 order_id Step 3:使用 order_id 調用支付接口


? 3. 數據動態提取與傳遞

利用自動化測試框架(如 Postman、pytest、HttpRunner)提取前置接口的返回值,通過變量機制傳入后續請求中。

🧩 示例:

  • 提取 token:{{login_response.token}}

  • 提取 order_id:extract_var("order_id") → inject_to("next_api_body")


? 4. 前置依賴封裝(setup/fixture)

將前置步驟封裝為 setup 方法或 fixture,讓測試框架自動先執行前置接口,保障數據準備完整。


? 5. 流程中加入斷言與失敗中斷機制

每個接口執行后加入斷言,若任一步失敗,及時中斷后續接口調用,避免無效操作或誤判結果。


? 6. 使用測試集或場景管理工具(高級做法)

在大型項目中,使用如 Postman Collection Runner、pytest 測試集、Jenkins 流程任務等,管理完整業務流程測試。

3.面試術語?

在多接口流程測試中,我會先梳理接口依賴關系,明確業務順序,然后按邏輯設計測試用例鏈條,并在每一步提取關鍵數據傳給下一個接口。通過斷言與前置方法機制,確保每一步成功執行,整體流程穩定可控。在自動化測試中,我也會使用 fixtures 或流程控制機制保障順序性。

七.接口測試是什么,為什么要做接口測試

接口測試就像是“檢查系統內部各個模塊之間的溝通是否順暢”,防止“你說的我聽不懂”這種情況。

接口測試是指針對系統中模塊或服務之間的數據交換接口(如 HTTP API、RPC 接口等)進行的測試,主要驗證接口的功能正確性、穩定性、安全性、兼容性和性能,確保系統各個部分之間數據傳輸準確、調用邏輯合理

通常包括:

  • 請求是否能正確處理參數;

  • 返回的數據是否符合預期;

  • 接口是否具備容錯機制、安全控制等。

接口測試是保障系統模塊間通信正確性與穩定性的關鍵手段。相比 UI 測試,它更早介入、更高效穩定,能快速定位服務端問題,是構建高質量系統不可或缺的環節,尤其在微服務和前后端分離架構中更為重要。

?八.Cookie、session、token的區別

  • Cookie 就像“你隨身帶的身份證”——瀏覽器存的,每次訪問都會自動發給服務器。

  • Session 是“服務器開的檔案柜”,你來一次,它給你一個編號(session id),存在服務端。

  • Token 是“數字簽名的通行證”,你帶著它,別人不能偽造,常用于移動端、分布式登錄。

對比項CookieSessionToken(如 JWT)
存儲位置瀏覽器端(客戶端)服務端客戶端(一般存 localStorage 或 Cookie)
數據存儲小量鍵值對(如 session ID)用戶信息保存在服務器內存或數據庫中用戶信息編碼后存儲在 token 中
生命周期可設置過期時間一般隨服務器關閉或用戶退出而失效可設置過期時間
安全性容易被盜用,需配合 HTTPOnly + HTTPS安全性較好,但服務端要保存大量會話信息簽名機制防偽造,不易被篡改
跨域支持默認不支持跨域不支持支持跨域,適合前后端分離系統
是否依賴服務端否(只是存數據)是(需服務器維護 session 狀態)不依賴服務端存狀態(無狀態)
常見應用場景網站登錄記住我、簡單信息記錄等PC端登錄、傳統網站移動端、前后端分離、單點登錄(SSO)

Cookie、Session 和 Token 都用于管理用戶身份和狀態:

  • Cookie 存在客戶端,用于在每次請求時攜帶信息;

  • Session 存在服務端,基于 Session ID 實現身份管理;

  • Token(如 JWT)是一種無狀態的身份驗證機制,適合前后端分離和分布式系統。

實際中,我通常在傳統網站使用 Cookie + Session,在前后端分離或移動端場景采用 Token 認證機制。

?九.接口測試中如何處理第三方依賴

接口測試中,第三方依賴就像“外包服務商” —— 比如發短信、支付接口、地圖服務等:

  • 你要測試自己的系統,但這些外部接口你控制不了;

  • 如果對方掛了、慢了、數據變了,你的測試就會出問題。

所以你要做的,就是:不完全依賴它,甚至“假裝它在”,也能測自己

? 1. 使用 Mock 技術模擬第三方接口返回

用 Mock Server 或工具(如 WireMock、Mock Service Worker、Postman Mock)模擬第三方接口的響應數據,避免測試依賴真實外部服務。

🧩 示例:

  • 模擬支付接口返回 {"code": 0, "msg": "success"}

  • 模擬地圖接口返回定位坐標。


? 2. 配置測試環境使用“沙箱環境”

如果第三方提供測試/沙箱環境,應切換接口配置,避免真實扣費、發短信等操作。

🧩 示例:

  • 支付寶、微信支付、短信服務等都有沙箱環境。


? 3. 前置準備依賴數據 / 響應緩存

對于無法 Mock 的接口,可提前調用一次并緩存響應結果,用于后續測試中“模擬使用”。


? 4. 接口調用進行降級處理 / 添加重試機制

在自動化測試腳本中,若第三方接口不穩定,可設定超時重試或失敗兜底邏輯,避免影響整條測試鏈路。


? 5. 僅測試集成邏輯,不重復驗證第三方服務功能

第三方接口自身已被測試過,我們關注的僅是與我方系統的集成是否正確,如參數是否正確傳入、回調是否處理成功。

總結:在接口測試中遇到第三方依賴時,我通常通過使用 Mock 服務模擬響應、切換至沙箱環境,或配置響應緩存,避免對外部接口的強依賴。同時,我會聚焦驗證系統自身的集成邏輯,確保參數傳遞、響應處理、容錯機制等正確,從而提高測試的穩定性和可控性。

十.你做接口測試的過程中發現了那些bug?

1.接口測試 Bug 匯總表

序號Bug 類型接口名稱問題描述預期行為實際返回示例 / 狀態碼優先級
1參數校驗缺失/api/user/login密碼字段為空仍返回 200 且提示登錄成功應返回 400 并提示“密碼不能為空”{ "code": 0, "msg": "登錄成功" }
2業務邏輯錯誤/api/order/create多次點擊“提交訂單”生成多筆相同訂單,缺少冪等性應限制重復提交或返回相同訂單號創建多個訂單編號
3越權訪問/api/admin/user普通用戶身份調用管理員接口可成功拉取所有用戶數據應返回 403 無權限狀態碼:200,返回全量用戶信息
4數據未更新/api/pay/notify支付完成后,訂單狀態未更新,但接口提示支付成功應將訂單狀態更新為“已支付”返回成功但查訂單仍為“待支付”
5字段缺失/api/user/info接口文檔中說明返回 nickname 字段,但實際返回中缺失應返回完整字段{ "code": 0, "data": { "id": 1 }}
6錯誤碼混亂/api/common/get所有錯誤均返回 200 狀態碼,錯誤信息寫在 body 中應使用語義正確的 HTTP 狀態碼(如 400、401、500 等)狀態碼:200,body: "msg": "參數錯誤"
7接口響應不一致/api/product/list部分情況下 data 字段返回數組,部分情況下返回 null接口返回結構應一致,空列表也應返回空數組{ "data": null }{ "data": [] }
8性能異常/超時/api/report/export數據量大時接口超時,無分頁導出或異步處理機制應使用異步任務或導出狀態輪詢機制請求卡住30秒后失敗
9安全漏洞/api/reset-pwd無需登錄即可傳手機號與驗證碼重置任意賬戶密碼應限制登錄態或增加權限校驗正常返回 密碼修改成功
10跨域限制缺失/api/open/query跨域請求時未配置 CORS 頭,瀏覽器攔截請求應返回帶有 Access-Control-Allow-Origin 等 CORS 頭部瀏覽器控制臺報錯 CORS policy blocked

? 通俗解釋:

當你訪問一個接口(比如打開一個網頁、請求一個后端服務),服務端都會返回一個“狀態碼”告訴你處理得怎么樣。

  • 返回 200,就像對方說:“? 請求我收到了,也處理成功了。”

  • 如果是 404,意思是“? 你找的接口地址我沒有”;

  • 如果是 500,是“? 我服務端出錯了”;

  • 如果是 401,是“? 你沒有權限(可能沒登錄)”。

🎯 專業術語表達:

HTTP 狀態碼是服務器對客戶端請求的響應結果的標準表示,其中 200 OK 表示接口請求成功且服務器已正確處理了該請求。

在接口測試中,檢查是否返回 200 是最基礎的斷言,用于判斷接口是否通、是否處理成功。


🧠 注意:

雖然 返回 200 表示接口成功響應,但:

  • 不代表業務一定正確!例如:登錄接口返回 200,但登錄失敗;

  • 所以還要結合業務字段斷言(如 code、msg、data)判斷接口是否真的“業務成功”。

總結:在接口測試過程中,我不僅關注接口是否返回 200,還會從參數合法性、權限控制、業務邏輯完整性、數據一致性等多個維度設計用例,實際也發現了不少隱藏較深的 Bug,比如重復下單、越權訪問、冪等缺失、接口結構不規范等,這些問題在早期發現能極大提升系統的穩定性與安全性。?

本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。
如若轉載,請注明出處:http://www.pswp.cn/news/913681.shtml
繁體地址,請注明出處:http://hk.pswp.cn/news/913681.shtml
英文地址,請注明出處:http://en.pswp.cn/news/913681.shtml

如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!

相關文章

Linux下的C/C++開發之操作Zookeeper

ZooKeeper C 客戶端簡介與安裝ZooKeeper C API 簡介ZooKeeper 官方提供了多語言客戶端&#xff0c;C 語言客戶端是最底層的實現之一&#xff0c;功能全面且穩定&#xff0c;適合嵌入式開發、系統級組件、C 項目集成等場景。zookeeper.h 是 ZooKeeper 提供的 C 語言客戶端頭文件…

【openp2p】學習3:【專利分析】一種基于混合網絡的自適應切換方法、裝 置、設備及介質

本專利與開源項目無關,但可能是實際商用的一種專利。專利地址從此專利,可見p2p的重要性。透傳服務可能是實時轉發服務,提供中繼能力 透傳服務可以是指一種通過公網服務器將數據從第一客戶端傳遞到另一個設備 或客戶端的服務。這種服務通常用于克服網絡中的障礙,如防火墻、…

OpenCV中DPM(Deformable Part Model)目標檢測類cv::dpm::DPMDetector

操作系統&#xff1a;ubuntu22.04 OpenCV版本&#xff1a;OpenCV4.9 IDE:Visual Studio Code 編程語言&#xff1a;C11 算法描述 OpenCV 中用于基于可變形部件模型&#xff08;DPM&#xff09; 的目標檢測器&#xff0c;主要用于行人、人臉等目標的檢測。它是一種傳統的基于特…

macOS 26快捷指令更新,融入AI打造智能操作體驗

快捷指令作為Mac系統中提升用戶操作效率的得力助手&#xff0c;在macOS 26中迎來了一次具有突破性的重大更新。此次更新融入了先進的AI技術&#xff0c;推出“智能操作”&#xff08;Intelligent Actions&#xff09;功能&#xff0c;讓快捷指令從簡單的自動化工具升級為真正的…

InstructBLIP:邁向具備指令微調能力的通用視覺語言模型

溫馨提示&#xff1a; 本篇文章已同步至"AI專題精講" InstructBLIP&#xff1a;邁向具備指令微調能力的通用視覺語言模型 摘要 大規模的預訓練與instruction tuning在構建通用語言模型方面已取得顯著成效。然而&#xff0c;構建通用的視覺-語言模型仍然具有挑戰性&…

基于dropbear實現嵌入式系統ssh服務端與客戶端完整交互

以下基于 Dropbear 實現 SSH 服務端與客戶端交互的完整步驟&#xff0c;涵蓋服務端部署、客戶端連接、認證配置及消息傳輸&#xff0c;結合了多篇權威資料的核心實踐&#xff1a;環境準備與安裝 服務端安裝 ? Linux 系統&#xff08;以 Ubuntu/CentOS 為例&#xff09; Ubuntu…

深圳安銳科技發布國內首款4G 索力儀!讓斜拉橋索力自動化監測更精準高效

近日&#xff0c;深圳安銳科技正式發布國內首款無線自供電、一體化的斜拉索實時監測設備 “4G索力監測儀”&#xff0c;成功攻克了傳統橋梁索體監測領域長期存在的實時性差、布設困難和成本高昂的行業難題&#xff0c;為斜拉橋、系桿拱橋提供全無線、自動化、云端實時同步的索力…

Pipeline 引用外部數據源最佳實踐

場景解析在企業網絡安全日志處理場景中&#xff0c;防火墻、入侵檢測系統&#xff08;IDS&#xff09;等設備會持續產生大量日志&#xff0c;記錄網絡流量、訪問請求、異常事件等基礎信息&#xff0c;但這些原始日志僅能呈現表面現象&#xff0c;難以全面剖析安全威脅&#xff…

UI + MCP Client + MCP Server(并且鏈接多個Server)

項目結構前端項目--------->MCP Client----------->MCP Serverserver就不過多贅述了&#xff0c;他只是相當于添加了多個的tools 鏈接前后端 http.createServer創建一個服務器// ---------------------------------------------------------------- // server.js import …

香港站群服務器與普通香港服務器對比

在選擇香港服務器時&#xff0c;用戶常常會遇到"站群服務器"和"普通服務器"兩種選項&#xff0c;雖然它們都基于香港數據中心的基礎設施&#xff0c;但在 IP 地址配置、功能定位和管理復雜度、成本上存在顯著差異&#xff0c;理解這些差異有助于用戶根據實…

4.B樹和B+樹的區別?為什么MySQL選擇B+樹作為索引?

區別&#xff1a;1.數據存儲位置B樹每個節點都存儲了索引和數據B樹只有葉子節點存儲數據&#xff0c;非葉子節點僅存儲索引2.葉子節點的鏈接B樹的所有葉子節點通過指針連接成一個雙向鏈表&#xff0c;可以高效地進行范圍查詢或者順序遍歷B樹則沒有這樣的連接關系&#xff0c;查…

轉換狂魔,Modbus TCP轉Profinet網關打通視覺傳感線連接之路

在汽車零部件沖壓生產線的世界中&#xff0c;液壓機的壓力穩定性是確保產品質量的秘密武器。然而&#xff0c;舊時代的人工巡檢和傳統監測方式卻好似拖累現代化進程的沉重枷鎖&#xff1a;效率低、成本高&#xff0c;還總是趕不上實時反饋的快車。這時&#xff0c;工廠決心大刀…

C++進階—二叉樹進階

第一章&#xff1a;內容安排說明 map和set特性需要先鋪墊二叉搜索樹&#xff0c;而二叉搜索樹也是一種樹形結構二叉搜索樹的特性了解&#xff0c;有助于更好的理解map和set的特性二叉樹中部分面試題稍微有點難度&#xff0c;在前面講解大家不容易接受&#xff0c;且時間長容易…

驅動下一代E/E架構的神經脈絡進化—10BASE-T1S

汽車電子電氣架構的演進正經歷一場深刻的變革&#xff0c;“中央計算單元區域控制器”的架構模式已成為當前主流車型平臺發展的明確方向。這種從傳統的“功能域”&#xff08;Domain&#xff09;架構向“區域”&#xff08;Zonal&#xff09;架構的轉型升級&#xff0c;旨在實現…

某學校系統中挖礦病毒應急排查

本篇文章主要記錄某學校長期未運營維護的程序&#xff0c;被黑客發現了漏洞&#xff0c;但好在學校有全流量設備&#xff0c;抓取到了過程中的流量包 需要你進行上機以及結合流量分析&#xff0c;排查攻擊者利用的漏洞以及上傳利用成功的木馬 文章目錄靶機介紹1.使用工具分析共…

vue 、react前端頁面支持縮放,echarts、地圖點擊左邊不準的原因和解決辦法

原因 由于以上都是通過canvas畫布生成的&#xff0c;一旦初始化&#xff0c;就會按照比例進行縮放&#xff0c;但與此同時&#xff0c;比例尺并沒有變化&#xff0c;導致坐標偏移 解決辦法 設置一個zoomVal產量&#xff0c;在頁面加載時計算縮放比例&#xff0c;然后在canvas容…

(LeetCode 每日一題) 1353. 最多可以參加的會議數目 (優先隊列、小頂堆)

題目&#xff1a;1353. 最多可以參加的會議數目 思路&#xff1a;優先隊列實現小頂堆&#xff0c;0(mx*logn) 在第i天&#xff0c;優先選endDay最小的那一個活動進行。那么遍歷每一天&#xff0c;用小頂堆來維護每個活動的最后一天即可&#xff0c;細節看注釋。 C版本&#xf…

Java結構型模式---代理模式

代理模式基礎概念代理模式是一種結構型設計模式&#xff0c;其核心思想是通過創建一個代理對象來控制對另一個真實對象的訪問。代理對象在客戶端和真實對象之間起到中介作用&#xff0c;允許在不改變真實對象的前提下&#xff0c;對其進行增強或控制。代理模式的核心組件主題接…

MySQL流程控制函數全解析

MySQL 中的流程控制函數&#xff08;也稱為條件函數&#xff09;允許你在 SQL 語句中進行邏輯判斷&#xff0c;根據不同的條件返回不同的值或執行不同的操作。它們極大地增強了 SQL 的靈活性和表達能力&#xff0c;尤其在進行數據轉換、結果格式化、條件聚合和復雜業務邏輯實現…

【7】PostgreSQL 事務

【7】PostgreSQL 事務前言使用事務事務內錯誤處理事務保存點DDL 事務前言 在 PostgreSQL 中&#xff0c;每一個操作都是一個事務。即使一個簡單的查詢(select)&#xff0c;這也是一個事務。 例如&#xff1a; postgres# select now();now --------------------…