1、你負責A項目,別人負責B項目,A項目5點鐘會上線新功能,在2點的時候,發(fā)現(xiàn)A項目的上線會影響B(tài)項目,B項目的人臨時被調走,沒有辦法進行協(xié)助,這時該怎么做?
此問題,考察候選人的向上反饋意識,及對突發(fā)事件的應變和協(xié)調工作的能力。
回答參考:
1、提前3小時發(fā)現(xiàn)問題,應及時向上級反映,做出應對方案,請求上級給與指示;
2、向上級申請B項目人員進行突發(fā)事件處理,確保A項目的發(fā)布順利進行;
3、評估A項目的上線對B項目的影響是否過大。征求上級意見,進行下一步補救;
4、向上級報備備選方案,如影響較大,延遲A項目上線時間,確保A項目與B項目正常運行與上線是否可行。
2、如果你正在測試一個電商APP,從APP中選擇了兩個產品,一個全價,一個打折,并且都添加到購物車中,在購物車中成功支付,之后去已購買產品的列表中查看時,發(fā)現(xiàn)只有全價產品,沒有打折商品。此時你應當如何分析和定位該問題?
此問題考察候選人分析問題定位問題能力,需分多鐘情況進行測試。
1、分析單個的打折產品、全價產品購買后,是否有購買記錄,需分別進行兩種產品的單獨購買
2、將題目中的場景再現(xiàn)一次,確定是否是偶發(fā)現(xiàn)象(此時分兩種情況,若打折產品出現(xiàn)了,則題目中有可能是偶發(fā)現(xiàn)象,需按照偶發(fā)問題處理方法來解決;若打折產品不出現(xiàn),此時需通過抓包確定是前端還是后端問題)
3、購買多個打折產品,查看是否有購買記錄,排除系統(tǒng)對于打折產品沒有單獨處理的情況
4、特殊情況:如手機兼容性,網絡情況,打折產品庫存不足等。
1、APP測試和web測試區(qū)別
答:App測試與Web測試從功能測試和整體流程角度來講,幾乎沒有什么區(qū)別,都是點點點的測試。Web測試,包含了UI測試、鏈接測試、搜索測試、表單測試、輸入域測試、數據交互、兼容性測試、安全性測試、性能測試等等很多方面。而App測試,是基于客戶端進行測試,測試人員的手機型號不同、版本不同、測試環(huán)境不同,涉及到的兼容性問題會有很多。
系統(tǒng)架構:Web測試一般是B/S架構,只要更新了服務器端,客戶端就會同步更新。而且客戶端能保證每位用戶的客戶端完全一致。但是App端一般是C/S架構,除非用戶更新客戶端,否則無法保證軟件在各人手機中的一致性。如果在App下修改了服務端,就意味著又需要進行回歸測試。
性能測試:Web測試比較關注網頁的響應時間,而App除了關注在流暢網絡下的響應時間,還需要關心流量、電量、CPU、GPU、Memory等等因素。
兼容性測試:Web端的測試更傾向于瀏覽器、電腦硬件配置以及電腦系統(tǒng)方向的兼容,不過一般還是以主流的瀏覽器為主。而App的測試則必須依賴移動端的設備:手機、平板等,不僅要看設備型號,還要看設備系統(tǒng):Android和iOS。
App專項測試:異常場景的考慮以及弱網測試。比如:中斷,來電,短信,關機,重啟等。而弱網測試是App測試中必須執(zhí)行的一項測試。包括弱網和網絡切換,需要測試弱網時的用戶體驗問題,提示語和等待頁面的設置,回退和刷新是否會造成二次提交,以及延時的處理機制等。?????針對App產品性質的測試內容,絕大多數用戶使用的都是觸屏手機,所以測試的時候還要注意手勢,橫豎屏切換,多點觸控,功能觸發(fā)區(qū)域等測試。
Web測試是針對瀏覽器,無需考慮安裝卸載問題。而App是客戶端,需要測試安裝卸載和更新的情況。除了常規(guī)的操作還要考慮到異常場景。比如說:安裝時的中斷、弱網、安裝后刪除文件,強制更新與非強制更新、斷點續(xù)傳、弱網,卸載后刪除App相關的文件等等。
2、什么是HTTP請求,HTTP請求方式有哪些
答:HTTP,即超文本傳輸協(xié)議,是HyperText Transfer Protocol的縮寫。瀏覽網頁時在瀏覽器地址欄中輸入的URL前面都是以"http://"開始的。HTTP定義了信息如何被格式化、如何被傳輸,以及在各種命令下服務器和瀏覽器所采取的響應。HTTP請求方式:GET、POST、PUT、HEAD、DELETE、OPTIONS、TRACE、CONNECT
3、Post請求與get請求的區(qū)別
答:GET----獲取資源 GET方法一般用來從服務器上獲取資源的方法。服務器端接到GET請求后,就會明白客戶端是要從服務器端獲取相應的資源,然后就會根據請求報文中相應的參數,將需要的資源返回給客戶端。使用GET方式的請求,傳輸的參數是拼接在URI上的。
POST----數據提交 POST方法一般用于表單提交,將客戶端的數據塞到請求體中發(fā)送給服務器端。
get 和 post區(qū)別:
get請求無消息體,只能攜帶少量數據;post請求有消息體,可以攜帶大量數據;
get請求將數據放在url地址中;post請求將數據放在消息體中
GET請求請?zhí)峤坏臄祿胖迷贖TTP請求協(xié)議頭中,而POST提交的數據則放在實體數據中;GET方式提交的數據最多只能有1024字節(jié),而POST則沒有此限制。
5、常用的測試用例設計方法
??答:等價類劃分法:等價類劃分主要適用于單個輸入條件,輸入為數值型的情況,如果輸入規(guī)定了輸入區(qū)間,可劃分出一個有效等價類,兩個無效等價類;如果輸入只規(guī)定了輸入范圍,可劃分出一個有效等價類,一個無效等價類。有效等價類:有意義的合理的正確輸入;無效等價類:非法的錯誤的異常的輸入;
邊界值分析法:邊界值方法也是適用于單個輸入條件的情況,輸入類型可以數值、字符等,要測試的邊界包括上點、下點、離點。相關術語:上點:邊界上的點叫做上點;離點:離邊界最近的點叫做離點(如果是閉區(qū)間,離點落在邊界外;如果是開區(qū)間,離點落在邊界內)內點:邊界內任意一個點叫做內點
因果圖法:如果輸入之間有關系,我們在測試時必須考慮輸入條件的各種組合,那么可以考慮使用一種適合于描述對于多種條件的組合,相應產生多個動作的形式來設計測試用例,這就需要利用因果圖。優(yōu)點:因果圖方法最終生成的就是判定表。它適合于檢查程序輸入條件的各種組合情況。
錯誤推測法:錯誤推測法主要是測試設計人員的測試經驗相關,測試經驗不同,設計出來的測試用例也區(qū)別很大。
判定表驅動法:判定表適合于解決多個邏輯條件的組合。將各種邏輯的組合羅列出來,避免遺漏。不能表達重復的操作。判定表包括條件樁、條件項、動作樁、動作項。
正交法:當輸入條件很多時,因果圖等設計方法設計出來的用例數往往多的驚人,用正交法可有效減少用例數。正交法的核心思想是從大量測試數據中選取有代表性的點來測試,從而減少測試用例數。
功能圖法:功能圖法適合于用來設計程序的控制結構的測試用例。有順序、選擇、重復三種控制結構。
場景法:場景法特別適用于控制流清晰的系統(tǒng)。測試過程中可以針對不同的場景設計測試用例。
6、常用工具的使用,postman,jmeter,F(xiàn)iddler
(此處常用工具的使用是檢查一名測試人員基本技能的基礎,也是項目組最為關注的點,這里只簡單介紹操作步驟,候選人若能答出流程即可)
Postman:postman是一個開源的接口測試工具,無論是做單個接口的測試還是整套測試腳本的撥測都非常方便。
1)get請求:Get請求是最簡單的請求方式,輸入URL就能完成。
第一步:新建一個tab頁面
第二步:輸入URL ,選擇請求方式為GET
第三步:點擊“send”按鈕
第四步:查看返回碼是否異常。
2)post請求:?Post請求跟Get的區(qū)別除了請求方式不同之外,還需要添加請求體,請求體內容多半為Json格式。
第一步:新建一個tab頁面
第二步:輸入URL ,選擇請求方式為POST
第三步:輸入請求體內容
第四步:點擊“send”按鈕
第五步:查看返回碼,返回信息等
3)帶cookie的請求:?該請求需要在Heards里面添加Cookie
第一步:新建一個tab頁面
第二步:輸入URL ,選擇請求方式為POST
第三步:輸入請求體內容
第四步:在Heard里面添加Cookie信息
第五步:點擊“send”按鈕
第六步:查看返回碼,返回信息等
4)帶Header的請求:該請求需要在Heards里面添加Cookie。
第一步:新建一個tab頁面
第二步:輸入URL ,選擇請求方式為POST
第三步:輸入請求體內容
第四步:在Heard里面對應的內容
第五步:點擊“send”按鈕
第六步:查看返回碼,返回信息等
5)文件上傳的請求:發(fā)送請求前需要先上傳文件。
第一步:新建一個tab頁面
第二步:輸入URL ,選擇請求方式為POST
第三步:輸入請求體內容,文件內容選擇file, 選擇本地的文件上傳
第四步:點擊“send”按鈕
第五步:查看返回碼,返回信息等
Jmeter:Apache JMeter是Apache組織開發(fā)的基于Java的壓力測試工具。用于對軟件做壓力測試,它最初被設計用于Web應用測試,但后來擴展到其他測試領域。它可以用于測試靜態(tài)和動態(tài)資源,例如靜態(tài)文件、Java?小服務程序、CGI 腳本、Java 對象、數據庫、FTP 服務器, 等等。
操作步驟如下:
首先,添加線程組,單擊右鍵->添加->Threads(Users)->線程組
右鍵“線程組”?->?“添加”?->?“取樣器”?->?“HTTP請求”,?輸入“服務器名稱或IP”,對應的端口號,http默認端口號80,可以不寫。
以下請求為POST,?所有“方法”那選擇“POST”,輸入對應的路徑,添加參數及值。
右鍵“線程組”?->?“添加”?->?“監(jiān)聽器”?->?“察看結果數”,?添加“察看結果數”,以察看運行后的結果,如圖所示。
數據補充完整后可點擊菜單欄目中“啟動”按鈕以啟動測試,如圖所示。
運行結束后可在結果樹中查看返回結果
簡單來說,jmeter操作過程就是:
1、新建一個線程組
2、輸入HTTP請求
3、設置一個或者多個斷言,增加監(jiān)聽器
4、運行后查看結果樹
Linux常用命令舉例:(紅色字體為輸入內容)
???答:cd ..返回上一級目錄;cd ../..返回上兩級目錄;ls查看目錄中的文件;ls -F查看目錄中的文件;ls -l顯示文件和目錄的詳細資料;ls -a顯示隱藏文件;tree 顯示文件和目錄由根目錄開始的樹形結構(1);lstree顯示文件和目錄由根目錄開始的樹形結構(2);mkdir dir1創(chuàng)建一個叫做'dir1' 的目錄';mkdir dir1 dir2同時創(chuàng)建兩個目錄;find / -user user1搜索屬于用戶'user1' 的文件和目錄;mv dir1 new_dir重命名/移動 一個目錄
數據庫常用SQL語句:
答:以常見的增、刪、改、查為例:
增:插入指定列:insert into 表名(列1,列2,...,列n) values(值1,值2,...,值n);
插入所有列:insert into 表名 values(值1,值2,...,值n);
一次插入多行:insert into 表名 values
(值1,值2,...,值n),
(值1,值2,...,值n),
...
(值1,值2,...,值n);
2)刪:delete from 表名 [where 條件]
3)改:update 表名 set 列1=新值1,列2=新值2,...,列n=新值n [where 條件];
4)查:查詢部分列:select 列1,列2,...,列n from 表名 [where 條件];
查詢所有列:select * from?from 表名 [where 條件];
測試過程中遇到一個bug,開發(fā)不認為是bug如何解決?
?????答:該問題是面試時常見問題,沒有固定答案,但是該問題能夠反映出測試人員在發(fā)現(xiàn)問題后,如何解決問題的能力,能夠體現(xiàn)出候選人的主動解決問題的能力和思路,作為一名測試人員,發(fā)現(xiàn)并主動解決問題最為關鍵,這里列出幾點,便于HR參考:
首先分析下到底會有哪些原因會導致開發(fā)不修改bug:
1、開發(fā)與測試對bug的定義理解不一致產生的問題,例如暴力操作、非常規(guī)操作出現(xiàn)的問題、問題路徑深、服務器返回的數據不規(guī)范、競品同樣有的問題、個別機型問題等情況,開發(fā)可能會不愿意修改。
2、工作流程方面的原因,例如開發(fā)有更高優(yōu)先級的任務沒有時間修改、上線時間緊急,來不及修改、開發(fā)不關注名下的bug、開發(fā)認為目前的實現(xiàn)比產品需求好等情況
3、當然還有個人能力原因,例如找不到好的解決方案、影響范圍大、找不到bug原因,沒有解決方案、技術實現(xiàn)難,不知道怎么修改等等原因
4、另外還有一些不可抗力的客觀因素,例如系統(tǒng)問題,第三方應用問題等等
我們逐條分析并列出簡單的解決方案:
針對路徑較深的bug,測試在推動開發(fā)修復bug時,需要注意以下幾點:
從用戶的角度分析問題的嚴重性,分析用戶的遇到此問題的概率,引導開發(fā)站在用戶角度去思考,從而使開發(fā)意識到問題的嚴重性。
可以和開發(fā)人員列舉一個之前的類似問題,為開發(fā)提供參考。
產品是負責這個軟件的人員,當測試與開發(fā)意見無法達成一致時,不要因為無法推動開發(fā)修改而放棄,一定要找產品確認,最終的決定權交給產品人員。
上線時間緊張,開發(fā)來不及修改了,這個時候測試應該分析問題的嚴重性,和產品人員商議是否需要修改。
修改bug改動較大,影響范圍廣,沒有最優(yōu)的解決方案等情況在項目即將上線的節(jié)點比較忌諱這種事情的發(fā)生。面對這種情況,建議開發(fā)人員做調研工作,請教其他的同事,或者組織一個臨時會議,集眾人之力研究好的修改方案。
第三方應用問題,開發(fā)無法修改。確認原因之后需要找相關的工作人員,例如產品,聯(lián)系第三方輸入法的工作人員,反饋問題,盡量推動應用解決問題。
bug修不修,測試應該有一個自己的原則,同時也要權衡利弊。不能因為推不動開發(fā),就放棄,由著bug上線,也不能揪著一個小bug不放,影響上線時間。
[測試用例設計題:
回答此處問題時,結合APP測試的特點進行回答,針對APP測試專項測試如:手機操作系統(tǒng)iOS、安卓、兼容性、后臺應用、通知、短信提醒、弱網、消息提醒等用例此處不做重復介紹,詳細請見問題一,但是候選人在回答問題時需要答出,下面詳細介紹點贊功能。
微信朋友圈點贊功能
功能類:1、首先檢查朋友圈可見權限設置,針對不同的權限、好友關系設置哪些好友可見
2、設置單個好友可見時,發(fā)送一條朋友圈,對方好友是否可見;
3、可見之后是否有可展開的操作欄(其中包括點贊和評論);
4、多次點擊后操作欄是否能夠重復展開或退回
5、點贊功能:UI檢查,是否有點贊圖標,點贊提示,評論圖標,評論提示
6、點擊點贊圖標后,圖標是否有點贊成功提示;
7、點贊成功后點贊提示是否變?yōu)槿∠c贊;
8、點贊成功后是否在該條朋友圈下有點贊人姓名及圖標;
9、點贊成功后,是否在被點贊人朋友圈處出現(xiàn)被點贊數統(tǒng)計提示;
10、被點贊人點擊被點贊的提示后,頁面是否跳轉至被點贊朋友圈處,并顯示已點贊的好友圖標;
11、設置多個好友可見時,重復點贊步驟后,被點贊人查看個人朋友圈,是否能夠展示所有點贊人的圖標,統(tǒng)計數量;
12、若多個好友同時點贊,被點贊人收到贊時頁面展示是否按照點贊時順序排序;
13、多個人同時點贊時,順序如何排序。
14、若其余幾位點贊人之間不互為好友關系,是否能夠看到對方點贊情況。
15、若有個別人員是好友關系,能否通過點贊的頭像進入對方信息;
16、點贊之后該條贊能否一直保持
17、若該條朋友圈被刪除,點贊的訊息是否也被刪除
18、取消點贊,只能對已點贊的朋友圈進行取消點贊;
19、在已點贊的朋友圈下點擊操作欄,是否彈出取消點贊的圖表及提示
20、點擊取消后是否提示已取消點贊;
21、取消的點贊后是否可以再次點贊;
22、取消點贊后是否會通知被點贊人;
23、設置朋友圈可見限制,當被點贊人收獲很多贊之后,關閉朋友圈可見,那么被點贊人是否能夠看到自己收獲點贊統(tǒng)計,其點贊好友是否能夠看到已點贊的信息;
(以上用例僅為參考,若有不足之處可以增加補充,完善用例)
場景問題解決:
如果在購物平臺上選購了物品,并且成功支付,但在“我的訂單”中沒有查到該筆訂單,此時怎么處理?
(該問題旨在考察候選人在面臨場景問題時的處理問題能力,并且如何準確定位問題,解決問題的思路,答案不固定)
答:測試人員發(fā)現(xiàn)問題后,先確認該問題是否滿足需求,若在需求要求下,則:
1.重現(xiàn)問題:如果是測試環(huán)境,可以再做一筆訂單,詳細記錄該筆訂單訊息,檢查該問題是否為偶發(fā)性問題,此處分兩種情況:
1、若該筆訂單能夠查到,則需判斷,沒有找到訂單的那筆有可能是偶發(fā)現(xiàn)象,需明確記錄;
2、若該筆訂單還是無法找到,則需確定是前端還是后端問題。
排查問題:若為web類測試,通過開發(fā)者工具查看界面返回結果,若“我的訂單”中有返回值,但在頁面中沒有展示,需找前端同事確認是否是做數據處理時沒有展示結果;若“我的訂單”中沒有返回值,有可能是數據沒有傳給前端,需確認是否是接口沒有返回或數據傳輸丟失。此時可以通過檢查數據庫對應表格、或者用抓包工具檢查接口是否報錯。若為APP類測試,通過抓包工具檢查接口返回,同時檢查數據庫中對應表,是否有存儲該筆數據。
3、確認是前端或后端問題后,可以截圖發(fā)送給對應同事確認問題,并將該問題提交至缺陷管理工具中,并及時跟蹤問題。若問題較嚴重并短期內無法解決,需及時與負責人,項目經理聯(lián)系,及時匯報該問題。
4、若該問題為偶發(fā)問題,需記錄該筆訂單詳細情況,并在后期測試中重點關注,若經過幾個迭代后該問題沒有再次出現(xiàn),則可降低該問題等級,但仍需留意。