● 請問你有沒有寫過測驗腳本,怎么寫的?
參考回答:
然后,撰寫測驗樁與驅動,白盒測驗保證代碼邏輯中回圈和分支都能夠走到,黑盒測驗保證函式和首先,代碼走查結合動態單步跟蹤以及觀察日志與檔案輸出,網路、CPU狀態,功能腳本介面正確,輸入輸出符合設計預期,
對于例外處理,特別是變數的檢查需要特別關注,變數在使用前都需要進行檢查,是否為空?或者為0?對于檔案名和路徑必須檢查,確認檔案是否存在,路徑是否可達之后再進行后續操作,
另外,需要考慮所依賴的其他功能腳本以及二進制工具,這些功能性單元應該如何使用,呼叫后的回傳會有哪些情況,對于正常和例外結果,腳本是否能夠捕捉到并且作出正確的判斷,
● 請問你有沒有寫過web測驗,怎么寫的?
參考回答:
Web測驗主要從下面幾個大方向考慮功能測驗,主要做鏈接測驗,表單測驗,cookies測驗,設計語言測驗等
性能測驗,考慮連接速度測驗,以及負載測驗,例如:Web應用系統能允許多少個用戶同時在線?如果超過了這個數量,會出現什么現象?Web應用系統能否處理大量用戶對同一個頁面的請求?還有壓力測驗
可用性測驗,比如導航測驗,圖形測驗,內容測驗,整體界面測驗等
兼容性測驗,市場上有很多不同的作業系統型別,最常見的有Windows、Unix、Macintosh、Linux等,Web應用系統的最終用戶究竟使用哪一種作業系統,取決于用戶系統的配置,這樣,就可能會發生兼容性問題,同一個應用可能在某些作業系統下能正常運行,但在另外的作業系統下可能會運行失敗,因此,在Web系統發布之前,需要在各種作業系統下對Web系統進行兼容性測驗,
安全性測驗,
(1)現在的Web應用系統基本采用先注冊,后登陸的方式,因此,必須測驗有效和無效的用戶名和密碼,要注意到是否大小寫敏感,可以試多少次的限制,是否可以不登陸而直接瀏覽某個頁面等,
(2)Web應用系統是否有超時的限制,也就是說,用戶登陸后在一定時間內(例如15分鐘)沒有點擊任何頁面,是否需要重新登陸才能正常使用,
(3)為了保證Web應用系統的安全性,日志檔案是至關重要的,需要測驗相關資訊是否寫進了日志檔案、是否可追蹤,
(4)當使用了安全套接字時,還要測驗加密是否正確,檢查資訊的完整性,
(5)服務器端的腳本常常構成安全漏洞,這些漏洞又常常被黑客利用,所以,還要測驗沒有經過授權,就不能在服務器端放置和編輯腳本的問題,
● 請問測驗路由器怎么測,用命令列還是界面?
參考回答:
可以采用lperf這個命令,Lperf是一個網路性能測驗工具,可以測量最大tcp和udp帶寬,具有多種引數和特性,可以記錄帶寬,延遲抖動,資料包丟失,通過這些資訊可以發現網路問題,檢查網路質量,定位網路瓶頸,
iperf的使用非常簡單,測驗的原理是在wan口連接一臺PC機,在LAN口連接一臺PC,兩邊分別運行iperf服務端和客戶端模式,用來測量LAN->WAN和WAN->LAN性能,具體命令如下:
服務端:iperf -s -w 1m
客戶端:iperf -c <server ip> -w 1m -t 20 -P 10
含義是TCP wndowsize 為1MByte,測驗時間是20s,執行緒是10,
● 請你回答一下如何測驗手機開機鍵?
參考回答:
功能測驗:按下開機鍵,螢屏能否亮起
性能測驗:
按下開機鍵,螢屏能否在規定時間內亮起
壓力測驗
連續多次按下開機鍵,觀察螢屏是否能一直亮起,到多久時間失靈
健壯性測驗
給定一個中了病毒的手機或者是淘汰許久的老機子,安歇開機鍵觀察螢屏能否亮起
可靠性測驗
連續按下開機鍵有限次數,比如1萬次,記錄螢屏未亮起的次數
可用性測驗
開機鍵按下費不費力,開機鍵的形狀設計是否貼合手指,開機鍵的位置設計是否方便
● 請問你遇到過哪些印象深刻的bug,介面測驗出現bug的原因有哪些?
參考回答:
面試官詢問遇到過哪些印象深刻的bug,其實它并不關心你描述的這個bug是否真的有價值,或有多曲折離奇?他只是:了解你平時作業中的測驗能力所以,這就要求的你平時作業中遇到bug時試著自己去定位,定位bug的程序遠比你的單純的執行測驗用例有“價值”(自我技能提高的價值),在定位bug的程序中你需要掌握和運用更多知識,
另外,建議你平時養成總結的好習慣,發現的bug,開發解決了,最好問問他原因以及解決的方法,這樣再遇到類似問題時,自己也可以試著定位解決,遇到難解決的bug,也可以把最終的解決程序記錄下來,(這不是就有素材了)
所以,建議你平時可以主動要求去分享一些自己作業中用到或學習的技術,或者多去參加集體活動,加強自己的表達能力,From:蟲師
介面測驗常見的bug有以下幾個:
特殊值處理不當導致程式例外退出或者崩潰
型別邊界溢位,導致資料獨處和寫入不一致
取值邊界外未回傳正確的錯誤資訊
權限未處理,可以訪問其他用戶的資訊
邏輯校驗不完善,可以利用漏洞獲取非正當利益
狀態處理不當,導致邏輯出現錯誤
陣列型別item個數為0或者item重復時程式例外退出
● 你在做專案中有做過壓力測驗嗎,怎么做
參考回答:
1、首先對要測驗的系統進行分析,明確需要對那一部分做壓力測驗,比如秒殺,支付2、如何對這些測驗點進行施壓
第一種方式可以通過寫腳本產生壓力機器人對服務器進行發包收報操作
第二點借助一些壓力測驗工具比如Jmeter,LoadRunner
3、如何對這些測驗點進行正確的施壓
需要用壓力測驗工具或者其他方法錄制腳本,模擬用戶的操作
4、對測驗點設計多大的壓力比較合適?
需要明確壓力測驗限制的數量,即用戶并發量
5、測驗結束后如何通過這些資料來定位性能問題
通過測驗可以得到吞吐量,平均回應時間等資料,這個資料的背后是整個后臺處理邏輯綜合作用的結果,這時候就可以先關注系統的CPU,記憶體,然后對比吞吐量,平均回應時間達到瓶頸時這些資料的情況,然后就能確認性能問題是系統的哪一塊造成的
● 請問你在專案中關于功能測驗和介面測驗是怎么做的
參考回答:
功能測驗:首先制定測驗計劃,然后進行測驗設計,將在測驗計劃階段指定的測驗活動分解,進而細化,為若干個可執行程式的子測驗程序,然后執行測驗,按照測驗計劃使用測驗用例對待測專案進行逐一的,詳細的排查分析評估,最后對測驗結果進行統計和分析,
介面測驗:
什么是介面(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. 執行測驗,查看不同的引數請求,介面的回傳的資料是否達到預期,
● 請問你有用過什么測驗工具嗎,用過哪些?
參考回答:
自動化測驗工具用過selenium和appium性能測驗工具有用過Jmeter
● 請你設計一個微信朋友圈點贊的測驗用例
參考回答:
功能測驗:點贊某條朋友圈,驗證是否成功
介面測驗:
點贊朋友圈,驗證朋友能否收到提示資訊
性能測驗
點贊朋友圈,是否在規定時間顯示結果,是否在規定時間在朋友手機上進行提示
兼容性測驗
在不同的終端比如ipad,手機上點贊朋友圈,驗證是否成功
● 請問如果用戶點擊微博的關注圖示但是app上面沒有反應,應該怎么排查這個問題
參考回答:
首先1.在Eclipse Devices視窗,選中app對應的包名,然后點擊debug圖示(綠色的小蟲子),然后切換到Debug視圖,2.切換視圖之后,可以看到debug下,app的執行緒串列,
3.對于main執行緒(第一個執行緒),選中,并將其掛起Suspend,
4.然后我們就可以看到,Suspend之后,main執行緒卡住的位置,
● 在做測驗的程序中,假如前端和后端吵起來了都在踢皮球覺得對方該改代碼,你怎么辦?
參考回答:
此時就應該找技術領導拍板或leader們基于安全性、性能、可測驗性、可維護性討論敲定一個解決方案,做到開發環境方便開發,線上環境少配置少依賴、少出錯機會,
● 如果廣東用戶頭條app刷不出東西了,你應該怎么排查問題
參考回答:
1、檢查網路連接是否穩定,更換網路嘗試2、更新頭條版本嘗試
3、清除app快取,應用資料
● 請你說一下能不能用機器學習去進行自動化測驗,如何監控例外流量,如果是脈沖呢,如何和正常流量作區分
參考回答:
如何用機器學習去進行自動化測驗,就是讓自動化測驗變得更加智能,在自動化測驗程序中,當測驗功能模塊越來越多,沒有太多的時間去全部覆寫,我們可以采用歸納學習的方式,基于自動化測驗的執行結果或者手工測驗執行的結果為資料輸入,然后基于一定的模型(例如:以通過率和模塊的重要率計算的平均值)得出測驗推薦模塊,或者當要執行一個功能模塊時,基于歷史資料和模型(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
● 請問如何對登錄界面進行測驗
參考回答:
黑盒測驗方法輸入正確用戶名和密碼,驗證是否登陸成功
輸入正確的用戶名和錯誤的密碼,驗證是否登陸失敗并且提示資訊正確
輸入未注冊的用戶名和任意的密碼,驗證是否登陸失敗并且提示資訊正確
用戶名和密碼都為空,驗證是否登陸失敗并且提示資訊正確
用戶名和密碼兩者之一為空
若啟用了驗證碼,輸入正確的用戶名密碼驗證碼是否能登陸成功
輸入正確用戶名和密碼,錯誤的驗證碼,能否登陸成功并且提示資訊正確
用戶名和密碼是否大小寫敏感
頁面上的密碼框是否加密顯示
后臺系統第一次創建的用戶重新登錄時是否提示修改密碼
忘記用戶名和忘記密碼的功能是否可用
前段功能是否根據要求限制用戶名和密碼的長度
點擊驗證碼圖片是否可以更換驗證碼,更換后的驗證碼是否可用
重繪頁面是否會重繪驗證碼
如果驗證碼具有時效性,分別驗證時效內和時效外驗證碼的有效性
用戶登錄成功但是會話超時后是否重定向到用戶登錄界面
不同級別的用戶登錄系統后的權限是否正確
頁面默認定位焦點是否定位到用戶名輸入框中
快捷鍵tab和回車鍵是否可以正常使用
非功能性需求,從安全,性能,兼容三個方面
安全:
用戶密碼后臺存盤是否加密
用戶密碼在網路傳輸程序中是否加密
密碼是否具有有效期,密碼有效期到期后是否提示修改密碼
不登陸的時候直接在瀏覽框中輸入登錄界面后的url地址,是否會重新定位到登陸界面
密碼輸入框是否不支持復制粘貼
頁面密碼輸入框中輸入的密碼是否可以在頁面原始碼模式下被查看
用戶名和密碼輸入框中輸入xss跨站腳本攻擊字串驗證系統的行為是否被篡改
連續多次登陸失敗后系統是否會阻止用戶后續的嘗試
統一用戶在同一終端的多種不同瀏覽器上登陸,驗證登錄功能的互斥性是否符合設計預期
同一用戶先后在不同終端的瀏覽器上登陸用戶名和密碼輸入框中輸入典型的sql注入攻擊字串驗證系統的回傳頁面
,驗證登陸是否有互斥性
性能測驗:
單用戶登陸的回應界面是否符合預期
單用戶登陸時后臺請求數量是否過多
高并發場景下用戶登錄的回應界面是否符合預期
高并發場景下服務端的監控指標是否符合預期
高集合點并發場景下是否存在資源死鎖和不合理的資源等待
長時間大量用戶連續登錄和登出,服務器端是否存在記憶體泄漏
兼容性測驗:
不同瀏覽器下驗證登陸功能的頁面顯示和功能正確性
相同瀏覽器的不同版本下驗證登陸功能的頁面顯示和功能正確性
不同終端的不同瀏覽器下驗證登陸功能的頁面顯示和功能正確性
不同解析度下……
補充:弱網測驗
網路切換和網路延遲時登陸界面是否正常
是否支持第三方登陸
是否可記住密碼,記住的密碼是否加密
● 請你說一說當前作業中涉及的測驗問題(測驗流程和測驗性能)
參考回答:
在測驗性能中,時常會出現腳本回訪卡住的問題,原因有以下幾種: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引數)
● 請你說一說洗牌問題的思路并手寫代碼,并設計測驗用例
參考回答:
洗牌問題:有個長度為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型的,浮點型的,還可以是大數型別,負數,進行測驗,
● 請你測驗一下游戲中英雄的技能
參考回答:
測驗的設計都是通用的,首先功能測驗看功能有沒有實作,然后再對性能、壓力、容量、健壯性、安全性、可靠性、恢復性、備份、協議、兼容性、可用性、配置、GUI這些非功能測驗去思考,具體答案這里不再贅述● 請你回答一下性能測驗有哪些指標,對一個登錄功能做性能測驗,有哪些指標,怎么測出可同時處理的最大請求數量
參考回答:
性能測驗常用指標:從外部看,主要有
1、吞吐量:每秒鐘系統能夠處理的請求數,任務數
2、回應時間:服務處理一個請求或一個任務的耗時
3、錯誤率:一批請求中結果出錯的請求所占比例
從服務器的角度看,性能測驗關注CPU,記憶體,服務器負載,網路,磁盤IO
對登錄功能做性能測驗
單用戶登陸的回應界面是否符合預期
單用戶登陸時后臺請求數量是否過多
高并發場景下用戶登錄的回應界面是否符合預期
高并發場景下服務端的監控指標是否符合預期
高集合點并發場景下是否存在資源死鎖和不合理的資源等待
長時間大量用戶連續登錄和登出,服務器端是否存在記憶體泄漏
怎么測出可同時處理的最大請求數量
可以采用性能測驗工具(WeTest服務器性能),該工具是騰訊wetest團隊出品,使用起來很簡單方便,但測驗功能相當強大,能提供10w+以上的并發量,定位性能拐點,測出服務器模型最大并發
● 請問你有沒有做過什么單元測驗,怎么進行單元測驗,對一個沒有引數沒有回傳值但可能對全域變數有影響的怎么進行單元測驗
參考回答:
如何進行單元測驗:1、創建單元測驗,該工具可以對任何類、介面、結構等物體中的欄位、屬性、建構式、方法等進行單元測驗,創建單元測驗大致可以分為兩類:
整體測驗,整體測驗是在類名稱上右擊滑鼠,在下拉選單中點擊創建單元測驗選項,這樣就可以為整個類創建單元測驗了,這時他會為整個類可以被測驗的內容全部添加測驗方法,開發人員直接在這些自動生成的測驗方法中添加單元測驗代碼就可以了,
單獨測驗,如果只想單獨對某個方法、屬性、欄位進行測驗,則可以將滑鼠焦點放在這個待測驗的專案名稱之上,然后點擊滑鼠右鍵,在右鍵選單中選擇創建單元測驗選項,這樣就可以單獨為某個方法創建單元測驗了,
運行單元測驗
查看測驗結果
撰寫單元測驗代碼
測驗沒有引數的函式,它可能還有別的輸入,例如全域變數,成員變數,或呼叫子函式獲得的輸入(這個要使用工具才能做到),只要函式需讀取的,都應該設定初始值,如果完全沒有,沒有輸入也是一種輸入,照樣測驗就是了,同樣道理,輸出也不僅僅是回傳值,沒有回傳值還可能修改了全域變數什么的,這些也是要判斷的輸出,
● 請問你有沒有做過壓力測驗
參考回答:
在軟體工程中,壓力測驗是對系統不斷施加壓力的測驗,是通過確定一個系統的瓶頸或者不能接收的性能點,來獲得系統能提供的最大服務級別的測驗,例如測驗一個Web 站點在大量的負荷下,何時系考察公司:網易統的回應會退化或失敗,網路游戲中也常用到這個詞匯,
● 對于有系統大量并發訪問,你會如何做測驗,有什么建議
參考回答:
如何做高并發系統的測驗,一般而言,整體的測驗策略是:先針對部分系統進行性能測驗及壓力測驗,得到各部分的峰值處理性能,再模擬整體流程測驗,重點測驗整體業務流程以及業務預期負荷,著重測驗以下幾點:1、不同省份,不同運營商CDN節點性能,可采用典型壓力測驗方案
2、核心機房BGP網路帶寬,此部分重點在于測驗各運行商的BGP網路可靠性,實際速率,一般采用smokeping,lxChariot等工具
3、各類硬體設備性能,一般采用專業的網路設備測驗工具
4、各類服務器并發性能,分布式處理能力,可采用壓力測驗方案工具
5、業務系統性能,采用業務系統壓力測驗方案
6、資料庫處理性能,這部分需要結合業務系統進行測驗,以獲取核心業務場景下的資料庫的TPS/QPS,
7、如果有支付功能,需要進行支付渠道介面及分流測驗,此部分相對而言可能是最大的瓶頸所在,此外還涉及備份方案,容災方案,業務降級方案的測驗,

轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/264407.html
標籤:其他
