1喻犁、你負責A項目槽片，別人負責B項目，A項目5點鐘會上線新功能肢础，在2點的時候还栓，發(fā)現(xiàn)A項目的上線會影響B(tài)項目，B項目的人臨時被調(diào)走传轰，沒有辦法進行協(xié)助剩盒，這時該怎么做？

此問題慨蛙，考察候選人的向上反饋意識辽聊，及對突發(fā)事件的應變和協(xié)調(diào)工作的能力纪挎。

回答參考：

1、提前3小時發(fā)現(xiàn)問題跟匆，應及時向上級反映异袄，做出應對方案，請求上級給與指示玛臂；

2烤蜕、向上級申請B項目人員進行突發(fā)事件處理，確保A項目的發(fā)布順利進行垢揩；

3玖绿、評估A項目的上線對B項目的影響是否過大。征求上級意見叁巨，進行下一步補救斑匪；

4、向上級報備備選方案锋勺，如影響較大蚀瘸，延遲A項目上線時間，確保A項目與B項目正常運行與上線是否可行庶橱。

2贮勃、如果你正在測試一個電商APP，從APP中選擇了兩個產(chǎn)品苏章，一個全價寂嘉，一個打折，并且都添加到購物車中枫绅，在購物車中成功支付泉孩，之后去已購買產(chǎn)品的列表中查看時，發(fā)現(xiàn)只有全價產(chǎn)品并淋，沒有打折商品寓搬。此時你應當如何分析和定位該問題？

此問題考察候選人分析問題定位問題能力县耽，需分多鐘情況進行測試句喷。

1、分析單個的打折產(chǎn)品兔毙、全價產(chǎn)品購買后唾琼，是否有購買記錄，需分別進行兩種產(chǎn)品的單獨購買

2瞒御、將題目中的場景再現(xiàn)一次父叙，確定是否是偶發(fā)現(xiàn)象（此時分兩種情況，若打折產(chǎn)品出現(xiàn)了，則題目中有可能是偶發(fā)現(xiàn)象趾唱，需按照偶發(fā)問題處理方法來解決岂却；若打折產(chǎn)品不出現(xiàn)父晶，此時需通過抓包確定是前端還是后端問題）

3夸溶、購買多個打折產(chǎn)品矾策，查看是否有購買記錄，排除系統(tǒng)對于打折產(chǎn)品沒有單獨處理的情況

4悠咱、特殊情況：如手機兼容性蒸辆，網(wǎng)絡情況，打折產(chǎn)品庫存不足等析既。

1躬贡、APP測試和web測試區(qū)別

答：App測試與Web測試從功能測試和整體流程角度來講，幾乎沒有什么區(qū)別眼坏，都是點點點的測試拂玻。Web測試，包含了UI測試宰译、鏈接測試檐蚜、搜索測試、表單測試沿侈、輸入域測試闯第、數(shù)據(jù)交互、兼容性測試缀拭、安全性測試咳短、性能測試等等很多方面。而App測試蛛淋，是基于客戶端進行測試诲泌，測試人員的手機型號不同、版本不同铣鹏、測試環(huán)境不同，涉及到的兼容性問題會有很多哀蘑。

系統(tǒng)架構：Web測試一般是B/S架構诚卸，只要更新了服務器端，客戶端就會同步更新绘迁。而且客戶端能保證每位用戶的客戶端完全一致合溺。但是App端一般是C/S架構，除非用戶更新客戶端缀台，否則無法保證軟件在各人手機中的一致性棠赛。如果在App下修改了服務端，就意味著又需要進行回歸測試。

性能測試：Web測試比較關注網(wǎng)頁的響應時間睛约，而App除了關注在流暢網(wǎng)絡下的響應時間鼎俘，還需要關心流量、電量辩涝、CPU贸伐、GPU、Memory等等因素怔揩。

兼容性測試：Web端的測試更傾向于瀏覽器捉邢、電腦硬件配置以及電腦系統(tǒng)方向的兼容，不過一般還是以主流的瀏覽器為主商膊。而App的測試則必須依賴移動端的設備：手機伏伐、平板等，不僅要看設備型號晕拆，還要看設備系統(tǒng)：Android和iOS藐翎。

App專項測試：異常場景的考慮以及弱網(wǎng)測試。比如：中斷潦匈，來電阱高，短信，關機茬缩，重啟等赤惊。而弱網(wǎng)測試是App測試中必須執(zhí)行的一項測試。包括弱網(wǎng)和網(wǎng)絡切換凰锡，需要測試弱網(wǎng)時的用戶體驗問題未舟，提示語和等待頁面的設置，回退和刷新是否會造成二次提交掂为，以及延時的處理機制等裕膀。?????針對App產(chǎn)品性質(zhì)的測試內(nèi)容，絕大多數(shù)用戶使用的都是觸屏手機勇哗，所以測試的時候還要注意手勢昼扛，橫豎屏切換，多點觸控欲诺，功能觸發(fā)區(qū)域等測試抄谐。

Web測試是針對瀏覽器，無需考慮安裝卸載問題扰法。而App是客戶端蛹含，需要測試安裝卸載和更新的情況。除了常規(guī)的操作還要考慮到異常場景塞颁。比如說：安裝時的中斷浦箱、弱網(wǎng)吸耿、安裝后刪除文件，強制更新與非強制更新酷窥、斷點續(xù)傳咽安、弱網(wǎng)，卸載后刪除App相關的文件等等竖幔。

2板乙、什么是HTTP請求，HTTP請求方式有哪些

答：HTTP拳氢，即超文本傳輸協(xié)議募逞，是HyperText Transfer Protocol的縮寫。瀏覽網(wǎng)頁時在瀏覽器地址欄中輸入的URL前面都是以"http://"開始的馋评。HTTP定義了信息如何被格式化放接、如何被傳輸，以及在各種命令下服務器和瀏覽器所采取的響應留特。HTTP請求方式：GET纠脾、POST、PUT蜕青、HEAD苟蹈、DELETE、OPTIONS右核、TRACE慧脱、CONNECT

3、Post請求與get請求的區(qū)別

答：GET----獲取資源 GET方法一般用來從服務器上獲取資源的方法贺喝。服務器端接到GET請求后菱鸥，就會明白客戶端是要從服務器端獲取相應的資源，然后就會根據(jù)請求報文中相應的參數(shù)躏鱼，將需要的資源返回給客戶端氮采。使用GET方式的請求，傳輸?shù)膮?shù)是拼接在URI上的染苛。

POST----數(shù)據(jù)提交 POST方法一般用于表單提交鹊漠，將客戶端的數(shù)據(jù)塞到請求體中發(fā)送給服務器端。

get 和 post區(qū)別：

get請求無消息體茶行，只能攜帶少量數(shù)據(jù)贸呢；post請求有消息體，可以攜帶大量數(shù)據(jù)拢军；

get請求將數(shù)據(jù)放在url地址中；post請求將數(shù)據(jù)放在消息體中

GET請求請?zhí)峤坏臄?shù)據(jù)放置在HTTP請求協(xié)議頭中怔鳖，而POST提交的數(shù)據(jù)則放在實體數(shù)據(jù)中茉唉；GET方式提交的數(shù)據(jù)最多只能有1024字節(jié)，而POST則沒有此限制。

5度陆、常用的測試用例設計方法

??答：等價類劃分法：等價類劃分主要適用于單個輸入條件艾凯，輸入為數(shù)值型的情況，如果輸入規(guī)定了輸入?yún)^(qū)間懂傀，可劃分出一個有效等價類趾诗，兩個無效等價類；如果輸入只規(guī)定了輸入范圍蹬蚁，可劃分出一個有效等價類恃泪，一個無效等價類。有效等價類：有意義的合理的正確輸入犀斋；無效等價類：非法的錯誤的異常的輸入贝乎；

邊界值分析法：邊界值方法也是適用于單個輸入條件的情況，輸入類型可以數(shù)值叽粹、字符等览效，要測試的邊界包括上點、下點虫几、離點锤灿。相關術語：上點：邊界上的點叫做上點；離點：離邊界最近的點叫做離點（如果是閉區(qū)間辆脸，離點落在邊界外但校；如果是開區(qū)間，離點落在邊界內(nèi)）內(nèi)點：邊界內(nèi)任意一個點叫做內(nèi)點

因果圖法：如果輸入之間有關系每强，我們在測試時必須考慮輸入條件的各種組合始腾，那么可以考慮使用一種適合于描述對于多種條件的組合，相應產(chǎn)生多個動作的形式來設計測試用例空执，這就需要利用因果圖浪箭。優(yōu)點：因果圖方法最終生成的就是判定表。它適合于檢查程序輸入條件的各種組合情況辨绊。

錯誤推測法：錯誤推測法主要是測試設計人員的測試經(jīng)驗相關奶栖，測試經(jīng)驗不同，設計出來的測試用例也區(qū)別很大门坷。

判定表驅(qū)動法：判定表適合于解決多個邏輯條件的組合宣鄙。將各種邏輯的組合羅列出來，避免遺漏默蚌。不能表達重復的操作冻晤。判定表包括條件樁、條件項绸吸、動作樁鼻弧、動作項设江。

正交法：當輸入條件很多時，因果圖等設計方法設計出來的用例數(shù)往往多的驚人攘轩，用正交法可有效減少用例數(shù)叉存。正交法的核心思想是從大量測試數(shù)據(jù)中選取有代表性的點來測試，從而減少測試用例數(shù)度帮。

功能圖法：功能圖法適合于用來設計程序的控制結構的測試用例歼捏。有順序、選擇笨篷、重復三種控制結構瞳秽。

場景法：場景法特別適用于控制流清晰的系統(tǒng)。測試過程中可以針對不同的場景設計測試用例冕屯。

6寂诱、常用工具的使用，postman安聘，jmeter痰洒，F(xiàn)iddler

（此處常用工具的使用是檢查一名測試人員基本技能的基礎，也是項目組最為關注的點浴韭，這里只簡單介紹操作步驟丘喻，候選人若能答出流程即可）

Postman：postman是一個開源的接口測試工具，無論是做單個接口的測試還是整套測試腳本的撥測都非常方便念颈。

1）get請求：Get請求是最簡單的請求方式泉粉，輸入URL就能完成。

　　第一步：新建一個tab頁面

　　第二步：輸入URL ,選擇請求方式為GET

　　第三步：點擊“send”按鈕

　　第四步：查看返回碼是否異常榴芳。

2）post請求：?Post請求跟Get的區(qū)別除了請求方式不同之外嗡靡，還需要添加請求體，請求體內(nèi)容多半為Json格式窟感。

　　第一步：新建一個tab頁面

　　第二步：輸入URL ,選擇請求方式為POST

　　第三步：輸入請求體內(nèi)容

　　第四步：點擊“send”按鈕

第五步：查看返回碼讨彼，返回信息等

3）帶cookie的請求：?該請求需要在Heards里面添加Cookie

　　第一步：新建一個tab頁面

　　第二步：輸入URL ,選擇請求方式為POST

　　第三步：輸入請求體內(nèi)容

　　第四步：在Heard里面添加Cookie信息

　　第五步：點擊“send”按鈕

第六步：查看返回碼，返回信息等

4）帶Header的請求：該請求需要在Heards里面添加Cookie柿祈。

　　第一步：新建一個tab頁面

　　第二步：輸入URL ,選擇請求方式為POST

　　第三步：輸入請求體內(nèi)容

　　第四步：在Heard里面對應的內(nèi)容

　　第五步：點擊“send”按鈕

第六步：查看返回碼哈误，返回信息等

5）文件上傳的請求：發(fā)送請求前需要先上傳文件。

　　第一步：新建一個tab頁面

　　第二步：輸入URL ,選擇請求方式為POST

　　第三步：輸入請求體內(nèi)容躏嚎，文件內(nèi)容選擇file, 選擇本地的文件上傳

　　第四步：點擊“send”按鈕

第五步：查看返回碼蜜自，返回信息等

Jmeter：Apache JMeter是Apache組織開發(fā)的基于Java的壓力測試工具。用于對軟件做壓力測試卢佣，它最初被設計用于Web應用測試重荠，但后來擴展到其他測試領域。它可以用于測試靜態(tài)和動態(tài)資源虚茶，例如靜態(tài)文件戈鲁、Java?小服務程序尾膊、CGI 腳本、Java 對象荞彼、數(shù)據(jù)庫、FTP 服務器待笑， 等等鸣皂。

操作步驟如下：

首先，添加線程組暮蹂，單擊右鍵->添加->Threads(Users)->線程組

右鍵“線程組”?->?“添加”?->?“取樣器”?->?“HTTP請求”,?輸入“服務器名稱或IP”寞缝，對應的端口號，http默認端口號80仰泻，可以不寫荆陆。

以下請求為POST,?所有“方法”那選擇“POST”，輸入對應的路徑集侯，添加參數(shù)及值被啼。

右鍵“線程組”?->?“添加”?->?“監(jiān)聽器”?->?“察看結果數(shù)”,?添加“察看結果數(shù)”，以察看運行后的結果棠枉，如圖所示浓体。

數(shù)據(jù)補充完整后可點擊菜單欄目中“啟動”按鈕以啟動測試，如圖所示辈讶。

運行結束后可在結果樹中查看返回結果

簡單來說命浴，jmeter操作過程就是：

1、新建一個線程組

2贱除、輸入HTTP請求

3生闲、設置一個或者多個斷言，增加監(jiān)聽器

4月幌、運行后查看結果樹

Linux常用命令舉例：（紅色字體為輸入內(nèi)容）

???答：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重命名/移動 一個目錄

數(shù)據(jù)庫常用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的定義理解不一致產(chǎn)生的問題椒惨，例如暴力操作缤至、非常規(guī)操作出現(xiàn)的問題、問題路徑深康谆、服務器返回的數(shù)據(jù)不規(guī)范领斥、競品同樣有的問題、個別機型問題等情況秉宿，開發(fā)可能會不愿意修改戒突。

2、工作流程方面的原因描睦，例如開發(fā)有更高優(yōu)先級的任務沒有時間修改膊存、上線時間緊急，來不及修改忱叭、開發(fā)不關注名下的bug隔崎、開發(fā)認為目前的實現(xiàn)比產(chǎn)品需求好等情況

3、當然還有個人能力原因韵丑，例如找不到好的解決方案爵卒、影響范圍大、找不到bug原因撵彻，沒有解決方案钓株、技術實現(xiàn)難，不知道怎么修改等等原因

4陌僵、另外還有一些不可抗力的客觀因素轴合，例如系統(tǒng)問題，第三方應用問題等等

我們逐條分析并列出簡單的解決方案：

針對路徑較深的bug碗短，測試在推動開發(fā)修復bug時受葛，需要注意以下幾點：

從用戶的角度分析問題的嚴重性，分析用戶的遇到此問題的概率，引導開發(fā)站在用戶角度去思考总滩，從而使開發(fā)意識到問題的嚴重性纲堵。

可以和開發(fā)人員列舉一個之前的類似問題，為開發(fā)提供參考闰渔。

產(chǎn)品是負責這個軟件的人員席函，當測試與開發(fā)意見無法達成一致時，不要因為無法推動開發(fā)修改而放棄冈涧，一定要找產(chǎn)品確認向挖，最終的決定權交給產(chǎn)品人員。

上線時間緊張炕舵，開發(fā)來不及修改了，這個時候測試應該分析問題的嚴重性跟畅，和產(chǎn)品人員商議是否需要修改咽筋。

修改bug改動較大，影響范圍廣徊件，沒有最優(yōu)的解決方案等情況在項目即將上線的節(jié)點比較忌諱這種事情的發(fā)生奸攻。面對這種情況，建議開發(fā)人員做調(diào)研工作虱痕，請教其他的同事睹耐，或者組織一個臨時會議，集眾人之力研究好的修改方案部翘。

第三方應用問題硝训，開發(fā)無法修改。確認原因之后需要找相關的工作人員新思，例如產(chǎn)品窖梁，聯(lián)系第三方輸入法的工作人員，反饋問題夹囚，盡量推動應用解決問題纵刘。

bug修不修，測試應該有一個自己的原則荸哟，同時也要權衡利弊假哎。不能因為推不動開發(fā)，就放棄鞍历，由著bug上線舵抹，也不能揪著一個小bug不放，影響上線時間堰燎。

[測試用例設計題：

回答此處問題時掏父，結合APP測試的特點進行回答，針對APP測試專項測試如：手機操作系統(tǒng)iOS秆剪、安卓赊淑、兼容性爵政、后臺應用、通知陶缺、短信提醒钾挟、弱網(wǎng)、消息提醒等用例此處不做重復介紹饱岸，詳細請見問題一掺出，但是候選人在回答問題時需要答出，下面詳細介紹點贊功能苫费。

微信朋友圈點贊功能

功能類：1汤锨、首先檢查朋友圈可見權限設置，針對不同的權限百框、好友關系設置哪些好友可見

2闲礼、設置單個好友可見時，發(fā)送一條朋友圈铐维，對方好友是否可見柬泽；

3、可見之后是否有可展開的操作欄（其中包括點贊和評論）嫁蛇；

4锨并、多次點擊后操作欄是否能夠重復展開或退回

5、點贊功能：UI檢查睬棚，是否有點贊圖標第煮，點贊提示，評論圖標抑党，評論提示

6空盼、點擊點贊圖標后，圖標是否有點贊成功提示新荤；

7揽趾、點贊成功后點贊提示是否變?yōu)槿∠c贊；

8苛骨、點贊成功后是否在該條朋友圈下有點贊人姓名及圖標篱瞎；

9、點贊成功后痒芝，是否在被點贊人朋友圈處出現(xiàn)被點贊數(shù)統(tǒng)計提示俐筋；

10、被點贊人點擊被點贊的提示后严衬，頁面是否跳轉(zhuǎn)至被點贊朋友圈處澄者，并顯示已點贊的好友圖標；

11、設置多個好友可見時粱挡，重復點贊步驟后赠幕，被點贊人查看個人朋友圈，是否能夠展示所有點贊人的圖標询筏，統(tǒng)計數(shù)量榕堰；

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ā)者工具查看界面返回結果，若“我的訂單”中有返回值赫蛇，但在頁面中沒有展示绵患，需找前端同事確認是否是做數(shù)據(jù)處理時沒有展示結果；若“我的訂單”中沒有返回值悟耘，有可能是數(shù)據(jù)沒有傳給前端落蝙，需確認是否是接口沒有返回或數(shù)據(jù)傳輸丟失。此時可以通過檢查數(shù)據(jù)庫對應表格暂幼、或者用抓包工具檢查接口是否報錯掘殴。若為APP類測試，通過抓包工具檢查接口返回粟誓，同時檢查數(shù)據(jù)庫中對應表奏寨，是否有存儲該筆數(shù)據(jù)。

3鹰服、確認是前端或后端問題后病瞳，可以截圖發(fā)送給對應同事確認問題揽咕，并將該問題提交至缺陷管理工具中，并及時跟蹤問題套菜。若問題較嚴重并短期內(nèi)無法解決亲善，需及時與負責人，項目經(jīng)理聯(lián)系逗柴，及時匯報該問題蛹头。

4、若該問題為偶發(fā)問題戏溺，需記錄該筆訂單詳細情況渣蜗，并在后期測試中重點關注，若經(jīng)過幾個迭代后該問題沒有再次出現(xiàn)旷祸，則可降低該問題等級耕拷，但仍需留意。