最近面試，遇到了不少題目，為今后的再面試做准備，特收集記錄於此
一、關於管理方面的
1、如何構建比較完整的測試體系框架，可以從哪些方面入手？
思路：（測試技術體系建設 測試管理支撐）
主要從團隊組織、環境建設、標准制定、人員培養、配置管理、工作流程
a、軟件測試管理體系建設可以從測試的總體規程、需求跟蹤管理、軟件缺陷跟蹤管理、軟件缺陷分析管理、軟件質量度量管理、軟件測試人員的職業體系規划、軟件測試人員的績效考核體系、軟件測試相關的配置管理體系
b、軟件測試技術體系建設可以從輸出技術技能圖譜，針對技術人員的系統測試培訓，測試技能體系的建立、試點、推廣
2、針對版本上線后，出現線上問題或漏測情況，如何規避？
思路：
a、故障可能在需求、技術設計、開發、漏測、上線不規范等過程產生，因而，故障的控制必須從各個階段分別入手
b、根據業務成熟度、團隊成員特點有針對性應對（業務需求分析、變更管理引起.人員是否充足、是否進行冒煙測試、風險控制.）
c、針對已有的故障，在復盤時找到最根本的原因
參考
3、作為管理者，怎樣招一個合格的測試人員？
思路；
分析能力、專業技能、溝通表達、適應和學習能力、記憶力、自信心、耐心、懷疑精神、洞察力、有條理和注意細節
4、如何管理團隊？
思路：可以從怎樣管理人和事方面說明，當時面試的時候，面試官就說我的經驗都是偏於管事多，管人方面需要加強
1）關於事
資源共享、同一個目標、
2）關於人
多溝通、盡早發現和解決問題，充分了解組員正在做什么和怎樣做
放權及授權、同等對待
5、怎樣留住人員？
思路：
a、制定明確的激勵計划和透明的未來目標，用人制度
b、適合的薪資制度
c、多多和團隊內成員進行溝通，建立一個融洽的團隊環境
d、加強項目管理，強化文檔管理，培訓機制
f、建立分享機制，使員工之間建立學習的氛圍
6、測試質量體系規划和建設
思路：（軟件規模、進度、工作量、缺陷指標、質量指標分析）
1）明確測試輸入輸出准則
2）測試策略、用例質量、執行質量、缺陷質量、過程質量監控（風險評估、缺陷預防）
二、關於技術方面的
1、數據庫方面
1）如何使用sql生成1000萬條數據？
思路：
a、生產環境拉取然后備份到測試環境（但也有問題，實際環境的數據由於各種原因不一定全部滿足測試數據）
b、寫代碼生成數據？ 涉及如何寫的問題
數據庫中新建函數---存儲過程，輸入批量增加數據的代碼塊
2）如何挑選出重復的數據（比如姓名字段會出現重名的情況）
思路：以姓名分組，然后使用函數統計出現重復的次數count
3）給多個表，然后寫出關聯的SQL語句
2、性能測試方面
1）性能測試怎么做的？ 如何保證並發數？ 為什么會用分布式，在做分布式時如何分配每台電腦的用戶數？ 服務器性能怎么做？
性能測試流程核心：搭建性能環境、設計用例、場景建模、准備測試數據、測試腳本開發（數據隔離，防止數據污染）、執行、問題分析與調優、維護
怎么做：
如果是測試響應時間，對一個接口進行壓力測試，不斷加壓，直到響應時間達到或超過指標，觀察當前其並發數和TPS，同樣的並發數，多執行幾次，得到一個平均值或穩定值（即TPS和TRT曲線相對穩定的值），並記錄下來
如果是測試接口的最大並發數，逐漸增加線程數，看聚合報告里吞吐量Throughput，每秒完成的請求數隨着發送的Samples（發出請求數量）實時在變，當吞吐量不再往上增加時，這個時候的並發數即是最大並發數，增加線程數，tps不變，響應時間增加，報錯增加，說明達到極限了
如何保證並發數：同一時刻的並發是很難做到的。我們用來發起壓力的測試工具本身要能做到同一時刻發起壓力，如果設置線程數過多，負載機本身資源不足會有排隊，請求建立和服務端的連接過程會排隊，請求數據發送到服務的時候在網絡隊列上也會排隊，請求數據達到服務端，在服務端也會進行排隊，所以嚴格意義上的並發多少用戶數等等是比較難做到的。但是，我們可以分層去看，像一般的webserver或容器服務都有監控數據，如nginx的Active connections，tomcat的currentThreadsBusy，這些參數表明服務本身目前正在處理的最大並發線程數（監控Web層（例如Nginx）的連接數和請求數，查看實際達到服務器端的並發數是否跟我們的設定值一致）
為什么會用分布式：電腦連接數不夠，為了解決單個物理服務器容量和性能瓶頸問題而采用的優化手段（分布式是從物理資源的角度去將不同的機器組成一個整體對外服務）
分布式時如何分配每台電腦的用戶數： 負載機的線程數與腳本設計的線程數一致，每台的負載機線程數是一樣的，由調度機監控匯總測試結果
服務器性能怎么做： 關注吞吐量、響應時間 、事務成功率、資源使用率
N個人在客戶端同時進行功能性操作的同時，在確保功能實現正確的前提下，考察服務端應用程序的各項性能指標，以及服務器硬件資源的使用情況
2）假設系統A調用系統B，把B的接口都mock了，有啥好處和壞處？
思路：
好處：避免其它模塊的出錯引起的本模塊錯誤，起到隔離作用、並行工作，進程互不影響、提前接入測試，保證測試效率，模擬數據，增加覆蓋
壞處：大量使用mock測試的場景失去了真實性，可能會導致在后續的系統性測試時才發現bug，使得缺陷發現的較晚，可能會造成后續修復成本更大；
3）多個接口之間存在調用關系，在對接口壓測時，系統崩了，怎么判斷是哪個接口引起的問題
思路：
a、從最低層的接口先做性能測試，再看該接口調用上層的哪些業務接口
b、雖然存在多層調用，分析當前壓測的接口的業務是否涉及多個接口，如果不涉及就不用考慮是其它接口的問題，如果涉及就需要一層層的向上找，看到底是哪個接口引起的系統崩潰
4）如何設計性能的測試用例
確定性能目標；場景設計，場景設計一定從簡單到復雜。（容量、安全、可靠、壓力、響應時間、寬帶、資源利用率、恢復能力、可擴展性）
5）App性能關注點，哪些指標
3、代碼方面
1）統計1-9999中數字3出現的次數
思路：包含3的數字都統計一次，如333，則統計3次
2）數組逆序輸出
3）計算1-100的和
4、自動化方面
1）ajax異步時，如何進行元素的定位？
思路：當時不太理解前端的異步是什么，回答的時候說一般元素定位不到，需要加等待時間，然后說沒遇到這種情況，然后面試官也沒說什么....然后百度了下，似乎就是要設置等待時間
這里應該可以答 三大延時等待處理（硬性等待 Thread sleep,隱式等待 Timeouts 顯示等待 自定義）
2）如何實現用例失敗或異常時需要截圖
思路：
a、定義一個截圖的方法並保存File
b、定義一個用例失敗的監聽類 ，繼承testng框架的失敗監聽接口IHookable，該接口有一個方法run
c、在testng.xml配置監聽運行
3）如何進行分布式執行webdriver用例
思路：
a、Selenium grid使用，同時啟動一個hub和至少一個node來實現
b、借助於Testng配置文件進行，即在Case中以變量形式替換真實地址
5、測試方面
1）如何測試一個下訂單
思路：
一次下單的商品數量、訂單的類型、同樣的商品是否可重復下單、 是否可下多個訂單
2）如何測試灰度配置
3）app和web測試的區別與關注點
流程和技術測試方面是一致的
app更關注流量、耗電、瀏覽器、手機品牌、安卓軟件版本、分辨率的兼容，弱網，網絡切換，交叉中斷測試、下載安裝升級測試
4）https協議
5）怎樣進行接口測試
思路：充分理解接口邏輯業務，配合接口參數組合，上下游服務的容錯處理，如依賴的接口異常，本接口是否有很好的容錯
6）微信掃碼登錄設計測試用例
6、其它方面
1）自己的優缺點