碼字太難了，這些問題保存在我的word檔案中，但是CSDN有特殊的模板格式，結果還是一行行粘貼過來的
大家看著這份文章上，多給點關注收藏呀~~~~~~

另外需要更多的面試題可以點擊并輸入暗號：CSDN

1.給你一個字串，你怎么判斷是不是ip地址？手寫這段代碼，并寫出測驗用例

參考回答：
IP的格式：(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;

}

//對輸入字串的首末字符判斷，如果是"."則是非法IP

if(str.charAt(0) == '.' || str.charAt(str.length()-1) == '.'){

return false;

}

//按"."分割字串，并判斷分割出來的個數，如果不是4個，則是非法IP

String[] arr = str.split("\\.");
if(arr.length != 4){
return false;
}
//對分割出來的每個字串進行單獨判斷

for(int i = 0; i < arr.length; i++){

//如果每個字串不是一位字符，且以'0'開頭，則是非法的IP，如：01.002.03.004

if(arr[i].length() > 1 && arr[i].charAt(0) == '0'){

return false;

}

//對每個字串的每個字符進行逐一判斷，如果不是數字0-9，則是非法的IP

for(int j = 0; j < arr[i].length(); j++){
if (arr[i].charAt(j) < '0' || arr[i].charAt(j) > '9'){
return false;
}
}
}
//對拆分的每一個字串進行轉換成數字，并判斷是否在0~255

for(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;
}
}

等價類劃分：

測驗用例：	有效可用的IP地址
A類	1.0.0.0 -126.255.255.254
A私有	10.0.0.0 -10.255.255.254
B類	128.0.0.0 -191.255.255.254
B私有	172.16.0.0 -172.31.255.254
C類	192.0.0.0 -223.255.255.254
C私有	192.168.0.0-192.168.255.254
windows自動分配	169.254.0.0-169.254.255.254
有效但不可用的IP地址
D	224.0.0.0 -239.255.255.254
E	240.0.0.0 -255.255.255.254
全網	0.x.x.x, x.x.x.0
廣播	x.x.x.255
回環	127.0.0.0 -127.255.255.254

輸入	輸出
64.11.22.33	有效可用
10.12.13.14	有效可用，不能直接訪問公網
151.123.234.56	有效可用
172.20.123.56	有效可用，不能直接訪問公網
192.127.35.65	有效可用
192.168.128.128	有效可用，不能直接訪問公網
169.254.15.200	有效可用，不能直接訪問公網
224.1.2.3	有效不可用，超過有效范圍（D類）
250.11.22.33	有效不可用，超過有效范圍（E類）
0.200.3.4	有效不可用，全網地址
64.11.22.0	有效不可用，全網地址
10.12.13.255	有效不可用，廣播地址
127.50.60.70	有效不可用，回環地址

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("不是閏年");

}

}

}

測驗用例：

測驗用例	輸入	預期輸出
被 4 整除, 但是不被100 整除的年份	2008	閏年
被 4 整除, 同時被100 整除的年份，且被 400 整除的年份	2000	閏年
被 4 整除, 同時被100 整除的年份，但是不被400 整除的年份	1900	不是閏年
偶數, 不被4 整除的年份	2022	不是閏年
奇數年份	1999	不是閏年
年份大于9999	10000	請輸入正確的年份
年份小于0	0	請輸入正確的年份

3.請你說一說簡單用戶界面登陸程序都需要做哪些分析

參考回答：

1. 功能測驗

• 輸入正確的用戶名和密碼，點擊提交按鈕，驗證是否能正確登錄，

• 輸入錯誤的用戶名或者密碼,驗證登錄會失敗，并且提示相應的錯誤資訊，

• 登錄成功后能否能否跳轉到正確的頁面

• 用戶名和密碼，如果太短或者太長，應該怎么處理

• 用戶名和密碼，中有特殊字符（比如空格），和其他非英文的情況

• 記住用戶名的功能

• 登陸失敗后，不能記錄密碼的功能

• 用戶名和密碼前后有空格的處理

• 密碼是否非明文顯示顯示，使用星號圓點等符號代替，

• 牽扯到驗證碼的，還要考慮文字是否扭曲過度導致辨認難度大，考慮顏色（色盲使 用者），重繪或換一個按鈕是否好用

• 登錄頁面中的注冊、忘記密碼，登出用另一帳號登陸等鏈接是否正確

• 輸入密碼的時候，大寫鍵盤開啟的時候要有提示資訊，

• 什么都不輸入，點擊提交按鈕，檢查提示資訊，

2. 界面測驗

• 布局是否合理，testbox和按鈕是否整齊，

• testbox和按鈕的長度，高度是否復合要求，

• 界面的設計風格是否與UI的設計風格統一，

• 界面中的文字簡潔易懂，沒有錯別字，

3. 性能測驗

• 打開登錄頁面，需要的時間是否在需求要求的時間內，

• 輸入正確的用戶名和密碼后，檢查登錄成功跳轉到新頁面的時間是否在需求要求的時間內，

• 模擬大量用戶同時登陸，檢查一定壓力下能否正常登陸跳轉，

4. 安全性測驗

• 登錄成功后生成的Cookie，是否是httponly (否則容易被腳本盜取)，

• 用戶名和密碼是否通過加密的方式，發送給Web服務器，

• 用戶名和密碼的驗證，應該是用服務器端驗證， 而不能單單是在客戶端用javascript 驗證，

• 用戶名和密碼的輸入框，應該屏蔽SQL注入攻擊，

• 用戶名和密碼的的輸入框，應該禁止輸入腳本 （防止XSS攻擊），

• 防止暴力破解，檢測是否有錯誤登陸的次數限制，

• 是否支持多用戶在同一機器上登錄，

• 同一用戶能否在多臺機器上登錄，

5. 可用性測驗

• 是否可以全用鍵盤操作，是否有快捷鍵，

• 輸入用戶名，密碼后按回車，是否可以登陸，

• 輸入框能否可以以Tab鍵切換，

6. 兼容性測驗

• 不同瀏覽器下能否顯示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等），

• 同種瀏覽器不同版本下能否顯示正常且功能正常，

• 不同的平臺是否能正常作業，比如Windows, Mac，

• 移動設備上是否正常作業，比如Iphone, Andriod，

• 不同的解析度下顯示是否正常，

7. 本地化測驗

• 不同語言環境下，頁面的顯示是否正確，

4.請對這個系統做出測驗用例：一個系統，多個攝像頭，抓拍車牌，識別車牌，上傳網上，網上展示

參考回答：

功能：

1. 每個攝像頭都能抓拍車牌；

2. 每個攝像頭抓拍到的車牌能正常交給系統處理；

3. 系統能夠正確識別車牌；

4. 系統能夠將識別出的車牌上傳；

5. 上傳至網路的車牌能夠正常展示出來；

一、功能測驗

• 使用正常的車牌，保持車牌靜止，檢查每個攝像頭是否能抓拍車牌；

• 使用類似非車牌的寫有字的紙板，檢查每個攝像頭是否抓拍；

• 使用正常的車牌，保持車牌較高速移動，檢查每個攝像頭是否能抓拍車牌；

• 在多種情況下檢查每個攝像頭抓拍到的車牌能否正常交給系統處理，如臨時斷電、斷網后能否正常將資料交給系統；

• 使用抓拍到的正常的車牌，交由系統處理，檢查系統能否識別車牌；

• 使用非車牌的其他圖片，交由系統處理，檢查系統能否識別；

• 在多種情況下檢查系統能否將正常識別出的車牌進行上傳，如臨時斷電、斷網后未上傳資料是否能繼續上傳；

• 構造非車牌的其他內容的資料，檢查系統能否將例外內容進行上傳；

• 檢查上傳至網路的車牌能否正常展示出來；

• 上傳非車牌的其他內容的資料，檢查能否正常顯示出來，

二、性能測驗

• 同時向一個攝像頭展示多個靜止的車牌，檢查攝像頭能否抓拍到多個車牌；

• 同時向一個攝像頭展示多個較高速運動的車牌，檢查攝像頭能否抓拍到多個車牌；

• 抓拍后，檢查系統識別車牌的時間是否在需求要求的時間內；

• 模擬大量抓拍照片同時交由系統處理，檢查一定壓力下系統能否正常識別車牌；

• 模擬大量車牌同時上傳，檢查一定壓力下能否上傳成功，

三、安全性測驗

• 檢查是否能夠通過給車牌加裝飾物等方法，使攝像頭無法抓拍或抓拍后系統無法正常識別車牌，

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現在已經是一個可以接受的代價，游戲行程需要進行不同網卡的配置和系結，確定內外網流量，

6. 請你根據微信登錄界面設計測驗用例

參考回答：

1. 功能測驗

• 輸入正確的用戶名和密碼，點擊提交按鈕，驗證是否能正確登錄，

• 輸入錯誤的用戶名或者密碼,驗證登錄會失敗，并且提示相應的錯誤資訊，

• 登錄成功后能否能否跳轉到正確的頁面

• 檢查能否選擇不同登錄方式進行登錄，如使用手機號登錄、使用微信號登錄或掃碼登錄，

• 記住用戶名的功能

• 登陸失敗后，不能記錄密碼的功能

• 密碼是否非明文顯示顯示，使用星號圓點等符號代替，

• 有驗證碼時，還要考慮文字是否扭曲過度導致辨認難度大，考慮顏色、重繪或換一個按鈕是否好用

• 登錄頁面中的注冊、忘記密碼，登出用另一帳號登陸等鏈接是否正確

• 輸入密碼的時候，大寫鍵盤開啟的時候要有提示資訊，

• 什么都不輸入，點擊提交按鈕，檢查提示資訊，

2. 界面測驗

• 布局是否合理，testbox和按鈕是否整齊，

• testbox和按鈕的長度，高度是否復合要求，

• 界面的設計風格是否與UI的設計風格統一，

• 界面中的文字簡潔易懂，沒有錯別字，

3. 性能測驗

• 打開登錄頁面，需要的時間是否在需求要求的時間內，

• 輸入正確的用戶名和密碼后，檢查登錄成功跳轉到新頁面的時間是否在需求要求的時間內，

• 模擬大量用戶同時登陸，檢查一定壓力下能否正常登陸跳轉，

4. 安全性測驗

• 登錄成功后生成的Cookie，是否是httponly (否則容易被腳本盜取)，

• 用戶名和密碼是否通過加密的方式，發送給Web服務器，

• 用戶名和密碼的驗證，應該是用服務器端驗證， 而不能單單是在客戶端用javascript 驗證，

• 用戶名和密碼的輸入框，應該屏蔽SQL注入攻擊，

• 用戶名和密碼的的輸入框，應該禁止輸入腳本 （防止XSS攻擊），

• 防止暴力破解，檢測是否有錯誤登陸的次數限制，

• 是否支持多用戶在同一機器上登錄，

• 同一用戶能否在多臺機器上登錄，

5. 兼容性測驗

• 不同移動平臺或PC環境下下能否顯示正常且功能正常

• 同種平臺下不同微信版本下能否顯示正常且功能正常，

• 不同的解析度下顯示是否正常，

6. 本地化測驗

• 不同語言環境下，頁面的顯示是否正確，

7.請你對朋友圈點贊功能進行測驗

參考回答：

1. 是否可以正常點贊和取消；

2. 點贊的人是否在可見分組里；

3. 點贊狀態是否能即時更新顯示；

4. 點贊狀態，共同好友是否可見；

5. 性能檢測，網速快慢對其影響；

6. 點贊顯示的是否正確，一行幾個；

7. 點贊是否按時間進行排序，頭像對應的是否正確；

8. 是否能在訊息串列中顯示點贊人的昵稱、5.不同手機，系統顯示界面如何；

備注；

9. 可擴展性測驗，點贊后是否能發表評論；

10. 是否在未登錄時可查看被點贊的資訊，

8.如果做一個杯子的檢測，你如何測驗（經典）

1. 功能

• 水倒水杯容量的一半

• 水倒規定的安全線

• 水杯容量刻度與其他水杯一致

• 蓋子擰緊水倒不出來

• 燙手驗證

2. 性能

• 使用最大次數或時間

• 掉地上不易損壞

• 蓋子擰到什么程度水倒不出來

• 保溫時間長

• 杯子的耐熱性

• 杯子的耐寒性

• 長時間放置水不會漏

• 杯子上放置重物達到什么程度杯子會被損壞

3. 界面

• 外觀完整、美觀

• 大小與設計一樣（高、寬、容量、直徑）

• 拿著舒服

• 材質與設計一樣

• 杯子上的圖案掉落

• 圖案遇水溶解

4. 安全

• 杯子使用的材質毒或細菌的驗證

• 高溫材質釋放毒性

• 低溫材質釋放毒性

5. 易用性

• 倒水方便

• 喝水方便

• 攜帶方便

• 使用簡單，容易操作

• 防滑措施

6. 兼容性

• 杯子能夠容納果汁、白水、酒精、汽油等，

7. 震動測驗

• 杯子加包裝（有填充物），六面震動，檢查產品是否能應對鐵路/公路/航空運輸，

8. 可移植性

• 杯子在不同地方、溫度環境下都可以正常使用，

9.如何對一個頁面進行測驗

參考回答：

1. UI測驗：頁面布局、頁面樣式檢查、控制元件長度是否夠長；顯示時，是否會被截斷；支持的快捷鍵，Tab鍵切換焦點順序正確性等，

2. 功能測驗：頁面上各類控制元件的測驗范圍，測驗點，結合控制元件的實際作用來補充檢查點： 比如， 密碼框是否*顯示， 輸入是否做trim處理等，

3. 安全測驗：輸入特殊字符，sql注入，腳本注入測驗，后臺驗證測驗，對于較重要的表單 ，繞過js檢驗后臺是否驗證；資料傳輸是否加密處理，比如， 直接請求轉發，地址欄直接顯示發送字串？

4. 兼容性測驗

5. 性能測驗

10.如何對水壺進行測驗(同水杯)

參考回答：

1. 功能

• 水倒水壺容量的一半

• 水倒規定的安全線

• 水壺容量刻度與其他水壺一致

• 蓋子擰緊水倒不出來

• 燙手驗證

2. 性能

• 使用最大次數或時間

• 掉地上不易損壞

• 蓋子擰到什么程度水倒不出來

• 保溫時間長

• 壺的耐熱性

• 壺的耐寒性

• 長時間放置水不會漏

• 壺上放置重物達到什么程度壺會被損壞

3. 界面

• 外觀完整、美觀

• 大小與設計一樣（高、寬、容量、直徑）

• 拿著舒服

• 材質與設計一樣

• 壺上的圖案掉落

• 圖案遇水溶解

4. 安全

• 壺使用的材質毒或細菌的驗證

• 高溫材質釋放毒性

• 低溫材質釋放毒性

5. 易用性

• 倒水方便

• 喝水方便

• 攜帶方便

• 使用簡單，容易操作

• 防滑措施

6. 兼容性

• 壺能夠容納果汁、白水、酒精、汽油等，

7. 震動測驗

• 壺加包裝（有填充物），六面震動，檢查產品是否能應對鐵路/公路/航空運輸，

8. 可移植性

• 壺在不同地方、溫度環境下都可以正常使用，

11.如何對淘寶搜索框進行測驗

參考回答：

1. 功能測驗
   1.輸入關鍵字，查看: 回傳結果是否準確，回傳的文本長度需限制
   1.1輸入可查到結果的正常關鍵字、詞、陳述句，檢索到的內容、鏈接正確性；
   1.2輸入不可查到結果的關鍵字、詞、陳述句；
   1.3輸入一些特殊的內容，如空、特殊符、標點符、極限值等，可引入等價類劃分的方法等；
   2.結果顯示：標題，賣家，銷售量，單行/多行，是否有圖片
   3.結果排序：價格 銷量 評價 綜合
   4.回傳結果龐大時，限制第一頁的現實量，需支持翻頁
   5.多選項搜索：關鍵字 品牌 產地 價格區間 是否天貓 是否全國購
   6.是否支持模糊搜索，支持通配符的查詢
   7, 網速慢的情況下的搜索
   8.搜索結果為空的情況
   9.未登錄情況和登錄情況下的搜索（登錄情況下 存盤用戶搜索的關鍵字/搜索習慣）

2. 性能測驗：
   1.壓力測驗：在不同發用戶數壓力下的表現（評價指標如回應時間等）
   2.負載測驗：看極限能承載多大的用戶量同時正常使用
   3.穩定性測驗：常規壓力下能保持多久持續穩定運行
   4.記憶體測驗：有無記憶體泄漏現象
   5.大資料量測驗：如模擬從龐大的海量資料中搜索結果、或搜索出海量的結果后列示出來，看表現如何等等，

3. 易用性：互動界面的設計是否便于、易于使用
   1.依據不同的查詢結果會有相關的人性化提示，查不到時告知？查到時統計條數并告知？有疑似輸入條件錯誤時提示可能正確的輸入項等等處理；
   2.查詢出的結果羅列有序，如按點擊率或其他排序規則，確保每次查詢出的結果位置按規則列示方便定位，顯示字體、字號、色彩便于識別等等；
   3.標題查詢、全文檢索、模糊查詢、容錯查詢、多關鍵字組織查詢（空格間格開）等實用的檢索方式是否正常？
   4.輸入搜索條件的控制元件風格設計、位置擺放是否醒目便于使用者注意到，有否快照等快捷查看方式等人性化設計？

4. 兼容性
   1.WINDOWS/LINUX/UNIX等各類作業系統下及各版本條件下的應用
   2.IE/FIREFOX/GOOGLE/360/QQ等各類瀏覽器下及各版本條件下、各種顯示解析度條件下的應用
   3.SQL/ORACLE/DB2/MYSQL等各類資料庫存盤情況下的兼容性測驗
   4.簡體中文、繁體中文、英文等各類語種軟體平臺下的兼容性測驗
   5.IPHONE/IPAD、安卓等各類移動應用平臺下的兼容性測驗
   6.與各相關的監控程式的兼容性測驗，如輸入法、殺毒、監控、防火墻等工具同時使用

5. 安全性
   1.被洗掉、加密、授權的資料，不允許被SQL注入等攻擊方式查出來的，是否有安全控制設計；
   2.錄入一些資料庫查詢的保留字符，如單引號、%等等，造成查詢SQL拼接出的陳述句產生漏洞，如可以查出所有資料等等，這方面要有一些黑客攻擊的思想并引入一些工具和技術，如爬網等，
   3.通過白盒測驗技術，檢查一下在程式設計上是否存在安全方面的隱患；
   4.對涉及國家安全、法律禁止的內容是否進行了相關的過濾和控制；

12.如何對一瓶礦泉水進行測驗

參考回答：

• 界面測驗:查看外觀是否美觀
• 功能度：查看水瓶漏不漏；瓶中水能不能被喝到
• 安全性：瓶子的材質有沒有毒或細菌
• 可靠性：從不同高度落下的損壞程度
• 可移植性：再不同的地方、溫度等環境下是否都可以正常使用
• 兼容性：是否能夠容納果汁、白水、酒精、汽油等
• 易用性：是否燙手、是否有防滑措施、是否方便飲用
• 用戶檔案：使用手冊是否對的用法、限制、使用條件等有詳細描述
• 疲勞測驗：將盛上水（案例一）放24小時檢查泄漏時間和情況；盛上汽油（案例二）放24小時檢查泄漏時間和情況等
• 壓力測驗：用根針并在針上面不斷加重量，看壓強多大時會穿透
  跌落測驗:測驗在何種高度跌落會破壞水瓶

13.如何測驗登陸界面

參考回答：

1. 功能測驗

• 輸入正確的用戶名和密碼，點擊提交按鈕，驗證是否能正確登錄，
• 輸入錯誤的用戶名或者密碼,驗證登錄會失敗，并且提示相應的錯誤資訊，
• 登錄成功后能否能否跳轉到正確的頁面
• 用戶名和密碼，如果太短或者太長，應該怎么處理
• 用戶名和密碼，中有特殊字符（比如空格），和其他非英文的情況
• 記住用戶名的功能
• 登陸失敗后，不能記錄密碼的功能
• 用戶名和密碼前后有空格的處理
• 密碼是否非明文顯示顯示，使用星號圓點等符號代替，
• 牽扯到驗證碼的，還要考慮文字是否扭曲過度導致辨認難度大，考慮顏色（色盲使 用者），重繪或換一個按鈕是否好用
• 登錄頁面中的注冊、忘記密碼，登出用另一帳號登陸等鏈接是否正確
• 輸入密碼的時候，大寫鍵盤開啟的時候要有提示資訊，
• 什么都不輸入，點擊提交按鈕，檢查提示資訊，

2. 界面測驗

• 布局是否合理，testbox和按鈕是否整齊，
• testbox和按鈕的長度，高度是否復合要求，
• 界面的設計風格是否與UI的設計風格統一，
• 界面中的文字簡潔易懂，沒有錯別字，

3. 性能測驗

• 打開登錄頁面，需要的時間是否在需求要求的時間內，
• 輸入正確的用戶名和密碼后，檢查登錄成功跳轉到新頁面的時間是否在需求要求的時間內，
• 模擬大量用戶同時登陸，檢查一定壓力下能否正常登陸跳轉，

4. 安全性測驗

• 登錄成功后生成的Cookie，是否是httponly (否則容易被腳本盜取)，
• 用戶名和密碼是否通過加密的方式，發送給Web服務器，
• 用戶名和密碼的驗證，應該是用服務器端驗證， 而不能單單是在客戶端用javascript 驗證，
• 用戶名和密碼的輸入框，應該屏蔽SQL注入攻擊，
• 用戶名和密碼的的輸入框，應該禁止輸入腳本 （防止XSS攻擊），
• 防止暴力破解，檢測是否有錯誤登陸的次數限制，
• 是否支持多用戶在同一機器上登錄，
• 同一用戶能否在多臺機器上登錄，

5. 可用性測驗

• 是否可以全用鍵盤操作，是否有快捷鍵，
• 輸入用戶名，密碼后按回車，是否可以登陸，
• 輸入框能否可以以Tab鍵切換，

6. 兼容性測驗

• 不同瀏覽器下能否顯示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等），
• 同種瀏覽器不同版本下能否顯示正常且功能正常，
• 不同的平臺是否能正常作業，比如Windows, Mac，
• 移動設備上是否正常作業，比如Iphone, Andriod，
• 不同的解析度下顯示是否正常，

7.本地化測驗

• 不同語言環境下，頁面的顯示是否正確，

14.請你說一下jmeter

參考回答：
Jmeter：Apache JMeter是Apache組織開發的基于Java的壓力測驗工具，用于對軟體做壓力測驗，它最初被設計用于Web應用測驗，但后來擴展到其他測驗領域， 它可以用于測驗靜態和動態資源，例如靜態檔案、Java 小服務程式、CGI 腳本、Java 物件、資料庫、FTP 服務器， 等等，JMeter 可以用于對服務器、網路或物件模擬巨大的負載，來自不同壓力類別下測驗它們的強度和分析整體性能，另外，JMeter能夠對應用程式做功能/回歸測驗，通過創建帶有斷言的腳本來驗證你的程式回傳了你期望的結果，為了最大限度的靈活性，JMeter允許使用正則運算式創建斷言，

15.為什么使用Jmeter：

• 開源免費，基于Java撰寫，可集成到其他系統可拓展各個功能插件
• 支持介面測驗，壓力測驗等多種功能，支持錄制回放，入門簡單
• 相較于自己撰寫框架或其他開源工具，有較為完善的UI界面，便于介面除錯
• 多平臺支持，可在Linux，Windows，Mac上運行

1. 用例生成與匯出：
   Jmeter的用例格式為jmx檔案，實際為xml格式，感興趣可以學習下自己定制生成想要的jmx檔案，

2. 生成原則：
   每個功能模塊為一個獨立的jmx檔案，增加可維護性，（盡量不要將一個jmx檔案放入太多功能，后期維護成本會很高，）
   模塊的私有變數保存在模塊中，多模塊共有的（例如服務器ip埠等）可以考慮存在單獨的檔案中讀取，
   介面測驗不要放太多執行緒，畢竟不是做壓力測驗，意義也不大，

3. 匯出方法：
   撰寫測驗用例
   檔案——保存為——確定：
   

4. Jmeter運行模式及引數
   GUI模式
   打開已有的jmx檔案（檔案——打開）
   點擊啟動按鈕運行
   命令列模式
   依賴：
   配置jmeter環境變數（windows下為將 j m e t e r h o m e / b i n 加 入 P a t h 變 量 ） 如 果 未 加 入 環 境 變 量 ， 在 執 行 的 時 候 可 以 直 接 給 出 全 路 徑 或 在 {jmeterhome}/bin加入Path變數） 如果未加入環境變數，在執行的時候可以直接給出全路徑或在 jmeterhome/bin加入Path變量）如果未加入環境變量，在執行的時候可以直接給出全路徑或在{jmeterhome}/bin下執行
   命令：
   jmeter -n -t -l
   引數：
   -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界面創建一個聚合報告
   聚合報告界面點擊瀏覽，選中生成的.jtl檔案，打開
   

8. Jmeter使用
   Jmeter創建介面測驗計劃實體
   測驗用例應該作為測驗的基礎內容，而用例的結構可能劃分，則是用例的基礎（忽然在這里想說一下，用例僅僅是一項測驗活動的綱要，有最好，沒有的話能保證質量也OK，更不用說用例的格式問題，無論是表格還是導圖，其實都無所謂！本文的用例是指jmx檔案中的控制元件結構），
   

• 模塊名稱（測驗計劃）：每個模塊獨立劃分為一個jmx檔案（例如登陸模塊），最好與介面類一一對應，對應的服務器資訊，資料庫資訊等可存在這里，
• 資料準備：用于測驗資料的準備（例如賬號資訊），
• 結果查看：用于放置需要查看結果的控制元件（例如結果樹），
• 執行緒組：所有的介面測驗用例放在執行緒組下，集中定義執行緒等資訊
• 獲取執行緒對應測驗資料：用于獲取針對獨立執行緒的測驗資料，例如在資料準備里面獲得了賬號資訊，在這里根據賬號資訊去資料庫獲取對應的名稱，ID等資訊，
• 請求名稱：用簡單控制器為檔案夾，內有不同的請求，簡單控制器為一個獨立的介面，不同請求對應不同的代碼路徑（例如成功請求，失敗請求等），建議請求名稱最好用英文形式，否則后期持續集成或許會出現問題（no zuo no die！），
• 在每條請求內放置正則匹配（用于應對需要回傳值作為下次請求的引數的情況）以及斷言，

16. 請你進行測驗：前端下拉框實作，測驗下拉框定位方式

參考回答：
Selenium+Python自動化測驗對下拉選單的定位

1. 通過selenium.webdriver.support.ui的Select進行定位

下拉選單如下圖：
定位代碼：

from 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. 定位非標簽的下拉選單
   非標簽的下拉選單如下圖所示：
   
   定位非標簽的下拉選單中的選項，需要兩個步驟，先定位到下拉選單，再對其中的選項進行定位，

定位代碼：

# 先定位到下拉選單

drop_down = driver.find_element_by_css_selector("div#select2_container > ul")

# 再對下拉選單中的選項進行選擇

drop_down.find_element_by_id("li2_input_2").click()

# 注：也可以用此方法定位<select>標簽的下拉選單，

17. 請你來聊一聊appium斷言

參考回答：
ppium-unittest單元測驗框架中，TestCase 類提供了一些方法來檢查并報告故障，如下圖 ：

上面所提供的斷言方法（assertRaises(), assertRaisesRegexp()除外）接收 msg 引數，如果指定， 將體作為失敗的錯誤資訊，

try:
num = input("Enter a number:")
assert (num == 10), "The number is not 10!"
except AssertionError,msg:
print msg
print ("Sadly, num not equals to 10")

在上面的程式中，運行到的python 的例外與斷言，通過 raw_input()方法要求用戶輸入一個數字，通過 arrsert 判斷用戶輸入的 num 是否等于10 ； 通過 python 的 AssertionError 型別的例外來實捕獲這個例外， msg 接收例外資訊并列印， 注意， msg 所結構的例外資訊是我們自定義的（“The number is not10!”） ，

• assertEqual(first, second, msg=None)：判斷 first 和 second 的值是否相等，如果不相等則測驗失敗，msg 用于定義失敗后所拋出的異 常資訊，

• assertNotEqual(first, second, msg=None)：測驗 first 和 second 不相等，如果相等，則測驗失敗，

• assertTure(expr,msg=None)、assertFalse(expr,msg=None)：測驗 expr 為 Ture（或為 False）

以下為python 2.7 版新增的斷言方法：

• assertIs(first, second, msg=None)、assertIsNot(first, second, msg=None)：測驗的 first 和 second 是（或 不是）相同的物件，

• assertIsNone(expr, msg=None)、assertIsNotNone(expr, msg=None)：測驗 expr 是（或 不是）為 None

• assertIn(first, second, msg=None)、assertNotIn(first, second, msg=None)：測驗 first 是（或不是）在 second 中，second 包含是否包含 first ，

• assertIsInstance(obj, cls, msg=None)、assertNotIsInstance(obj, cls, msg=None)：測驗 obj 不（或 不是）cls 的一個實體， （obj 和 cls 可以是一個類或元組） ，要檢查他們的型別使用 assertIs(type(obj), cls)，

18.請你來說一下購物車的測驗用例

參考回答：

1. 界面測驗

• 界面布局、排版是否合理；文字是否顯示清晰；不同賣家的商品是否區分明顯，

2. 功能測驗

未登錄時：

• 將商品加入購物車，頁面跳轉到登錄頁面，登錄成功后購物車數量增加；

• 點擊購物車選單，頁面跳轉到登錄頁面，

登錄后：

• 所有鏈接是否跳轉正確；

• 商品是否可以成功加入購物車；

• 購物車商品總數是否有限制；

• 商品總數是否正確；

• 全選功能是否好用；

• 洗掉功能是否好用；

• 填寫委托單功能是否好用；

• 委托單中填寫的價格是否正確顯示；

• 價格總計是否正確；

• 商品文字太長時是否顯示完整；

• 店鋪名字太長時是否顯示完整；

• 創新券商品是否打標；

• 購物車中下架的商品是否有特殊標識；

• 新加入購物車商品排序（添加購物車中存在店鋪的商品和購物車中不存在店鋪的商品）；

• 是否支持TAB、ENTER等快捷鍵；

• 商品洗掉后商品總數是否減少；

• 購物車結算功能是否好用，

3. 兼容性測驗

• 不同瀏覽器測驗，

4. 易用性測驗

• 洗掉功能是否有提示；是否有回到頂部的功能；商品過多時結算按鈕是否可以浮動顯示，

5. 性能測驗

• 壓力測驗；并發測驗，

19.請你進行一下弱網模擬

參考回答：
方法一：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除錯功能，具體如下：

if (Build.VERSION.SDK_INT >=
Build.VERSION_CODES.KITKAT) {

WebView.setWebContentsDebuggingEnabled(true);

}

• 手機鏈接電腦，運行APP，進入具體H5頁面；

• chrome的DevTools中打開Webview：進入chrome://inspect/#devices，會顯示已經連接設備，選中待除錯webview的inspect
  network頁面，No throttling下拉框，可以進行網路模擬，

方法三：iOS手機自帶Network Link Conditioner 弱網模擬

iPhone手機打開開發者選項，具體參考：

• 設定-開發者選項 > Network Link Conditioner 入口，

• 系統已經內置常見網路配置，也可以增加自定義配置，

具體配置引數：

• in Bandwidth 下行帶寬，即下行網路速度

• In packet loss 下行丟包率

• in delay 下行延遲，單位ms

• out bandwidth 上行帶寬

• out packet loss 上行丟包率

• out delay 上行延遲

• DNS delay DNS決議延遲

• protocol 支持Any，IPV4、IPV6

• interface 支持Any，WI-Fi，cellular（蜂窩網）

20.你寫的測驗程式是怎么樣的，你寫過前端、后端程式嗎？

參考回答：
開發測驗驅動程式一般分為4步：

1. 指出需要的新特性，可以記錄下來，然后為其撰寫一個測驗，

2. 撰寫特性的概要代碼，這樣程式就可以運行而沒有任何語法等方面的錯誤，但是測驗會失敗，看到測驗失敗是很重要的，這樣就能確定測驗可以失敗，如果測驗代碼中出現了錯誤，那么就有可能出現任何情況，測驗都會成功，這樣等于沒測驗任何東西，再強調一遍：在試圖測驗成功之前，先要看到它失敗，

3. 為特性的概要撰寫虛設代碼，能滿足測驗要求就行，不用準確的實作功能，只要保證測驗可以通過即可，這樣一來就可以保證在開發的時候總是通過測驗了，（除了第一次測驗的時候）甚至在最初實作功能時亦是如此，

4. 現在重寫（或者重構）代碼，這樣它就會做自己應該做的事，從而保證測驗一直成功，
   在編碼完成時，應該保證代碼處于健康狀態–不要遺留下任何測驗失敗，
   寫過前端程式，

21.請問你有沒有寫過測驗腳本，怎么寫的？

參考回答：
然后，撰寫測驗樁與驅動，白盒測驗保證代碼邏輯中回圈和分支都能夠走到，黑盒測驗保證函式和首先，代碼走查結合動態單步跟蹤以及觀察日志與檔案輸出，網路、CPU狀態，

功能腳本介面正確，輸入輸出符合設計預期，

對于例外處理，特別是變數的檢查需要特別關注，變數在使用前都需要進行檢查，是否為空？或者為0？對于檔案名和路徑必須檢查，確認檔案是否存在，路徑是否可達之后再進行后續操作，
另外，需要考慮所依賴的其他功能腳本以及二進制工具，這些功能性單元應該如何使用，呼叫后的回傳會有哪些情況，對于正常和例外結果，腳本是否能夠捕捉到并且作出正確的判斷，

22.請問你有沒有寫過web測驗，怎么寫的？

參考回答：
Web測驗主要從下面幾個大方向考慮：

1. 功能測驗，主要做鏈接測驗，表單測驗，cookies測驗，設計語言測驗等

2. 性能測驗，考慮連接速度測驗，以及負載測驗，例如：Web應用系統能允許多少個用戶同時在線？如果超過了這個數量，會出現什么現象？Web應用系統能否處理大量用戶對同一個頁面的請求？還有壓力測驗

3. 可用性測驗，比如導航測驗，圖形測驗，內容測驗，整體界面測驗等

4. 兼容性測驗，市場上有很多不同的作業系統型別，最常見的有Windows、Unix、Macintosh、Linux等，Web應用系統的最終用戶究竟使用哪一種作業系統，取決于用戶系統的配置，這樣，就可能會發生兼容性問題，同一個應用可能在某些作業系統下能正常運行，但在另外的作業系統下可能會運行失敗，因此，在Web系統發布之前，需要在各種作業系統下對Web系統進行兼容性測驗，

5. 安全性測驗，

• 現在的Web應用系統基本采用先注冊，后登陸的方式，因此，必須測驗有效和無效的用戶名和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等，

• Web應用系統是否有超時的限制，也就是說，用戶登陸后在一定時間內（例如15分鐘）沒有點擊任何頁面，是否需要重新登陸才能正常使用，

• 為了保證Web應用系統的安全性，日志檔案是至關重要的，需要測驗相關資訊是否寫進了日志檔案、是否可追蹤，

• 當使用了安全套接字時，還要測驗加密是否正確，檢查資訊的完整性，

• 服務器端的腳本常常構成安全漏洞，這些漏洞又常常被黑客利用，所以，還要測驗沒有經過授權，就不能在服務器端放置和編輯腳本的問題，

23.請問測驗路由器怎么測，用命令列還是界面？

參考回答：
可以采用lperf這個命令，
Lperf是一個網路性能測驗工具，可以測量最大tcp和udp帶寬，具有多種引數和特性，可以記錄帶寬，延遲抖動，資料包丟失，通過這些資訊可以發現網路問題，檢查網路質量，定位網路瓶頸，

iperf的使用非常簡單，測驗的原理是在wan口連接一臺PC機，在LAN口連接一臺PC，兩邊分別運行iperf服務端和客戶端模式，用來測量LAN->WAN和WAN->LAN性能，具體命令如下：

服務端：iperf -s -w 1m
客戶端：iperf -c -w 1m -t 20 -P 10

含義是TCP wndowsize 為1MByte，測驗時間是20s，執行緒是10，

24.請你回答一下如何測驗手機開機鍵？

參考回答：

• 功能測驗：
  按下開機鍵，螢屏能否亮起

• 性能測驗：
  按下開機鍵，螢屏能否在規定時間內亮起

• 壓力測驗

連續多次按下開機鍵，觀察螢屏是否能一直亮起，到多久時間失靈

• 健壯性測驗
  給定一個中了病毒的手機或者是淘汰許久的老機子，安歇開機鍵觀察螢屏能否亮起

• 可靠性測驗
  連續按下開機鍵有限次數，比如1萬次，記錄螢屏未亮起的次數

• 可用性測驗
  開機鍵按下費不費力，開機鍵的形狀設計是否貼合手指，開機鍵的位置設計是否方便

25.請問你遇到過哪些印象深刻的bug，介面測驗出現bug的原因有哪些？

參考回答：
面試官詢問遇到過哪些印象深刻的bug，其實它并不關心你描述的這個bug是否真的有價值，或有多曲折離奇？他只是：了解你平時作業中的測驗能力
所以，這就要求的你平時作業中遇到bug時試著自己去定位，定位bug的程序遠比你的單純的執行測驗用例有“價值”（自我技能提高的價值），在定位bug的程序中你需要掌握和運用更多知識，

另外，建議你平時養成總結的好習慣，發現的bug，開發解決了，最好問問他原因以及解決的方法，這樣再遇到類似問題時，自己也可以試著定位解決，遇到難解決的bug，也可以把最終的解決程序記錄下來，（這不是就有素材了）

所以，建議你平時可以主動要求去分享一些自己作業中用到或學習的技術，或者多去參加集體活動，加強自己的表達能力，From:蟲師

介面測驗常見的bug有以下幾個:

1. 特殊值處理不當導致程式例外退出或者崩潰

2. 型別邊界溢位，導致資料獨處和寫入不一致

3. 取值邊界外未回傳正確的錯誤資訊

4. 權限未處理，可以訪問其他用戶的資訊

5. 邏輯校驗不完善，可以利用漏洞獲取非正當利益

6. 狀態處理不當，導致邏輯出現錯誤

7. 陣列型別item個數為0或者item重復時程式例外退出

26.你在做專案中有做過壓力測驗嗎，怎么做

參考回答：

1. 首先對要測驗的系統進行分析，明確需要對那一部分做壓力測驗，比如秒殺，支付

2. 如何對這些測驗點進行施壓
   第一種方式可以通過寫腳本產生壓力機器人對服務器進行發包收報操作
   第二點借助一些壓力測驗工具比如Jmeter,LoadRunner

3. 如何對這些測驗點進行正確的施壓
   需要用壓力測驗工具或者其他方法錄制腳本，模擬用戶的操作

4. 對測驗點設計多大的壓力比較合適？
   需要明確壓力測驗限制的數量，即用戶并發量

5. 測驗結束后如何通過這些資料來定位性能問題
   通過測驗可以得到吞吐量，平均回應時間等資料，這個資料的背后是整個后臺處理邏輯綜合作用的結果，這時候就可以先關注系統的CPU，記憶體，然后對比吞吐量，平均回應時間達到瓶頸時這些資料的情況，然后就能確認性能問題是系統的哪一塊造成的

27.請問你在專案中關于功能測驗和介面測驗是怎么做的

1. 功能測驗：
   首先制定測驗計劃，然后進行測驗設計，將在測驗計劃階段指定的測驗活動分解，進而細化，為若干個可執行程式的子測驗程序，然后執行測驗，按照測驗計劃使用測驗用例對待測專案進行逐一的，詳細的排查分析評估，最后對測驗結果進行統計和分析，

2. 介面測驗：

• 什么是介面（API）
  API全稱Application Programming Interface，這里面我們其實不用去關注AP，只需要I上就可以，一個API就是一個Interface，我們無時不刻不在使用interfaces，我們乘坐電梯里面的按鈕是一個interface，我們開車一個踩油門它也是一個interface，我們計算機作業系統也是有很多的介面，(這是目前個人找到比較好理解的一段解釋)
  介面就是一個位于復雜系統之上并且能簡化你的任務，它就像一個中間人讓你不需要了解詳細的所有細節，那我們今天要講的Web API就是這么一類東西，像谷歌搜索系統，它提供了搜索介面，簡化了你的搜索任務，再像用戶登錄頁面，我們只需要呼叫我們的登錄介面，我們就可以達到登錄系統的目的，
  現在市面上有非常多種風格的Web API，目前最流行的是也容易訪問的一種風格是REST或者叫RESTful 風格的API，從現在開始，以下我提到的所有API都是指RESTful風格的API，

• 什么是介面測驗和為什么要做介面測驗
  介面測驗是測驗系統組件間介面的一種測驗，介面測驗主要用于檢測外部系統與系統之間以及內部各個子系統之間的互動點，測驗的重點是要檢查資料的交換，傳遞和控制管理程序，以及系統間的相互邏輯依賴關系等，
  現在很多系統前后端架構是分離的，從安全層面來說，只依賴前端進行限制已經完全不能滿足系統的安全要求（繞過前端太容易了），需要后端同樣進行控制，在這種情況下就需要從介面層面進行驗證，
  如今系統越來越復雜，傳統的靠前端測驗已經大大降低了效率，而且現在我們都推崇測驗前移，希望測驗能更早的介入測驗，那介面測驗就是一種及早介入的方式，例如傳統測驗，你是不是得等前后端都完成你才能進行測驗，才能進行自動化代碼撰寫，而如果是介面測驗，只需要前后端定義好介面，那這時自動化就可以介入撰寫介面自動化測驗代碼，手工測驗只需要后端代碼完成就可以介入測驗后端邏輯而不用等待前端作業完成，

• 介面測驗的策略
  介面測驗也是屬于功能測驗，所以跟我們以往的功能測驗流程并沒有太大區別，測驗流程依舊是：

1. 測驗介面檔案（需求檔案）
2. 根據介面檔案撰寫測驗用例（用例撰寫完全可以按照以往規則來撰寫，例如等價類劃分，邊界值等設計方法）
3. 執行測驗，查看不同的引數請求，介面的回傳的資料是否達到預期，

28.請問你有用過什么測驗工具嗎，用過哪些？

參考回答：
自動化測驗工具用過selenium和appium
性能測驗工具有用過Jmeter

29.請你設計一個微信朋友圈點贊的測驗用例

參考回答：

• 功能測驗：
  點贊某條朋友圈，驗證是否成功

• 介面測驗：
  點贊朋友圈，驗證朋友能否收到提示資訊

• 性能測驗
  點贊朋友圈，是否在規定時間顯示結果，是否在規定時間在朋友手機上進行提示

• 兼容性測驗
  在不同的終端比如ipad,手機上點贊朋友圈，驗證是否成功

30.請問如果用戶點擊微博的關注圖示但是app上面沒有反應，應該怎么排查這個問題

參考回答：

1. 在Eclipse Devices視窗，選中app對應的包名，然后點擊debug圖示（綠色的小蟲子），然后切換到Debug視圖，

2. 切換視圖之后，可以看到debug下，app的執行緒串列，

3. 對于main執行緒（第一個執行緒），選中，并將其掛起Suspend，

4. 然后我們就可以看到，Suspend之后，main執行緒卡住的位置，

31.在做測驗的程序中，假如前端和后端吵起來了都在踢皮球覺得對方該改代碼，你怎么辦？

參考回答：
此時就應該找技術領導拍板或leader們基于安全性、性能、可測驗性、可維護性討論敲定一個解決方案，做到開發環境方便開發，線上環境少配置
少依賴、少出錯機會，

32.如果廣東用戶頭條app刷不出東西了，你應該怎么排查問題

參考回答：

1. 檢查網路連接是否穩定，更換網路嘗試

2. 更新頭條版本嘗試

3. 清除app快取，應用資料

33.請你說一下能不能用機器學習去進行自動化測驗，如何監控例外流量，如果是脈沖呢，如何和正常流量作區分

參考回答：
如何用機器學習去進行自動化測驗，就是讓自動化測驗變得更加智能，在自動化測驗程序中，當測驗功能模塊越來越多，沒有太多的時間去全部覆寫，我們可以采用歸納學習的方式，基于自動化測驗的執行結果或者手工測驗執行的結果為資料輸入，然后基于一定的模型（例如：以通過率和模塊的重要率計算的平均值）得出測驗推薦模塊，或者當要執行一個功能模塊時，基于歷史資料和模型（bug出現的錯誤相關性，功能相關性等）計算出與該功能模塊相關性最大模塊，并推薦測驗，

如何監控例外流量:

1. 抓包
   tcpdump -i eth0 -w server.cap
   對包檔案使用第三方工具如：wireshark做分析

2. iftop
   yum install iftop

3. iptraf
   yum install iptraf –y 或 yum install iptraf-ng -y
   啟動命令ifptraf-ng

34. 請問如何對登錄界面進行測驗

參考回答：

1. 黑盒測驗方法

• 輸入正確用戶名和密碼，驗證是否登陸成功
• 輸入正確的用戶名和錯誤的密碼，驗證是否登陸失敗并且提示資訊正確
• 輸入未注冊的用戶名和任意的密碼，驗證是否登陸失敗并且提示資訊正確
• 用戶名和密碼都為空，驗證是否登陸失敗并且提示資訊正確
• 用戶名和密碼兩者之一為空
• 若啟用了驗證碼，輸入正確的用戶名密碼驗證碼是否能登陸成功
• 輸入正確用戶名和密碼，錯誤的驗證碼，能否登陸成功并且提示資訊正確
• 用戶名和密碼是否大小寫敏感
• 頁面上的密碼框是否加密顯示
• 后臺系統第一次創建的用戶重新登錄時是否提示修改密碼
• 忘記用戶名和忘記密碼的功能是否可用
• 前段功能是否根據要求限制用戶名和密碼的長度
• 點擊驗證碼圖片是否可以更換驗證碼，更換后的驗證碼是否可用
• 重繪頁面是否會重繪驗證碼
• 如果驗證碼具有時效性，分別驗證時效內和時效外驗證碼的有效性
• 用戶登錄成功但是會話超時后是否重定向到用戶登錄界面
• 不同級別的用戶登錄系統后的權限是否正確
• 頁面默認定位焦點是否定位到用戶名輸入框中
• 快捷鍵tab和回車鍵是否可以正常使用

非功能性需求，從安全，性能，兼容三個方面

2. 安全：

• 用戶密碼后臺存盤是否加密

• 用戶密碼在網路傳輸程序中是否加密

• 密碼是否具有有效期，密碼有效期到期后是否提示修改密碼

• 不登陸的時候直接在瀏覽框中輸入登錄界面后的url地址，是否會重新定位到登陸界面

• 密碼輸入框是否不支持復制粘貼

• 頁面密碼輸入框中輸入的密碼是否可以在頁面原始碼模式下被查看

• 用戶名和密碼輸入框中輸入xss跨站腳本攻擊字串驗證系統的行為是否被篡改

• 連續多次登陸失敗后系統是否會阻止用戶后續的嘗試

• 統一用戶在同一終端的多種不同瀏覽器上登陸，驗證登錄功能的互斥性是否符合設計預期

• 同一用戶先后在不同終端的瀏覽器上登陸用戶名和密碼輸入框中輸入典型的sql注入攻擊字串驗證系統的回傳頁面

• 驗證登陸是否有互斥性

3. 性能測驗：

• 單用戶登陸的回應界面是否符合預期

• 單用戶登陸時后臺請求數量是否過多

• 高并發場景下用戶登錄的回應界面是否符合預期

• 高并發場景下服務端的監控指標是否符合預期

• 高集合點并發場景下是否存在資源死鎖和不合理的資源等待

• 長時間大量用戶連續登錄和登出，服務器端是否存在記憶體泄漏

4.兼容性測驗：

• 不同瀏覽器下驗證登陸功能的頁面顯示和功能正確性

• 相同瀏覽器的不同版本下驗證登陸功能的頁面顯示和功能正確性

• 不同終端的不同瀏覽器下驗證登陸功能的頁面顯示和功能正確性

• 不同解析度下……

5. 弱網測驗

• 網路切換和網路延遲時登陸界面是否正常

• 是否支持第三方登陸

• 是否可記住密碼，記住的密碼是否加密

35.請你說一說當前作業中涉及的測驗問題(測驗流程和測驗性能)

參考回答：
在測驗性能中，時常會出現腳本回訪卡住的問題，原因有以下幾種：

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瀏覽器）
   解決辦法：注釋掉或者洗掉掉該段代碼即可， 關聯問題：在用loadrunner自帶對比工具對比腳本后 找到需要關聯的動態值，在關聯后回放腳本時報錯HTTP-status code 417（exception failed）錯誤時

產生的原因如下：

1. 腳本中還存在沒有關聯或者關聯失敗的動態值，利用lr自帶對比工具仔細對比
2. 腳本中的動態值被做了加密策略，仔細查看腳本中動態值的部分，看看動態值是否被做了安全策略（隨機生成或者打亂動態值順序、在動態值中加入了特殊符號），由于在tree-response中的動態值是未被加密的狀態，在client向server發送請求時，client的動態值發給服務器，這時服務器的動態值已經被做了引數化，所以服務器不認準client向服務器發送的動態值，

解決辦法：去掉動態值的安全策略即可（JVM引數）

36. 請你說一說洗牌問題的思路并手寫代碼，并設計測驗用例

參考回答：
洗牌問題：有個長度為2n的陣列{a1,a2,a3,…,an,b1,b2,b3,…,bn}，希望排序后{a1,b1,a2,b2,….,an,bn}，請考慮有無時間復雜度o(n)，空間復雜度0(1)的解法，

void 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型的，浮點型的，還可以是大數型別，負數，進行測驗，

37.請你測驗一下游戲中英雄的技能

參考回答：
測驗的設計都是通用的，首先功能測驗看功能有沒有實作，然后再對性能、壓力、容量、健壯性、安全性、可靠性、恢復性、備份、協議、兼容性、可用性、配置、GUI這些非功能測驗去思考，具體答案這里不再贅述

38.請你回答一下性能測驗有哪些指標，對一個登錄功能做性能測驗，有哪些指標，怎么測出可同時處理的最大請求數量

參考回答：
性能測驗常用指標：
從外部看，主要有

1. 吞吐量：每秒鐘系統能夠處理的請求數，任務數

2. 回應時間：服務處理一個請求或一個任務的耗時

3. 錯誤率：一批請求中結果出錯的請求所占比例

從服務器的角度看
性能測驗關注CPU，記憶體，服務器負載，網路，磁盤ＩＯ

• 對登錄功能做性能測驗

• 單用戶登陸的回應界面是否符合預期

• 單用戶登陸時后臺請求數量是否過多

• 高并發場景下用戶登錄的回應界面是否符合預期

• 高并發場景下服務端的監控指標是否符合預期

• 高集合點并發場景下是否存在資源死鎖和不合理的資源等待

• 長時間大量用戶連續登錄和登出，服務器端是否存在記憶體泄漏

• 怎么測出可同時處理的最大請求數量

• 可以采用性能測驗工具(WeTest服務器性能)，該工具是騰訊wetest團隊出品，使用起來很簡單方便，但測驗功能相當強大，能提供10w+以上的并發量，定位性能拐點，測出服務器模型最大并發

39.請問你有沒有做過什么單元測驗，怎么進行單元測驗，對一個沒有引數沒有回傳值但可能對全域變數有影響的怎么進行單元測驗

參考回答：
如何進行單元測驗：
創建單元測驗，該工具可以對任何類、介面、結構等物體中的欄位、屬性、建構式、方法等進行單元測驗，創建單元測驗大致可以分為兩類：
第一類整體測驗，整體測驗是在類名稱上右擊滑鼠，在下拉選單中點擊創建單元測驗選項，這樣就可以為整個類創建單元測驗了，這時他會為整個類可以被測驗的內容全部添加測驗方法，開發人員直接在這些自動生成的測驗方法中添加單元測驗代碼就可以了，

第二類單獨測驗，如果只想單獨對某個方法、屬性、欄位進行測驗，則可以將滑鼠焦點放在這個待測驗的專案名稱之上，然后點擊滑鼠右鍵，在右鍵選單中選擇創建單元測驗選項，這樣就可以單獨為某個方法創建單元測驗了，

運行單元測驗

查看測驗結果

撰寫單元測驗代碼

測驗沒有引數的函式，它可能還有別的輸入，例如全域變數，成員變數，或呼叫子函式獲得的輸入（這個要使用工具才能做到），只要函式需讀取的，都應該設定初始值，如果完全沒有，沒有輸入也是一種輸入，照樣測驗就是了，同樣道理，輸出也不僅僅是回傳值，沒有回傳值還可能修改了全域變數什么的，這些也是要判斷的輸出，

40.請問你有沒有做過壓力測驗

參考回答：
在軟體工程中，壓力測驗是對系統不斷施加壓力的測驗，是通過確定一個系統的瓶頸或者不能接收的性能點，來獲得系統能提供的最大服務級別的測驗，例如測驗一個Web 站點在大量的負荷下，何時系統的回應會退化或失敗，

41. 對于有系統大量并發訪問，你會如何做測驗，有什么建議

參考回答：
如何做高并發系統的測驗，一般而言，整體的測驗策略是：先針對部分系統進行性能測驗及壓力測驗，得到各部分的峰值處理性能，再模擬整體流程測驗，重點測驗整體業務流程以及業務預期負荷，著重測驗以下幾點：

1. 不同省份，不同運營商CDN節點性能，可采用典型壓力測驗方案

2. 核心機房BGP網路帶寬，此部分重點在于測驗各運行商的BGP網路可靠性，實際速率，一般采用smokeping,lxChariot等工具

3. 各類硬體設備性能，一般采用專業的網路設備測驗工具

4. 各類服務器并發性能，分布式處理能力，可采用壓力測驗方案工具

5. 業務系統性能，采用業務系統壓力測驗方案

6. 資料庫處理性能，這部分需要結合業務系統進行測驗，以獲取核心業務場景下的資料庫的TPS/QPS，

7. 如果有支付功能，需要進行支付渠道介面及分流測驗，此部分相對而言可能是最大的瓶頸所在，此外還涉及備份方案，容災方案，業務降級方案的測驗，