● 給你一個字符串，你怎麼判斷是不是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;
}
方法二：正則表達式
複製代碼
1 2 3 4 5 |
|
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 |
有效不可用，迴環地址 |
● 請進行測試用例設計：一串數字，閏年的判別
參考回答：
判斷閏年的標準是:能整除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 |
請輸入正確的年份 |
● 請你說一說簡單用戶界面登陸過程都需要做哪些分析
參考回答：
一、功能測試
1.輸入正確的用戶名和密碼，點擊提交按鈕，驗證是否能正確登錄。
2.輸入錯誤的用戶名或者密碼,驗證登錄會失敗，並且提示相應的錯誤信息。
3.登錄成功後能否能否跳轉到正確的頁面
4.用戶名和密碼，如果太短或者太長，應該怎麼處理
5.用戶名和密碼，中有特殊字符（比如空格），和其他非英文的情況
6.記住用戶名的功能
7.登陸失敗後，不能記錄密碼的功能
8.用戶名和密碼前後有空格的處理
9.密碼是否非明文顯示顯示，使用星號圓點等符號代替。
10.牽扯到驗證碼的，還要考慮文字是否扭曲過度導致辨認難度大，考慮顏色（色盲使 用者），刷新或換一個按鈕是否好用
11.登錄頁面中的註冊、忘記密碼，登出用另一帳號登陸等鏈接是否正確
12.輸入密碼的時候，大寫鍵盤開啓的時候要有提示信息。
13.什麼都不輸入，點擊提交按鈕，檢查提示信息。
二、界面測試
1.佈局是否合理，testbox和按鈕是否整齊。
2.testbox和按鈕的長度，高度是否複合要求。
3. 界面的設計風格是否與UI的設計風格統一。
4. 界面中的文字簡潔易懂，沒有錯別字。
三、性能測試
1.打開登錄頁面，需要的時間是否在需求要求的時間內。
2.輸入正確的用戶名和密碼後，檢查登錄成功跳轉到新頁面的時間是否在需求要求的時間內。
3.模擬大量用戶同時登陸，檢查一定壓力下能否正常登陸跳轉。
四、安全性測試
1.登錄成功後生成的Cookie，是否是httponly (否則容易被腳本盜取)。
2.用戶名和密碼是否通過加密的方式，發送給Web服務器。
3.用戶名和密碼的驗證，應該是用服務器端驗證， 而不能單單是在客戶端用javascript 驗證。
4.用戶名和密碼的輸入框，應該屏蔽SQL注入***。
5.用戶名和密碼的的輸入框，應該禁止輸入腳本 （防止XSS***）。
6.防止暴力破解，檢測是否有錯誤登陸的次數限制。
7. 是否支持多用戶在同一機器上登錄。
8. 同一用戶能否在多臺機器上登錄。
五、可用性測試
1. 是否可以全用鍵盤操作，是否有快捷鍵。
2. 輸入用戶名，密碼後按回車，是否可以登陸。
3. 輸入框能否可以以Tab鍵切換。
六、兼容性測試
1.不同瀏覽器下能否顯示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）。
2.同種瀏覽器不同版本下能否顯示正常且功能正常。
2.不同的平臺是否能正常工作，比如Windows, Mac。
3.移動設備上是否正常工作，比如Iphone, Andriod。
4.不同的分辨率下顯示是否正常。
七、本地化測試
1. 不同語言環境下，頁面的顯示是否正確。
● 請對這個系統做出測試用例：一個系統，多個攝像頭，抓拍車牌，識別車牌，上傳網上，網上展示
參考回答：
功能：
1.每個攝像頭都能抓拍車牌；
2.每個攝像頭抓拍到的車牌能正常交給系統處理；
3.系統能夠正確識別車牌；
4.系統能夠將識別出的車牌上傳；
5.上傳至網絡的車牌能夠正常展示出來；
一、功能測試
1.使用正常的車牌，保持車牌靜止，檢查每個攝像頭是否能抓拍車牌；
2.使用類似非車牌的寫有字的紙板，檢查每個攝像頭是否抓拍；
3.使用正常的車牌，保持車牌較高速移動，檢查每個攝像頭是否能抓拍車牌；
4.在多種情況下檢查每個攝像頭抓拍到的車牌能否正常交給系統處理，如臨時斷電、斷網後能否正常將數據交給系統；
5.使用抓拍到的正常的車牌，交由系統處理，檢查系統能否識別車牌；
6.使用非車牌的其他圖片，交由系統處理，檢查系統能否識別；
7.在多種情況下檢查系統能否將正常識別出的車牌進行上傳，如臨時斷電、斷網後未上傳數據是否能繼續上傳；
8.構造非車牌的其他內容的數據，檢查系統能否將異常內容進行上傳；
9.檢查上傳至網絡的車牌能否正常展示出來；
10.上傳非車牌的其他內容的數據，檢查能否正常顯示出來。
二、性能測試
1.同時向一個攝像頭展示多個靜止的車牌，檢查攝像頭能否抓拍到多個車牌；
2.同時向一個攝像頭展示多個較高速運動的車牌，檢查攝像頭能否抓拍到多個車牌；
3.抓拍後，檢查系統識別車牌的時間是否在需求要求的時間內；
4.模擬大量抓拍照片同時交由系統處理，檢查一定壓力下系統能否正常識別車牌；
5.模擬大量車牌同時上傳，檢查一定壓力下能否上傳成功。
三、安全性測試
1.檢查是否能夠通過給車牌加裝飾物等方法，使攝像頭無法抓拍或抓拍後系統無法正常識別車牌。
● 請你對喫雞遊戲進行壓力測試
參考回答：
一.首先明確需要測試壓力的內容:
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現在已經是一個可以接受的代價。遊戲進程需要進行不同網卡的配置和綁定。確定內外網流量。
● 請你根據微信登錄界面設計測試用例
參考回答：
一、功能測試
1.輸入正確的用戶名和密碼，點擊提交按鈕，驗證是否能正確登錄。
2.輸入錯誤的用戶名或者密碼,驗證登錄會失敗，並且提示相應的錯誤信息。
3.登錄成功後能否能否跳轉到正確的頁面
4.檢查能否選擇不同登錄方式進行登錄，如使用手機號登錄、使用微信號登錄或掃碼登錄。
5.記住用戶名的功能
6.登陸失敗後，不能記錄密碼的功能
7.密碼是否非明文顯示顯示，使用星號圓點等符號代替。
8.有驗證碼時，還要考慮文字是否扭曲過度導致辨認難度大，考慮顏色、刷新或換一個按鈕是否好用
9.登錄頁面中的註冊、忘記密碼，登出用另一帳號登陸等鏈接是否正確
10.輸入密碼的時候，大寫鍵盤開啓的時候要有提示信息。
11.什麼都不輸入，點擊提交按鈕，檢查提示信息。
二、界面測試
1.佈局是否合理，testbox和按鈕是否整齊。
2.testbox和按鈕的長度，高度是否複合要求。
3. 界面的設計風格是否與UI的設計風格統一。
4. 界面中的文字簡潔易懂，沒有錯別字。
三、性能測試
1.打開登錄頁面，需要的時間是否在需求要求的時間內。
2.輸入正確的用戶名和密碼後，檢查登錄成功跳轉到新頁面的時間是否在需求要求的時間內。
3.模擬大量用戶同時登陸，檢查一定壓力下能否正常登陸跳轉。
四、安全性測試
1.登錄成功後生成的Cookie，是否是httponly (否則容易被腳本盜取)。
2.用戶名和密碼是否通過加密的方式，發送給Web服務器。
3.用戶名和密碼的驗證，應該是用服務器端驗證， 而不能單單是在客戶端用javascript 驗證。
4.用戶名和密碼的輸入框，應該屏蔽SQL注入***。
5.用戶名和密碼的的輸入框，應該禁止輸入腳本 （防止XSS***）。
6.防止暴力破解，檢測是否有錯誤登陸的次數限制。
7. 是否支持多用戶在同一機器上登錄。
8. 同一用戶能否在多臺機器上登錄。
五、兼容性測試
1.不同移動平臺或PC環境下下能否顯示正常且功能正常
2.同種平臺下不同微信版本下能否顯示正常且功能正常。
3.不同的分辨率下顯示是否正常。
七、本地化測試
1. 不同語言環境下，頁面的顯示是否正確。
● 請你對朋友圈點贊功能進行測試
參考回答：
1.是否可以正常點贊和取消；
2.點讚的人是否在可見分組裏；
3.點贊狀態是否能即時更新顯示；
4.點贊狀態，共同好友是否可見；
6.性能檢測，網速快慢對其影響；
7.點贊顯示的是否正確，一行幾個；
8.點贊是否按時間進行排序，頭像對應的是否正確；
9.是否能在消息列表中顯示點贊人的暱稱、5.不同手機，系統顯示界面如何；
備註；
10.可擴展性測試，點贊後是否能發表評論；
11.是否在未登錄時可查看被點讚的信息。
● 如果做一個杯子的檢測，你如何測試
參考回答：
1.功能
（1）水倒水杯容量的一半
（2）水倒規定的安全線
（4）水杯容量刻度與其他水杯一致
（5）蓋子擰緊水倒不出來
（6）燙手驗證
2.性能
（1）使用最大次數或時間
（2）掉地上不易損壞
（3）蓋子擰到什麼程度水倒不出來
（4）保溫時間長
（5）杯子的耐熱性
（6）杯子的耐寒性
（7）長時間放置水不會漏
（8）杯子上放置重物達到什麼程度杯子會被損壞
3.界面
（1）外觀完整、美觀
（2）大小與設計一樣（高、寬、容量、直徑）
（3）拿着舒服
（4）材質與設計一樣
（5）杯子上的圖案掉落
（6）圖案遇水溶解
4.安全
（1）杯子使用的材質毒或細菌的驗證
（2）高溫材質釋放毒性
（3）低溫材質釋放毒性
5.易用性
（1）倒水方便
（2）喝水方便
（3）攜帶方便
（4）使用簡單，容易操作
（5）防滑措施
6.兼容性
（1）杯子能夠容納果汁、白水、酒精、汽油等。
7.震動測試
（1）杯子加包裝（有填充物），六面震動，檢查產品是否能應對鐵路/公路/航空運輸。
8.可移植性
（1）杯子在不同地方、溫度環境下都可以正常使用。
● 如何對一個頁面進行測試
參考回答：
1、UI測試：頁面佈局、頁面樣式檢查、控件長度是否夠長；顯示時，是否會被截斷；支持的快捷鍵，Tab鍵切換焦點順序正確性等。
2、功能測試：頁面上各類控件的測試範圍，測試點。結合控件的實際作用來補充檢查點：比如， 密碼框是否*顯示， 輸入是否做trim處理等。
3、安全測試：輸入特殊字符，sql注入，腳本注入測試。後臺驗證測試，對於較重要的表單 ，繞過js檢驗後臺是否驗證；數據傳輸是否加密處理，比如， 直接請求轉發，地址欄直接顯示發送字符串？
4、兼容性測試
5、性能測試
● 如何對水壺進行測試
參考回答：
（同快手對水杯的測試）
1.功能
（1）水倒水壺容量的一半
（2）水倒規定的安全線
（4）水壺容量刻度與其他水壺一致
（5）蓋子擰緊水倒不出來
（6）燙手驗證
2.性能
（1）使用最大次數或時間
（2）掉地上不易損壞
（3）蓋子擰到什麼程度水倒不出來
（4）保溫時間長
（5）壺的耐熱性
（6）壺的耐寒性
（7）長時間放置水不會漏
（8）壺上放置重物達到什麼程度壺會被損壞
3.界面
（1）外觀完整、美觀
（2）大小與設計一樣（高、寬、容量、直徑）
（3）拿着舒服
（4）材質與設計一樣
（5）壺上的圖案掉落
（6）圖案遇水溶解
4.安全
（1）壺使用的材質毒或細菌的驗證
（2）高溫材質釋放毒性
（3）低溫材質釋放毒性
5.易用性
（1）倒水方便
（2）喝水方便
（3）攜帶方便
（4）使用簡單，容易操作
（5）防滑措施
6.兼容性
（1）壺能夠容納果汁、白水、酒精、汽油等。
7.震動測試
（1）壺加包裝（有填充物），六面震動，檢查產品是否能應對鐵路/公路/航空運輸。
8.可移植性
（1）壺在不同地方、溫度環境下都可以正常使用。
● 如何對淘寶搜索框進行測試
參考回答：
一, 功能測試
1. 輸入關鍵字，查看: 返回結果是否準確，返回的文本長度需限制
1.1輸入可查到結果的正常關鍵字、詞、語句，檢索到的內容、鏈接正確性；
1.2輸入不可查到結果的關鍵字、詞、語句；
1.3輸入一些特殊的內容，如空、特殊符、標點符、極限值等，可引入等價類劃分的方法等；
2. 結果顯示：標題，賣家，銷售量，單行/多行，是否有圖片
3. 結果排序：價格 銷量 評價 綜合
4.返回結果龐大時，限制第一頁的現實量，需支持翻頁
5. 多選項搜索：關鍵字 品牌 產地 價格區間 是否天貓 是否全國購
6. 是否支持模糊搜索，支持通配符的查詢
7, 網速慢的情況下的搜索
8. 搜索結果爲空的情況
9. 未登錄情況和登錄情況下的搜索（登錄情況下 存儲用戶搜索的關鍵字/搜索習慣）
二.性能測試：
1壓力測試：在不同發用戶數壓力下的表現（評價指標如響應時間等）
2負載測試：看極限能承載多大的用戶量同時正常使用
3穩定性測試：常規壓力下能保持多久持續穩定運行
4內存測試：有無內存泄漏現象
5大數據量測試：如模擬從龐大的海量數據中搜索結果、或搜索出海量的結果後列示出來，看錶現如何等等。
三. 易用性：交互界面的設計是否便於、易於使用
1依據不同的查詢結果會有相關的人性化提示，查不到時告知？查到時統計條數並告知？有疑似輸入條件錯誤時提示可能正確的輸入項等等處理；
2查詢出的結果羅列有序，如按點擊率或其他排序規則，確保每次查詢出的結果位置按規則列示方便定位，顯示字體、字號、色彩便於識別等等；
3標題查詢、全文檢索、模糊查詢、容錯查詢、多關鍵字組織查詢（空格間格開）等實用的檢索方式是否正常？
4輸入搜索條件的控件風格設計、位置擺放是否醒目便於使用者注意到，有否快照等快捷查看方式等人性化設計？
四. 兼容性
1WINDOWS/LINUX/UNIX等各類操作系統下及各版本條件下的應用
2IE/FIREFOX/GOOGLE/360/QQ等各類瀏覽器下及各版本條件下、各種顯示分辨率條件下的應用
3SQL/ORACLE/DB2/MYSQL等各類數據庫存儲情況下的兼容性測試
4簡體中文、繁體中文、英文等各類語種軟件平臺下的兼容性測試
5IPHONE/IPAD、安卓等各類移動應用平臺下的兼容性測試
6與各相關的監控程序的兼容性測試，如輸入法、殺毒、監控、防火牆等工具同時使用
五. 安全性
1被刪除、加密、授權的數據，不允許被SQL注入等***方式查出來的，是否有安全控制設計；
2錄入一些數據庫查詢的保留字符，如單引號、%等等，造成查詢SQL拼接出的語句產生漏洞，如可以查出所有數據等等，這方面要有一些******的思想並引入一些工具和技術，如爬網等。
3通過白盒測試技術，檢查一下在程序設計上是否存在安全方面的隱患；
4對涉及國家安全、法律禁止的內容是否進行了相關的過濾和控制；
● 如何對一瓶礦泉水進行測試
參考回答：
界面測試:查看外觀是否美觀
功能度：查看水瓶漏不漏；瓶中水能不能被喝到
安全性：瓶子的材質有沒有毒或細菌
可靠性：從不同高度落下的損壞程度
可移植性：再不同的地方、溫度等環境下是否都可以正常使用
兼容性：是否能夠容納果汁、白水、酒精、汽油等
易用性：是否燙手、是否有防滑措施、是否方便飲用
用戶文檔：使用手冊是否對的用法、限制、使用條件等有詳細描述
疲勞測試：將盛上水（案例一）放24小時檢查泄漏時間和情況；盛上汽油（案例二）放24小時檢查泄漏時間和情況等
壓力測試：用根針並在針上面不斷加重量，看壓強多大時會穿透
跌落測試:測試在何種高度跌落會破壞水瓶
● 如何測試登陸界面
參考回答：
一、功能測試
1.輸入正確的用戶名和密碼，點擊提交按鈕，驗證是否能正確登錄。
2.輸入錯誤的用戶名或者密碼,驗證登錄會失敗，並且提示相應的錯誤信息。
3.登錄成功後能否能否跳轉到正確的頁面
4.用戶名和密碼，如果太短或者太長，應該怎麼處理
5.用戶名和密碼，中有特殊字符（比如空格），和其他非英文的情況
6.記住用戶名的功能
7.登陸失敗後，不能記錄密碼的功能
8.用戶名和密碼前後有空格的處理
9.密碼是否非明文顯示顯示，使用星號圓點等符號代替。
10.牽扯到驗證碼的，還要考慮文字是否扭曲過度導致辨認難度大，考慮顏色（色盲使 用者），刷新或換一個按鈕是否好用
11.登錄頁面中的註冊、忘記密碼，登出用另一帳號登陸等鏈接是否正確
12.輸入密碼的時候，大寫鍵盤開啓的時候要有提示信息。
13.什麼都不輸入，點擊提交按鈕，檢查提示信息。
二、界面測試
1.佈局是否合理，testbox和按鈕是否整齊。
2.testbox和按鈕的長度，高度是否複合要求。
3. 界面的設計風格是否與UI的設計風格統一。
4. 界面中的文字簡潔易懂，沒有錯別字。
三、性能測試
1.打開登錄頁面，需要的時間是否在需求要求的時間內。
2.輸入正確的用戶名和密碼後，檢查登錄成功跳轉到新頁面的時間是否在需求要求的時間內。
3.模擬大量用戶同時登陸，檢查一定壓力下能否正常登陸跳轉。
四、安全性測試
1.登錄成功後生成的Cookie，是否是httponly (否則容易被腳本盜取)。
2.用戶名和密碼是否通過加密的方式，發送給Web服務器。
3.用戶名和密碼的驗證，應該是用服務器端驗證， 而不能單單是在客戶端用javascript 驗證。
4.用戶名和密碼的輸入框，應該屏蔽SQL注入***。
5.用戶名和密碼的的輸入框，應該禁止輸入腳本 （防止XSS***）。
6.防止暴力破解，檢測是否有錯誤登陸的次數限制。
7. 是否支持多用戶在同一機器上登錄。
8. 同一用戶能否在多臺機器上登錄。
五、可用性測試
1. 是否可以全用鍵盤操作，是否有快捷鍵。
2. 輸入用戶名，密碼後按回車，是否可以登陸。
3. 輸入框能否可以以Tab鍵切換。
六、兼容性測試
1.不同瀏覽器下能否顯示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）。
2.同種瀏覽器不同版本下能否顯示正常且功能正常。
2.不同的平臺是否能正常工作，比如Windows, Mac。
3.移動設備上是否正常工作，比如Iphone, Andriod。
4.不同的分辨率下顯示是否正常。
七、本地化測試
1. 不同語言環境下，頁面的顯示是否正確。
● 請你說一下jmeter
參考回答：
Jmeter：Apache JMeter是Apache組織開發的基於Java的壓力測試工具。用於對軟件做壓力測試，它最初被設計用於Web應用測試，但後來擴展到其他測試領域。它可以用於測試靜態和動態資源，例如靜態文件、Java 小服務程序、CGI 腳本、Java 對象、數據庫、FTP 服務器， 等等。JMeter 可以用於對服務器、網絡或對象模擬巨大的負載，來自不同壓力類別下測試它們的強度和分析整體性能。另外，JMeter能夠對應用程序做功能/迴歸測試，通過創建帶有斷言的腳本來驗證你的程序返回了你期望的結果。爲了最大限度的靈活性，JMeter允許使用正則表達式創建斷言。
爲什麼使用Jmeter：
• 開源免費，基於Java編寫，可集成到其他系統可拓展各個功能插件
• 支持接口測試，壓力測試等多種功能，支持錄製回放，入門簡單
• 相較於自己編寫框架或其他開源工具，有較爲完善的UI界面，便於接口調試
• 多平臺支持，可在Linux，Windows，Mac上運行
用例生成與導出：
Jmeter的用例格式爲jmx文件，實際爲xml格式，感興趣可以學習下自己定製生成想要的jmx文件。
生成原則：
每個功能模塊爲一個獨立的jmx文件。增加可維護性。（儘量不要將一個jmx文件放入太多功能，後期維護成本會很高。）
模塊的私有變量保存在模塊中，多模塊共有的（例如服務器ip端口等）可以考慮存在單獨的文件中讀取。
接口測試不要放太多線程，畢竟不是做壓力測試，意義也不大。
導出方法：
編寫測試用例
文件——保存爲——確定：
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日誌文件的名稱
實例：
JMeter -n -t my_test.jmx -l log.jtl -H my.proxy.server -P 8000
執行步驟：
JMeter 默認去當前目錄尋找腳本文件，並把日誌記錄在當前目錄。比如你在 C:\tools\apache-jmeter-2.11\bin 目錄下執行以上命令，JMeter 會去該目錄下尋找 test.jmx 腳本並把執行結果放在該目錄。如果你的腳本在其他目錄，而且想要把執行結果放在另外文件夾，可以使用絕對路徑告訴 JMeter。
執行結果查看：
GUI界面打開聚合報告
在GUI界面創建一個聚合報告
聚合報告界面點擊瀏覽，選中生成的.jtl文件，打開
Jmeter使用
Jmeter創建接口測試計劃實例
測試用例應該作爲測試的基礎內容，而用例的結構可能劃分，則是用例的基礎（忽然在這裏想說一下，用例僅僅是一項測試活動的綱要，有最好，沒有的話能保證質量也OK。更不用說用例的格式問題，無論是表格還是導圖，其實都無所謂！本文的用例是指jmx文件中的控件結構）。
• 模塊名稱（測試計劃）：每個模塊獨立劃分爲一個jmx文件（例如登陸模塊），最好與接口類一一對應。對應的服務器信息，數據庫信息等可存在這裏。
• 數據準備：用於測試數據的準備（例如賬號信息）。
• 結果查看：用於放置需要查看結果的控件（例如結果樹）。
• 線程組：所有的接口測試用例放在線程組下，集中定義線程等信息
• 獲取線程對應測試數據：用於獲取針對獨立線程的測試數據，例如在數據準備裏面獲得了賬號信息，在這裏根據賬號信息去數據庫獲取對應的名稱，ID等信息。
• 請求名稱：用簡單控制器爲文件夾，內有不同的請求。簡單控制器爲一個獨立的接口，不同請求對應不同的代碼路徑（例如成功請求，失敗請求等）。建議請求名稱最好用英文形式，否則後期持續集成或許會出現問題（no zuo no die！）。
• 在每條請求內放置正則匹配（用於應對需要返回值作爲下次請求的參數的情況）以及斷言。
● 請你進行測試：前端下拉框實現，測試下拉框定位方式
參考回答：
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.定位非<select>標籤的下拉菜單
非<select>標籤的下拉菜單如下圖所示：
定位非<select>標籤的下拉菜單中的選項，需要兩個步驟，先定位到下拉菜單，再對其中的選項進行定位。
定位代碼：
# 先定位到下拉菜單
drop_down = driver.find_element_by_css_selector("div#select2_container > ul")
# 再對下拉菜單中的選項進行選擇
drop_down.find_element_by_id("li2_input_2").click()
注：也可以用此方法定位<select>標籤的下拉菜單。
● 請你來聊一聊appium斷言
參考回答：
appium-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)。
● 請你來說一下購物車的測試用例
參考回答：
界面測試
• 界面佈局、排版是否合理；文字是否顯示清晰；不同賣家的商品是否區分明顯。
2.功能測試
未登錄時：
• 將商品加入購物車，頁面跳轉到登錄頁面，登錄成功後購物車數量增加；
• 點擊購物車菜單，頁面跳轉到登錄頁面。
登錄後：
• 所有鏈接是否跳轉正確；
• 商品是否可以成功加入購物車；
• 購物車商品總數是否有限制；
• 商品總數是否正確；
• 全選功能是否好用；
• 刪除功能是否好用；
• 填寫委託單功能是否好用；
• 委託單中填寫的價格是否正確顯示；
• 價格總計是否正確；
• 商品文字太長時是否顯示完整；
• 店鋪名字太長時是否顯示完整；
• 創新券商品是否打標；
• 購物車中下架的商品是否有特殊標識；
• 新加入購物車商品排序（添加購物車中存在店鋪的商品和購物車中不存在店鋪的商品）；
• 是否支持TAB、ENTER等快捷鍵；
• 商品刪除後商品總數是否減少；
• 購物車結算功能是否好用。
3.兼容性測試
• 不同瀏覽器測試。
4.易用性測試
• 刪除功能是否有提示；是否有回到頂部的功能；商品過多時結算按鈕是否可以浮動顯示。
5.性能測試
• 壓力測試；併發測試。
● 請你進行一下弱網模擬
參考回答：
方法一：charles弱網模擬
配置參數解析：
bandwidth —— 帶寬，即上行、下行數據傳輸速度
utilisation —— 帶寬可用率，大部分modern是100%
round-trip latency —— 第一個請求的時延，單位是ms。
MTU —— 最大傳輸單元，即TCP包的最大size，可以更真實模擬TCP層，每次傳輸的分包情況。
Releability —— 指連接的可靠性。這裏指的是10kb的可靠率。用於模擬網絡不穩定。
Stability —— 連接穩定性，也會影響帶寬可用性。用於模擬移動網絡，移動網絡連接一般不可靠。
使用chrome的webview調試工具，缺點是隻適用於web頁面的弱網模擬。
方法二：chrome的webview調試工具弱網模擬
使用chrome的webview調試工具，缺點是隻適用於web頁面的弱網模擬。
具體步驟：
（1）應用打開webview調試功能，具體如下：
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
WebView.setWebContentsDebuggingEnabled(true);
}
（2）手機鏈接電腦，運行APP，進入具體H5頁面；
（3）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（蜂窩網）
● 你寫的測試程序是怎麼樣的，你寫過前端、後端程序嗎？
參考回答：
開發測試驅動程序一般分爲4步：
1，指出需要的新特性。可以記錄下來，然後爲其編寫一個測試。
2，編寫特性的概要代碼，這樣程序就可以運行而沒有任何語法等方面的錯誤，但是測試會失敗。看到測試失敗是很重要的，這樣就能確定測試可以失敗。如果測試代碼中出現了錯誤，那麼就有可能出現任何情況，測試都會成功，這樣等於沒測試任何東西。再強調一遍：在試圖測試成功之前，先要看到它失敗。
3，爲特性的概要編寫虛設代碼，能滿足測試要求就行。不用準確的實現功能，只要保證測試可以通過即可。這樣一來就可以保證在開發的時候總是通過測試了，（除了第一次測試的時候）甚至在最初實現功能時亦是如此。
4，現在重寫（或者重構）代碼，這樣它就會做自己應該做的事，從而保證測試一直成功。
在編碼完成時，應該保證代碼處於健康狀態--不要遺留下任何測試失敗。
寫過前段程序。
