面試題_項目篇

項目介紹實例  http://www.javashuo.com/article/p-yxhilbtu-bo.html面試

https://www.songqinnet.com/article/1193數據庫

一、你在項目中負責什麼?(意思就是,你在項目中參與了哪些事情)瀏覽器

 

參考答案:安全

        在工做中我主要負責功能測試,其次還參與了一些非功能測試,如:接口測試,自動化測試,性能測試,兼容性測試等。在項目中主要參與了需求分析和需求評審,負責收集項目資料協助上級完成測試計劃的編寫,編寫測試用例並評審,測試環境的搭建以及測試執行和編寫測試報告等工做。服務器

 

二、問題:怎麼保證覆蓋用戶需求?微信

 

回答:架構

        從BA那裏拿到需求文檔,熟悉文檔,畫好流程圖,保證整個流程都覆蓋全面,小組之間每一個人都要根據各自的流程圖,來說解一下本身的思路,防止測試點遺漏,各個功能點有哪些限制條件,防止以後編寫測試用例時發現遺漏;用例編寫完以後,再進行用例的評審,看看測試點有沒有用遺漏,對需求理解有沒有錯誤,測試場景是否覆蓋徹底。併發

 

三、通常測試過程當中出現問題,你是怎麼定位的?佈局

 

參考答案:性能

        1)檢查測試環境是否有問題 

        2)用fiddler抓包,分析請求和響應數據是否存在問題 

        3)查看應用服務器的日誌 

        4)而後再查看數據庫的數據是否存在問題

 

四、你會編寫測試計劃嗎?

 

參考答案:

        咱們以前的測試計劃都是測試組長寫的,咱們只是負責收集數據,協助組長完成測試計劃的編寫,測試計劃的內容仍是知道的,有測試範圍、測試方式/策略、測試資源、測試開始和結束條件、進度安排、測試組織等,若是之後有機會讓我來編寫測試計劃,我以爲我沒問題。-----(回答的時候,要自信。)

 

五、缺陷怎麼分類的?怎麼跟蹤?印象最深的bug有哪些?

 

參考答案:

        缺陷類型分爲:致命,嚴重,通常,輕微 怎麼跟蹤:印象最深的bug:(這個問題常常問題,必需要提早準備好)

 

六、測試通常作幾輪?

 

參考答案:

        通常是兩三輪,看狀況,缺陷很少,就兩輪;稍微多些,就三輪。

 

七、迭代兩到三週的項目,需求分析寫多久,用例寫多久,寫多少用例,執行多久,發現多少個bug,作了幾個版本,項目有沒有上線?

 

參考答案:

        1)需求分析1到2天,用例也是寫兩天左右,包括用例評審; 

        2)用例的個數看需求和顆粒度的大小,若是時間充足,咱們寫的用例細,用例數就多些,一個版本大概有100多條,執行花的時間長了,通常要4到5天; 

        3)每一個版本發現的bug數量,要看需求和實現起來的難易程度,開發人員的水平和測試用例的質量,通常一個版本咱們能找50-60個bug,越到後面,系統愈來愈穩定,發現的bug就越少; 

        4)總的版本數記不清了,十來個版本是有了的; 

        5)項目上線了,咱們是給用戶定製產品的,交付給用戶本身運營。

 

八、大家的項目作了多久,一直在作?你負責哪些模塊?

 

提示:

        回答負責哪些模塊的時候,必定不能說 註冊,登錄,查詢!!!!

 

九、那大家用例執行後bug佔總體的比率,是什麼緣由形成的? 

 

參考答案:

        通常是40%左右

 

十、公司在哪裏?有多少人?項目有多少人? 

 

參考答案:

        公司在xxxx,有40來人,沒問的項目開發有7個,測試2個。

 

十一、問題:當用戶需求變動時,你會怎麼作?

 

參考答案:

        這個會常常遇到的,通常若是是小的需求變動,合理的話,能改的,經理會讓開發直接改,而後測試再測一下就行了,若是是涉及到比較大的改動的話,咱們會開會討論一下會影響到的模塊,經理會計算一下修改的成本,通常會建議放到下一個版本再修改,若是必需要改的話,開發就會改的,測試也會從新修改一下測試用例,把可能會影響到的模塊再測一遍。 

 

十二、面試官:支付功能怎麼測試(特別重要)

 

1)從功能方面考慮:

 

      a.用戶的使用場景:

         包括正常完成支付的流程;支付中斷後繼續支付的流程;支付中斷後結束支付的流程;單訂單支付的流程;多訂單合併支付的流程;餘額不足;未綁定銀行卡;密碼錯誤;密碼錯誤次數過多;找人代付;弱網狀態下,連續點擊支付功能功能,會不會支付屢次;分期付款等;

      b.不一樣終端上支付:

         包括PC端的支付、筆記本電腦的支付、平板電腦的支付、手機端的支付等;

 

      c.不一樣的支付方式:

         銀行卡網銀支付、支付寶支付、微信支付等;

 

      d.從產品容錯性上:

          包括支付失敗後,可否再次支付、可否退款;

 

2)從性能方面考慮:

      多個用戶併發支付可否成功;支付的響應時間;

 

3)從安全性方面考慮:

      使用Fiddler攔截訂單信息,並修改訂單金額,或者修改訂單號,(下兩個訂單A,B,付款時攔截訂單B,並把訂單B的訂單號改成A訂單的訂單號)沒法完成支付;

 

4)從用戶體驗方面考慮:

      是否支持快捷鍵功能;點擊付款按鈕,是否有提示;取消付款,是否有提示;UI界面是否整潔;輸入框是否對齊,大小是否適中等。

 

5)兼容性 BS架構:

      不一樣瀏覽器測試。APP:不一樣類型,不一樣分辨率,不一樣操做系統的手機上測試

 

1三、購物車怎麼測試?(特別重要)

 

1)功能測試

        a.未登陸時:將商品加入購物車,頁面跳轉到登陸頁面,登陸成功後購物車數量增長。

 

        b.登陸後:全部連接是否跳轉正確;商品是否能夠成功加入購物車;購物車商品總數是否有限制;商品總數統計是否正確;全選功能是否可用;刪除功能是否可用;價格總計是否正確;商品文字太長時是否顯示完整;購物車中下架的商品是否有標識,是否還能支付;新加入購物車商品排序(添加購物車中存在的店鋪的商品和購物車中不存在的店鋪的商品);是否支持快TAB、ENTER等快捷鍵;商品刪除後商品總數是否減小;收藏功能是否可用;購物車結算功能是否可用。

 

2)兼容性測試 BS架構:

      不一樣瀏覽器測試,好比:IE,火狐,谷歌,360這些。APP:在主流的不一樣類型,不一樣分辨率,不一樣操做系統的手機上測試,華爲,vivo,oppo等

 

3)用戶體驗測試:

      刪除商品是否有提示;是否支持快捷鍵功能;是否有回到頂部的功能;商品過多時結算按鈕是否能夠浮動顯示;購物車有多個商品時,能不能只對單個商品結算;界面佈局、排版是否合理;文字是否顯示清晰;不一樣賣家的商品是否區分明顯。

 

4)性能測試

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

 

1四、面試官:大家整個購物流程是怎樣的,都有那些測試點?

 

-- 如下答案爲只能做爲回答思路的參考,具體細節須要本身再細化 

 

答:咱們整個測試購物流程是這樣的,首先在前臺界面去搜索本身要購買的商品,搜索這功能是咱們的一個測試點

 

     (問:那你是怎麼去測試這搜索功能的)首先我會按正常狀況下輸入正確的信息去進行搜索看是否達到本身想要的結果,而後會輸入一些異常的信息去搜索如:搜索不存在的商品、敏感的字符等看是否能搜索,這就是我對搜索功能的一個測試。把本身要購買的商品添加購物車(說了下購物車的測試)添加一件商品到購物車而後去檢驗是否添加成功,添加一樣的商品是否數量疊加,添加前的價格和添加後的價格是否同樣等這些都詳細說了下........最後就是結算,我說在結算以前要確認購物車商品的價格是否和結算的價格同樣,確認一致後選擇一種支付方式如微信、支付寶、餘額支付等支付以後去確認扣款的錢是否和結算的錢同樣.......以後還說了下物流方面還有訂單狀態方面(簡單說了下)

相關文章
相關標籤/搜索