1、你在項目中負(fù)責(zé)什么？

參考答案：在工作中我主要負(fù)責(zé)功能測試，其次還參與了一些非功能測試，如：接口測試，自動化測試，性能測試，兼容性測試等。在項目中主要參與了需求分析和需求評審，負(fù)責(zé)收集項目資料協(xié)助上級完成測試計劃的編寫，編寫測試用例并評審，測試環(huán)境的搭建以及測試執(zhí)行和編寫測試報告等工作。

2、問題：怎么保證覆蓋用戶需求？

? 回答：從BA那里拿到需求文檔，熟悉文檔，畫好流程圖，保證整個流程都覆蓋全面，小組之間每個人都要根據(jù)各自的流程圖，來講解一下自己的思路，防止測試點遺漏，各個功能點有哪些限制條件，防止之后編寫測試用例時發(fā)現(xiàn)遺漏；用例編寫完之后，再進(jìn)行用例的評審，看看測試點有沒有用遺漏，對需求理解有沒有錯誤，測試場景是否覆蓋完全。

3、一般測試過程中出現(xiàn)問題，你是怎么定位的？

參考答案：

1）、檢查測試環(huán)境是否有問題

2）、用fiddler抓包，分析請求和響應(yīng)數(shù)據(jù)是否存在問題

3）、查看應(yīng)用服務(wù)器的日志

4）、然后再查看數(shù)據(jù)庫的數(shù)據(jù)是否存在問題

4、測試結(jié)束的標(biāo)準(zhǔn)是什么？

答：需求覆蓋率、用例執(zhí)行率、缺陷遺留率達(dá)到預(yù)定質(zhì)量目標(biāo)

5、你會編寫測試計劃嗎？

參考答案：我們之前的測試計劃都是測試組長寫的，我們只是負(fù)責(zé)收集數(shù)據(jù)，協(xié)助組長完成測試計劃的編寫，測試計劃的內(nèi)容還是知道的，有測試范圍、測試方式/策略、測試資源、測試開始和結(jié)束條件、進(jìn)度安排、測試組織等，如果以后有機(jī)會讓我來編寫測試計劃，我覺得我沒問題。-----(回答的時候，要自信。)

6、缺陷怎么分類的？怎么跟蹤？印象最深的bug有哪些？

參考答案：缺陷類型分為：致命，嚴(yán)重，一般，輕微

? ? ? ? ? 怎么跟蹤：

? ? ? ? ? 印象最深的bug：（這個問題經(jīng)常問題，必須要提前準(zhǔn)備好）

7、測試一般做幾輪？

參考答案：一般是兩三輪，看情況，缺陷不多，就兩輪；稍微多些，就三輪。（一般我們測試都分兩到三輪，通常是兩輪，如果Bug數(shù)量多的話就三輪。然后我們拿到求文檔后，進(jìn)行需求分析和評審一般要兩天左右，測試計劃的編寫大概也要半天時間，編寫測試用例和評審也要兩到三天，然后測試執(zhí)行也要兩到三天，中途開發(fā)要修復(fù)bug和回歸測試也要兩到三天）

8、工作中遇到過什么困難，是怎么解決的？

參考答案：(思考三四秒...)在上個項目遇到過一個，當(dāng)時我們的測試環(huán)境有問題，在界面上構(gòu)造不了數(shù)據(jù)，導(dǎo)致測試堵塞了，項目又趕著上線，當(dāng)時我們的解決方法是，從生產(chǎn)環(huán)境上把數(shù)據(jù)導(dǎo)到測試環(huán)境上來測試。

8、你們兼容性怎么測試的？

面：你們上一個項目寫了多少條測試用例

我：我也記不太清了，大概一千多條吧，但我們迭代比較頻繁，大概一個迭代是100多條用例，這個也是要根據(jù)需求來，需求多的話，就寫多一些

面：發(fā)現(xiàn)了多少個Bug

我：發(fā)現(xiàn)了五六十個bug吧，如果面試官問：發(fā)現(xiàn)這么多?就回答開發(fā)的水平有限，如果說少，就說開發(fā)的能力可以

面：項目有上線嗎

我：我們公司是做外包的，產(chǎn)品一般都是給客戶定制，完成項目后交付給客戶他們會自己去運(yùn)營，有可能把軟件的名字改了再上線，我們也不清楚

9、迭代兩到三周的項目，需求分析寫多久，用例寫多久，寫多少用例，執(zhí)行多久，發(fā)現(xiàn)多少個bug，做了幾個版本，項目有沒有上線？

參考答案：

1）、需求分析1到2天，用例也是寫兩天左右，包括用例評審；

2）、用例的個數(shù)看需求和顆粒度的大小，如果時間充足，我們寫的用例細(xì)，用例數(shù)就多些，一個版本大概有100多條，執(zhí)行花的時間長了，一般要4到5天；

3）、每個版本發(fā)現(xiàn)的bug數(shù)量，要看需求和實現(xiàn)起來的難易程度，開發(fā)人員的水平和測試用例的質(zhì)量，一般一個版本我們能找50-60個bug，越到后面，系統(tǒng)越來越穩(wěn)定，發(fā)現(xiàn)的bug就越少；

4）、總的版本數(shù)記不清了，十來個版本是有了的；

5）、項目上線了，我們是給用戶定制產(chǎn)品的，交付給用戶自己運(yùn)營。

10、你們的項目做了多久，一直在做？你負(fù)責(zé)哪些模塊？

提示：這個項目到現(xiàn)在還一直在做，已經(jīng)做了8個月了(多長時間，可以靈活修改)，前期需求比較多，迭代的版本多一些，到后期項目基本穩(wěn)定了，需求變化不大，我們會被調(diào)去做其他項目，這個項目后期如果需求發(fā)生變化，我們還是要負(fù)責(zé)測試。所以，在上家公司基本每個人都會跟著幾個項目。

提示：回答負(fù)責(zé)哪些模塊的時候，一定不能說 注冊，登陸，查詢！?。?！

11、項目多久迭代一次

1）、沒有固定時間，看需求的多少和復(fù)雜程度，快的這個星期，慢的一個月

2）、看需求的多少，我們寫的用例比較細(xì)，一個用例測試一個場景，基本每個迭代都有100多條用例

3）、把bug單對應(yīng)的用例執(zhí)行一遍，還要檢查有數(shù)據(jù)交互的模塊會不會受影響，有沒有引入新的問題；項目上線前，還要把當(dāng)前版本的重要功能以及冒煙測試的用例都回歸一遍，確保重要功能上線后不出問題。

12、那你們用例執(zhí)行后bug占整體的比率，是什么原因造成的？

參考答案：一般是40%左右

14、問題：當(dāng)用戶需求變更時，你會怎么做？

答案：這個會經(jīng)常遇到的，一般如果是小的需求變更，合理的話，能改的，經(jīng)理會讓開發(fā)直接改，然后測試再測一下就好了，如果是涉及到比較大的改動的話，我們會開會討論一下會影響到的模塊，經(jīng)理會計算一下修改的成本，一般會建議放到下一個版本再修改，如果必須要改的話，開發(fā)就會改的，測試也會重新修改一下測試用例，把可能會影響到的模塊再測一遍。

14、公司在哪里？有多少人？項目有多少人？

參考答案：公司在xxxx，有40來人，沒問的項目開發(fā)有7個，測試2個。

17、問：在最新的項目中有學(xué)習(xí)到什么，對自身的成長有沒有什么幫助

答： 通過這個項目首先是豐富了我自身的測試經(jīng)驗，然后這個項目也是有做性能、接口、自動化等等，這讓我的測試能力更能全面的發(fā)展，同時通過項目也讓我對web端的測試更加熟悉，相信在以后的工作中我對web端的項目能夠盡快上手的。

---（PS：根據(jù)自己的理解來回答）

************************************

15、面試官：支付功能怎么測試(特別重要)

第三方支付，微信怎么測？

像第三方支付寶，微信調(diào)用接口，然后我們公司有專用的支付寶賬號和微信賬號

1、從功能方面考慮：

1）、用戶的使用場景：包括正常完成支付的流程；支付中斷后繼續(xù)支付的流程；支付中斷后結(jié)束支付的流程；單訂單支付的流程；多訂單合并支付的流程；余額不足；未綁定銀行卡；密碼錯誤；密碼錯誤次數(shù)過多；找人代付；弱網(wǎng)狀態(tài)下，連續(xù)點擊支付功能功能，會不會支付多次；分期付款等；

2）、不同終端上支付：包括PC端的支付、筆記本電腦的支付、平板電腦的支付、手機(jī)端的支付等；

3）、不同的支付方式：銀行卡網(wǎng)銀支付、支付寶支付、微信支付等；

4）、從產(chǎn)品容錯性上：包括支付失敗后，能否再次支付、能否退款；

2、從性能方面考慮：

多個用戶并發(fā)支付能否成功；

支付的響應(yīng)時間；

3、從安全性方面考慮

? 使用Fiddler攔截訂單信息，并修改訂單金額，或者修改訂單號，(下兩個訂單A,B，付款時攔截訂單B，并把訂單B的訂單號改為A訂單的訂單號)無法完成支付；

4、從用戶體驗方面考慮

是否支持快捷鍵功能；

點擊付款按鈕，是否有提示；

取消付款，是否有提示；

UI界面是否整潔；

輸入框是否對齊，大小是否適中等。

5、兼容性

? BS架構(gòu)：不同瀏覽器測試。

? APP：不同類型，不同分辨率，不同操作系統(tǒng)的手機(jī)上測試

16、購物車怎么測試？(特別重要)

1.功能測試

? ? a）、未登錄時：

將商品加入購物車，頁面跳轉(zhuǎn)到登錄頁面，登錄成功后購物車數(shù)量增加。

? ? b）、登錄后：

所有鏈接是否跳轉(zhuǎn)正確；

商品是否可以成功加入購物車；

購物車商品總數(shù)是否有限制；

商品總數(shù)統(tǒng)計是否正確；

全選功能是否可用；

刪除功能是否可用；

價格總計是否正確；

商品文字太長時是否顯示完整；

購物車中下架的商品是否有標(biāo)識，是否還能支付；

新加入購物車商品排序（添加購物車中存在的店鋪的商品和購物車中不存在的店鋪的商品）；

是否支持快TAB、ENTER等快捷鍵；

商品刪除后商品總數(shù)是否減少；

收藏功能是否可用；

購物車結(jié)算功能是否可用。

2.兼容性測試

? ? ? BS架構(gòu)：不同瀏覽器測試，比如：IE，火狐，谷歌，360這些。

? ? ? APP：在主流的不同類型，不同分辨率，不同操作系統(tǒng)的手機(jī)上測試，華為，vivo，oppo等

3.用戶體驗測試

? ? ? 刪除商品是否有提示；

? ? ? 是否支持快捷鍵功能；

? ? ? 是否有回到頂部的功能；

? ? ? 商品過多時結(jié)算按鈕是否可以浮動顯示；

? ? ? 購物車有多個商品時，能不能只對單個商品結(jié)算；

? ? ? 界面布局、排版是否合理；

? ? ? 文字是否顯示清晰；

? ? ? 不同賣家的商品是否區(qū)分明顯。

4.性能測試

? ? ? 打開購物車頁面要多長時間

************************************

17、面試官：你們整個購物流程是怎樣的，都有那些測試點？ -- 以下答案為只能作為回答思路的參考，具體細(xì)節(jié)需要自己再細(xì)化

答：我們整個測試購物流程是這樣的，首先在前臺界面去搜索自己要購買的商品，搜索這功能是我們的一個測試點（問:那你是怎么去測試這搜索功能的）首先我會按正常情況下輸入正確的信息去進(jìn)行搜索看是否達(dá)到自己想要的結(jié)果，然后會輸入一些異常的信息去搜索如：搜索不存在的商品、敏感的字符等看是否能搜索，這就是我對搜索功能的一個測試。把自己要購買的商品添加購物車（說了下購物車的測試）添加一件商品到購物車然后去檢驗是否添加成功，添加同樣的商品是否數(shù)量疊加，添加前的價格和添加后的價格是否一樣等這些都詳細(xì)說了下........最后就是結(jié)算，我說在結(jié)算之前要確認(rèn)購物車商品的價格是否和結(jié)算的價格一樣，確認(rèn)一致后選擇一種支付方式如微信、支付寶、余額支付等支付之后去確認(rèn)扣款的錢是否和結(jié)算的錢一樣.......之后還說了下物流方面還有訂單狀態(tài)方面（簡單說了下）

安裝測試：

通過第三方軟件協(xié)助安裝是否正常

在不同操作系統(tǒng)下安裝是否正常

安裝過程中斷網(wǎng)，安裝是否能完成

安裝后的文件夾及文件是否寫到了指定的目錄里，且沒有生成多余的目錄結(jié)構(gòu)和文件

軟件安裝過程是否可以取消，點擊取消后，寫入的文件是否如概要設(shè)計說明處理

軟件安裝過程中斷電/重啟/死機(jī)

安裝空間不足時是否有相應(yīng)提示

卸載測試

可以通過第三方軟件協(xié)助卸載

測試卸載后文件是否全部刪除所有的安裝文件夾

軟件卸載過程中斷電/重啟/死機(jī)

卸載后是否可以重裝

升級測試

在線跨版本升級

通過第三方軟件協(xié)助升級是否正常

在不同操作系統(tǒng)下升級是否正常

升級過程中斷網(wǎng)，升級是否能完成

升級后的文件夾及文件是否寫到了指定的目錄里，且沒有生成多余的目錄結(jié)構(gòu)和文件

軟件升級過程是否可以取消，點擊取消后，寫入的文件是否如概要設(shè)計說明處理

軟件升級過程中斷電/重啟/死機(jī)

升級空間不足時是否有相應(yīng)提示

總用例數(shù)1500條， 總bug500個左右， 每天寫50-60個，一個每個項目大概6-12個月，

、如果一個項目給你負(fù)責(zé)、你會怎么做？

參考答案： 在測試前需要先做好測試計劃，其中最重要的是本次測試使用的測試方法、使用的測試工具、測試環(huán)境。人員方面需要進(jìn)行人員及進(jìn)度的安排，每個測試階段后的輸出件，還要有風(fēng)險評估。在測試前將這些準(zhǔn)備工作做到位，這樣在測試的時候就會比較有條理。

如果項目很趕，經(jīng)理安排一個項目要三周內(nèi)完成，你知道你完成不了，你怎么辦？

參考答案：先和經(jīng)理說明，時間太短，存在風(fēng)險；然后，將任務(wù)劃分優(yōu)先級，先完成優(yōu)先級高的任務(wù) ，保證項目的主要功能沒問題，然后，時間允許的話，再做優(yōu)先級稍微低的；在這個時間段內(nèi)，每天向 上級報告工作的進(jìn)度，讓領(lǐng)導(dǎo)知道現(xiàn)在的工作進(jìn)展和存在的風(fēng)險。

21、驗收測試(UAT測試)怎么做？

參考答案：在UAT測試之前，我們會制定測試方案，選擇基線用例，即級別高的用例，在UAT測試環(huán)境上進(jìn)行測試，如果測試通過，驗收測試就通過了。