碼字太難了，這些問題保存在我的word文檔中，結(jié)果還是一行行粘貼過來的。

大家看著這份文章上，多給點(diǎn)關(guān)注收藏呀~~~~~~

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

參考回答：
IP的格式：(1~ 255).(0~ 255).(0~ 255).(0~255)
方法一：基于對字符串的處理

方法二：正則表達(dá)式

等價類劃分：

2.請進(jìn)行測試用例設(shè)計：一串?dāng)?shù)字，閏年的判別

參考回答：
判斷閏年的標(biāo)準(zhǔn)是:能整除4且不能整除100，能整除400。設(shè)定合法的年份為1-9999

測試用例：

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

參考回答：

1、功能測試

輸入正確的用戶名和密碼，點(diǎn)擊提交按鈕，驗證是否能正確登錄。

輸入錯誤的用戶名或者密碼,驗證登錄會失敗，并且提示相應(yīng)的錯誤信息。

登錄成功后能否能否跳轉(zhuǎn)到正確的頁面

用戶名和密碼，如果太短或者太長，應(yīng)該怎么處理

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

記住用戶名的功能

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

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

密碼是否非明文顯示顯示，使用星號圓點(diǎn)等符號代替。

牽扯到驗證碼的，還要考慮文字是否扭曲過度導(dǎo)致辨認(rèn)難度大，考慮顏色（色盲使 用者），刷新或換一個按鈕是否好用

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

輸入密碼的時候，大寫鍵盤開啟的時候要有提示信息。

什么都不輸入，點(diǎn)擊提交按鈕，檢查提示信息。

2、界面測試

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

testbox和按鈕的長度，高度是否復(fù)合要求。

界面的設(shè)計風(fēng)格是否與UI的設(shè)計風(fēng)格統(tǒng)一。

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

3、性能測試

打開登錄頁面，需要的時間是否在需求要求的時間內(nèi)。

輸入正確的用戶名和密碼后，檢查登錄成功跳轉(zhuǎn)到新頁面的時間是否在需求要求的時間內(nèi)。

模擬大量用戶同時登陸，檢查一定壓力下能否正常登陸跳轉(zhuǎn)。

4、安全性測試

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

用戶名和密碼是否通過加密的方式，發(fā)送給Web服務(wù)器。

用戶名和密碼的驗證，應(yīng)該是用服務(wù)器端驗證， 而不能單單是在客戶端用javascript 驗證。

用戶名和密碼的輸入框，應(yīng)該屏蔽SQL注入攻擊。

用戶名和密碼的的輸入框，應(yīng)該禁止輸入腳本 （防止XSS攻擊）。

防止暴力破解，檢測是否有錯誤登陸的次數(shù)限制。

是否支持多用戶在同一機(jī)器上登錄。

同一用戶能否在多臺機(jī)器上登錄。

5、可用性測試

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

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

輸入框能否可以以Tab鍵切換。

6、兼容性測試

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

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

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

移動設(shè)備上是否正常工作，比如Iphone, Andriod。

不同的分辨率下顯示是否正常。

7、本地化測試

不同語言環(huán)境下，頁面的顯示是否正確。

在這里我向大家推薦一個自動化學(xué)習(xí)交流群。交流學(xué)習(xí)群號：313782132 里面會分享一些資深架構(gòu)師錄制的視頻錄像

4.請對這個系統(tǒng)做出測試用例：一個系統(tǒng)，多個攝像頭，抓拍車牌，識別車牌，上傳網(wǎng)上，網(wǎng)上展示

參考回答：

功能：

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

每個攝像頭抓拍到的車牌能正常交給系統(tǒng)處理；

系統(tǒng)能夠正確識別車牌；

系統(tǒng)能夠?qū)⒆R別出的車牌上傳；

上傳至網(wǎng)絡(luò)的車牌能夠正常展示出來；

一、功能測試

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

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

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

在多種情況下檢查每個攝像頭抓拍到的車牌能否正常交給系統(tǒng)處理，如臨時斷電、斷網(wǎng)后能否正常將數(shù)據(jù)交給系統(tǒng)；

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

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

在多種情況下檢查系統(tǒng)能否將正常識別出的車牌進(jìn)行上傳，如臨時斷電、斷網(wǎng)后未上傳數(shù)據(jù)是否能繼續(xù)上傳；

構(gòu)造非車牌的其他內(nèi)容的數(shù)據(jù)，檢查系統(tǒng)能否將異常內(nèi)容進(jìn)行上傳；

檢查上傳至網(wǎng)絡(luò)的車牌能否正常展示出來；

上傳非車牌的其他內(nèi)容的數(shù)據(jù)，檢查能否正常顯示出來。

二、性能測試

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

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

抓拍后，檢查系統(tǒng)識別車牌的時間是否在需求要求的時間內(nèi)；

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

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

三、安全性測試

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

5.請你對吃雞游戲進(jìn)行壓力測試

參考回答：

首先明確需要測試壓力的內(nèi)容:

游戲服務(wù)器硬件

a.硬盤I/o

b.內(nèi)存

c.CPU

網(wǎng)絡(luò)壓力

a.長連接

a1.最大連接數(shù)

a2.流量(內(nèi)網(wǎng)、外網(wǎng)、進(jìn)、出)

b.長連接短周期(類似Http的TCP應(yīng)用，這個比較特殊的一個需求，專門針對LoginAgent)

b1.每秒建立的連接數(shù)

b2.實(shí)際處理能力

數(shù)據(jù)庫

a.每秒事務(wù)數(shù)

b.每秒鎖等待數(shù)

c.平均延時(ms)

d.CPU暫用

多線程的最優(yōu)線程數(shù)

a.數(shù)據(jù)庫執(zhí)行的多線程

b.多連接處理

Windows Server環(huán)境測試方式

服務(wù)器性能監(jiān)測

使用Server自帶的性能監(jiān)測器設(shè)置各個進(jìn)程的監(jiān)測參數(shù)。Window的這個自動工具做的相當(dāng)強(qiáng)大。大家自己摸一摸基本就會用了。每個參數(shù)都由詳細(xì)的說明。

案例設(shè)計注意

a.對于數(shù)據(jù)庫的性能測試上，現(xiàn)在由于所有的游戲服務(wù)器構(gòu)架在DB前面都有一個實(shí)現(xiàn)DB緩沖功能的進(jìn)程，以減少數(shù)據(jù)庫頻繁的讀寫操作。所以其實(shí)數(shù)據(jù)庫的讀是一個輕量級的數(shù)量；而數(shù)據(jù)庫的寫操作是一個周期性能過程。案例設(shè)計一定要能夠驅(qū)動這種周期性能過程。比如我們游戲的戰(zhàn)斗，導(dǎo)致游戲玩家數(shù)據(jù)的改變，或驅(qū)動所有在線玩家數(shù)據(jù)的周期性存儲。

b.選擇具有代表性，并且最頻繁的游戲操作。用于進(jìn)行最高用戶在線的各種性能指標(biāo)采集。如，開槍、道具拾取、道具使用、移動、聊天

c.聊天性能測試

廣播聊天是最為考驗游戲信息發(fā)送能力的功能。通過進(jìn)行全局廣播的壓力測試。我們可以獲取服務(wù)器進(jìn)程發(fā)送信息到客戶端的最高承載量。進(jìn)而可以對我們的各種廣播功能進(jìn)行一個預(yù)估和頻率限制。

d.同屏玩家的移動測試

移動+廣播。這兩種信息，基本是網(wǎng)絡(luò)游戲流量的70-80%左右。同屏玩家數(shù)量，將會增加各種數(shù)據(jù)的廣播需求，非常影響游戲性能。所以同屏的移動測試也是廣播測試的一個必要環(huán)節(jié)。需要根據(jù)實(shí)際結(jié)果進(jìn)行適當(dāng)?shù)膬?yōu)化。

e.大量玩家同時登錄測試

玩家登錄時，有大量的信息需要進(jìn)行分配和初始化；同時也有大量的數(shù)據(jù)需要下傳客戶端。服務(wù)器需要進(jìn)行大量的TCP連接建立。所以是一個比較關(guān)鍵的過程。這個測試案例是一個比較特殊，但是運(yùn)營是肯定會碰到的案例。

f.由于線程池處理事務(wù)，隨著事務(wù)的時耗，存在一個最優(yōu)線程數(shù)的問題。過多的線程反而會降低服務(wù)器效率

細(xì)節(jié)問題

a.進(jìn)行測試需要仔細(xì)思考客戶端性能影響服務(wù)器最后表現(xiàn)的可能性。比如

a1.模擬客戶端的性能無法有效處理服務(wù)器返回信息,可能就導(dǎo)致服務(wù)器發(fā)送的信息緩存在服務(wù)器系統(tǒng)緩存，從而表現(xiàn)出服務(wù)器內(nèi)存不斷增加。表現(xiàn)為服務(wù)器發(fā)送能力不足，其實(shí)可能根本就是客戶端的性能問題

a2.客戶端性能問題，導(dǎo)致發(fā)起的請求數(shù)過少，從而導(dǎo)致單位時間內(nèi)服務(wù)器處理的請求過少。表現(xiàn)為服務(wù)器性能不足，其實(shí)根本就是客戶端的請求能力不足。

b.網(wǎng)絡(luò)帶寬導(dǎo)致最后表現(xiàn)不足

b1.確認(rèn)服務(wù)器的各個網(wǎng)卡，以及相互的帶寬。不然可能因為相互帶寬，導(dǎo)致服務(wù)器對于客戶端請求的處理延時。表現(xiàn)為服務(wù)器卡機(jī)

b2.客戶端模擬多個玩家，比如1000個玩家。而客戶端的網(wǎng)卡或者客戶端與服務(wù)器之間的中轉(zhuǎn)服務(wù)器帶寬過小，導(dǎo)致服務(wù)器數(shù)據(jù)發(fā)送不出，內(nèi)存不斷增加。表現(xiàn)為服務(wù)器發(fā)送能力不足，其實(shí)是中間帶寬問題。

c.debug i/o導(dǎo)致服務(wù)器性能下降

c1.進(jìn)行性能測試，一定要取消debug用的同步的i/o.比如我們服務(wù)器的debuginternalLog.同步i/o是非常影響性能的，特別在壓力測試下可能導(dǎo)致每秒上千上萬甚至幾十萬次的執(zhí)行。一處的文件寫入操作就可以導(dǎo)致幾十萬次的處理能力變成幾千次的處理能力。

c2.客戶端避免進(jìn)行阻塞操作導(dǎo)致模擬多用戶性能下降，導(dǎo)致服務(wù)器表現(xiàn)性能下降

d.流量需要區(qū)分內(nèi)網(wǎng)

網(wǎng)內(nèi)、外網(wǎng)流量在游戲正式運(yùn)行時是完全分開的。價格也是完全不同的。一個千M的外網(wǎng)是一個無法想象的運(yùn)營成本，而kmbps/s現(xiàn)在已經(jīng)是一個可以接受的代價。游戲進(jìn)程需要進(jìn)行不同網(wǎng)卡的配置和綁定。確定內(nèi)外網(wǎng)流量。

6. 請你根據(jù)微信登錄界面設(shè)計測試用例

參考回答：

功能測試

輸入正確的用戶名和密碼，點(diǎn)擊提交按鈕，驗證是否能正確登錄。

輸入錯誤的用戶名或者密碼,驗證登錄會失敗，并且提示相應(yīng)的錯誤信息。

登錄成功后能否能否跳轉(zhuǎn)到正確的頁面

檢查能否選擇不同登錄方式進(jìn)行登錄，如使用手機(jī)號登錄、使用微信號登錄或掃碼登錄。

記住用戶名的功能

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

密碼是否非明文顯示顯示，使用星號圓點(diǎn)等符號代替。

有驗證碼時，還要考慮文字是否扭曲過度導(dǎo)致辨認(rèn)難度大，考慮顏色、刷新或換一個按鈕是否好用

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

輸入密碼的時候，大寫鍵盤開啟的時候要有提示信息。

什么都不輸入，點(diǎn)擊提交按鈕，檢查提示信息。

界面測試

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

testbox和按鈕的長度，高度是否復(fù)合要求。

界面的設(shè)計風(fēng)格是否與UI的設(shè)計風(fēng)格統(tǒng)一。

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

性能測試

打開登錄頁面，需要的時間是否在需求要求的時間內(nèi)。

輸入正確的用戶名和密碼后，檢查登錄成功跳轉(zhuǎn)到新頁面的時間是否在需求要求的時間內(nèi)。

模擬大量用戶同時登陸，檢查一定壓力下能否正常登陸跳轉(zhuǎn)。

安全性測試

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

用戶名和密碼是否通過加密的方式，發(fā)送給Web服務(wù)器。

用戶名和密碼的驗證，應(yīng)該是用服務(wù)器端驗證， 而不能單單是在客戶端用javascript 驗證。

用戶名和密碼的輸入框，應(yīng)該屏蔽SQL注入攻擊。

用戶名和密碼的的輸入框，應(yīng)該禁止輸入腳本 （防止XSS攻擊）。

防止暴力破解，檢測是否有錯誤登陸的次數(shù)限制。

是否支持多用戶在同一機(jī)器上登錄。

同一用戶能否在多臺機(jī)器上登錄。

兼容性測試

不同移動平臺或PC環(huán)境下下能否顯示正常且功能正常

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

不同的分辨率下顯示是否正常。

本地化測試

不同語言環(huán)境下，頁面的顯示是否正確。

7.請你對朋友圈點(diǎn)贊功能進(jìn)行測試

參考回答：

是否可以正常點(diǎn)贊和取消；

點(diǎn)贊的人是否在可見分組里；

點(diǎn)贊狀態(tài)是否能即時更新顯示；

點(diǎn)贊狀態(tài)，共同好友是否可見；

性能檢測，網(wǎng)速快慢對其影響；

點(diǎn)贊顯示的是否正確，一行幾個；

點(diǎn)贊是否按時間進(jìn)行排序，頭像對應(yīng)的是否正確；

是否能在消息列表中顯示點(diǎn)贊人的昵稱、5.不同手機(jī)，系統(tǒng)顯示界面如何；

備注；

可擴(kuò)展性測試，點(diǎn)贊后是否能發(fā)表評論；

是否在未登錄時可查看被點(diǎn)贊的信息。

8.如果做一個杯子的檢測，你如何測試（經(jīng)典）

功能

水倒水杯容量的一半

水倒規(guī)定的安全線

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

蓋子擰緊水倒不出來

燙手驗證

性能

使用最大次數(shù)或時間

掉地上不易損壞

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

保溫時間長

杯子的耐熱性

杯子的耐寒性

長時間放置水不會漏

杯子上放置重物達(dá)到什么程度杯子會被損壞

界面

外觀完整、美觀

大小與設(shè)計一樣（高、寬、容量、直徑）

拿著舒服

材質(zhì)與設(shè)計一樣

杯子上的圖案掉落

圖案遇水溶解

安全

杯子使用的材質(zhì)毒或細(xì)菌的驗證

高溫材質(zhì)釋放毒性

低溫材質(zhì)釋放毒性

易用性

倒水方便

喝水方便

攜帶方便

使用簡單，容易操作

防滑措施

兼容性

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

震動測試

杯子加包裝（有填充物），六面震動，檢查產(chǎn)品是否能應(yīng)對鐵路/公路/航空運(yùn)輸。

可移植性

杯子在不同地方、溫度環(huán)境下都可以正常使用。

9.如何對一個頁面進(jìn)行測試

參考回答：

UI測試：頁面布局、頁面樣式檢查、控件長度是否夠長；顯示時，是否會被截斷；支持的快捷鍵，Tab鍵切換焦點(diǎn)順序正確性等。

功能測試：頁面上各類控件的測試范圍，測試點(diǎn)。結(jié)合控件的實(shí)際作用來補(bǔ)充檢查點(diǎn)： 比如， 密碼框是否*顯示， 輸入是否做trim處理等。

安全測試：輸入特殊字符，sql注入，腳本注入測試。后臺驗證測試，對于較重要的表單 ，繞過js檢驗后臺是否驗證；數(shù)據(jù)傳輸是否加密處理，比如， 直接請求轉(zhuǎn)發(fā)，地址欄直接顯示發(fā)送字符串？

兼容性測試

性能測試

在這里我向大家推薦一個自動化學(xué)習(xí)交流群。交流學(xué)習(xí)群號：313782132 里面會分享一些資深架構(gòu)師錄制的視頻錄像

10.如何對水壺進(jìn)行測試(同水杯)

參考回答：

功能

水倒水壺容量的一半

水倒規(guī)定的安全線

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

蓋子擰緊水倒不出來

燙手驗證

性能

使用最大次數(shù)或時間

掉地上不易損壞

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

保溫時間長

壺的耐熱性

壺的耐寒性

長時間放置水不會漏

壺上放置重物達(dá)到什么程度壺會被損壞

界面

外觀完整、美觀

大小與設(shè)計一樣（高、寬、容量、直徑）

拿著舒服

材質(zhì)與設(shè)計一樣

壺上的圖案掉落

圖案遇水溶解

安全

壺使用的材質(zhì)毒或細(xì)菌的驗證

高溫材質(zhì)釋放毒性

低溫材質(zhì)釋放毒性

易用性

倒水方便

喝水方便

攜帶方便

使用簡單，容易操作

防滑措施

兼容性

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

震動測試

壺加包裝（有填充物），六面震動，檢查產(chǎn)品是否能應(yīng)對鐵路/公路/航空運(yùn)輸。

可移植性

壺在不同地方、溫度環(huán)境下都可以正常使用。

11.如何對淘寶搜索框進(jìn)行測試

參考回答：

功能測試

1.輸入關(guān)鍵字，查看: 返回結(jié)果是否準(zhǔn)確，返回的文本長度需限制

1.1輸入可查到結(jié)果的正常關(guān)鍵字、詞、語句，檢索到的內(nèi)容、鏈接正確性；

1.2輸入不可查到結(jié)果的關(guān)鍵字、詞、語句；

1.3輸入一些特殊的內(nèi)容，如空、特殊符、標(biāo)點(diǎn)符、極限值等，可引入等價類劃分的方法等；

2.結(jié)果顯示：標(biāo)題，賣家，銷售量，單行/多行，是否有圖片

3.結(jié)果排序：價格 銷量 評價 綜合

4.返回結(jié)果龐大時，限制第一頁的現(xiàn)實(shí)量，需支持翻頁

5.多選項搜索：關(guān)鍵字 品牌 產(chǎn)地 價格區(qū)間 是否天貓 是否全國購

6.是否支持模糊搜索，支持通配符的查詢

7, 網(wǎng)速慢的情況下的搜索

8.搜索結(jié)果為空的情況

9.未登錄情況和登錄情況下的搜索（登錄情況下 存儲用戶搜索的關(guān)鍵字/搜索習(xí)慣）

性能測試：

1.壓力測試：在不同發(fā)用戶數(shù)壓力下的表現(xiàn)（評價指標(biāo)如響應(yīng)時間等）

2.負(fù)載測試：看極限能承載多大的用戶量同時正常使用

3.穩(wěn)定性測試：常規(guī)壓力下能保持多久持續(xù)穩(wěn)定運(yùn)行

4.內(nèi)存測試：有無內(nèi)存泄漏現(xiàn)象

5.大數(shù)據(jù)量測試：如模擬從龐大的海量數(shù)據(jù)中搜索結(jié)果、或搜索出海量的結(jié)果后列示出來，看表現(xiàn)如何等等。

易用性：交互界面的設(shè)計是否便于、易于使用

1.依據(jù)不同的查詢結(jié)果會有相關(guān)的人性化提示，查不到時告知？查到時統(tǒng)計條數(shù)并告知？有疑似輸入條件錯誤時提示可能正確的輸入項等等處理；

2.查詢出的結(jié)果羅列有序，如按點(diǎn)擊率或其他排序規(guī)則，確保每次查詢出的結(jié)果位置按規(guī)則列示方便定位，顯示字體、字號、色彩便于識別等等；

3.標(biāo)題查詢、全文檢索、模糊查詢、容錯查詢、多關(guān)鍵字組織查詢（空格間格開）等實(shí)用的檢索方式是否正常？

4.輸入搜索條件的控件風(fēng)格設(shè)計、位置擺放是否醒目便于使用者注意到，有否快照等快捷查看方式等人性化設(shè)計？

兼容性

1.WINDOWS/LINUX/UNIX等各類操作系統(tǒng)下及各版本條件下的應(yīng)用

2.IE/FIREFOX/GOOGLE/360/QQ等各類瀏覽器下及各版本條件下、各種顯示分辨率條件下的應(yīng)用

3.SQL/ORACLE/DB2/MYSQL等各類數(shù)據(jù)庫存儲情況下的兼容性測試

4.簡體中文、繁體中文、英文等各類語種軟件平臺下的兼容性測試

5.IPHONE/IPAD、安卓等各類移動應(yīng)用平臺下的兼容性測試

6.與各相關(guān)的監(jiān)控程序的兼容性測試，如輸入法、殺毒、監(jiān)控、防火墻等工具同時使用

安全性

1.被刪除、加密、授權(quán)的數(shù)據(jù)，不允許被SQL注入等攻擊方式查出來的，是否有安全控制設(shè)計；

2.錄入一些數(shù)據(jù)庫查詢的保留字符，如單引號、%等等，造成查詢SQL拼接出的語句產(chǎn)生漏洞，如可以查出所有數(shù)據(jù)等等，這方面要有一些黑客攻擊的思想并引入一些工具和技術(shù)，如爬網(wǎng)等。

3.通過白盒測試技術(shù)，檢查一下在程序設(shè)計上是否存在安全方面的隱患；

4.對涉及國家安全、法律禁止的內(nèi)容是否進(jìn)行了相關(guān)的過濾和控制；

12.如何對一瓶礦泉水進(jìn)行測試

參考回答：

界面測試:查看外觀是否美觀

功能度：查看水瓶漏不漏；瓶中水能不能被喝到

安全性：瓶子的材質(zhì)有沒有毒或細(xì)菌

可靠性：從不同高度落下的損壞程度

可移植性：再不同的地方、溫度等環(huán)境下是否都可以正常使用

兼容性：是否能夠容納果汁、白水、酒精、汽油等

易用性：是否燙手、是否有防滑措施、是否方便飲用

用戶文檔：使用手冊是否對的用法、限制、使用條件等有詳細(xì)描述

疲勞測試：將盛上水（案例一）放24小時檢查泄漏時間和情況；盛上汽油（案例二）放24小時檢查泄漏時間和情況等

壓力測試：用根針并在針上面不斷加重量，看壓強(qiáng)多大時會穿透

跌落測試:測試在何種高度跌落會破壞水瓶

13.如何測試登陸界面

參考回答：

功能測試

輸入正確的用戶名和密碼，點(diǎn)擊提交按鈕，驗證是否能正確登錄。

輸入錯誤的用戶名或者密碼,驗證登錄會失敗，并且提示相應(yīng)的錯誤信息。

登錄成功后能否能否跳轉(zhuǎn)到正確的頁面

用戶名和密碼，如果太短或者太長，應(yīng)該怎么處理

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

記住用戶名的功能

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

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

密碼是否非明文顯示顯示，使用星號圓點(diǎn)等符號代替。

牽扯到驗證碼的，還要考慮文字是否扭曲過度導(dǎo)致辨認(rèn)難度大，考慮顏色（色盲使 用者），刷新或換一個按鈕是否好用

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

輸入密碼的時候，大寫鍵盤開啟的時候要有提示信息。

什么都不輸入，點(diǎn)擊提交按鈕，檢查提示信息。

界面測試

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

testbox和按鈕的長度，高度是否復(fù)合要求。

界面的設(shè)計風(fēng)格是否與UI的設(shè)計風(fēng)格統(tǒng)一。

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

性能測試

打開登錄頁面，需要的時間是否在需求要求的時間內(nèi)。

輸入正確的用戶名和密碼后，檢查登錄成功跳轉(zhuǎn)到新頁面的時間是否在需求要求的時間內(nèi)。

模擬大量用戶同時登陸，檢查一定壓力下能否正常登陸跳轉(zhuǎn)。

安全性測試

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

用戶名和密碼是否通過加密的方式，發(fā)送給Web服務(wù)器。

用戶名和密碼的驗證，應(yīng)該是用服務(wù)器端驗證， 而不能單單是在客戶端用javascript 驗證。

用戶名和密碼的輸入框，應(yīng)該屏蔽SQL注入攻擊。

用戶名和密碼的的輸入框，應(yīng)該禁止輸入腳本 （防止XSS攻擊）。

防止暴力破解，檢測是否有錯誤登陸的次數(shù)限制。

是否支持多用戶在同一機(jī)器上登錄。

同一用戶能否在多臺機(jī)器上登錄。

可用性測試

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

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

輸入框能否可以以Tab鍵切換。

兼容性測試

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

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

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

移動設(shè)備上是否正常工作，比如Iphone, Andriod。

不同的分辨率下顯示是否正常。

7.本地化測試

不同語言環(huán)境下，頁面的顯示是否正確。

14.請你說一下jmeter

參考回答：

Jmeter：Apache JMeter是Apache組織開發(fā)的基于Java的壓力測試工具。用于對軟件做壓力測試，它最初被設(shè)計用于Web應(yīng)用測試，但后來擴(kuò)展到其他測試領(lǐng)域。 它可以用于測試靜態(tài)和動態(tài)資源，例如靜態(tài)文件、Java 小服務(wù)程序、CGI 腳本、Java 對象、數(shù)據(jù)庫、FTP 服務(wù)器， 等等。JMeter 可以用于對服務(wù)器、網(wǎng)絡(luò)或?qū)ο竽M巨大的負(fù)載，來自不同壓力類別下測試它們的強(qiáng)度和分析整體性能。另外，JMeter能夠?qū)?yīng)用程序做功能/回歸測試，通過創(chuàng)建帶有斷言的腳本來驗證你的程序返回了你期望的結(jié)果。為了最大限度的靈活性，JMeter允許使用正則表達(dá)式創(chuàng)建斷言。

15.為什么使用Jmeter：

開源免費(fèi)，基于Java編寫，可集成到其他系統(tǒng)可拓展各個功能插件

支持接口測試，壓力測試等多種功能，支持錄制回放，入門簡單

相較于自己編寫框架或其他開源工具，有較為完善的UI界面，便于接口調(diào)試

多平臺支持，可在Linux，Windows，Mac上運(yùn)行

用例生成與導(dǎo)出：

Jmeter的用例格式為jmx文件，實(shí)際為xml格式，感興趣可以學(xué)習(xí)下自己定制生成想要的jmx文件。

生成原則：

每個功能模塊為一個獨(dú)立的jmx文件。增加可維護(hù)性。（盡量不要將一個jmx文件放入太多功能，后期維護(hù)成本會很高。）

模塊的私有變量保存在模塊中，多模塊共有的（例如服務(wù)器ip端口等）可以考慮存在單獨(dú)的文件中讀取。

接口測試不要放太多線程，畢竟不是做壓力測試，意義也不大。

導(dǎo)出方法：

編寫測試用例

文件——保存為——確定：

?

Jmeter運(yùn)行模式及參數(shù)

GUI模式

打開已有的jmx文件（文件——打開）

點(diǎn)擊啟動按鈕運(yùn)行

命令行模式

依賴：

配置jmeter環(huán)境變量（windows下為將j m e t e r h o m e / b i n 加 入 P a t h 變 量 ） 如 果 未 加 入 環(huán) 境 變 量 ， 在 執(zhí) 行 的 時 候 可 以 直 接 給 出 全 路 徑 或 在 {jmeterhome}/bin加入Path變量） 如果未加入環(huán)境變量，在執(zhí)行的時候可以直接給出全路徑或在jmeterhome/bin加入Path變量）如果未加入環(huán)境變量，在執(zhí)行的時候可以直接給出全路徑或在{jmeterhome}/bin下執(zhí)行

命令：

jmeter -n -t -l

參數(shù)：

-h 幫助 -> 打印出有用的信息并退出

-n 非 GUI 模式 -> 在非 GUI 模式下運(yùn)行 JMeter

-t 測試文件 -> 要運(yùn)行的 JMeter 測試腳本文件

-l jtl文件 -> 記錄結(jié)果的文件

-r 遠(yuǎn)程執(zhí)行 -> 啟動遠(yuǎn)程服務(wù)

-H 代理主機(jī) -> 設(shè)置 JMeter 使用的代理主機(jī)

-P 代理端口 -> 設(shè)置 JMeter 使用的代理主機(jī)的端口號

-j 日志文件->設(shè)置JMeter日志文件的名稱

實(shí)例：

JMeter -n -t my_test.jmx -l log.jtl -H my.proxy.server -P 8000

執(zhí)行步驟：

JMeter 默認(rèn)去當(dāng)前目錄尋找腳本文件，并把日志記錄在當(dāng)前目錄。比如你在 C:\tools\apache-jmeter-2.11\bin 目錄下執(zhí)行以上命令，JMeter 會去該目錄下尋找 test.jmx 腳本并把執(zhí)行結(jié)果放在該目錄。如果你的腳本在其他目錄，而且想要把執(zhí)行結(jié)果放在另外文件夾，可以使用絕對路徑告訴 JMeter。

執(zhí)行結(jié)果查看：

GUI界面打開聚合報告

在GUI界面創(chuàng)建一個聚合報告

聚合報告界面點(diǎn)擊瀏覽，選中生成的.jtl文件，打開

Jmeter使用

Jmeter創(chuàng)建接口測試計劃實(shí)例

測試用例應(yīng)該作為測試的基礎(chǔ)內(nèi)容，而用例的結(jié)構(gòu)可能劃分，則是用例的基礎(chǔ)（忽然在這里想說一下，用例僅僅是一項測試活動的綱要，有最好，沒有的話能保證質(zhì)量也OK。更不用說用例的格式問題，無論是表格還是導(dǎo)圖，其實(shí)都無所謂！本文的用例是指jmx文件中的控件結(jié)構(gòu)）。

模塊名稱（測試計劃）：每個模塊獨(dú)立劃分為一個jmx文件（例如登陸模塊），最好與接口類一一對應(yīng)。對應(yīng)的服務(wù)器信息，數(shù)據(jù)庫信息等可存在這里。

數(shù)據(jù)準(zhǔn)備：用于測試數(shù)據(jù)的準(zhǔn)備（例如賬號信息）。

結(jié)果查看：用于放置需要查看結(jié)果的控件（例如結(jié)果樹）。

線程組：所有的接口測試用例放在線程組下，集中定義線程等信息

獲取線程對應(yīng)測試數(shù)據(jù)：用于獲取針對獨(dú)立線程的測試數(shù)據(jù)，例如在數(shù)據(jù)準(zhǔn)備里面獲得了賬號信息，在這里根據(jù)賬號信息去數(shù)據(jù)庫獲取對應(yīng)的名稱，ID等信息。

請求名稱：用簡單控制器為文件夾，內(nèi)有不同的請求。簡單控制器為一個獨(dú)立的接口，不同請求對應(yīng)不同的代碼路徑（例如成功請求，失敗請求等）。建議請求名稱最好用英文形式，否則后期持續(xù)集成或許會出現(xiàn)問題（no zuo no die！）。

在每條請求內(nèi)放置正則匹配（用于應(yīng)對需要返回值作為下次請求的參數(shù)的情況）以及斷言。

在這里我向大家推薦一個自動化學(xué)習(xí)交流群。交流學(xué)習(xí)群號：313782132 里面會分享一些資深架構(gòu)師錄制的視頻錄像

16. 請你進(jìn)行測試：前端下拉框?qū)崿F(xiàn)，測試下拉框定位方式

參考回答：

Selenium+Python自動化測試對下拉菜單的定位

通過selenium.webdriver.support.ui的Select進(jìn)行定位

下拉菜單如下圖：

定位代碼：

1. 定位非標(biāo)簽的下拉菜單
   非標(biāo)簽的下拉菜單如下圖所示：
   

定位非標(biāo)簽的下拉菜單中的選項，需要兩個步驟，先定位到下拉菜單，再對其中的選項進(jìn)行定位。

定位代碼：

17. 請你來聊一聊Appium斷言

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

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

在上面的程序中，運(yùn)行到的python 的異常與斷言。通過 raw_input()方法要求用戶輸入一個數(shù)字，通過 arrsert 判斷用戶輸入的 num 是否等于10 ； 通過 python 的 AssertionError 類型的異常來實(shí)捕獲這個異常， msg 接收異常信息并打印， 注意， msg 所結(jié)構(gòu)的異常信息是我們自定義的（“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 的一個實(shí)例。 （obj 和 cls 可以是一個類或元組） ，要檢查他們的類型使用 assertIs(type(obj), cls)。

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

參考回答：

界面測試

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

功能測試

未登錄時：

將商品加入購物車，頁面跳轉(zhuǎn)到登錄頁面，登錄成功后購物車數(shù)量增加；

點(diǎn)擊購物車菜單，頁面跳轉(zhuǎn)到登錄頁面。

登錄后：

所有鏈接是否跳轉(zhuǎn)正確；

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

購物車商品總數(shù)是否有限制；

商品總數(shù)是否正確；

全選功能是否好用；

刪除功能是否好用；

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

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

價格總計是否正確；

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

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

創(chuàng)新券商品是否打標(biāo)；

購物車中下架的商品是否有特殊標(biāo)識；

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

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

商品刪除后商品總數(shù)是否減少；

購物車結(jié)算功能是否好用。

兼容性測試

不同瀏覽器測試。

易用性測試

刪除功能是否有提示；是否有回到頂部的功能；商品過多時結(jié)算按鈕是否可以浮動顯示。

性能測試

壓力測試；并發(fā)測試。

19.請你進(jìn)行一下弱網(wǎng)模擬

參考回答：

方法一：charles弱網(wǎng)模擬

配置參數(shù)解析：

bandwidth —— 帶寬，即上行、下行數(shù)據(jù)傳輸速度

utilisation —— 帶寬可用率，大部分modern是100%

round-trip latency —— 第一個請求的時延，單位是ms。

MTU —— 最大傳輸單元，即TCP包的最大size，可以更真實(shí)模擬TCP層，每次傳輸?shù)姆职闆r。

Releability —— 指連接的可靠性。這里指的是10kb的可靠率。用于模擬網(wǎng)絡(luò)不穩(wěn)定。

Stability —— 連接穩(wěn)定性，也會影響帶寬可用性。用于模擬移動網(wǎng)絡(luò)，移動網(wǎng)絡(luò)連接一般不可靠。

• 使用chrome的webview調(diào)試工具，缺點(diǎn)是只適用于web頁面的弱網(wǎng)模擬。

方法二：chrome的webview調(diào)試工具弱網(wǎng)模擬

使用chrome的webview調(diào)試工具，缺點(diǎn)是只適用于web頁面的弱網(wǎng)模擬。

具體步驟：

• 應(yīng)用打開webview調(diào)試功能，具體如下：

手機(jī)鏈接電腦，運(yùn)行App，進(jìn)入具體H5頁面；

chrome的DevTools中打開Webview：進(jìn)入chrome://inspect/#devices，會顯示已經(jīng)連接設(shè)備，選中待調(diào)試webview的inspect

network頁面，No throttling下拉框，可以進(jìn)行網(wǎng)絡(luò)模擬。

方法三：iOS手機(jī)自帶Network Link Conditioner 弱網(wǎng)模擬

iPhone手機(jī)打開開發(fā)者選項，具體參考：

設(shè)置-開發(fā)者選項 > Network Link Conditioner 入口。

系統(tǒng)已經(jīng)內(nèi)置常見網(wǎng)絡(luò)配置，也可以增加自定義配置。

具體配置參數(shù)：

in Bandwidth 下行帶寬，即下行網(wǎng)絡(luò)速度

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（蜂窩網(wǎng)）

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

參考回答：

開發(fā)測試驅(qū)動程序一般分為4步：

指出需要的新特性?？梢杂涗浵聛?，然后為其編寫一個測試。

編寫特性的概要代碼，這樣程序就可以運(yùn)行而沒有任何語法等方面的錯誤，但是測試會失敗?？吹綔y試失敗是很重要的，這樣就能確定測試可以失敗。如果測試代碼中出現(xiàn)了錯誤，那么就有可能出現(xiàn)任何情況，測試都會成功，這樣等于沒測試任何東西。再強(qiáng)調(diào)一遍：在試圖測試成功之前，先要看到它失敗。

為特性的概要編寫虛設(shè)代碼，能滿足測試要求就行。不用準(zhǔn)確的實(shí)現(xiàn)功能，只要保證測試可以通過即可。這樣一來就可以保證在開發(fā)的時候總是通過測試了，（除了第一次測試的時候）甚至在最初實(shí)現(xiàn)功能時亦是如此。

現(xiàn)在重寫（或者重構(gòu)）代碼，這樣它就會做自己應(yīng)該做的事，從而保證測試一直成功。

在編碼完成時，應(yīng)該保證代碼處于健康狀態(tài)–不要遺留下任何測試失敗。

寫過前端程序。

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

參考回答：

然后，撰寫測試樁與驅(qū)動，白盒測試保證代碼邏輯中循環(huán)和分支都能夠走到，黑盒測試保證函數(shù)和首先，代碼走查結(jié)合動態(tài)單步跟蹤以及觀察日志與文件輸出，網(wǎng)絡(luò)、CPU狀態(tài)。

功能腳本接口正確，輸入輸出符合設(shè)計預(yù)期。

對于異常處理，特別是變量的檢查需要特別關(guān)注，變量在使用前都需要進(jìn)行檢查，是否為空？或者為0？對于文件名和路徑必須檢查，確認(rèn)文件是否存在，路徑是否可達(dá)之后再進(jìn)行后續(xù)操作。

另外，需要考慮所依賴的其他功能腳本以及二進(jìn)制工具，這些功能性單元應(yīng)該如何使用，調(diào)用后的返回會有哪些情況，對于正常和異常結(jié)果，腳本是否能夠捕捉到并且作出正確的判斷。

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

參考回答：

Web測試主要從下面幾個大方向考慮：

功能測試，主要做鏈接測試，表單測試，cookies測試，設(shè)計語言測試等

性能測試，考慮連接速度測試，以及負(fù)載測試，例如：Web應(yīng)用系統(tǒng)能允許多少個用戶同時在線？如果超過了這個數(shù)量，會出現(xiàn)什么現(xiàn)象？Web應(yīng)用系統(tǒng)能否處理大量用戶對同一個頁面的請求？還有壓力測試

可用性測試，比如導(dǎo)航測試，圖形測試，內(nèi)容測試，整體界面測試等

兼容性測試，市場上有很多不同的操作系統(tǒng)類型，最常見的有Windows、Unix、Macintosh、Linux等。Web應(yīng)用系統(tǒng)的最終用戶究竟使用哪一種操作系統(tǒng)，取決于用戶系統(tǒng)的配置。這樣，就可能會發(fā)生兼容性問題，同一個應(yīng)用可能在某些操作系統(tǒng)下能正常運(yùn)行，但在另外的操作系統(tǒng)下可能會運(yùn)行失敗。因此，在Web系統(tǒng)發(fā)布之前，需要在各種操作系統(tǒng)下對Web系統(tǒng)進(jìn)行兼容性測試。

安全性測試，

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

Web應(yīng)用系統(tǒng)是否有超時的限制，也就是說，用戶登陸后在一定時間內(nèi)（例如15分鐘）沒有點(diǎn)擊任何頁面，是否需要重新登陸才能正常使用。

為了保證Web應(yīng)用系統(tǒng)的安全性，日志文件是至關(guān)重要的。需要測試相關(guān)信息是否寫進(jìn)了日志文件、是否可追蹤。

當(dāng)使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。

服務(wù)器端的腳本常常構(gòu)成安全漏洞，這些漏洞又常常被黑客利用。所以，還要測試沒有經(jīng)過授權(quán)，就不能在服務(wù)器端放置和編輯腳本的問題。

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

參考回答：

可以采用lperf這個命令，

Lperf是一個網(wǎng)絡(luò)性能測試工具，可以測量最大tcp和udp帶寬，具有多種參數(shù)和特性，可以記錄帶寬，延遲抖動，數(shù)據(jù)包丟失，通過這些信息可以發(fā)現(xiàn)網(wǎng)絡(luò)問題，檢查網(wǎng)絡(luò)質(zhì)量，定位網(wǎng)絡(luò)瓶頸。

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

服務(wù)端：iperf -s -w 1m

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

含義是TCP wndowsize 為1MByte，測試時間是20s，線程是10。

24.請你回答一下如何測試手機(jī)開機(jī)鍵？

參考回答：

功能測試：

按下開機(jī)鍵，屏幕能否亮起

性能測試：

按下開機(jī)鍵，屏幕能否在規(guī)定時間內(nèi)亮起

壓力測試

連續(xù)多次按下開機(jī)鍵，觀察屏幕是否能一直亮起，到多久時間失靈

健壯性測試

給定一個中了病毒的手機(jī)或者是淘汰許久的老機(jī)子，安歇開機(jī)鍵觀察屏幕能否亮起

可靠性測試

連續(xù)按下開機(jī)鍵有限次數(shù)，比如1萬次，記錄屏幕未亮起的次數(shù)

可用性測試

開機(jī)鍵按下費(fèi)不費(fèi)力，開機(jī)鍵的形狀設(shè)計是否貼合手指，開機(jī)鍵的位置設(shè)計是否方便

25.請問你遇到過哪些印象深刻的bug，接口測試出現(xiàn)bug的原因有哪些？

參考回答：

面試官詢問遇到過哪些印象深刻的bug，其實(shí)它并不關(guān)心你描述的這個bug是否真的有價值，或有多曲折離奇？他只是：了解你平時工作中的測試能力

所以，這就要求的你平時工作中遇到bug時試著自己去定位，定位bug的過程遠(yuǎn)比你的單純的執(zhí)行測試用例有“價值”（自我技能提高的價值），在定位bug的過程中你需要掌握和運(yùn)用更多知識。

另外，建議你平時養(yǎng)成總結(jié)的好習(xí)慣，發(fā)現(xiàn)的bug，開發(fā)解決了，最好問問他原因以及解決的方法，這樣再遇到類似問題時，自己也可以試著定位解決。遇到難解決的bug，也可以把最終的解決過程記錄下來。（這不是就有素材了）

所以，建議你平時可以主動要求去分享一些自己工作中用到或?qū)W習(xí)的技術(shù)。或者多去參加集體活動，加強(qiáng)自己的表達(dá)能力。From:蟲師

接口測試常見的bug有以下幾個:

特殊值處理不當(dāng)導(dǎo)致程序異常退出或者崩潰

類型邊界溢出，導(dǎo)致數(shù)據(jù)獨(dú)處和寫入不一致

取值邊界外未返回正確的錯誤信息

權(quán)限未處理，可以訪問其他用戶的信息

邏輯校驗不完善，可以利用漏洞獲取非正當(dāng)利益

狀態(tài)處理不當(dāng)，導(dǎo)致邏輯出現(xiàn)錯誤

數(shù)組類型item個數(shù)為0或者item重復(fù)時程序異常退出

26.你在做項目中有做過壓力測試嗎，怎么做

參考回答：

首先對要測試的系統(tǒng)進(jìn)行分析，明確需要對那一部分做壓力測試，比如秒殺，支付

如何對這些測試點(diǎn)進(jìn)行施壓

第一種方式可以通過寫腳本產(chǎn)生壓力機(jī)器人對服務(wù)器進(jìn)行發(fā)包收報操作

第二點(diǎn)借助一些壓力測試工具比如Jmeter,LoadRunner

如何對這些測試點(diǎn)進(jìn)行正確的施壓

需要用壓力測試工具或者其他方法錄制腳本，模擬用戶的操作

對測試點(diǎn)設(shè)計多大的壓力比較合適？

需要明確壓力測試限制的數(shù)量，即用戶并發(fā)量

測試結(jié)束后如何通過這些數(shù)據(jù)來定位性能問題

通過測試可以得到吞吐量，平均響應(yīng)時間等數(shù)據(jù)，這個數(shù)據(jù)的背后是整個后臺處理邏輯綜合作用的結(jié)果，這時候就可以先關(guān)注系統(tǒng)的CPU，內(nèi)存，然后對比吞吐量，平均響應(yīng)時間達(dá)到瓶頸時這些數(shù)據(jù)的情況，然后就能確認(rèn)性能問題是系統(tǒng)的哪一塊造成的

27.請問你在項目中關(guān)于功能測試和接口測試是怎么做的

功能測試：

首先制定測試計劃，然后進(jìn)行測試設(shè)計，將在測試計劃階段指定的測試活動分解，進(jìn)而細(xì)化，為若干個可執(zhí)行程序的子測試過程，然后執(zhí)行測試，按照測試計劃使用測試用例對待測項目進(jìn)行逐一的，詳細(xì)的排查分析評估，最后對測試結(jié)果進(jìn)行統(tǒng)計和分析，

接口測試：

什么是接口（API）

API全稱Application Programming Interface，這里面我們其實(shí)不用去關(guān)注AP，只需要I上就可以。一個API就是一個Interface。我們無時不刻不在使用interfaces。我們乘坐電梯里面的按鈕是一個interface。我們開車一個踩油門它也是一個interface。我們計算機(jī)操作系統(tǒng)也是有很多的接口。(這是目前個人找到比較好理解的一段解釋)

接口就是一個位于復(fù)雜系統(tǒng)之上并且能簡化你的任務(wù)，它就像一個中間人讓你不需要了解詳細(xì)的所有細(xì)節(jié)。那我們今天要講的Web API就是這么一類東西。像谷歌搜索系統(tǒng)，它提供了搜索接口，簡化了你的搜索任務(wù)。再像用戶登錄頁面，我們只需要調(diào)用我們的登錄接口，我們就可以達(dá)到登錄系統(tǒng)的目的。

現(xiàn)在市面上有非常多種風(fēng)格的Web API，目前最流行的是也容易訪問的一種風(fēng)格是REST或者叫RESTful 風(fēng)格的API。從現(xiàn)在開始，以下我提到的所有API都是指RESTful風(fēng)格的API。

什么是接口測試和為什么要做接口測試

接口測試是測試系統(tǒng)組件間接口的一種測試。接口測試主要用于檢測外部系統(tǒng)與系統(tǒng)之間以及內(nèi)部各個子系統(tǒng)之間的交互點(diǎn)。測試的重點(diǎn)是要檢查數(shù)據(jù)的交換，傳遞和控制管理過程，以及系統(tǒng)間的相互邏輯依賴關(guān)系等。

現(xiàn)在很多系統(tǒng)前后端架構(gòu)是分離的，從安全層面來說，只依賴前端進(jìn)行限制已經(jīng)完全不能滿足系統(tǒng)的安全要求（繞過前端太容易了），需要后端同樣進(jìn)行控制，在這種情況下就需要從接口層面進(jìn)行驗證。

如今系統(tǒng)越來越復(fù)雜，傳統(tǒng)的靠前端測試已經(jīng)大大降低了效率，而且現(xiàn)在我們都推崇測試前移，希望測試能更早的介入測試，那接口測試就是一種及早介入的方式。例如傳統(tǒng)測試，你是不是得等前后端都完成你才能進(jìn)行測試，才能進(jìn)行自動化代碼編寫。而如果是接口測試，只需要前后端定義好接口，那這時自動化就可以介入編寫接口自動化測試代碼，手工測試只需要后端代碼完成就可以介入測試后端邏輯而不用等待前端工作完成。

接口測試的策略

接口測試也是屬于功能測試，所以跟我們以往的功能測試流程并沒有太大區(qū)別，測試流程依舊是：

測試接口文檔（需求文檔）

根據(jù)接口文檔編寫測試用例（用例編寫完全可以按照以往規(guī)則來編寫，例如等價類劃分，邊界值等設(shè)計方法）

執(zhí)行測試，查看不同的參數(shù)請求，接口的返回的數(shù)據(jù)是否達(dá)到預(yù)期。

在這里我向大家推薦一個自動化學(xué)習(xí)交流群。交流學(xué)習(xí)群號：313782132 里面會分享一些資深架構(gòu)師錄制的視頻錄像

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

參考回答：

自動化測試工具用過selenium和Appium

性能測試工具有用過Jmeter

29.請你設(shè)計一個微信朋友圈點(diǎn)贊的測試用例

參考回答：

功能測試：

點(diǎn)贊某條朋友圈，驗證是否成功

接口測試：

點(diǎn)贊朋友圈，驗證朋友能否收到提示信息

性能測試

點(diǎn)贊朋友圈，是否在規(guī)定時間顯示結(jié)果，是否在規(guī)定時間在朋友手機(jī)上進(jìn)行提示

兼容性測試

在不同的終端比如ipad,手機(jī)上點(diǎn)贊朋友圈，驗證是否成功

30.請問如果用戶點(diǎn)擊微博的關(guān)注圖標(biāo)但是App上面沒有反應(yīng)，應(yīng)該怎么排查這個問題

參考回答：

在Eclipse Devices窗口，選中App對應(yīng)的包名，然后點(diǎn)擊debug圖標(biāo)（綠色的小蟲子），然后切換到Debug視圖。

切換視圖之后，可以看到debug下，App的線程列表。

對于main線程（第一個線程），選中，并將其掛起Suspend。

然后我們就可以看到，Suspend之后，main線程卡住的位置。

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

參考回答：

此時就應(yīng)該找技術(shù)領(lǐng)導(dǎo)拍板或leader們基于安全性、性能、可測試性、可維護(hù)性討論敲定一個解決方案，做到開發(fā)環(huán)境方便開發(fā)，線上環(huán)境少配置

少依賴、少出錯機(jī)會。

32.如果廣東用戶頭條App刷不出東西了，你應(yīng)該怎么排查問題

參考回答：

檢查網(wǎng)絡(luò)連接是否穩(wěn)定，更換網(wǎng)絡(luò)嘗試

更新頭條版本嘗試

清除App緩存，應(yīng)用數(shù)據(jù)

33.請你說一下能不能用機(jī)器學(xué)習(xí)去進(jìn)行自動化測試，如何監(jiān)控異常流量，如果是脈沖呢，如何和正常流量作區(qū)分

參考回答：

如何用機(jī)器學(xué)習(xí)去進(jìn)行自動化測試，就是讓自動化測試變得更加智能，在自動化測試過程中，當(dāng)測試功能模塊越來越多，沒有太多的時間去全部覆蓋，我們可以采用歸納學(xué)習(xí)的方式，基于自動化測試的執(zhí)行結(jié)果或者手工測試執(zhí)行的結(jié)果為數(shù)據(jù)輸入，然后基于一定的模型（例如：以通過率和模塊的重要率計算的平均值）得出測試推薦模塊，或者當(dāng)要執(zhí)行一個功能模塊時，基于歷史數(shù)據(jù)和模型（bug出現(xiàn)的錯誤相關(guān)性，功能相關(guān)性等）計算出與該功能模塊相關(guān)性最大模塊，并推薦測試。

如何監(jiān)控異常流量:

抓包

tcpdump -i eth0 -w server.cap

對包文件使用第三方工具如：wireshark做分析

iftop

yum install iftop

iptraf

yum install iptraf –y 或 yum install iptraf-ng -y

啟動命令ifptraf-ng

34. 請問如何對登錄界面進(jìn)行測試

參考回答：

黑盒測試方法

輸入正確用戶名和密碼，驗證是否登陸成功

輸入正確的用戶名和錯誤的密碼，驗證是否登陸失敗并且提示信息正確

輸入未注冊的用戶名和任意的密碼，驗證是否登陸失敗并且提示信息正確

用戶名和密碼都為空，驗證是否登陸失敗并且提示信息正確

用戶名和密碼兩者之一為空

若啟用了驗證碼，輸入正確的用戶名密碼驗證碼是否能登陸成功

輸入正確用戶名和密碼，錯誤的驗證碼，能否登陸成功并且提示信息正確

用戶名和密碼是否大小寫敏感

頁面上的密碼框是否加密顯示

后臺系統(tǒng)第一次創(chuàng)建的用戶重新登錄時是否提示修改密碼

忘記用戶名和忘記密碼的功能是否可用

前段功能是否根據(jù)要求限制用戶名和密碼的長度

點(diǎn)擊驗證碼圖片是否可以更換驗證碼，更換后的驗證碼是否可用

刷新頁面是否會刷新驗證碼

如果驗證碼具有時效性，分別驗證時效內(nèi)和時效外驗證碼的有效性

用戶登錄成功但是會話超時后是否重定向到用戶登錄界面

不同級別的用戶登錄系統(tǒng)后的權(quán)限是否正確

頁面默認(rèn)定位焦點(diǎn)是否定位到用戶名輸入框中

快捷鍵tab和回車鍵是否可以正常使用

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

安全：

用戶密碼后臺存儲是否加密

用戶密碼在網(wǎng)絡(luò)傳輸過程中是否加密

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

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

密碼輸入框是否不支持復(fù)制粘貼

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

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

連續(xù)多次登陸失敗后系統(tǒng)是否會阻止用戶后續(xù)的嘗試

統(tǒng)一用戶在同一終端的多種不同瀏覽器上登陸，驗證登錄功能的互斥性是否符合設(shè)計預(yù)期

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

驗證登陸是否有互斥性

性能測試：

單用戶登陸的響應(yīng)界面是否符合預(yù)期

單用戶登陸時后臺請求數(shù)量是否過多

高并發(fā)場景下用戶登錄的響應(yīng)界面是否符合預(yù)期

高并發(fā)場景下服務(wù)端的監(jiān)控指標(biāo)是否符合預(yù)期

高集合點(diǎn)并發(fā)場景下是否存在資源死鎖和不合理的資源等待

長時間大量用戶連續(xù)登錄和登出，服務(wù)器端是否存在內(nèi)存泄漏

4.兼容性測試：

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

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

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

不同分辨率下……

弱網(wǎng)測試

網(wǎng)絡(luò)切換和網(wǎng)絡(luò)延遲時登陸界面是否正常

是否支持第三方登陸

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

35.請你說一說當(dāng)前工作中涉及的測試問題(測試流程和測試性能)

參考回答：

在測試性能中，時常會出現(xiàn)腳本回訪卡住的問題，原因有以下幾種：

runtimesetting 中的continue error沒有勾選

錄制的腳本中存在冗余的代碼部分，需要對腳本進(jìn)行優(yōu)化，去除冗余的部分（優(yōu)化腳本）

例如：在用FireFox錄制腳本時，腳本中會產(chǎn)生一個叫”Url=http://download.cdn.mozilla.net/pub/firefox/releases/43.0.1/update/win32/zh-CN/firefox-43.0.1.complete.mar",“Referer=”, ENDITEM,”這樣的代碼（該代碼出現(xiàn)的問題不止一處，在查找時一定要注意。），這是因為采用firefox瀏覽器錄制時產(chǎn)生的壓縮文件，在腳本回放時卡住的原因正是因為這個（建議：能采用IE錄制盡量用IE瀏覽器）

解決辦法：注釋掉或者刪除掉該段代碼即可， 關(guān)聯(lián)問題：在用loadrunner自帶對比工具對比腳本后 找到需要關(guān)聯(lián)的動態(tài)值。在關(guān)聯(lián)后回放腳本時報錯HTTP-status code 417（exception failed）錯誤時

產(chǎn)生的原因如下：

腳本中還存在沒有關(guān)聯(lián)或者關(guān)聯(lián)失敗的動態(tài)值，利用lr自帶對比工具仔細(xì)對比

腳本中的動態(tài)值被做了加密策略，仔細(xì)查看腳本中動態(tài)值的部分，看看動態(tài)值是否被做了安全策略（隨機(jī)生成或者打亂動態(tài)值順序、在動態(tài)值中加入了特殊符號），由于在tree-response中的動態(tài)值是未被加密的狀態(tài)，在client向server發(fā)送請求時，client的動態(tài)值發(fā)給服務(wù)器，這時服務(wù)器的動態(tài)值已經(jīng)被做了參數(shù)化，所以服務(wù)器不認(rèn)準(zhǔn)client向服務(wù)器發(fā)送的動態(tài)值。

解決辦法：去掉動態(tài)值的安全策略即可（JVM參數(shù)）

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

參考回答：

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

可以就數(shù)組的類型，可以是int型的，浮點(diǎn)型的，還可以是大數(shù)類型，負(fù)數(shù)，進(jìn)行測試。

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

參考回答：

測試的設(shè)計都是通用的，首先功能測試看功能有沒有實(shí)現(xiàn)，然后再對性能、壓力、容量、健壯性、安全性、可靠性、恢復(fù)性、備份、協(xié)議、兼容性、可用性、配置、GUI這些非功能測試去思考。具體答案這里不再贅述

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

參考回答：

性能測試常用指標(biāo)：

從外部看，主要有

吞吐量：每秒鐘系統(tǒng)能夠處理的請求數(shù)，任務(wù)數(shù)

響應(yīng)時間：服務(wù)處理一個請求或一個任務(wù)的耗時

錯誤率：一批請求中結(jié)果出錯的請求所占比例

從服務(wù)器的角度看

性能測試關(guān)注CPU，內(nèi)存，服務(wù)器負(fù)載，網(wǎng)絡(luò)，磁盤ＩＯ

對登錄功能做性能測試

單用戶登陸的響應(yīng)界面是否符合預(yù)期

單用戶登陸時后臺請求數(shù)量是否過多

高并發(fā)場景下用戶登錄的響應(yīng)界面是否符合預(yù)期

高并發(fā)場景下服務(wù)端的監(jiān)控指標(biāo)是否符合預(yù)期

高集合點(diǎn)并發(fā)場景下是否存在資源死鎖和不合理的資源等待

長時間大量用戶連續(xù)登錄和登出，服務(wù)器端是否存在內(nèi)存泄漏

怎么測出可同時處理的最大請求數(shù)量

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

39.請問你有沒有做過什么單元測試，怎么進(jìn)行單元測試，對一個沒有參數(shù)沒有返回值但可能對全局變量有影響的怎么進(jìn)行單元測試

參考回答：

如何進(jìn)行單元測試：

創(chuàng)建單元測試，該工具可以對任何類、接口、結(jié)構(gòu)等實(shí)體中的字段、屬性、構(gòu)造函數(shù)、方法等進(jìn)行單元測試。創(chuàng)建單元測試大致可以分為兩類：

第一類整體測試，整體測試是在類名稱上右擊鼠標(biāo)，在下拉菜單中點(diǎn)擊創(chuàng)建單元測試選項。這樣就可以為整個類創(chuàng)建單元測試了，這時他會為整個類可以被測試的內(nèi)容全部添加測試方法。開發(fā)人員直接在這些自動生成的測試方法中添加單元測試代碼就可以了。

第二類單獨(dú)測試，如果只想單獨(dú)對某個方法、屬性、字段進(jìn)行測試，則可以將鼠標(biāo)焦點(diǎn)放在這個待測試的項目名稱之上，然后點(diǎn)擊鼠標(biāo)右鍵，在右鍵菜單中選擇創(chuàng)建單元測試選項。這樣就可以單獨(dú)為某個方法創(chuàng)建單元測試了。

運(yùn)行單元測試

查看測試結(jié)果

編寫單元測試代碼

測試沒有參數(shù)的函數(shù)，它可能還有別的輸入，例如全局變量，成員變量，或調(diào)用子函數(shù)獲得的輸入（這個要使用工具才能做到），只要函數(shù)需讀取的，都應(yīng)該設(shè)定初始值，如果完全沒有，沒有輸入也是一種輸入，照樣測試就是了。同樣道理，輸出也不僅僅是返回值，沒有返回值還可能修改了全局變量什么的，這些也是要判斷的輸出。

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

參考回答：

在軟件工程中，壓力測試是對系統(tǒng)不斷施加壓力的測試，是通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點(diǎn)，來獲得系統(tǒng)能提供的最大服務(wù)級別的測試。例如測試一個Web 站點(diǎn)在大量的負(fù)荷下，何時系統(tǒng)的響應(yīng)會退化或失敗。

41. 對于有系統(tǒng)大量并發(fā)訪問，你會如何做測試，有什么建議

參考回答：

如何做高并發(fā)系統(tǒng)的測試，一般而言，整體的測試策略是：先針對部分系統(tǒng)進(jìn)行性能測試及壓力測試，得到各部分的峰值處理性能，再模擬整體流程測試，重點(diǎn)測試整體業(yè)務(wù)流程以及業(yè)務(wù)預(yù)期負(fù)荷，著重測試以下幾點(diǎn)：

不同省份，不同運(yùn)營商CDN節(jié)點(diǎn)性能，可采用典型壓力測試方案

核心機(jī)房BGP網(wǎng)絡(luò)帶寬，此部分重點(diǎn)在于測試各運(yùn)行商的BGP網(wǎng)絡(luò)可靠性，實(shí)際速率，一般采用smokeping,lxChariot等工具

各類硬件設(shè)備性能，一般采用專業(yè)的網(wǎng)絡(luò)設(shè)備測試工具

各類服務(wù)器并發(fā)性能，分布式處理能力，可采用壓力測試方案工具

業(yè)務(wù)系統(tǒng)性能，采用業(yè)務(wù)系統(tǒng)壓力測試方案

數(shù)據(jù)庫處理性能，這部分需要結(jié)合業(yè)務(wù)系統(tǒng)進(jìn)行測試，以獲取核心業(yè)務(wù)場景下的數(shù)據(jù)庫的TPS/QPS，

如果有支付功能，需要進(jìn)行支付渠道接口及分流測試，此部分相對而言可能是最大的瓶頸所在，此外還涉及備份方案，容災(zāi)方案，業(yè)務(wù)降級方案的測試。

?最后也為大家準(zhǔn)備了一份配套的學(xué)習(xí)資源，你能在 公眾號：【傷心的辣條】免費(fèi)獲取一份216頁軟件測試工程師面試寶典文檔資料。以及相對應(yīng)的視頻學(xué)習(xí)教程免費(fèi)分享！，其中資料包括了有基礎(chǔ)知識、Linux必備、Shell、互聯(lián)網(wǎng)程序原理、Mysql數(shù)據(jù)庫、抓包工具專題、接口測試工具、測試進(jìn)階-Python編程、Web自動化測試、App自動化測試、接口自動化測試、測試高級持續(xù)集成、測試架構(gòu)開發(fā)測試框架、性能測試、安全測試等。