1、自我介紹
面試官好，我叫。我有5年多的軟體測試經驗。在工作中，熟練掌握了各種測試方法和工具，包括黑盒測試、白盒測試、自動化測試、效能測試、安全測試等。有一定的程式設計能力，能夠根據需要編寫測試用例和指令碼。有良好的溝通能力和團隊協作能力，能夠與開發人員、產品經理等各部門人員有效合作。對軟體測試工作很有熱情，希望能夠在未來的測試工作中繼續學習和成長。
我在公司參主要負責交易商品和物流專案的測試工作。公司的產品主要是線上賣課程和直播電商業務。我的目標是確保該平臺的功能完整性、效能穩定性和安全性。
在專案實施過程中，我負責以下工作：
設計和執行測試用例，覆蓋了所有功能需求和效能需求。
與開發人員合作，跟蹤和解決缺陷。
linux常用命令，mysql複雜語句，python基礎列表與元組的區別。
2、MQ/redis的測試
MQ 測試主要關注以下幾個方面：
- 功能測試：驗證 MQ 的基本功能，例如訊息傳送、接收、佇列管理等。
- 效能測試：測試 MQ 的吞吐量、延遲、可靠性等效能指標。
- 相容性測試：測試 MQ 與不同應用、框架、作業系統等的相容性。
- 安全性測試：測試 MQ 的安全性，例如訊息防篡改、防竊聽等。
具體測試方法如下：
- 功能測試：可以使用自動化測試工具來模擬訊息傳送、接收等操作，並驗證結果是否符合預期。
- 效能測試：可以使用壓測工具來模擬大量訊息的傳送和接收，並測試 MQ 的效能指標。
- 相容性測試：可以使用不同的應用、框架、作業系統等來測試 MQ 的相容性。
- 安全性測試：可以使用安全測試工具來測試 MQ 的安全性。
Redis 測試
Redis 測試主要關注以下幾個方面：
- 功能測試：驗證 Redis 的基本功能，例如資料存取、快取、過期等。
- 效能測試：測試 Redis 的吞吐量、延遲、可靠性等效能指標。
- 相容性測試：測試 Redis 與不同應用、框架、作業系統等的相容性。
- 安全性測試：測試 Redis 的安全性，例如資料防篡改、防竊聽等。
具體測試方法如下：
- 功能測試：可以使用自動化測試工具來模擬資料存取、快取等操作，並驗證結果是否符合預期。
- 效能測試：可以使用壓測工具來模擬大量資料的存取，並測試 Redis 的效能指標。
- 相容性測試：可以使用不同的應用、框架、作業系統等來測試 Redis 的相容性。
- 安全性測試：可以使用安全測試工具來測試 Redis 的安全性。
以下是一些常用的 MQ 和 Redis 測試工具：
- MQ 測試工具： JMeter、Kafka Tool、RocketMQ Test Tool
- Redis 測試工具： Redis-benchmark、Jedis、Lettuce
以下是一些具體的測試建議：
- 在測試 MQ 時，可以關注以下幾點：
- 訊息傳送和接收是否成功
- 訊息是否按順序傳送和接收
- 訊息是否丟失或重複
- 佇列是否能正常管理
- 在測試 Redis 時，可以關注以下幾點：
- 資料存取是否成功
- 快取是否有效
- 資料是否過期
- Redis 是否能正常執行
生成器，迭代器，裝飾器。生成物件，迭代物件：
它允許程式設計師擴充套件或修改函式、方法或類的行為，而不需要改變它們的實際程式碼。裝飾器本質上是一個接受函式作為引數並返回一個新函式的函式。
常見用途
- 計時：測量函式執行的時間。
- 日誌記錄：在函式執行前後記錄日誌。
- 許可權檢查：在函式執行前檢查使用者許可權。
- 快取：快取函式的執行結果。
迭代器是一個可以記住遍歷的位置的物件。迭代器從集合的第一個元素開始訪問，直到所有的元素被訪問完結束。迭代器只能往前不會後退。
迭代器有兩個基本的方法：__iter__() 和 __next__()。
生成器是一種特殊的迭代器，它使用 yield語句來生產一系列的值，用於迭代。生成器在Python中非常流行，因為它們易於使用，並且可以建立高效的程式碼。
生成器函式被呼叫時，它返回一個生成器物件，但不會立即執行函式體內的程式碼。當生成器的 __next__() 方法被呼叫時，函式會執行，直到遇到 yield 語句，然後返回 yield 後面的值。每次呼叫 __next__()方法時，函式都會繼續執行，直到再次遇到 yield 語句或函式結束。
3、介面自動化測試框架搭建
介面自動化的框架開發：
-
用到的知識點:
-
pytest
-
allure
-
引數化
-
Excel操作，不會，用xlrd
-
日誌操作，學過，不太會
-
郵件，會
-
檔案操作，檔案壓縮， 沒講，但你要會的，zipfile
-
執行終端命令，os.system, subprocess:cell, popen
-
如何使用python檢視當前目錄下的所有檔案或者目錄？
-
-
-
實現的個功能：
-
將各個功能拆分為多個目錄
-
使用引數化讀取Excel中的用例
-
發請求
-
獲取請求結果
-
校驗/斷言
-
-
使用allure生成測試報告
-
將allure測試報告所在的目錄打包
-
將打包的zip檔案使用郵件傳送到1206180814@qq.com
-
在重點位置加日誌
-
實現思路：
-
讀取Excel，每一行資料都是一個用例，你在讀出來之後，把這個一行用例封裝成一個物件，字典，列表。
-
使用引數化每次講一個用例物件傳進去。
-
使用requests獲取用例物件中的相關引數發請求。
-
然後將請求結果與預期值（用例物件）做斷言
-
此時，allure所需的json資料已經有了。
-
使用allure命名讀取josn資料生成測試報告
-
將報告壓縮
-
使用發郵件功能將壓縮檔案傳送
-
在重點位置，新增日誌功能
4、自動化平臺的搭建
管理所有的介面：
-
介面的增刪改查
-
一鍵執行介面，並生成測試報告
-
批次執行
-
下載報告
-
-
批次匯入
-
從Excel表格中
-
-
定時任務
-
-
視覺化
-
echarts
-
實現：
-
django + pytest
參考專案列表圖，完成：
-
新建專案
-
編輯專案
-
刪除專案
-
為專案新增用例
資料庫設計：
-
專案表的欄位：
-
專案名稱
-
專案描述
-
用例資料量，該欄位是統計出來的
-
覆蓋率欄位，計算出來的（透過的用例數量除以專案總的用例數量）
-
開始時間
-
結束時間
-
-
用例表
-
用例名稱
-
用例描述
-
所屬專案
-
請求的url
-
請求的型別
-
請求的引數
-
期望值
-
執行狀態
-
已執行
-
未執行
-
-
透過狀態，用例執行後，修改此狀態
-
執行成功，已透過
-
執行失敗，未透過
-
-
用例報告
-
-
日誌表：
-
所屬專案
-
執行時間
-
執行的報告
-
作業完成順序：專案表的增刪改查 ---> 用例表的增刪改查 -----> 用例執行------> 批次執行的用例日誌 ---> 資料視覺化
-
頁面中，勾選了一個或者多個用例，CheckBox（核取方塊）
-
點選執行按鈕後，後端接收一個或者多個CheckBox的值（用例id）：
-
前端如何往後端傳送？
-
ajax傳送，迴圈CheckBox的外部盒子，獲取每一個CheckBox狀態為選中的input框，獲取input的value值（用例id），然後push到陣列中，再將該陣列傳送到後端。
-
form表單提交
-
-
後端如何接收form表單提交的值
-
request.POST.get_list
-
-
def index(request):
if request.method == "POST":
request.POST.get("username") # username對應的是單個值
request.POST.get_list('checkbox_list') # 以列表的形式接收多個值
-
後端接收到了前端傳過來的值：
[1, 2, 3, 4]-
根據獲取到的用例id列表，去資料庫中提取出對應記錄（用例物件）
-
如果是多個用例物件，迴圈使用requests提取用例物件中的欄位發請求。
-
結果斷言
-
生成測試報告
-
將測試報告儲存到用例的相應欄位中
-
修改用例的執行狀態和透過狀態
-
考慮如何獲取批次執行的測試結果報告
-
-
用例批次執行完畢，將批次執行結果儲存到log表中
-
用例執行的時間
-
用例報告
-
-
將執行結果給前端返回。
5、效能測試
設計：
在設計評審之後，開發在不知道服務效能瓶頸，需要測試協助定位服務的效能瓶頸，需要測試模擬一定時間之內設計併發使用者同時向系統發出請求，檢測出系統的響應能力，包括響應時間以及CPU/記憶體等的使用情況，以驗證系統對併發請求時的支援能力，並獲取該系統的最大併發請求數量。
目的：
1）清楚服務的效能瓶頸，為設定介面的限流提供參考依據
2）判斷資源是否溢位，可節省機器成本
3）檢測系統可能存在的問題（程式碼、db、cache、系統配置、容量）
報告：
（1）cup使用率：26.3%<80% 暫未發現明顯效能瓶頸問題
（2）記憶體使用率：69.1%，暫未發現明顯效能瓶頸問題
（3）平均響應時間為0.599s<1S,暫未發現明顯效能問題
（4）事務失敗率為0.01%，資料庫請求資料為46869，請求失敗數為6；日誌記錄如下，error_log中記錄為空，服務端暫未發現明顯報錯，但是在高併發時存在客戶端請求連線失敗的情況