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)，則可降低該問題等級，但仍需留意。
