參考回答：
P的格式：(1~ 255).(0~ 255).(0~ 255).(0~255)
方法一：基於對字串的處理
public static void main(String[] args){Scanner scanner = new Scanner(System.in);String ipStr = scanner.next();boolean isIpLegal = isIpLegal(ipStr);if(isIpLegal) {System.out.println(ipStr + " 合法");}else{System.out.println(ipStr + " 非法");}}public static boolean isIpLegal(String str){//檢查ip是否為空if(str == null){return false;}//檢查ip長度，最短為：x.x.x.x(7位)，最長為：xxx.xxx.xxx.xxx(15位)if(str.length() < 7 || str.length() > 15){return false;}//對輸入字串的首末字元判斷，如果是"."則是非法IPif(str.charAt(0) == '.' || str.charAt(str.length()-1) == '.'){return false;}//按"."分割字串，並判斷分割出來的個數，如果不是4個，則是非法IPString[] arr = str.split("\\.");if(arr.length != 4){return false;}//對分割出來的每個字串進行單獨判斷for(int i = 0; i < arr.length; i++){//如果每個字串不是一位字元，且以'0'開頭，則是非法的IP，如：01.002.03.004if(arr[i].length() > 1 && arr[i].charAt(0) == '0'){return false;}//對每個字串的每個字元進行逐一判斷，如果不是數字0-9，則是非法的IPfor(int j = 0; j < arr[i].length(); j++){if (arr[i].charAt(j) < '0' || arr[i].charAt(j) > '9'){return false;}}}//對拆分的每一個字串進行轉換成數字，並判斷是否在0~255for(int i = 0; i < arr.length; i++){int temp = Integer.parseInt(arr[i]);if(i == 0){if (temp < 1 || temp > 255){return false;}}else{if(temp < 0 || temp > 255){return false;}}}return true;}```方法二：正則表示式
public static void main(String[] args) {Scanner scanner = new Scanner(System.in);String ipStr = scanner.next();boolean isIpLegal = isIpLegal(ipStr);if(isIpLegal) {System.out.println(ipStr + " 合法");}else{System.out.println(ipStr + " 非法");}}public static boolean isIpLegal(String ipStr) {String ipRegEx = "^([1-9]|([1-9][0-9])|(1[0-9][0-9])|(2[0-4][0-9])|(25[0-5]))(\\.([0-9]|([1-9][0-9])|(1[0-9][0-9])|(2[0-4][0-9])|(25[0-5]))){3}$";Pattern pattern = Pattern.compile(ipRegEx);Matcher matcher = pattern.matcher(ipStr);if (matcher.matches()) {return true;} else {return false;}}```等價類劃分：
2.請進行測試用例設計：一串數字，閏年的判別參考回答：
判斷閏年的標準是:能整除4且不能整除100，能整除400。
設定合法的年份為1-9999
public class Test2 {public static void main(String[] args) {Scanner in = new Scanner (System.in);int year=in.nextInt();if(year<=0||year>9999){System.out.println("請輸入正確的年份");}if((year%4==0&&year%100!=0)||year%400==0){System.out.println("閏年");}else{System.out.println("不是閏年");}}}```測試用例：
3.請你說一說簡單使用者介面登陸過程都需要做哪些分析參考回答：
1. 功能測試
1.1.輸入正確的使用者名稱和密碼，點選提交按鈕，驗證是否能正確登入。1.2.輸入錯誤的使用者名稱或者密碼,驗證登入會失敗，並且提示相應的錯誤資訊。1.3.登入成功後能否能否跳轉到正確的頁面1.4.使用者名稱和密碼，如果太短或者太長，應該怎麼處理1.5.使用者名稱和密碼，中有特殊字元（比如空格），和其他非英文的情況1.6.記住使用者名稱的功能1.7.登陸失敗後，不能記錄密碼的功能1.8.使用者名稱和密碼前後有空格的處理1.9.密碼是否非明文顯示顯示，使用星號圓點等符號代替。1.10.牽扯到驗證碼的，還要考慮文字是否扭曲過度導致辨認難度大，考慮顏色（色盲使 用者），重新整理或換一個按鈕是否好用1.11.登入頁面中的註冊、忘記密碼，登出用另一帳號登陸等連結是否正確1.12.輸入密碼的時候，大寫鍵盤開啟的時候要有提示資訊。1.13.什麼都不輸入，點選提交按鈕，檢查提示資訊。2. 介面測試
3. 效能測試
3.1.開啟登入頁面，需要的時間是否在需求要求的時間內。3.2.輸入正確的使用者名稱和密碼後，檢查登入成功跳轉到新頁面的時間是否在需求要求的時間內。3.3.模擬大量使用者同時登陸，檢查一定壓力下能否正常登陸跳轉。4. 安全性測試
4.1.登入成功後生成的Cookie，是否是httponly (否則容易被指令碼盜取)。4.2.使用者名稱和密碼是否透過加密的方式，傳送給Web伺服器。4.3.使用者名稱和密碼的驗證，應該是用伺服器端驗證， 而不能單單是在客戶端用javascript 驗證。4.4.使用者名稱和密碼的輸入框，應該遮蔽SQL注入攻擊。4.5.使用者名稱和密碼的的輸入框，應該禁止輸入指令碼 （防止XSS攻擊）。4.6.防止暴力破解，檢測是否有錯誤登陸的次數限制。4.7.是否支援多使用者在同一機器上登入。4.8.同一使用者能否在多臺機器上登入。5. 可用性測試
5.1.是否可以全用鍵盤操作，是否有快捷鍵。5.2.輸入使用者名稱，密碼後按回車，是否可以登陸。5.3.輸入框能否可以以Tab鍵切換。6. 相容性測試
6.1.不同瀏覽器下能否顯示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）。6.2.同種瀏覽器不同版本下能否顯示正常且功能正常。6.3.不同的平臺是否能正常工作，比如Windows, Mac。6.4.移動裝置上是否正常工作，比如Iphone, Andriod。6.5.不同的解析度下顯示是否正常。7. 本地化測試
7.1不同語言環境下，頁面的顯示是否正確。4.請對這個系統做出測試用例：一個系統，多個攝像頭，抓拍車牌，識別車牌，上傳網上，網上展示參考回答：
需要測試的功能：
1. 每個攝像頭都能抓拍車牌；
2. 每個攝像頭抓拍到的車牌能正常交給系統處理；
3. 系統能夠正確識別車牌；
4. 系統能夠將識別出的車牌上傳；
5. 上傳至網路的車牌能夠正常展示出來；
一.功能測試
1.1使用正常的車牌，保持車牌靜止，檢查每個攝像頭是否能抓拍車牌；1.2使用類似非車牌的寫有字的紙板，檢查每個攝像頭是否抓拍；1.3使用正常的車牌，保持車牌較高速移動，檢查每個攝像頭是否能抓拍車牌；1.4在多種情況下檢查每個攝像頭抓拍到的車牌能否正常交給系統處理，如臨時斷電、斷網後1.5能否正常將資料交給系統；1.6使用抓拍到的正常的車牌，交由系統處理，檢查系統能否識別車牌；1.7使用非車牌的其他圖片，交由系統處理，檢查系統能否識別；1.8在多種情況下檢查系統能否將正常識別出的車牌進行上傳，如臨時斷電、斷網後未上傳數1.9據是否能繼續上傳；1.10構造非車牌的其他內容的資料，檢查系統能否將異常內容進行上傳；1.11檢查上傳至網路的車牌能否正常展示出來；1.12上傳非車牌的其他內容的資料，檢查能否正常顯示出來。二.效能測試
2.1同時向一個攝像頭展示多個靜止的車牌，檢查攝像頭能否抓拍到多個車牌；2.2同時向一個攝像頭展示多個較高速運動的車牌，檢查攝像頭能否抓拍到多個車牌；2.3抓拍後，檢查系統識別車牌的時間是否在需求要求的時間內；2.4模擬大量抓拍照片同時交由系統處理，檢查一定壓力下系統能否正常識別車牌；2.5模擬大量車牌同時上傳，檢查一定壓力下能否上傳成功。三.安全性測試
3.1檢查是否能夠透過給車牌加裝飾物等方法，使攝像頭無法抓拍或抓拍後系統無法正常識別車牌。5.請你對吃雞遊戲進行壓力測試參考回答：
首先明確需要測試壓力的內容:
1. 遊戲伺服器硬體
a.硬碟I/o
b.記憶體
c.CPU
2. 網路壓力
a.長連線
a1.最大連線數
a2.流量(內網、外網、進、出)
b.長連線短週期(類似Http的TCP應用，這個比較特殊的一個需求，專門針對LoginAgent)
b1.每秒建立的連線數
b2.實際處理能力
3. 資料庫
a.每秒事務數
b.每秒鎖等待數
c.平均延時(ms)
d.CPU暫用
4. 多執行緒的最優執行緒數
a.資料庫執行的多執行緒
b.多連線處理
Windows Server環境測試方式
1. 伺服器效能監測
使用Server自帶的效能監測器設定各個程序的監測引數。Window的這個自動工具做的相當強大。大家自己摸一摸基本就會用了。每個引數都有詳細的說明。
2. 案例設計注意
a.對於資料庫的效能測試上，現在由於所有的遊戲伺服器構架在DB前面都有一個實現DB緩衝功能的程序，以減少資料庫頻繁的讀寫操作。所以其實資料庫的都是一個輕量級的數量；而資料庫的寫操作是一個週期性能過程。案例設計一定要能夠驅動這種週期性能過程。比如我們遊戲的戰鬥，導致遊戲玩家資料的改變，或驅動所有線上玩家資料的週期性儲存。
b.選擇具有代表性，並且最頻繁的遊戲操作。用於進行最高使用者線上的各種效能指標採集。如，開槍、道具拾取、道具使用、移動、聊天
c.聊天效能測試
廣播聊天是最為考驗遊戲資訊傳送能力的功能。透過進行全域性廣播的壓力測試。我們可以獲取伺服器程序傳送資訊到客戶端的最高承載量。進而可以對我們的各種廣播功能進行一個預估和頻率限制。
d.同屏玩家的移動測試
移動+廣播。這兩種資訊，基本是網路遊戲流量的70-80%左右。同屏玩家數量，將會增加各種資料的廣播需求，非常影響遊戲效能。所以同屏的移動測試也是廣播測試的一個必要環節。需要根據實際結果進行適當的最佳化。
e.大量玩家同時登入測試
玩家登入時，有大量的資訊需要進行分配和初始化；同時也有大量的資料需要下傳客戶端。伺服器需要進行大量的TCP連線建立。所以是一個比較關鍵的過程。這個測試案例是一個比較特殊，但是運營是肯定會碰到的案例。
f.由於執行緒池處理事務，隨著事務的時耗，存在一個最優執行緒數的問題。過多的執行緒反而會降低伺服器效率
3. 細節問題
a.進行測試需要仔細思考客戶端效能影響伺服器最後表現的可能性。比如
a1.模擬客戶端的效能無法有效處理伺服器返回資訊,可能就導致伺服器傳送的資訊快取在伺服器系統快取，從而表現出伺服器記憶體不斷增加。表現為伺服器傳送能力不足，其實可能根本就是客戶端的效能問題
a2.客戶端效能問題，導致發起的請求數過少，從而導致單位時間內伺服器處理的請求過少。表現為伺服器效能不足，其實根本就是客戶端的請求能力不足。
b.網路頻寬導致最後表現不足
b1.確認伺服器的各個網絡卡，以及相互的頻寬。不然可能因為相互頻寬，導致伺服器對於客戶端請求的處理延時。表現為伺服器卡機
b2.客戶端模擬多個玩家，比如1000個玩家。而客戶端的網絡卡或者客戶端與伺服器之間的中轉伺服器頻寬過小，導致伺服器資料傳送不出，記憶體不斷增加。表現為伺服器傳送能力不足，其實是中間頻寬問題。
c.debug i/o導致伺服器效能下降
c1.進行效能測試，一定要取消debug用的同步的i/o.比如我們伺服器的debuginternalLog.同步i/o是非常影響效能的，特別在壓力測試下可能導致每秒上千上萬甚至幾十萬次的執行。一處的檔案寫入操作就可以導致幾十萬次的處理能力變成幾千次的處理能力。
c2.客戶端避免進行阻塞操作導致模擬多使用者效能下降，導致伺服器表現效能下降
d.流量需要區分內網
網內、外網流量在遊戲正式執行時是完全分開的。價格也是完全不同的。一個千M的外網是一個無法想象的運營成本，而kmbps/s現在已經是一個可以接受的代價。遊戲程序需要進行不同網絡卡的配置和繫結。確定內外網流量。
5. 效能檢測，網速快慢對其影響；
備註；
7.如果做一個杯子的檢測，你如何測試（經典）1. 功能
1.1水倒水杯容量的一半1.2水倒規定的安全線1.3水杯容量刻度與其他水杯一致1.4蓋子擰緊水倒不出來1.5燙手驗證2. 效能
2.1使用最大次數或時間2.2掉地上不易損壞2.3蓋子擰到什麼程度水倒不出來2.4保溫時間長2.5杯子的耐熱性2.6杯子的耐寒性2.7長時間放置水不會漏2.8杯子上放置重物達到什麼程度杯子會被損壞3. 介面
3.1外觀完整、美觀3.2大小與設計一樣（高、寬、容量、直徑）3.3拿著舒服3.4材質與設計一樣3.5杯子上的圖案掉落3.6圖案遇水溶解4. 安全
4.1杯子使用的材質毒或細菌的驗證4.2高溫材質釋放毒性4.3低溫材質釋放毒性5. 易用性
5.1倒水方便5.2喝水方便5.3攜帶方便5.4使用簡單，容易操作5.5防滑措施6. 相容性
6.1杯子能夠容納果汁、白水、酒精、汽油等。7. 震動測試
7.1杯子加包裝（有填充物），六面震動，檢查產品是否能應對鐵路/公路/航空運輸。8. 可移植性
8.1杯子在不同地方、溫度環境下都可以正常使用。8.如何對一個頁面進行測試參考回答：
1. UI測試：頁面佈局、頁面樣式檢查、控制元件長度是否夠長；顯示時，是否會被截斷；支援的快捷鍵，Tab鍵切換焦點順序正確性等。
2. 功能測試：頁面上各類控制元件的測試範圍，測試點。結合控制元件的實際作用來補充檢查點：比如， 密碼框是否*顯示， 輸入是否做trim處理等。
4. 相容性測試
5. 效能測試
9.如何對水壺進行測試(同水杯)參考回答：
1. 功能
1.1水倒水壺容量的一半1.2水倒規定的安全線1.3水壺容量刻度與其他水壺一致1.4蓋子擰緊水倒不出來1.5燙手驗證2. 效能
2.1使用最大次數或時間2.2掉地上不易損壞2.3蓋子擰到什麼程度水倒不出來2.4保溫時間長2.5壺的耐熱性2.6壺的耐寒性2.7長時間放置水不會漏2.8壺上放置重物達到什麼程度壺會被損壞3. 介面
3.1外觀完整、美觀3.2大小與設計一樣（高、寬、容量、直徑）3.3拿著舒服3.4材質與設計一樣3.5壺上的圖案掉落3.6圖案遇水溶解4. 安全
4.1壺使用的材質毒或細菌的驗證4.2高溫材質釋放毒性4.3低溫材質釋放毒性5. 易用性
5.1倒水方便5.2喝水方便5.3攜帶方便5.4使用簡單，容易操作5.5防滑措施6. 相容性
6.1壺能夠容納果汁、白水、酒精、汽油等。7. 震動測試
7.1壺加包裝（有填充物），六面震動，檢查產品是否能應對鐵路/公路/航空運輸。8. 可移植性
8.1壺在不同地方、溫度環境下都可以正常使用。10.如何對淘寶搜尋框進行測試參考回答：
1.功能測試
1.輸入關鍵字，檢視: 返回結果是否準確，返回的文字長度需限制
1.1輸入可查到結果的正常關鍵字、詞、語句，檢索到的內容、連結正確性；
1.2輸入不可查到結果的關鍵字、詞、語句；
1.3輸入一些特殊的內容，如空、特殊符、標點符、極限值等，可引入等價類劃分的方法等；
2.結果顯示：標題，賣家，銷售量，單行/多行，是否有圖片
3.結果排序：價格 銷量 評價 綜合
4.返回結果龐大時，限制第一頁的現實量，需支援翻頁
5.多選項搜尋：關鍵字 品牌 產地 價格區間 是否天貓 是否全國購
6.是否支援模糊搜尋，支援萬用字元的查詢
7, 網速慢的情況下的搜尋
8.搜尋結果為空的情況
9.未登入情況和登入情況下的搜尋（登入情況下 儲存使用者搜尋的關鍵字/搜尋習慣）
2. 效能測試：
1.壓力測試：在不同發使用者數壓力下的表現（評價指標如響應時間等）
2.負載測試：看極限能承載多大的使用者量同時正常使用
3.穩定性測試：常規壓力下能保持多久持續穩定執行
4.記憶體測試：有無記憶體洩漏現象
5.大資料量測試：如模擬從龐大的海量資料中搜索結果、或搜尋出海量的結果後列示出來，看錶現如何等等。
3. 易用性：互動介面的設計是否便於、易於使用
1.依據不同的查詢結果會有相關的人性化提示，查不到時告知？查到時統計條數並告知？有疑似輸入條件錯誤時提示可能正確的輸入項等等處理；
3.標題查詢、全文檢索、模糊查詢、容錯查詢、多關鍵字組織查詢（空格間格開）等實用的檢索方式是否正常？
4.輸入搜尋條件的控制元件風格設計、位置擺放是否醒目便於使用者注意到，有否快照等快捷檢視方式等人性化設計？
4. 相容性
1.WINDOWS/LINUX/UNIX等各類作業系統下及各版本條件下的應用
2.IE/FIREFOX/GOOGLE/360/QQ等各類瀏覽器下及各版本條件下、各種顯示解析度條件下的應用
3.SQL/ORACLE/DB2/MYSQL等各類資料庫儲存情況下的相容性測試
4.簡體中文、繁體中文、英文等各類語種軟體平臺下的相容性測試
5.IPHONE/IPAD、安卓等各類移動應用平臺下的相容性測試
6.與各相關的監控程式的相容性測試，如輸入法、防毒、監控、防火牆等工具同時使用
5. 安全性
2.錄入一些資料庫查詢的保留字元，如單引號、%等等，造成查詢SQL拼接出的語句產生漏洞，如可以查出所有資料等等，這方面要有一些駭客攻擊的思想並引入一些工具和技術，如爬網等。
3.透過白盒測試技術，檢查一下在程式設計上是否存在安全方面的隱患；
4.對涉及國家安全、法律禁止的內容是否進行了相關的過濾和控制；
11.如何對一瓶礦泉水進行測試參考回答：
1.介面測試:檢視外觀是否美2.功能度：檢視水瓶漏不漏；瓶中水能不能被喝到3.安全性：瓶子的材質有沒有毒或細菌4.可靠性：從不同高度落下的損壞程度5.可移植性：再不同的地方、溫度等環境下是否都可以正常使用6.相容性：是否能夠容納果汁、白水、酒精、汽油等7.易用性：是否燙手、是否有防滑措施、是否方便飲用8.使用者文件：使用手冊是否對的用法、限制、使用條件等有詳細描述9.疲勞測試：將盛上水（案例一）放24小時檢查洩漏時間和情況；盛上汽油（案例二）放24小時檢查洩漏時間和情況等10.壓力測試：用根針並在針上面不斷加重量，看壓強多大時會穿透11.跌落測試:測試在何種高度跌落會破壞水瓶12.請你說一下jmeter參考回答：
Jmeter：Apache JMeter是Apache組織開發的基於Java的壓力測試工具。用於對軟體做壓力測試，它最初被設計用於Web應用測試，但後來擴充套件到其他測試領域。它可以用於測試靜態和動態資源，例如靜態檔案、Java 小服務程式、CGI 指令碼、Java 物件、資料庫、FTP 伺服器， 等等。JMeter 可以用於對伺服器、網路或物件模擬巨大的負載，來自不同壓力類別下測試它們的強度和分析整體效能。另外，JMeter能夠對應用程式做功能/迴歸測試，透過建立帶有斷言的指令碼來驗證你的程式返回了你期望的結果。為了最大限度的靈活性，JMeter允許使用正則表示式建立斷言。
13.為什麼使用Jmeter：1.開源免費，基於Java編寫，可整合到其他系統可拓展各個功能外掛2.支援介面測試，壓力測試等多種功能，支援錄製回放，入門簡單3.相較於自己編寫框架或其他開源工具，有較為完善的UI介面，便於介面除錯4.多平臺支援，可在Linux，Windows，Mac上執行1. 用例生成與匯出：
Jmeter的用例格式為jmx檔案，實際為xml格式，感興趣可以學習下自己定製生成想要的jmx檔案。
2. 生成原則：
每個功能模組為一個獨立的jmx檔案。增加可維護性。（儘量不要將一個jmx檔案放入太多功能，後期維護成本會很高。）
模組的私有變數儲存在模組中，多模組共有的（例如伺服器ip埠等）可以考慮存在單獨的檔案中讀取。
介面測試不要放太多執行緒，畢竟不是做壓力測試，意義也不大。
3. 匯出方法：
編寫測試用例
檔案——儲存為——確定：
4. Jmeter執行模式及引數
GUI模式
開啟已有的jmx檔案（檔案——開啟）
命令列模式
依賴：
配置jmeter環境變數（windows下為將${jmeterhome}/bin加入Path變數）
如果未加入環境變數，在執行的時候可以直接給出全路徑或在${jmeterhome}/bin下執行
命令：
jmeter -n -t <testplan filename> -l <listener filename>
引數：
-h 幫助 -> 打印出有用的資訊並退出
-n 非 GUI 模式 -> 在非 GUI 模式下執行 JMeter
-t 測試檔案 -> 要執行的 JMeter 測試指令碼檔案
-l jtl檔案 -> 記錄結果的檔案
-r 遠端執行 -> 啟動遠端服務
-H 代理主機 -> 設定 JMeter 使用的代理主機
-P 代理埠 -> 設定 JMeter 使用的代理主機的埠號
-j 日誌檔案->設定JMeter日誌檔案的名稱
5. 例項：
JMeter -n -t my_test.jmx -l log.jtl -H my.proxy.server -P 8000
6. 執行步驟：
JMeter 預設去當前目錄尋找指令碼檔案，並把日誌記錄在當前目錄。比如你在 C:\tools\apache-jmeter-2.11\bin 目錄下執行以上命令，JMeter 會去該目錄下尋找 test.jmx 指令碼並把執行結果放在該目錄。如果你的指令碼在其他目錄，而且想要把執行結果放在另外資料夾，可以使用絕對路徑告訴 JMeter。
7. 執行結果檢視：
GUI介面開啟聚合報告
在GUI介面建立一個聚合報告
8. Jmeter使用
Jmeter建立介面測試計劃例項
測試用例應該作為測試的基礎內容，而用例的結構可能劃分，則是用例的基礎（忽然在這裡想說一下，用例僅僅是一項測試活動的綱要，有最好，沒有的話能保證質量也OK。更不用說用例的格式問題，無論是表格還是導圖，其實都無所謂！本文的用例是指jmx檔案中的控制元件結構）。
1.模組名稱（測試計劃）：每個模組獨立劃分為一個jmx檔案（例如登陸模組），最好與介面類一一對應。對應的伺服器資訊，資料庫資訊等可存在這裡。2.資料準備：用於測試資料的準備（例如賬號資訊）。3.結果檢視：用於放置需要檢視結果的控制元件（例如結果樹）。4.執行緒組：所有的介面測試用例放線上程組下，集中定義執行緒等資訊5.獲取執行緒對應測試資料：用於獲取針對獨立執行緒的測試資料，例如在資料準備裡面獲得了賬號資訊，在這裡根據賬號資訊去資料庫獲取對應的名稱，ID等資訊。6.請求名稱：用簡單控制器為資料夾，內有不同的請求。簡單控制器為一個獨立的介面，不同7.請求對應不同的程式碼路徑（例如成功請求，失敗請求等）。建議請求名稱最好用英文形式，否則後期持續整合或許會出現問題（no zuo no die！）。8.在每條請求內放置正則匹配（用於應對需要返回值作為下次請求的引數的情況）以及斷言。14. 請你進行測試：前端下拉框實現，測試下拉框定位方式參考回答：
Selenium+Python自動化測試對下拉選單的定位
1. 透過selenium.webdriver.support.ui的Select進行定位
下拉選單如下圖：
定位程式碼：
pythonfrom selenium.webdriver.support.ui import Select# 透過index進行選擇Select(driver.find_element_by_id("gender")).select_by_index(1)# 透過value進行選擇Select(driver.find_element_by_id("gender")).select_by_value("2")# 透過選項文字進行選擇Select(driver.find_element_by_id("gender")).select_by_visible_text("Male")# 注：Select only works on <select> elements（Select只對<select>標籤的下拉選單有效）.```2. 定位非<select>標籤的下拉選單
非<select>標籤的下拉選單如下圖所示：
定位非<select>標籤的下拉選單中的選項，需要兩個步驟，先定位到下拉選單，再對其中的選項進行定位。
定位程式碼：
python# 先定位到下拉選單drop_down = driver.find_element_by_css_selector("div#select2_container > ul")# 再對下拉選單中的選項進行選擇drop_down.find_element_by_id("li2_input_2").click()# 注：也可以用此方法定位<select>標籤的下拉選單。```參考回答：
ppium-unittest單元測試框架中，TestCase 類提供了一些方法來檢查並報告故障，如下圖：
上面所提供的斷言方法（assertRaises(), assertRaisesRegexp()除外）接收 msg 引數，如果指定， 將體作為失敗的錯誤資訊。
pythontry:num = input("Enter a number:")assert (num == 10), "The number is not 10!"except AssertionError,msg:print msgprint ("Sadly, num not equals to 10")```在上面的程式中，執行到的python 的異常與斷言。透過 raw_input()方法要求使用者輸入一個數字，透過 arrsert 判斷使用者輸入的 num 是否等於10 ；透過 python 的 AssertionError 型別的異常來實捕獲這個異常， msg 接收異常資訊並列印， 注意， msg 所結構的異常資訊是我們自定義的（"The number is not10!"） 。
1.assertEqual(first, second, msg=None)：判斷 first 和 second 的值是否相等，如果不相等則測試失敗，msg 用於定義失敗後所丟擲的異 常資訊。2.assertNotEqual(first, second, msg=None)：測試 first 和 second 不相等，如果相等，則測試失敗。3.assertTure(expr,msg=None)、assertFalse(expr,msg=None)：測試 expr 為 Ture（或為 False）以下為python 2.7 版新增的斷言方法：
1.assertIs(first, second, msg=None)、assertIsNot(first, second, msg=None)：測試的 first 和 second 是（或 不是）相同的物件。2.assertIsNone(expr, msg=None)、assertIsNotNone(expr, msg=None)：測試 expr 是（或 不是）為 None3.assertIn(first, second, msg=None)、assertNotIn(first, second, msg=None)：測試 first 是（或不是）在 second 中。second 包含是否包含 first 。4.assertIsInstance(obj, cls, msg=None)、assertNotIsInstance(obj, cls, msg=None)：測試 obj 不（或 不是）cls 的一個例項。（obj 和 cls 可以是一個類或元組） ，要檢查他們的型別使用 5.assertIs(type(obj), cls)。16.請你來說一下購物車的測試用例參考回答：
1. 介面測試
1.1介面佈局、排版是否合理；文字是否顯示清晰；不同賣家的商品是否區分明顯。2. 功能測試
2.1未登入時：
2.2.1所有連結是否跳轉正確；2.2.2商品是否可以成功加入購物車；2.2.3購物車商品總數是否有限制；2.2.4商品總數是否正確；2.2.5全選功能是否好用；2.2.6刪除功能是否好用；2.2.7填寫委託單功能是否好用；2.2.8委託單中填寫的價格是否正確顯示；2.2.9價格總計是否正確；2.2.10商品文字太長時是否顯示完整；2.2.11店鋪名字太長時是否顯示完整；2.2.12創新券商品是否達標；2.2.13購物車中下架的商品是否有特殊標識；2.2.14新加入購物車商品排序（新增購物車中存在店鋪的商品和購物車中不存在店鋪的商品）；2.2.15是否支援TAB、ENTER等快捷鍵；2.2.16商品刪除後商品總數是否減少；2.2.17購物車結算功能是否好用。3. 相容性測試
3.1不同瀏覽器測試。4. 易用性測試
5. 效能測試
5.1壓力測試；併發測試。17.請你進行一下弱網模擬參考回答：
方法一：charles弱網模擬
配置引數解析：
bandwidth —— 頻寬，即上行、下行資料傳輸速度utilisation —— 頻寬可用率，大部分modern是100%round-trip latency —— 第一個請求的時延，單位是ms。MTU —— 最大傳輸單元，即TCP包的最大size，可以更真實模擬TCP層，每次傳輸的分包情況。Releability —— 指連線的可靠性。這裡指的是10kb的可靠率。用於模擬網路不穩定。Stability —— 連線穩定性，也會影響頻寬可用性。用於模擬行動網路，行動網路連線一般不可靠。使用chrome的webview除錯工具，缺點是隻適用於web頁面的弱網模擬。
方法二：chrome的webview除錯工具弱網模擬
使用chrome的webview除錯工具，缺點是隻適用於web頁面的弱網模擬。
具體步驟：
應用開啟webview除錯功能，具體如下：pythonif (Build.VERSION.SDK_INT >=Build.VERSION_CODES.KITKAT) {WebView.setWebContentsDebuggingEnabled(true);}```方法三：iOS手機自帶Network Link Conditioner 弱網模擬
iPhone手機開啟開發者選項
具體參考：
設定-開發者選項 > Network Link Conditioner 入口。系統已經內建常見網路配置，也可以增加自定義配置。具體配置引數：
in Bandwidth 下行頻寬，即下行網路速度In packet loss 下行丟包率in delay 下行延遲，單位msout bandwidth 上行頻寬out packet loss 上行丟包率out delay 上行延遲DNS delay DNS解析延遲protocol 支援Any，IPV4、IPV6interface 支援Any，WI-Fi，cellular（蜂窩網）18.你寫的測試程式是怎麼樣的，你寫過前端、後端程式嗎？參考回答：
開發測試驅動程式一般分為4步：
1. 指出需要的新特性。可以記錄下來，然後為其編寫一個測試。
2. 編寫特性的概要程式碼，這樣程式就可以執行而沒有任何語法等方面的錯誤，但是測試會失敗。看到測試失敗是很重要的，這樣就能確定測試可以失敗。如果測試程式碼中出現了錯誤，那麼就有可能出現任何情況，測試都會成功，這樣等於沒測試任何東西。再強調一遍：在試圖測試成功之前，先要看到它失敗。
3. 為特性的概要編寫虛設程式碼，能滿足測試要求就行。不用準確的實現功能，只要保證測試可以透過即可。這樣一來就可以保證在開發的時候總是透過測試了，（除了第一次測試的時候）甚至在最初實現功能時亦是如此。
4. 現在重寫（或者重構）程式碼，這樣它就會做自己應該做的事，從而保證測試一直成功。
在編碼完成時，應該保證程式碼處於健康狀態--不要遺留下任何測試失敗。
寫過前端程式。
19.請問你有沒有寫過測試指令碼，怎麼寫的？參考回答：
然後，撰寫測試樁與驅動，白盒測試保證程式碼邏輯中迴圈和分支都能夠走到，黑盒測試保證函式和首先，程式碼走查結合動態單步跟蹤以及觀察日誌與檔案輸出，網路、CPU狀態。
功能指令碼介面正確，輸入輸出符合設計預期。
對於異常處理，特別是變數的檢查需要特別關注，變數在使用前都需要進行檢查，是否為空？或者為0？對於檔名和路徑必須檢查，確認檔案是否存在，路徑是否可達之後再進行後續操作。
另外，需要考慮所依賴的其他功能指令碼以及二進位制工具，這些功能性單元應該如何使用，呼叫後的返回會有哪些情況，對於正常和異常結果，指令碼是否能夠捕捉到並且作出正確的判斷。
20.請問你有沒有寫過web測試，怎麼寫的？參考回答：
Web測試主要從下面幾個大方向考慮：
1.功能測試
主要做連結測試，表單測試，cookies測試，設計語言測試等
2. 效能測試
考慮連線速度測試，以及負載測試，例如：Web應用系統能允許多少個使用者同時線上？如果超過了這個數量，會出現什麼現象？Web應用系統能否處理大量使用者對同一個頁面的請求？還有壓力測試
3. 可用性測試
比如導航測試，圖形測試，內容測試，整體介面測試等
4. 相容性測試
市場上有很多不同的作業系統型別，最常見的有Windows、Unix、Macintosh、Linux等。Web應用系統的終端使用者究竟使用哪一種作業系統，取決於使用者系統的配置。這樣，就可能會發生相容性問題，同一個應用可能在某些作業系統下能正常執行，但在另外的作業系統下可能會執行失敗。因此，在Web系統釋出之前，需要在各種作業系統下對Web系統進行相容性測試。
5. 安全性測試
-現在的Web應用系統基本採用先註冊，後登陸的方式。因此，必須測試有效和無效的使用者名稱和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。-Web應用系統是否有超時的限制，也就是說，使用者登陸後在一定時間內（例如15分鐘）沒有點選任何頁面，是否需要重新登陸才能正常使用。-為了保證Web應用系統的安全性，日誌檔案是至關重要的。需要測試相關資訊是否寫進了日誌檔案、是否可追蹤。-當使用了安全套接字時，還要測試加密是否正確，檢查資訊的完整性。-伺服器端的指令碼常常構成安全漏洞，這些漏洞又常常被駭客利用。所以，還要測試沒有經過授權，就不能在伺服器端放置和編輯指令碼的問題。21.請問測試路由器怎麼測，用命令列還是介面？參考回答：
可以採用lperf這個命令
Lperf是一個網路效能測試工具，可以測量最大tcp和udp頻寬，具有多種引數和特性，可以記錄頻寬，延遲抖動，資料包丟失，透過這些資訊可以發現網路問題，檢查網路質量，定位網路瓶頸。
iperf的使用非常簡單，測試的原理是在wan口連線一臺PC機，在LAN口連線一臺PC，兩邊分別執行iperf服務端和客戶端模式，用來測量LAN->WAN和WAN->LAN效能。具體命令如下：
服務端：iperf -s -w 1m
客戶端：iperf -c <server ip> -w 1m -t 20 -P 10
含義是TCP wndowsize 為1MByte，測試時間是20s，執行緒是10。
22.請你回答一下如何測試手機開機鍵？參考回答：
1.功能測試：按下開機鍵，螢幕能否亮起2.效能測試：按下開機鍵，螢幕能否在規定時間內亮起3.壓力測試：連續多次按下開機鍵，觀察螢幕是否能一直亮起，到多久時間失靈4.健壯性測試：給定一箇中了病毒的手機或者是淘汰許久的老機子，安歇開機鍵觀察螢幕能否亮起5.可靠性測試：連續按下開機鍵有限次數，比如1萬次，記錄螢幕未亮起的次數6.可用性測試：開機鍵按下費不費力，開機鍵的形狀設計是否貼合手指，開機鍵的位置設計是否方便23.請問你遇到過哪些印象深刻的bug，介面測試出現bug的原因有哪些？參考回答：
面試官詢問遇到過哪些印象深刻的bug，其實它並不關心你描述的這個bug是否真的有價值，或有多曲折離奇？他只是：瞭解你平時工作中的測試能力
所以，這就要求的你平時工作中遇到bug時試著自己去定位，定位bug的過程遠比你的單純的執行測試用例有“價值”（自我技能提高的價值），在定位bug的過程中你需要掌握和運用更多知識。
另外，建議你平時養成總結的好習慣，發現的bug，開發解決了，最好問問他原因以及解決的方法，這樣再遇到類似問題時，自己也可以試著定位解決。遇到難解決的bug，也可以把最終的解決過程記錄下來。（這不是就有素材了）
介面測試常見的bug有以下幾個:
1. 特殊值處理不當導致程式異常退出或者崩潰
2. 型別邊界溢位，導致資料獨處和寫入不一致
3. 取值邊界外未返回正確的錯誤資訊
4. 許可權未處理，可以訪問其他使用者的資訊
5. 邏輯校驗不完善，可以利用漏洞獲取非正當利益
6. 狀態處理不當，導致邏輯出現錯誤
7. 陣列型別item個數為0或者item重複時程式異常退出
24.你在做專案中有做過壓力測試嗎，怎麼做參考回答：
1. 首先對要測試的系統進行分析，明確需要對那一部分做壓力測試，比如秒殺，支付
2. 如何對這些測試點進行施壓
P.S.：第一種方式可以透過寫指令碼產生壓力機器人對伺服器進行發包收報操作，第二點藉助一些壓力測試工具比如Jmeter,LoadRunner
3. 如何對這些測試點進行正確的施壓
需要用壓力測試工具或者其他方法錄製指令碼，模擬使用者的操作
4. 對測試點設計多大的壓力比較合適？
需要明確壓力測試限制的數量，即使用者併發量
5. 測試結束後如何透過這些資料來定位效能問題
透過測試可以得到吞吐量，平均響應時間等資料，這個資料的背後是整個後臺處理邏輯綜合作用的結果，這時候就可以先關注系統的CPU，記憶體，然後對比吞吐量，平均響應時間達到瓶頸時這些資料的情況，然後就能確認效能問題是系統的哪一塊造成的
25.請問你在專案中關於功能測試和介面測試是怎麼做的1. 功能測試：
首先制定測試計劃，然後進行測試設計，將在測試計劃階段指定的測試活動分解，進而細化，為若干個可執行程式的子測試過程，然後執行測試，按照測試計劃使用測試用例對待測專案進行逐一的，詳細的排查分析評估，最後對測試結果進行統計和分析，
2. 介面測試：
2.1什麼是介面（API）API全稱Application Programming Interface，這裡面我們其實不用去關注AP，只需要I上就可以。一個API就是一個Interface。我們無時不刻不在使用interfaces。我們乘坐電梯裡面的按鈕是一個interface。我們開車一個踩油門它也是一個interface。我們計算機作業系統也是有很多的介面。(這是目前個人找到比較好理解的一段解釋)
介面就是一個位於複雜系統之上並且能簡化你的任務，它就像一箇中間人讓你不需要了解詳細的所有細節。那我們今天要講的Web API就是這麼一類東西。像谷歌搜尋系統，它提供了搜尋介面，簡化了你的搜尋任務。再像使用者登入頁面，我們只需要呼叫我們的登入介面，我們就可以達到登入系統的目的。
現在市面上有非常多種風格的Web API，目前最流行的是也容易訪問的一種風格是REST或者叫RESTful 風格的API。從現在開始，以下我提到的所有API都是指RESTful風格的API。
2.2什麼是介面測試和為什麼要做介面測試介面測試是測試系統元件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的互動點。測試的重點是要檢查資料的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。
現在很多系統前後端架構是分離的，從安全層面來說，只依賴前端進行限制已經完全不能滿足系統的安全要求（繞過前端太容易了），需要後端同樣進行控制，在這種情況下就需要從介面層面進行驗證。
如今系統越來越複雜，傳統的靠前端測試已經大大降低了效率，而且現在我們都推崇測試前移，希望測試能更早的介入測試，那介面測試就是一種及早介入的方式。例如傳統測試，你是不是得等前後端都完成你才能進行測試，才能進行自動化程式碼編寫。而如果是介面測試，只需要前後端定義好介面，那這時自動化就可以介入編寫介面自動化測試程式碼，手工測試只需要後端程式碼完成就可以介入測試後端邏輯而不用等待前端工作完成。
2.3介面測試的策略介面測試也是屬於功能測試，所以跟我們以往的功能測試流程並沒有太大區別，測試流程依舊是：
2.3.1 測試介面文件（需求文件）
2. 3.2根據介面文件編寫測試用例（用例編寫完全可以按照以往規則來編寫，例如等價類劃分，邊界值等設計方法）
2.3.3 執行測試，檢視不同的引數請求，介面的返回的資料是否達到預期。
26.請問你有用過什麼測試工具嗎，用過哪些？參考回答：
自動化測試工具用過selenium和appium
效能測試工具有用過Jmeter
功能測試:點贊某條朋友圈，驗證是否成功介面測試:點贊朋友圈，驗證朋友能否收到提示資訊效能測試:點贊朋友圈，是否在規定時間顯示結果，是否在規定時間在朋友手機上進行提示相容性測試:在不同的終端比如ipad,手機上點贊朋友圈，驗證是否成功28.請問如果使用者點選微博的關注圖示但是app上面沒有反應，應該怎麼排查這個問題參考回答：
2. 切換檢視之後，可以看到debug下，app的執行緒列表。
3. 對於main執行緒（第一個執行緒），選中，並將其掛起Suspend。
4. 然後我們就可以看到，Suspend之後，main執行緒卡住的位置。
29.在做測試的過程中，假如前端和後端吵起來了都在踢皮球覺得對方該改程式碼，你怎麼辦？參考回答：
少依賴、少出錯機會。
1. 檢查網路連線是否穩定，更換網路嘗試
3. 清除app快取，應用資料
31.請你說一下能不能用機器學習去進行自動化測試，如何監控異常流量，如果是脈衝呢，如何和正常流量作區分參考回答：
如何用機器學習去進行自動化測試，就是讓自動化測試變得更加智慧，在自動化測試過程中，當測試功能模組越來越多，沒有太多的時間去全部覆蓋，我們可以採用歸納學習的方式，基於自動化測試的執行結果或者手工測試執行的結果為資料輸入，然後基於一定的模型（例如：以透過率和模組的重要率計算的平均值）得出測試推薦模組，或者當要執行一個功能模組時，基於歷史資料和模型（bug出現的錯誤相關性，功能相關性等）計算出與該功能模組相關性最大模組，並推薦測試。
1.如何監控異常流量:
1.1 抓包
tcpdump -i eth0 -w server.cap
對包檔案使用第三方工具如：wireshark做分析
1.2. iftop
yum install iftop
1.3. iptraf
yum install iptraf –y 或 yum install iptraf-ng -y
啟動命令ifptraf-ng
32.請你說一說當前工作中涉及的測試問題(測試流程和測試效能)參考回答：
在測試效能中，時常會出現腳本回訪卡住的問題
原因有以下幾種：
1. runtimesetting 中的continue error沒有勾選
2. 錄製的指令碼中存在冗餘的程式碼部分，需要對指令碼進行最佳化，去除冗餘的部分（最佳化指令碼）
例如：在用FireFox錄製指令碼時，指令碼中會產生一個叫”Url=http://download.cdn.mozilla.net/pub/firefox/releases/43.0.1/update/win32/zh-CN/firefox-43.0.1.complete.mar","Referer=", ENDITEM,”這樣的程式碼（該程式碼出現的問題不止一處，在查詢時一定要注意。），這是因為採用firefox瀏覽器錄製時產生的壓縮檔案，在腳本回放時卡住的原因正是因為這個（建議：能採用IE錄製儘量用IE瀏覽器）
產生的原因如下：
1. 指令碼中還存在沒有關聯或者關聯失敗的動態值，利用lr自帶對比工具仔細對比
2. 指令碼中的動態值被做了加密策略，仔細檢視指令碼中動態值的部分，看看動態值是否被做了安全策略（隨機生成或者打亂動態值順序、在動態值中加入了特殊符號），由於在tree-response中的動態值是未被加密的狀態，在client向server傳送請求時，client的動態值發給伺服器，這時伺服器的動態值已經被做了引數化，所以伺服器不認準client向伺服器傳送的動態值。
解決辦法：去掉動態值的安全策略即可（JVM引數）
33. 請你說一說洗牌問題的思路並手寫程式碼，並設計測試用例參考回答：
洗牌問題：有個長度為2n的陣列{a1,a2,a3,…,an,b1,b2,b3,…,bn}，希望排序後{a1,b1,a2,b2,….,an,bn}，請考慮有無時間複雜度o(n)，空間複雜度0(1)的解法。
pythonvoid PerfectShuffle(int *A,int n){if(n <= 1){return;}//if//int size = 2*n;int index,count;for(int i = n;i < size;++i){// 交換個數count = n - (i - n) - 1;// 待交換index = i;for(int j = 1;j <= count;++j){swap(A[index],A[i-j]);index = i - j;}//for}//for}};```可以就陣列的型別，可以是int型的，浮點型的，還可以是大數型別，負數，進行測試。
34.請你測試一下游戲中英雄的技能參考回答：
測試的設計都是通用的，首先功能測試看功能有沒有實現，然後再對效能、壓力、容量、健壯性、安全性、可靠性、恢復性、備份、協議、相容性、可用性、配置、GUI這些非功能測試去思考。具體答案這裡不再贅述
35.請你回答一下效能測試有哪些指標，對一個登入功能做效能測試，有哪些指標，怎麼測出可同時處理的最大請求數量參考回答：
1.效能測試常用指標：
從外部看，主要有
1.1. 吞吐量：每秒鐘系統能夠處理的請求數，任務數
1.2. 響應時間：服務處理一個請求或一個任務的耗時
1.3. 錯誤率：一批請求中結果出錯的請求所佔比例
2.從伺服器的角度看
效能測試關注CPU，記憶體，伺服器負載，網路，磁碟ＩＯ
2.1對登入功能做效能測試2.2單使用者登陸的響應介面是否符合預期2.3單使用者登陸時後臺請求數量是否過多2.4高併發場景下使用者登入的響應介面是否符合預期2.5高併發場景下服務端的監控指標是否符合預期2.6高集合點併發場景下是否存在資源死鎖和不合理的資源等待2.7長時間大量使用者連續登入和登出，伺服器端是否存在記憶體洩漏2.8怎麼測出可同時處理的最大請求數量2.9可以採用效能測試工具(WeTest伺服器效能)，該工具是騰訊wetest團隊出品，使用起來很簡單方便，但測試功能相當強大，能提供10w+以上的併發量，定位效能拐點，測出伺服器模型最大併發36.請問你有沒有做過什麼單元測試，怎麼進行單元測試，對一個沒有引數沒有返回值但可能對全域性變數有影響的怎麼進行單元測試參考回答：
如何進行單元測試：
建立單元測試，該工具可以對任何類、介面、結構等實體中的欄位、屬性、建構函式、方法等進行單元測試。建立單元測試大致可以分為兩類：
執行單元測試
檢視測試結果
編寫單元測試程式碼
測試沒有引數的函式，它可能還有別的輸入，例如全域性變數，成員變數，或呼叫子函式獲得的輸入（這個要使用工具才能做到），只要函式需讀取的，都應該設定初始值，如果完全沒有，沒有輸入也是一種輸入，照樣測試就是了。同樣道理，輸出也不僅僅是返回值，沒有返回值還可能修改了全域性變數什麼的，這些也是要判斷的輸出。
37.請問你有沒有做過壓力測試參考回答：
在軟體工程中，壓力測試是對系統不斷施加壓力的測試，是透過確定一個系統的瓶頸或者不能接收的效能點，來獲得系統能提供的最大服務級別的測試。例如測試一個Web 站點在大量的負荷下，何時系統的響應會退化或失敗。
38. 對於有系統大量併發訪問，你會如何做測試，有什麼建議參考回答：
如何做高併發系統的測試，一般而言，整體的測試策略是：先針對部分系統進行效能測試及壓力測試，得到各部分的峰值處理效能，再模擬整體流程測試，重點測試整體業務流程以及業務預期負荷，著重測試以下幾點：
1. 不同省份，不同運營商CDN節點效能，可採用典型壓力測試方案
2. 核心機房BGP網路頻寬，此部分重點在於測試各執行商的BGP網路可靠性，實際速率，一般採用smokeping,lxChariot等工具
3. 各類硬體裝置效能，一般採用專業的網路裝置測試工具
4. 各類伺服器併發效能，分散式處理能力，可採用壓力測試方案工具
5. 業務系統性能，採用業務系統壓力測試方案
6. 資料庫處理效能，這部分需要結合業務系統進行測試，以獲取核心業務場景下的資料庫的TPS/QPS，
7. 如果有支付功能，需要進行支付渠道介面及分流測試，此部分相對而言可能是最大的瓶頸所在，此外還涉及備份方案，容災方案，業務降級方案的測試。