測試面試題總結一

列表、元組、字典的區別

nvicat連接出現問題如何排查

mysql性能調優

python連接mysql數據庫方法

參數化 @pytest.mark.parametrize 裝飾器

list1 = [1,7,4,5,5,6]? for i in range(len(list1): assert list1[i] < list1[i+1]? 這段程序有問題嘛？

?pytest.int 是干什么的

前端問題后端問題怎么辨別？

性能測試的指標如何獲取？

批量接口的參數怎么驗證？

給你一個水杯，怎么測（結合功能，性能，安全性，易用性，外觀）

測試流程

?對于postman和JMeter工具，a接口需要b接口傳入數據怎么辦

常用的測試方法

測試用例怎么寫才能不遺漏測試點？

?sql完整的增刪改查命令

如果誤執行了DELETE FROM orders怎么辦？

如果開發人員不認可你提出的缺陷，你會如何處理

Bug 嚴重等級劃分標準

測試人員發現 Bug 后要怎么處理

接口測試用例的設計思路一般是從哪些方面去考慮的？

什么是冒煙測試？其目的和意義是什么？

談談你對敏捷測試的理解與實踐？

介紹一下po模型

什么項目適合做自動化測試?

對于頻繁更新的頁面元素，如何在自動化測試中進行有效定位和維護

軟件測試工作可能會面臨項目緊急、任務繁重以及來自開發團隊和上級的壓力，你會如何應對？

列表、元組、字典的區別

nvicat連接出現問題如何排查

檢查連接參數:主機名，端口號，用戶名，密碼，數據庫名

ping 服務器：檢查服務器是否可達。

telnet 測試端口：確認端口開放。

確認 MySQL 服務運行狀態：

Windows：在服務管理器中檢查 MySQL 服務是否啟動。
Linux：systemctl status mysql

檢查服務器防火墻：Windows 防火墻--》在防火墻中添加 MySQL 允許規則。

檢查 MySQL 配置文件my.ini中?bind-address?是否配置正確

驗證用戶權限：
-- 查看用戶權限
SHOW GRANTS FOR 'username'@'%';-- 授予遠程訪問權限（示例）
GRANT ALL PRIVILEGES ON *.* TO 'username'@'%' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;

mysql性能調優

?MySQL 性能調優是提升數據庫應用響應速度和吞吐量的關鍵工作。

方法：

使用最小的數據類型存儲數據（如?TINYINT?代替?INT）

索引優化

避免全表掃描

多表關聯時用小表驅動大表

python連接mysql數據庫方法

使用 mysql-connector-python（官方驅動）

##安裝庫
pip install mysql-connector-python##連接數據庫
import mysql.connector
# 建立連接
try:conn = mysql.connector.connect(host="localhost",      # 主機名user="your_username",  # 用戶名password="your_password",  # 密碼database="your_database",  # 數據庫名（可選）port=3306              # 端口（默認3306）)if conn.is_connected():print("數據庫連接成功！")# 創建游標對象cursor = conn.cursor()# 執行SQL查詢cursor.execute("SELECT VERSION()")version = cursor.fetchone()print(f"MySQL版本: {version[0]}")# 關閉游標和連接cursor.close()conn.close()print("數據庫連接已關閉")except mysql.connector.Error as err:print(f"連接錯誤: {err}")

使用 pymysql（純 Python 實現）

##安裝庫
pip install pymysql#操作步驟
#導包
import pymysql
#創建連接
conn=pymysql.connnect(host="211.103.136.224",port="3306",user="student",password="123",database="test",charset="utf8")
#創建游標
my_cursor=conn.cursor()
# 執行 select sq]
my_cursor.execute("select version;")
#提取結果，打印查看
res = my_cursor.fetchone(
print("查詢結果為:"，res)
print("查詢結果為:"，res[0])
# 關閉游標
my_cursor.close(
#關閉連接
conn.close()

參數化 @pytest.mark.parametrize 裝飾器

它能讓單個測試函數執行多組參數

#語法：
#@pytest.mark.parametrize("測試函數的參數名(多個參數用逗號隔開)", 可迭代對象)示例：簡單
import pytest
def add(a, b):return a + b
@pytest.mark.parametrize("a, b, expected", [(1, 2, 3),       # 測試用例1：1+2=3(0, 0, 0),       # 測試用例2：0+0=0(-1, 1, 0),      # 測試用例3：-1+1=0(1.5, 2.5, 4.0), # 測試用例4：1.5+2.5=4.0
])
def test_add(a, b, expected):assert add(a, b) == expected示例：參數組合測試
import pytest
@pytest.mark.parametrize("x", [1, 2])
@pytest.mark.parametrize("y", [3, 4])
def test_combination(x, y):print(f"測試組合: x={x}, y={y}")   #1，3   1，4   2，3   2，4示例：從數據文件讀取參數
@pytest.mark.parametrize("a, b, expected", load_test_data())
def test_add_from_csv(a, b, expected):assert add(a, b) == expected

list1 = [1,7,4,5,5,6]? for i in range(len(list1): assert list1[i] < list1[i+1]? 這段程序有問題嘛？

當?i=0：檢查 list1[0] < list1[1] → 1 < 7，True，沒問題。
當?i=1：檢查 list1[1] < list1[2] → 7 < 4，False，這會觸發 AssertionError，但首先我們得處理索引問題。
當?i=2：list1[2] < list1[3] → 4 < 5，True。
當?i=3：list1[3] < list1[4] → 5 < 5？False，因為 5 不小于 5。--》邏輯錯誤
當?i=4：list1[4] < list1[5] → 5 < 6，True。
當?i=5：list1[5] < list1[6]，但 list1[6] 不存在，所以 IndexError。--》索引越界錯誤

?pytest.int 是干什么的

pytest.ini 是 Pytest 測試框架的核心全局配置文件。通常位于項目根目錄下，Pytest 運行時會自動加載其配置。

#設置默認命令行參數 (addopts)
[pytest]
addopts = -v -s --html=report.html --maxfail=2
-v：顯示詳細測試結果（輸出每個用例名稱） 
-s：輸出測試中的打印信息（如 print() 語句）。
--html=report.html：自動生成 HTML 測試報告（需安裝 pytest-html）。
--maxfail=2：當失敗用例達到 2 個時停止測試。#定義測試用例的識別規則
[pytest]
python_files = test_*.py      # 識別以 "test_" 開頭的文件
python_classes = Test*        # 識別以 "Test" 開頭的類
python_functions = test_*     # 識別以 "test_" 開頭的方法/函數

前端問題后端問題怎么辨別？

主要是想探你有沒有基礎的服務端測試經驗。web端F12抓接口看傳參，app抓包工具抓接口，傳參沒異常排除前端，響應異常的話服務端看日志有沒有具體的報錯信息這是后端異常，定位到具體代碼行數可以看看代碼實現。

性能測試的指標如何獲取？

指標要結合測試場景制定，大概分為兩種，一種對方沒有明確的指標要求只是想知道系統瓶頸，那就從小往大增壓；對方有明確的指標要求比如QPS、并發人數等等那就按目標遞增。

批量接口的參數怎么驗證？

想探你接口自動化經驗，不管是自己搭腳手架還是用開源工具，批量驗證響應結果的話基本都是靠斷言。

給你一個水杯，怎么測（結合功能，性能，安全性，易用性，外觀）

1. 功能測試

1.1 基本功能

容量測試：
用標準量杯注入精確體積的水（如 500ml），檢查水杯是否能正常容納且無溢出。
測試最大容量標記是否準確（誤差應小于 ±5%）。

密封性測試：
裝滿水后蓋上杯蓋，水平放置 1 小時，檢查是否漏水。
模擬顛簸（如放入背包走動 10 分鐘），觀察是否滲水。

1.2 特殊功能

保溫性測試：
注入 100℃熱水，蓋上杯蓋，2 小時后測量水溫（保溫杯應保持在 60℃以上）。
記錄水溫從 100℃降至 50℃的時間，評估保溫效率。

便攜功能：
測試掛繩、提手的承重能力（懸掛 1kg 重物 30 分鐘無斷裂）。
檢查杯套、防滑設計是否有效。

2. 性能測試

2.1 耐用性

抗摔測試：
從 1 米高度自由落體到水泥地面，重復 5 次，檢查是否破裂或變形。
塑料杯需測試耐老化性能（如紫外線照射 100 小時后是否變脆）。

抗壓測試：
對杯身施加逐漸增加的壓力，記錄破裂時的壓力值（普通水杯應承受 50N 以上）。

2.2 材料穩定性

冷熱循環測試：
交替注入 100℃熱水和 0℃冰水，重復 10 次，檢查是否開裂或漏水。

化學穩定性：
用醋、果汁等酸性液體浸泡 24 小時，檢測是否有有害物質析出（如重金屬）。

3. 安全性測試

3.1 材料安全

食品接觸安全性：
檢查是否通過 FDA、LFGB 等認證，確認材料符合食品級標準。
測試塑料杯是否含 BPA（雙酚 A）等有害物質。

耐高溫性：
對塑料杯進行高溫測試（如 95℃熱水浸泡 30 分鐘），檢查是否釋放異味或變形。

3.2 使用安全

防燙設計：
注入 80℃熱水，觸摸杯身外部，溫度應低于 40℃（避免燙傷）。

防漏設計：
測試杯蓋鎖止功能是否可靠（誤觸打開的概率應小于 1%）。

4. 易用性測試

4.1 操作便捷性

開合測試：
測試杯蓋開啟和關閉的力度（建議在 5-15N 之間，避免過緊或過松）。
單手操作測試：評估單手打開 / 關閉杯蓋的難易程度。

飲水體驗：
測試吸嘴、直飲口的出水速度（每秒 10-20ml 為宜）。
檢查是否有嗆水、漏水問題。

4.2 清潔難度

內部結構評估：
檢查杯口直徑是否足夠大（≥6cm），便于清潔工具進入。
測試帶濾網、茶隔的水杯，評估拆卸和清洗的便利性。

5. 外觀測試

5.1 美學設計

視覺評價：
檢查表面是否平整、無劃痕、色澤均勻。
評估圖案、logo 的印刷質量（耐磨測試：用酒精棉擦拭 50 次不褪色）。

人體工學：
測量杯身直徑和握感（建議直徑在 6-8cm，符合大多數人手掌尺寸）。
測試防滑紋理的有效性（濕手狀態下滑落概率應小于 5%）。

5.2 環保性

材料可持續性：
檢查是否使用可回收材料（如 PC、PP5 等）。
評估包裝是否簡約、可降解。

測試流程

需求分析，測試計劃測試方案，設計用例及測試前的準備（環境搭建，數據初始化，腳本編寫等），執行測試，缺陷管理，回歸測試達到要求，測試報告

?對于postman和JMeter工具，a接口需要b接口傳入數據怎么辦

?思路：提取B接口的數據設為變量，再在A接口的請求中引用變量，最后保證B接口在A接口前執行。

postman

在 B 接口的響應中提取需要的數據（如 token、ID 等），并保存到環境變量或全局變量中,在
A 接口的請求參數、Headers 或 Body 中使用保存的變量，
在 Collection Runner 中設置執行順序，確保 B 接口先于 A 接口執行：

JMeter

在 B 接口的 HTTP 請求后添加后端處理器中?JSON 提取器，用于提取需要的數據，并設置為變量
在 A 接口的請求參數、Headers 或 Body 中使用提取的變量。
在線程組中確保 B 接口的 HTTP 請求位于 A 接口之前，JMeter 會按順序執行。

常用的測試方法

等價類

邊界值

判定表：分析輸入條件的各種組合及其對應的輸出結果。

場景法：基于用戶實際使用場景設計測試用例，通常包含基本流和備選流。

因果圖：分析輸入條件（原因）與輸出結果（效果）之間的邏輯關系。

錯誤推斷法：基于經驗預測可能的錯誤并設計測試用例。

測試用例怎么寫才能不遺漏測試點？

系統化分析需求：從需求文檔中提取所有功能點、業務規則和隱含要求。

將需求分解為最小可測試單元（如"登錄頁面"拆分為輸入字段，驗證規則，交互邏輯）
挖掘隱含需求：性能（響應時間）、兼容性（瀏覽器 / 設備適配）、安全性（密碼加密），界面布局合理性、操作流暢性。

結構化設計用例：通過系統化方法覆蓋不同維度的測試點，避免憑經驗遺漏。同時保證用例步驟清晰，可復現

功能測試：基于黑盒測試對需求的正向 / 反向驗證

流程測試：使用場景分析法和狀態遷移法覆蓋業務邏輯路徑

非功能測試：按需求點進行測試

團隊協作評審

團隊評審：組織開發、產品、測試人員共同評審用例，從不同視角發現遺漏
動態補充：在測試執行中，記錄未覆蓋的場景（如偶然發現的異常流程），及時補充用例。
歷史用例復用：參考類似項目的測試用例庫，補充通用場景（如登錄功能的驗證碼測試、忘記密碼流程）。

?sql完整的增刪改查命令

#查詢
SELECT 列1, 列2 FROM 表名 
WHERE 條件 
ORDER BY 排序列 
LIMIT 行數;#插入
INSERT INTO 表名 (列1, 列2) 
VALUES (值1, 值2), (值3, 值4);  -- 支持批量插入#更新
UPDATE 表名 
SET 列1=新值1, 列2=新值2 
WHERE 條件;  -- WHERE是安全關鍵！#刪除
DELETE FROM 表名 
WHERE 條件;  -- 無WHERE將清空全表，單保留表結構

如果誤執行了`DELETE FROM orders`怎么辦？

立即停止數據庫操作
聯系DBA（數據管理員）嘗試從binlog恢復
后續流程中增加SQL執行審核機制

如果開發人員不認可你提出的缺陷，你會如何處理

1）缺陷復現

再次嚴格按照測試用例復現問題，確保缺陷是穩定出現的（非偶發）。記錄詳細的復現步驟、環境信息（如瀏覽器版本、操作系統、數據配置）、截圖 / 日志等證據。同時檢查是否因測試環境不穩定、數據緩存或權限問題導致誤判。

2）明確缺陷影響

從用戶體驗、功能完整性、合規性等角度說明問題的嚴重性。

3）與開發人員進行技術溝通

簡單問題的話即可溝通；復雜問題可進行會議討論。

4）僵持不下

若爭議源于需求模糊或變更，可邀請產品經理確認。

引用同類問題的處理方式或行業規范。

使用數據或用戶反饋佐證

Bug 嚴重等級劃分標準

1. 致命級（Critical）

定義：導致系統無法正常運行、數據丟失或存在重大安全風險的 Bug。
典型場景：
程序崩潰、無法啟動或頻繁無響應。
核心功能完全不可用（如支付功能異常導致交易失敗）。
敏感數據泄露（如用戶密碼明文存儲、數據庫連接信息暴露）。
多用戶并發操作時數據嚴重不一致或系統癱瘓。

處理優先級：立即修復，需優先安排開發資源處理，避免影響線上用戶或造成重大損失。

2. 嚴重級（High）

定義：影響主要功能使用或導致用戶體驗顯著下降，但系統仍可部分運行的 Bug。
典型場景：
主要功能存在錯誤（如搜索結果不準確、訂單狀態顯示異常）。
流程阻斷（如注冊流程中必填項驗證失敗但無提示）。
性能問題顯著（如頁面加載時間超過 5 秒、內存占用持續飆升）。
兼容性問題導致核心功能不可用（如某瀏覽器無法提交表單）。

處理優先級：高優先級，需在版本迭代周期內盡快修復，避免影響多數用戶的核心操作。

3. 中級（Medium）

定義：影響次要功能或用戶體驗，但不影響系統核心流程的 Bug。
典型場景：
界面顯示異常（如圖片加載失敗、按鈕樣式錯位）。
交互邏輯不友好（如提示信息不明確、操作步驟冗余）。
非核心功能錯誤（如幫助文檔鏈接失效、統計圖表數據偏差較小）。
兼容性問題影響非核心功能（如某機型鬧鐘提醒聲音異常）。

處理優先級：中優先級，可在后續版本中規劃修復，或根據資源情況調整處理時間。

4. 輕微級（Low）

定義：對功能和體驗影響極小，屬于細節優化范疇的 Bug。
典型場景：
文案錯別字、標點符號錯誤。
界面元素間距不一致、按鈕顏色偏差。
非關鍵頁面的加載動畫卡頓。
低頻率出現的邊緣情況問題（如極端格式輸入導致的顯示異常）。

處理優先級：低優先級，可集中在迭代末期或專門的優化版本中處理，或根據產品策略決定是否修復。

除了影響程度，劃分 Bug 等級時還需考慮以下因素：

用戶影響范圍：影響大量用戶或高頻操作的 Bug 等級更高。
重現概率：穩定重現的 Bug 比偶發問題更易定位和修復，等級可能更高。
行業規范與合規性：涉及安全合規（如 GDPR、金融監管）的 Bug 需提升等級。
業務場景：業務高峰期出現的 Bug 或影響關鍵業務流程的問題優先級更高。

測試人員發現 Bug 后要怎么處理

記錄與描述：詳細填寫 Bug 標題、重現步驟、預期 / 實際結果、截圖 / 日志等信息。
初步定級：根據標準初判等級，提交給開發團隊評審。
開發評審：開發人員復現并評估 Bug，確認等級或調整（如偶發的致命 Bug 可能降級為嚴重）。
修復與驗證：按優先級修復后，測試人員重新驗證，關閉或重新激活 Bug（若未解決）。
總結復盤：定期分析高頻或高等級 Bug，優化測試用例和開發流程，減少同類問題。

接口測試用例的設計思路一般是從哪些方面去考慮的？

1.功能測試是從業務流程和單功能方面進行測試的

業務流程用最少的用例覆蓋最多的業務場景，只進行正向測試即可。
單功能對數值和參數進行正反測試。

2.性能測試主要測響應時間，吞吐量，并發數，資源使用率

3.安全測試主要測試敏感數據是否加密

什么是冒煙測試？其目的和意義是什么？

冒煙測試的定義

在版本發布或進入正式測試階段前，對軟件的核心功能和關鍵流程進行快速、輕量級的驗證，確保軟件的基本功能正常運行，沒有 “致命性錯誤”，從而避免后續測試在不可用的版本上浪費時間。

目的

驗證版本基本可用性
快速定位致命缺陷
減少無效測試投入

意義

對測試來說，可以過濾掉無效版本，明確測試的準入條件。

談談你對敏捷測試的理解與實踐？

敏捷測試強調快速響應變化、持續交付價值、團隊協作和以用戶為中心。他要求測試應在需求分析階段就開始，同時測試和開發并行迭代，優先使用自動化。

介紹一下po模型

PO 模型（Page Object Model，頁面對象模型）?是一種自動化測試設計模式，用于分離測試邏輯與頁面元素操作，通過將頁面抽象為對象，降低測試代碼的耦合度，提高可維護性和復用性。PO模型將頁面分為三層，分別為對象層，操作層和業務層。它是 UI 自動化測試（如 Selenium、Appium）中最主流的設計模式之一。

什么項目適合做自動化測試?

1）需求穩定、迭代周期長的項目：自動化腳本可長期復用，維護成本低。

2）高頻次重復測試的項目：自動化腳本可快速執行數百 / 數千條用例，效率遠超手動測試。

3）技術復雜度高或風險高的模塊：通過自動化腳本精準驗證邏輯正確性（如計算精度、接口響應時間）。提前暴露代碼缺陷，降低生產環境故障風險。

4）跨平臺 / 多環境兼容測試：自動化工具（如 Selenium、Appium）可批量執行跨平臺測試，覆蓋手動難以觸及的組合（如 “Chrome + Windows 10 + 屏幕分辨率 1920x1080”）。

5）性能 / 負載測試需求明確的項目：借助工具（如 JMeter、LoadRunner）模擬真實負載，自動化生成性能報告（如響應時間、吞吐量、錯誤率）。