本文為霍格沃茲測試學院學員學習筆記。
本系列文章總結歸納了一些軟體測試工程師常見的面試題，主要來源於個人面試遇到的、網路蒐集（完善）、工作日常討論等，分為以下十個部分，供大家參考。如有錯誤的地方，歡迎指正。有更多的面試題或面試中遇到的坑，也歡迎補充分享。希望大家都能找到滿意的工作，共勉之！~
- 測試常見問題與流程篇
- 測試工具篇
- 計算機網路知識與資料庫篇
- Linux 與 Python 程式設計技能篇
- 自動化測試與效能測試篇
- 軟素質篇（10 大靈魂拷問）與反問面試官篇
包含 Selenium、Appium 和介面測試。
- 單例模式
- 工廠模式
- PO模式
- 資料驅動模式
- 檢查一個條件，如果它為真，就不做任何事，用例通過。如果它為假，則會丟擲 AssertError 並且包含錯誤資訊。
- Selenium Grid，分散式執行用例
- Appium 使用 STF 管理多裝置
- Docker+K8S 管理叢集
- 萬能驗證碼
- 測試環境遮蔽驗證
- 其他操作不推薦
- 儘量使用 by_css_selector() 方法
- by_css_selector() 方法的執行速度比 by_id() 方法的更快，因為原始碼中 by_id() 方法會被自動轉成 by_css_selector() 方法處理；
- 使用等待時，儘量使用顯示等待，少用 sleep()，儘量不用隱式等待；
- 儘量減少不必要的操作：可以直接訪問頁面的，不要通過點選操作訪問；
- 併發執行測試用例：同時執行多條測試用例，降低用例間的耦合；
- 有些頁面載入時間長，可以中斷載入；
- 可以發現很多在頁面上操作發現不了的 bug；
- 檢查系統的異常處理能力；
- 檢查系統的安全性、穩定性；
- 前端隨便變，介面測好了，後端不用變；
- 可以測試併發情況，一個賬號，同時（大於 2 個請求）對最後一個商品下單，或不同賬號，對最後一個商品下單；
- 可以修改請求引數，突破前端頁面輸入限制（如金額）；
- 如果單純的定位的話，隱藏元素和普通不隱藏元素定位沒啥區別，用正常定位方法就行了（這個很多面試官也搞不清楚）；
- 元素的屬性隱藏和顯示，主要是 type=“hidden” 和 style=“display: none;” 屬性來控制的，接下來在元素屬性裡面讓它隱藏，隱藏元素可以正常定位到，只是不能操作（定位元素和操作元素是兩碼事，很多初學者傻傻分不清楚），操作元素是 click,clear,send_keys 這些方法；
- JS 操作隱藏元素；
- 方法一：用 try…except…
- 方法二：用 elements 定義一組元素方法，判斷元素是否存在,存在返回 True,不存返回 False
- 方法三：結合 WebDriverWait 和 expected_conditions 判斷（推薦）
- 不要右鍵複製 xpath(十萬八千里那種路徑，肯定不穩定)，自己寫相對路徑，多用 id 為節點查詢；
- 定位沒問題，第二個影響因素那就是等待了，sleep 等待儘量少用（影響執行時間）；
- 定位元素方法重新封裝，結合 WebDriverWait 和 expected_conditions 判斷元素方法，自己封裝一套定位元素方法；
- 動態元素有 2 種情況，一個是屬性動態，比如 id 是動態的，定位時候，那就不要用 id 定位就是了；
- 還有一種情況動態的，那就是這個元素一會在頁面上方，一會在下方，飄忽不定的動態元素，定位方法也是一樣，按 f12，根據元素屬性定位（元素的 tag、name的步伐屬性是不會變的，動的只是 class 屬性和 styles 屬性）；
- 使用element.parent方法
- 可以把平常遇到的元素定位的一些坑說下，然後說下為什麼沒定位到，比如動態 id、有 iframe、沒加等待等因素；
- 使用 JS 點選，Selenium 有時候點選元素是會失效；
- 對於賬號密碼，這種管全域性的引數，可以用命令列引數，單獨抽出來，寫的配置檔案裡（如 ini）；
- 對於一些一次性消耗的資料，比如註冊，每次註冊不一樣的數，可以用隨機函式生成；
- 對於一個介面有多組測試的引數，可以引數化，資料放 YAML,Text,JSON,Excel 都可以；
- 對於可以反覆使用的資料，比如訂單的各種狀態需要造資料的情況，可以放到資料庫，每次資料初始化，用完後再清理；
- 對於郵箱配置的一些引數，可以用 ini 配置檔案；
- 對於全部是獨立的介面專案，可以用資料驅動方式，用 excel/csv 管理測試的介面資料；
- 對於少量的靜態資料，比如一個介面的測試資料，也就 2-3 組，可以寫到 py指令碼的開頭，十年八年都不會變更的；
- 引數化的思想是程式碼用例寫好了後，不需要改程式碼，只需維護測試資料就可以了，並且根據不同的測試資料生成多個用例；
- 使用單例模式
- 使用自定義快取機制
- 使用測試框架中的 setup 機制
- pytest 中 fixture 機制
- 造資料和資料清理，需用 python 連資料庫了，做增刪改查的操作測試用例前置操作，setUp 做資料準備後置操作，tearDown 做資料清理
- 考慮不同的業務場景，一個介面走過的流程是什麼樣的，流程的邏輯是什麼樣的，什麼樣的引數會有什麼樣的結果，多場景覆蓋；
- 最大併發使用者數，HPS（點選率）、事務響應時間、每秒事務數、每秒點選量、吞吐量、CPU 使用率、實體記憶體使用、網路流量使用等。
- 前端需主要關注的點是：
- 響應時間：使用者從客戶端發出請求，並得到響應，以及展示出來的整個過程的時間。
- 載入速度：通俗的理解為頁面內容顯示的快慢。
流量：所消耗的網路流量。
- 後端需主要關注的是：
- 響應時間：介面從請求到響應、返回的時間。
- 併發使用者數：同一時間點請求伺服器的使用者數，支援的最大併發數。
- 記憶體佔用：也就是記憶體開銷。
- 吞吐量（TPS）：Transaction Per Second, 每秒事務數。在沒有遇到效能瓶頸時：TPS=併發使用者數*事務數/響應時間。
- 錯誤率：失敗的事務數/事務總數。
- 資源使用率：CPU佔用率、記憶體使用率、磁碟I/O、網路I/O。
- 從效能測試分析度量的度角來看，主要可以從如下幾個大的維度來收集考察效能指標：
- 系統效能指標、資源效能指標、穩定性指標
- 先輸出業務資料，如 pv、pu、時間段等，計算出大概的值，然後不斷加壓測到峰值
- 請求名、執行緒數、響應時間（50 95 99 最小 最大）錯誤率、吞吐量
- 後臺：介面返回資料慢，查詢效能等各種問題
- 前端：使用 Chrome 工具除錯，判斷 JS 執行久或是其他問題
- 網路問題
- 根據自己專案中的經驗實話實說，有沒有經驗很容易露餡。
- 結合自己的專案經驗聊。大家也可以自行搜尋。
- 詳細的不展開了，最重要的是相對來說 LoadRunner 的笨重、昂貴、閉源，理念和生態都落後，而 JMeter 是開源、可定製化開發，功能強大易用，並且在網際網路大廠都已經有非常成熟的落地方案（主流的網際網路公司基本都在使用 JMeter+ELK+Grafana+Influxdb 這套架構），可以說是進 BAT 大廠必備技能。還不會 JMeter 的同學建議抓緊補起來。