软件测试实例 面试经验
● 請你說一說簡單用戶界面登陸過程都需要做哪些分析？
一、功能測試
1.輸入正確的用戶名和密碼，點(diǎn)擊提交按鈕，驗(yàn)證是否能正確登錄。
2.輸入錯誤的用戶名或者密碼,驗(yàn)證登錄會失敗，并且提示相應(yīng)的錯誤信息。
3.登錄成功后能否能否跳轉(zhuǎn)到正確的頁面
4.用戶名和密碼，如果太短或者太長，應(yīng)該怎么處理
5.用戶名和密碼，中有特殊字符（比如空格），和其他非英文的情況
6.記住用戶名的功能
7.登陸失敗后，不能記錄密碼的功能
8.用戶名和密碼前后有空格的處理
9.密碼是否非明文顯示顯示，使用星號圓點(diǎn)等符號代替。
10.牽扯到驗(yàn)證碼的，還要考慮文字是否扭曲過度導(dǎo)致辨認(rèn)難度大，考慮顏色（色盲使 用者），刷新或換一個按鈕是否好用
11.登錄頁面中的注冊、忘記密碼，登出用另一帳號登陸等鏈接是否正確
12.輸入密碼的時候，大寫鍵盤開啟的時候要有提示信息。
13.什么都不輸入，點(diǎn)擊提交按鈕，檢查提示信息。
二、界面測試
1.布局是否合理，testbox和按鈕是否整齊。
2.testbox和按鈕的長度，高度是否復(fù)合要求。
界面的設(shè)計(jì)風(fēng)格是否與UI的設(shè)計(jì)風(fēng)格統(tǒng)一。
界面中的文字簡潔易懂，沒有錯別字。
三、性能測試
1.打開登錄頁面，需要的時間是否在需求要求的時間內(nèi)。
2.輸入正確的用戶名和密碼后，檢查登錄成功跳轉(zhuǎn)到新頁面的時間是否在需求要求的時間內(nèi)。
3.模擬大量用戶同時登陸，檢查一定壓力下能否正常登陸跳轉(zhuǎn)。
四、安全性測試
1.登錄成功后生成的Cookie，是否是httponly (否則容易被腳本盜取)。
2.用戶名和密碼是否通過加密的方式，發(fā)送給Web服務(wù)器。
3.用戶名和密碼的驗(yàn)證，應(yīng)該是用服務(wù)器端驗(yàn)證， 而不能單單是在客戶端用javascript 驗(yàn)證。
4.用戶名和密碼的輸入框，應(yīng)該屏蔽SQL注入攻擊。
5.用戶名和密碼的的輸入框，應(yīng)該禁止輸入腳本 （防止XSS攻擊）。
6.防止暴力破解，檢測是否有錯誤登陸的次數(shù)限制。
是否支持多用戶在同一機(jī)器上登錄。
同一用戶能否在多臺機(jī)器上登錄。
五、可用性測試
是否可以全用鍵盤操作，是否有快捷鍵。
輸入用戶名，密碼后按回車，是否可以登陸。
輸入框能否可以以Tab鍵切換。
六、兼容性測試
1.不同瀏覽器下能否顯示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）。
2.同種瀏覽器不同版本下能否顯示正常且功能正常。
2.不同的平臺是否能正常工作，比如Windows, Mac。
3.移動設(shè)備上是否正常工作，比如Iphone, Andriod。
4.不同的分辨率下顯示是否正常。
七、本地化測試
● 請對這個系統(tǒng)做出測試用例：一個系統(tǒng)，多個攝像頭，抓拍車牌，識別車牌，上傳網(wǎng)上，網(wǎng)上展示
功能：
1.每個攝像頭都能抓拍車牌；
2.每個攝像頭抓拍到的車牌能正常交給系統(tǒng)處理；
3.系統(tǒng)能夠正確識別車牌；
4.系統(tǒng)能夠?qū)⒆R別出的車牌上傳；
5.上傳至網(wǎng)絡(luò)的車牌能夠正常展示出來；
一、功能測試
1.使用正常的車牌，保持車牌靜止，檢查每個攝像頭是否能抓拍車牌；
2.使用類似非車牌的寫有字的紙板，檢查每個攝像頭是否抓拍；
3.使用正常的車牌，保持車牌較高速移動，檢查每個攝像頭是否能抓拍車牌；
4.在多種情況下檢查每個攝像頭抓拍到的車牌能否正常交給系統(tǒng)處理，如臨時斷電、斷網(wǎng)后能否正常將數(shù)據(jù)交給系統(tǒng)；
5.使用抓拍到的正常的車牌，交由系統(tǒng)處理，檢查系統(tǒng)能否識別車牌；
6.使用非車牌的其他圖片，交由系統(tǒng)處理，檢查系統(tǒng)能否識別；
7.在多種情況下檢查系統(tǒng)能否將正常識別出的車牌進(jìn)行上傳，如臨時斷電、斷網(wǎng)后未上傳數(shù)據(jù)是否能繼續(xù)上傳；
8.構(gòu)造非車牌的其他內(nèi)容的數(shù)據(jù)，檢查系統(tǒng)能否將異常內(nèi)容進(jìn)行上傳；
9.檢查上傳至網(wǎng)絡(luò)的車牌能否正常展示出來；
10.上傳非車牌的其他內(nèi)容的數(shù)據(jù)，檢查能否正常顯示出來。
二、性能測試
1.同時向一個攝像頭展示多個靜止的車牌，檢查攝像頭能否抓拍到多個車牌；
2.同時向一個攝像頭展示多個較高速運(yùn)動的車牌，檢查攝像頭能否抓拍到多個車牌；
3.抓拍后，檢查系統(tǒng)識別車牌的時間是否在需求要求的時間內(nèi)；
4.模擬大量抓拍照片同時交由系統(tǒng)處理，檢查一定壓力下系統(tǒng)能否正常識別車牌；
5.模擬大量車牌同時上傳，檢查一定壓力下能否上傳成功。
三、安全性測試
1.檢查是否能夠通過給車牌加裝飾物等方法，使攝像頭無法抓拍或抓拍后系統(tǒng)無法正常識別車牌。
● 請你對吃雞游戲進(jìn)行壓力測試
一.首先明確需要測試壓力的內(nèi)容:
1.游戲服務(wù)器硬件
a.硬盤I/o
b.內(nèi)存
c.CPU
2.網(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í)際處理能力
3.數(shù)據(jù)庫
a.每秒事務(wù)數(shù)
b.每秒鎖等待數(shù)
c.平均延時(ms)
d.CPU暫用
4.多線程的最優(yōu)線程數(shù)
a.數(shù)據(jù)庫執(zhí)行的多線程
b.多連接處理
二.Windows Server環(huán)境測試方式
1.服務(wù)器性能監(jiān)測
使用Server自帶的性能監(jiān)測器設(shè)置各個進(jìn)程的監(jiān)測參數(shù)。Window的這個自動工具做的相當(dāng)強(qiáng)大。大家自己摸一摸基本就會用了。每個參數(shù)都由詳細(xì)的說明。
2.案例設(shè)計(jì)注意
a.對于數(shù)據(jù)庫的性能測試上，現(xiàn)在由于所有的游戲服務(wù)器構(gòu)架在DB前面都有一個實(shí)現(xiàn)DB緩沖功能的進(jìn)程，以減少數(shù)據(jù)庫頻繁的讀寫操作。所以其實(shí)數(shù)據(jù)庫的讀是一個輕量級的數(shù)量；而數(shù)據(jù)庫的寫操作是一個周期性能過程。案例設(shè)計(jì)一定要能夠驅(qū)動這種周期性能過程。比如我們游戲的戰(zhàn)斗，導(dǎo)致游戲玩家數(shù)據(jù)的改變，或驅(qū)動所有在線玩家數(shù)據(jù)的周期性存儲。
b.選擇具有代表性，并且最頻繁的游戲操作。用于進(jìn)行最高用戶在線的各種性能指標(biāo)采集。如，開槍、道具拾取、道具使用、移動、聊天
c.聊天性能測試
廣播聊天是最為考驗(yàn)游戲信息發(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ù)器效率
3.細(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)卡，以及相互的帶寬。不然可能因?yàn)橄嗷?#xff0c;導(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)流量。
● 請你根據(jù)微信登錄界面設(shè)計(jì)測試用例
參考回答：
一、功能測試
1.輸入正確的用戶名和密碼，點(diǎn)擊提交按鈕，驗(yàn)證是否能正確登錄。
2.輸入錯誤的用戶名或者密碼,驗(yàn)證登錄會失敗，并且提示相應(yīng)的錯誤信息。
3.登錄成功后能否能否跳轉(zhuǎn)到正確的頁面
4.檢查能否選擇不同登錄方式進(jìn)行登錄，如使用手機(jī)號登錄、使用微信號登錄或掃碼登錄。
5.記住用戶名的功能
6.登陸失敗后，不能記錄密碼的功能
7.密碼是否非明文顯示顯示，使用星號圓點(diǎn)等符號代替。
8.有驗(yàn)證碼時，還要考慮文字是否扭曲過度導(dǎo)致辨認(rèn)難度大，考慮顏色、刷新或換一個按鈕是否好用
9.登錄頁面中的注冊、忘記密碼，登出用另一帳號登陸等鏈接是否正確
10.輸入密碼的時候，大寫鍵盤開啟的時候要有提示信息。
11.什么都不輸入，點(diǎn)擊提交按鈕，檢查提示信息。
二、界面測試
1.布局是否合理，testbox和按鈕是否整齊。
2.testbox和按鈕的長度，高度是否復(fù)合要求。
界面的設(shè)計(jì)風(fēng)格是否與UI的設(shè)計(jì)風(fēng)格統(tǒng)一。
界面中的文字簡潔易懂，沒有錯別字。
三、性能測試
1.打開登錄頁面，需要的時間是否在需求要求的時間內(nèi)。
2.輸入正確的用戶名和密碼后，檢查登錄成功跳轉(zhuǎn)到新頁面的時間是否在需求要求的時間內(nèi)。
3.模擬大量用戶同時登陸，檢查一定壓力下能否正常登陸跳轉(zhuǎn)。
四、安全性測試
1.登錄成功后生成的Cookie，是否是httponly (否則容易被腳本盜取)。
2.用戶名和密碼是否通過加密的方式，發(fā)送給Web服務(wù)器。
3.用戶名和密碼的驗(yàn)證，應(yīng)該是用服務(wù)器端驗(yàn)證， 而不能單單是在客戶端用javascript 驗(yàn)證。
4.用戶名和密碼的輸入框，應(yīng)該屏蔽SQL注入攻擊。
5.用戶名和密碼的的輸入框，應(yīng)該禁止輸入腳本 （防止XSS攻擊）。
6.防止暴力破解，檢測是否有錯誤登陸的次數(shù)限制。
是否支持多用戶在同一機(jī)器上登錄。
同一用戶能否在多臺機(jī)器上登錄。
五、兼容性測試
1.不同移動平臺或PC環(huán)境下下能否顯示正常且功能正常
2.同種平臺下不同微信版本下能否顯示正常且功能正常。
3.不同的分辨率下顯示是否正常。
七、本地化測試
● 請你對朋友圈點(diǎn)贊功能進(jìn)行測試
參考回答：
1.是否可以正常點(diǎn)贊和取消；
2.點(diǎn)贊的人是否在可見分組里；
3.點(diǎn)贊狀態(tài)是否能即時更新顯示；
4.點(diǎn)贊狀態(tài)，共同好友是否可見；
6.性能檢測，網(wǎng)速快慢對其影響；
7.點(diǎn)贊顯示的是否正確，一行幾個；
8.點(diǎn)贊是否按時間進(jìn)行排序，頭像對應(yīng)的是否正確；
9.是否能在消息列表中顯示點(diǎn)贊人的昵稱、5.不同手機(jī)，系統(tǒng)顯示界面如何；
備注；
10.可擴(kuò)展性測試，點(diǎn)贊后是否能發(fā)表評論；
11.是否在未登錄時可查看被點(diǎn)贊的信息。
● 請你設(shè)計(jì)一個微信朋友圈點(diǎn)贊的測試用例
參考回答：
功能測試：
點(diǎn)贊某條朋友圈，驗(yàn)證是否成功
接口測試：
點(diǎn)贊朋友圈，驗(yàn)證朋友能否收到提示信息
性能測試
點(diǎn)贊朋友圈，是否在規(guī)定時間顯示結(jié)果，是否在規(guī)定時間在朋友手機(jī)上進(jìn)行提示
兼容性測試
在不同的終端比如ipad,手機(jī)上點(diǎn)贊朋友圈，驗(yàn)證是否成功
● 如果做一個杯子的檢測，你如何測試
參考回答：
1.功能
（1）水倒水杯容量的一半
（2）水倒規(guī)定的安全線
（4）水杯容量刻度與其他水杯一致
（5）蓋子擰緊水倒不出來
（6）燙手驗(yàn)證
2.性能
（1）使用最大次數(shù)或時間
（2）掉地上不易損壞
（3）蓋子擰到什么程度水倒不出來
（4）保溫時間長
（5）杯子的耐熱性
（6）杯子的耐寒性
（7）長時間放置水不會漏
（8）杯子上放置重物達(dá)到什么程度杯子會被損壞
3.界面
（1）外觀完整、美觀
（2）大小與設(shè)計(jì)一樣（高、寬、容量、直徑）
（3）拿著舒服
（4）材質(zhì)與設(shè)計(jì)一樣
（5）杯子上的圖案掉落
（6）圖案遇水溶解
4.安全
（1）杯子使用的材質(zhì)毒或細(xì)菌的驗(yàn)證
（2）高溫材質(zhì)釋放毒性
（3）低溫材質(zhì)釋放毒性
5.易用性
（1）倒水方便
（2）喝水方便
（3）攜帶方便
（4）使用簡單，容易操作
（5）防滑措施
6.兼容性
（1）杯子能夠容納果汁、白水、酒精、汽油等。
7.震動測試
（1）杯子加包裝（有填充物），六面震動，檢查產(chǎn)品是否能應(yīng)對鐵路/公路/航空運(yùn)輸。
8.可移植性
（1）杯子在不同地方、溫度環(huán)境下都可以正常使用。
● 如何對一個頁面進(jìn)行測試
參考回答：
1、UI測試：頁面布局、頁面樣式檢查、控件長度是否夠長；顯示時，是否會被截?cái)?#xff1b;支持的快捷鍵，Tab鍵切換焦點(diǎn)順序正確性等。
2、功能測試：頁面上各類控件的測試范圍，測試點(diǎn)。結(jié)合控件的實(shí)際作用來補(bǔ)充檢查點(diǎn)： 比如， 密碼框是否*顯示， 輸入是否做trim處理等。
3、安全測試：輸入特殊字符，sql注入，腳本注入測試。后臺驗(yàn)證測試，對于較重要的表單 ，繞過js檢驗(yàn)后臺是否驗(yàn)證；數(shù)據(jù)傳輸是否加密處理，比如， 直接請求轉(zhuǎn)發(fā)，地址欄直接顯示發(fā)送字符串？
4、兼容性測試
5、性能測試
● 如何對淘寶搜索框進(jìn)行測試
參考回答：
一, 功能測試
1.1輸入可查到結(jié)果的正常關(guān)鍵字、詞、語句，檢索到的內(nèi)容、鏈接正確性；
1.2輸入不可查到結(jié)果的關(guān)鍵字、詞、語句；
1.3輸入一些特殊的內(nèi)容，如空、特殊符、標(biāo)點(diǎn)符、極限值等，可引入等價類劃分的方法等；
結(jié)果顯示：標(biāo)題，賣家，銷售量，單行/多行，是否有圖片
結(jié)果排序：價格 銷量 評價 綜合
4.返回結(jié)果龐大時，限制第一頁的現(xiàn)實(shí)量，需支持翻頁
多選項(xiàng)搜索：關(guān)鍵字 品牌 產(chǎn)地 價格區(qū)間 是否天貓 是否全國購
是否支持模糊搜索，支持通配符的查詢
7, 網(wǎng)速慢的情況下的搜索
搜索結(jié)果為空的情況
未登錄情況和登錄情況下的搜索（登錄情況下 存儲用戶搜索的關(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è)計(jì)是否便于、易于使用
1依據(jù)不同的查詢結(jié)果會有相關(guān)的人性化提示，查不到時告知？查到時統(tǒng)計(jì)條數(shù)并告知？有疑似輸入條件錯誤時提示可能正確的輸入項(xiàng)等等處理；
2查詢出的結(jié)果羅列有序，如按點(diǎn)擊率或其他排序規(guī)則，確保每次查詢出的結(jié)果位置按規(guī)則列示方便定位，顯示字體、字號、色彩便于識別等等；
3標(biāo)題查詢、全文檢索、模糊查詢、容錯查詢、多關(guān)鍵字組織查詢（空格間格開）等實(shí)用的檢索方式是否正常？
4輸入搜索條件的控件風(fēng)格設(shè)計(jì)、位置擺放是否醒目便于使用者注意到，有否快照等快捷查看方式等人性化設(shè)計(jì)？
四. 兼容性
1WINDOWS/LINUX/UNIX等各類操作系統(tǒng)下及各版本條件下的應(yīng)用
2IE/FIREFOX/GOOGLE/360/QQ等各類瀏覽器下及各版本條件下、各種顯示分辨率條件下的應(yīng)用
3SQL/ORACLE/DB2/MYSQL等各類數(shù)據(jù)庫存儲情況下的兼容性測試
4簡體中文、繁體中文、英文等各類語種軟件平臺下的兼容性測試
5IPHONE/IPAD、安卓等各類移動應(yīng)用平臺下的兼容性測試
6與各相關(guān)的監(jiān)控程序的兼容性測試，如輸入法、殺毒、監(jiān)控、防火墻等工具同時使用
五. 安全性
1被刪除、加密、授權(quán)的數(shù)據(jù)，不允許被SQL注入等攻擊方式查出來的，是否有安全控制設(shè)計(jì)；
2錄入一些數(shù)據(jù)庫查詢的保留字符，如單引號、%等等，造成查詢SQL拼接出的語句產(chǎn)生漏洞，如可以查出所有數(shù)據(jù)等等，這方面要有一些黑客攻擊的思想并引入一些工具和技術(shù)，如爬網(wǎng)等。
3通過白盒測試技術(shù)，檢查一下在程序設(shè)計(jì)上是否存在安全方面的隱患；
4對涉及國家安全、法律禁止的內(nèi)容是否進(jìn)行了相關(guān)的過濾和控制；
● 如何對一瓶礦泉水進(jìn)行測試
參考回答：
界面測試:查看外觀是否美觀
功能度：查看水瓶漏不漏；瓶中水能不能被喝到
安全性：瓶子的材質(zhì)有沒有毒或細(xì)菌
可靠性：從不同高度落下的損壞程度
可移植性：再不同的地方、溫度等環(huán)境下是否都可以正常使用
兼容性：是否能夠容納果汁、白水、酒精、汽油等
易用性：是否燙手、是否有防滑措施、是否方便飲用
用戶文檔：使用手冊是否對的用法、限制、使用條件等有詳細(xì)描述
疲勞測試：將盛上水（案例一）放24小時檢查泄漏時間和情況；盛上汽油（案例二）放24小時檢查泄漏時間和情況等
壓力測試：用根針并在針上面不斷加重量，看壓強(qiáng)多大時會穿透
跌落測試:測試在何種高度跌落會破壞水瓶
● 請你來說一下購物車的測試用例
參考回答：
界面測試
? 界面布局、排版是否合理；文字是否顯示清晰；不同賣家的商品是否區(qū)分明顯。
2.功能測試
未登錄時：
? 將商品加入購物車，頁面跳轉(zhuǎn)到登錄頁面，登錄成功后購物車數(shù)量增加；
? 點(diǎn)擊購物車菜單，頁面跳轉(zhuǎn)到登錄頁面。
登錄后：
? 所有鏈接是否跳轉(zhuǎn)正確；
? 商品是否可以成功加入購物車；
? 購物車商品總數(shù)是否有限制；
? 商品總數(shù)是否正確；
? 全選功能是否好用；
? 刪除功能是否好用；
? 填寫委托單功能是否好用；
? 委托單中填寫的價格是否正確顯示；
? 價格總計(jì)是否正確；
? 商品文字太長時是否顯示完整；
? 店鋪名字太長時是否顯示完整；
? 創(chuàng)新券商品是否打標(biāo)；
? 購物車中下架的商品是否有特殊標(biāo)識；
? 新加入購物車商品排序（添加購物車中存在店鋪的商品和購物車中不存在店鋪的商品）；
? 是否支持TAB、ENTER等快捷鍵；
? 商品刪除后商品總數(shù)是否減少；
? 購物車結(jié)算功能是否好用。
3.兼容性測試
? 不同瀏覽器測試。
4.易用性測試
? 刪除功能是否有提示；是否有回到頂部的功能；商品過多時結(jié)算按鈕是否可以浮動顯示。
5.性能測試
? 壓力測試；并發(fā)測試。
● 你寫的測試程序是怎么樣的，你寫過前端、后端程序嗎？
參考回答：
開發(fā)測試驅(qū)動程序一般分為4步：
1，指出需要的新特性。可以記錄下來，然后為其編寫一個測試。
2，編寫特性的概要代碼，這樣程序就可以運(yùn)行而沒有任何語法等方面的錯誤，但是測試會失敗。看到測試失敗是很重要的，這樣就能確定測試可以失敗。如果測試代碼中出現(xiàn)了錯誤，那么就有可能出現(xiàn)任何情況，測試都會成功，這樣等于沒測試任何東西。再強(qiáng)調(diào)一遍：在試圖測試成功之前，先要看到它失敗。
3，為特性的概要編寫虛設(shè)代碼，能滿足測試要求就行。不用準(zhǔn)確的實(shí)現(xiàn)功能，只要保證測試可以通過即可。這樣一來就可以保證在開發(fā)的時候總是通過測試了，（除了第一次測試的時候）甚至在最初實(shí)現(xiàn)功能時亦是如此。
4，現(xiàn)在重寫（或者重構(gòu)）代碼，這樣它就會做自己應(yīng)該做的事，從而保證測試一直成功。
在編碼完成時，應(yīng)該保證代碼處于健康狀態(tài)–不要遺留下任何測試失敗。
● 對于有系統(tǒng)大量并發(fā)訪問，你會如何做測試，有什么建議
參考回答：
如何做高并發(fā)系統(tǒng)的測試，一般而言，整體的測試策略是：先針對部分系統(tǒng)進(jìn)行性能測試及壓力測試，得到各部分的峰值處理性能，再模擬整體流程測試，重點(diǎn)測試整體業(yè)務(wù)流程以及業(yè)務(wù)預(yù)期負(fù)荷，著重測試以下幾點(diǎn)：
1、不同省份，不同運(yùn)營商CDN節(jié)點(diǎn)性能，可采用典型壓力測試方案
2、核心機(jī)房BGP網(wǎng)絡(luò)帶寬，此部分重點(diǎn)在于測試各運(yùn)行商的BGP網(wǎng)絡(luò)可靠性，實(shí)際速率，一般采用smokeping,lxChariot等工具
3、各類硬件設(shè)備性能，一般采用專業(yè)的網(wǎng)絡(luò)設(shè)備測試工具
4、各類服務(wù)器并發(fā)性能，分布式處理能力，可采用壓力測試方案工具
5、業(yè)務(wù)系統(tǒng)性能，采用業(yè)務(wù)系統(tǒng)壓力測試方案
6、數(shù)據(jù)庫處理性能，這部分需要結(jié)合業(yè)務(wù)系統(tǒng)進(jìn)行測試，以獲取核心業(yè)務(wù)場景下的數(shù)據(jù)庫的TPS/QPS，
7、如果有支付功能，需要進(jìn)行支付渠道接口及分流測試，此部分相對而言可能是最大的瓶頸所在，此外還涉及備份方案，容災(zāi)方案，業(yè)務(wù)降級方案的測試。
● 請你回答一下性能測試有哪些指標(biāo)，對一個登錄功能做性能測試，有哪些指標(biāo)，怎么測出可同時處理的最大請求數(shù)量
參考回答：
性能測試常用指標(biāo)：
從外部看，主要有
1、吞吐量：每秒鐘系統(tǒng)能夠處理的請求數(shù)，任務(wù)數(shù)
2、響應(yīng)時間：服務(wù)處理一個請求或一個任務(wù)的耗時
3、錯誤率：一批請求中結(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)隊(duì)出品，使用起來很簡單方便，但測試功能相當(dāng)強(qiáng)大，能提供10w+以上的并發(fā)量，定位性能拐點(diǎn)，測出服務(wù)器模型最大并發(fā)
● 請問你有沒有做過什么單元測試，怎么進(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)建單元測試選項(xiàng)。這樣就可以為整個類創(chuàng)建單元測試了，這時他會為整個類可以被測試的內(nèi)容全部添加測試方法。開發(fā)人員直接在這些自動生成的測試方法中添加單元測試代碼就可以了。
單獨(dú)測試，如果只想單獨(dú)對某個方法、屬性、字段進(jìn)行測試，則可以將鼠標(biāo)焦點(diǎn)放在這個待測試的項(xiàng)目名稱之上，然后點(diǎn)擊鼠標(biāo)右鍵，在右鍵菜單中選擇創(chuàng)建單元測試選項(xiàng)。這樣就可以單獨(dú)為某個方法創(chuàng)建單元測試了。
運(yùn)行單元測試
查看測試結(jié)果
編寫單元測試代碼
測試沒有參數(shù)的函數(shù)，它可能還有別的輸入，例如全局變量，成員變量，或調(diào)用子函數(shù)獲得的輸入（這個要使用工具才能做到），只要函數(shù)需讀取的，都應(yīng)該設(shè)定初始值，如果完全沒有，沒有輸入也是一種輸入，照樣測試就是了。同樣道理，輸出也不僅僅是返回值，沒有返回值還可能修改了全局變量什么的，這些也是要判斷的輸出。
● 請你說一說當(dāng)前工作中涉及的測試問題(測試流程和測試性能)
參考回答：
在測試性能中，時常會出現(xiàn)腳本回訪卡住的問題，原因有以下幾種：
1、 runtimesetting 中的continue error沒有勾選
2、錄制的腳本中存在冗余的代碼部分，需要對腳本進(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)的問題不止一處，在查找時一定要注意。），這是因?yàn)椴捎胒irefox瀏覽器錄制時產(chǎn)生的壓縮文件，在腳本回放時卡住的原因正是因?yàn)檫@個（建議：能采用IE錄制盡量用IE瀏覽器）
解決辦法：注釋掉或者刪除掉該段代碼即可， 關(guān)聯(lián)問題：在用loadrunner自帶對比工具對比腳本后 找到需要關(guān)聯(lián)的動態(tài)值。在關(guān)聯(lián)后回放腳本時報(bào)錯HTTP-status code 417（exception failed）錯誤時，產(chǎn)生的原因如下：
1、腳本中還存在沒有關(guān)聯(lián)或者關(guān)聯(lián)失敗的動態(tài)值，利用lr自帶對比工具仔細(xì)對比
2、腳本中的動態(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ù)）
● 請你說一下能不能用機(jī)器學(xué)習(xí)去進(jìn)行自動化測試，如何監(jiān)控異常流量，如果是脈沖呢，如何和正常流量作區(qū)分
參考回答：
如何用機(jī)器學(xué)習(xí)去進(jìn)行自動化測試，就是讓自動化測試變得更加智能，在自動化測試過程中，當(dāng)測試功能模塊越來越多，沒有太多的時間去全部覆蓋，我們可以采用歸納學(xué)習(xí)的方式，基于自動化測試的執(zhí)行結(jié)果或者手工測試執(zhí)行的結(jié)果為數(shù)據(jù)輸入，然后基于一定的模型（例如：以通過率和模塊的重要率計(jì)算的平均值）得出測試推薦模塊，或者當(dāng)要執(zhí)行一個功能模塊時，基于歷史數(shù)據(jù)和模型（bug出現(xiàn)的錯誤相關(guān)性，功能相關(guān)性等）計(jì)算出與該功能模塊相關(guān)性最大模塊，并推薦測試。
如何監(jiān)控異常流量
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
● 請問如果用戶點(diǎn)擊微博的關(guān)注圖標(biāo)但是app上面沒有反應(yīng)，應(yīng)該怎么排查這個問題
參考回答：
首先1.在Eclipse Devices窗口，選中app對應(yīng)的包名，然后點(diǎn)擊debug圖標(biāo)（綠色的小蟲子），然后切換到Debug視圖。
2.切換視圖之后，可以看到debug下，app的線程列表。
3.對于main線程（第一個線程），選中，并將其掛起Suspend。
4.然后我們就可以看到，Suspend之后，main線程卡住的位置。
● 請問你有沒有寫過測試腳本，怎么寫的？
參考回答：
然后，撰寫測試樁與驅(qū)動，白盒測試保證代碼邏輯中循環(huán)和分支都能夠走到，黑盒測試保證函數(shù)和首先，代碼走查結(jié)合動態(tài)單步跟蹤以及觀察日志與文件輸出，網(wǎng)絡(luò)、CPU狀態(tài)。
功能腳本接口正確，輸入輸出符合設(shè)計(jì)預(yù)期。
對于異常處理，特別是變量的檢查需要特別關(guān)注，變量在使用前都需要進(jìn)行檢查，是否為空？或者為0？對于文件名和路徑必須檢查，確認(rèn)文件是否存在，路徑是否可達(dá)之后再進(jìn)行后續(xù)操作。
另外，需要考慮所依賴的其他功能腳本以及二進(jìn)制工具，這些功能性單元應(yīng)該如何使用，調(diào)用后的返回會有哪些情況，對于正常和異常結(jié)果，腳本是否能夠捕捉到并且作出正確的判斷。
● 請問你有沒有寫過web測試，怎么寫的？
參考回答：
Web測試主要從下面幾個大方向考慮
功能測試，主要做鏈接測試，表單測試，cookies測試，設(shè)計(jì)語言測試等
性能測試，考慮連接速度測試，以及負(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)行兼容性測試。
安全性測試，
（1）現(xiàn)在的Web應(yīng)用系統(tǒng)基本采用先注冊，后登陸的方式。因此，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。
（2）Web應(yīng)用系統(tǒng)是否有超時的限制，也就是說，用戶登陸后在一定時間內(nèi)（例如15分鐘）沒有點(diǎn)擊任何頁面，是否需要重新登陸才能正常使用。
（3）為了保證Web應(yīng)用系統(tǒng)的安全性，日志文件是至關(guān)重要的。需要測試相關(guān)信息是否寫進(jìn)了日志文件、是否可追蹤。
（4）當(dāng)使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。
（5）服務(wù)器端的腳本常常構(gòu)成安全漏洞，這些漏洞又常常被黑客利用。所以，還要測試沒有經(jīng)過授權(quán)，就不能在服務(wù)器端放置和編輯腳本的問題。
● 請問測試路由器怎么測，用命令行還是界面？
參考回答：
可以采用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。
● 請你回答一下如何測試手機(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ì)是否貼合手指，開機(jī)鍵的位置設(shè)計(jì)是否方便
● 請問你遇到過哪些印象深刻的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)限未處理，可以訪問其他用戶的信息
邏輯校驗(yàn)不完善，可以利用漏洞獲取非正當(dāng)利益
狀態(tài)處理不當(dāng)，導(dǎo)致邏輯出現(xiàn)錯誤
數(shù)組類型item個數(shù)為0或者item重復(fù)時程序異常退出
● 你在做項(xiàng)目中有做過壓力測試嗎，怎么做
參考回答：
1、首先對要測試的系統(tǒng)進(jìn)行分析，明確需要對那一部分做壓力測試，比如秒殺，支付
2、如何對這些測試點(diǎn)進(jìn)行施壓
第一種方式可以通過寫腳本產(chǎn)生壓力機(jī)器人對服務(wù)器進(jìn)行發(fā)包收報(bào)操作
第二點(diǎn)借助一些壓力測試工具比如Jmeter,LoadRunner
3、如何對這些測試點(diǎn)進(jìn)行正確的施壓
需要用壓力測試工具或者其他方法錄制腳本，模擬用戶的操作
4、對測試點(diǎn)設(shè)計(jì)多大的壓力比較合適？
需要明確壓力測試限制的數(shù)量，即用戶并發(fā)量
5、測試結(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)的哪一塊造成的
● 請問你在項(xiàng)目中關(guān)于功能測試和接口測試是怎么做的
參考回答：
功能測試：
首先制定測試計(jì)劃，然后進(jìn)行測試設(shè)計(jì)，將在測試計(jì)劃階段指定的測試活動分解，進(jìn)而細(xì)化，為若干個可執(zhí)行程序的子測試過程，然后執(zhí)行測試，按照測試計(jì)劃使用測試用例對待測項(xiàng)目進(jìn)行逐一的，詳細(xì)的排查分析評估，最后對測試結(jié)果進(jìn)行統(tǒng)計(jì)和分析，
接口測試：
什么是接口（API）
API全稱Application Programming Interface，這里面我們其實(shí)不用去關(guān)注AP，只需要I上就可以。一個API就是一個Interface。我們無時不刻不在使用interfaces。我們乘坐電梯里面的按鈕是一個interface。我們開車一個踩油門它也是一個interface。我們計(jì)算機(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)行驗(yàn)證。
如今系統(tǒng)越來越復(fù)雜，傳統(tǒng)的靠前端測試已經(jīng)大大降低了效率，而且現(xiàn)在我們都推崇測試前移，希望測試能更早的介入測試，那接口測試就是一種及早介入的方式。例如傳統(tǒng)測試，你是不是得等前后端都完成你才能進(jìn)行測試，才能進(jìn)行自動化代碼編寫。而如果是接口測試，只需要前后端定義好接口，那這時自動化就可以介入編寫接口自動化測試代碼，手工測試只需要后端代碼完成就可以介入測試后端邏輯而不用等待前端工作完成。
接口測試的策略
接口測試也是屬于功能測試，所以跟我們以往的功能測試流程并沒有太大區(qū)別，測試流程依舊是：1.測試接口文檔（需求文檔） 2.根據(jù)接口文檔編寫測試用例（用例編寫完全可以按照以往規(guī)則來編寫，例如等價類劃分，邊界值等設(shè)計(jì)方法）3. 執(zhí)行測試，查看不同的參數(shù)請求，接口的返回的數(shù)據(jù)是否達(dá)到預(yù)期。
總結(jié)
以上是生活随笔為你收集整理的软件测试实例 面试经验的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： jsp java语法_JSP 语法 |
- 下一篇： OC 获取view相对位置_正版OC渲染