互聯網測試開發面試題集錦（中）

測試流程篇

需求階段-開發階段-測試階段-上線階段-上線後

需求階段

需求文檔規範

首先需求文檔要有規範，這部分測試能夠要求若是產品需求文檔不夠完善標準的話，一個好的需求文檔應當包含以下幾個方面：

• 版本信息（包含版本履歷，建立人，修改人，日期等）

• 需求概述包含背景，目的，影響範圍等

• 流程圖（包含業務流程圖，系統操做流程圖）

• 具體功能模塊詳解

需求評審前

• 測試負責人拆分需求模塊，分配對應的模塊負責人

• 模塊負責人進行需求瞭解、分析，整理需求疑問、建議等，若時間容許，提早發送郵件或口頭與產品進行確認，提早發送郵件或口頭與產品進行確認。

需求評審中

• 測試須要思考的地方不限於如下幾點
  瞭解需求產生的背景，瞭解產品人員想要達到的效果以及要解決的核心問題是什麼？

• 一個新功能添加的必要性須要評估。(產品預期狀態是否可以達到，投入產出比是否合適，評估這個需求是否合理，從用戶體驗角度考慮)

• 功能模塊是否與其餘模塊需求衝突，衝突時是否有相關處理方式？

• 涉及到UI方面，文字，顏色，位置，大小，樣式，佈局等是否有詳細說明，效果是否統一

• 確認以前標註的地方獲得解答

• 最後測試須要輸出的：

• 測試模塊拆分負責表，對應模塊測試負責人，測試所需時間
  評審會議所須要輸出的；需求評審會議記錄

需求評審後

• 項目經理根據會議過程整理出會議記錄公示全部相關參會人員包括相應領導。

• 測試對應模塊負責人開始用例設計，準備測試數據，按照日期監督各模塊開發負責人，準時提測

• 產品及時更新文檔，確保文檔內容是會議三方所述一致
  

會議記錄至少包括如下內容：

1. 會議中沒有解決的疑問地方，產品給出的解決方案（有些地方產品也須要會下跟業務再次確認）

2. 明確對應模塊開發負責人，測試負責人，開發測試對應所須要的時間等

3. 需求影響的模塊以及所涉及到的風險，上線以後應對的容災方案，回滾計劃等

需求優先級排期：

需求變動：
三方確認，若是確認一致經過贊成變動，產品發出郵件，產品更新文檔，開發從新修改研發時間，測試從新調整計劃，是否須要延期，測試工做量，人力，時間資源等調配

 

跨部門，跨組須要多方配合的需求如何展開測試?
避免如下點便可，如何避免如下問題多溝通多交流，拉到一個羣組交流，由項目經理牽頭組織，若是沒有測試負責。
經過文字郵件等方式確認每一個模塊開發測試按時完成，最終進行聯調測試。

開發階段

• 參與開發詳細設計評審，瞭解功能實現過程

• 開發書寫代碼，完畢以後，有兩種方式一種人工方式進行code review，組內leader負責檢查code。

• 另外一種提交到系統，由系統通知相關負責人檢查或者藉助第三方工具如(Checkstyle，FindBugs，PMD，Jtest），若是review經過則容許提交到svn

• 開發在開發環境自測，書寫自測報告

 

測試階段

從需求評審階段就開始，一個是分析需求拆分模塊，每一個對應的模塊負責人書寫測試用例（一個根據開發詳設或還有就是需求文檔），進行測試用例評審，當開發提測以後進行code review環節（適當補充用例），準備測試數據測試環境調試，冒煙測試（不接受一句話提測，對於提測信息不明確或者缺乏自測報告或者冒煙不經過給予打回），經過以後進行功能，性能，兼容性，異常測試等（若是有接口測試必定是在客戶端沒提測時候，若是涉及到先後端分離測試，那麼都是先測試服務端，而後測試客戶端），提交bug，驗證fix的bug，迴歸測試，最後肯定沒有問題，發送驗收郵件，提交上線申請。

上線階段

上線的標準：

• 本版本全部需求都已經實現

• 本版本全部測試任務已經執行完畢

• 確認全部major級別bug都關閉，個別問題若是不修復要有明確說明，bug解決率要達到95%以上，

• app穩定性評估，包含如下三個方面

  自動化評測
  （1）隨機瀏覽自動化評測結果無新增的未知的Crash發生；
  （2）隨機瀏覽自動化評測中全部已知Crash可以用修復的均已修復。

  線上灰度崩潰
  （1）線上主進程Crash所有修復；
  （2）線上子進程全部已知Crash均已修復；
  （3）線上子進程沒有新增的密集的崩潰。

  與上一版本數據對比
  （1）對上一版本穩定性對比，不差於上一版本。

• app性能評估

  頁面加載性能
  （1）Wifi頁面加載速度與上一版本相比，不能降低。
  （2）2G3G頁面加載速度與上一版本相比，不能降低。

  冷啓動時間評測
  （1）冷啓動時間與上一版相比，不能增長。
  （2）向競品看齊，與競品的差距狀況公示。

  主觀性能感知
  （1）高端機不能有很是卡的狀況，有點卡的狀況也應該控制數量
  （2）高中低端機均不能有較線上版明顯的卡頓內容

• 對於上線出現的問題應急措施考慮

  出現問題，有完善的應急預案，出現問題可以及時回滾或者立刻修復

  若是上線失敗，過後覆盤總結出這次的問題，造成郵件形式發送相關人員，避免下次再次出錯

上線以後

• 線上監控新功能運行狀況

• 出現異常狀況或者問題，須要臨時發版從新打補丁包

  補丁包提測的內容通常是：

  修復線上待修復的功能邏輯Bug

  修復線上待修復的崩潰

  優化線上體驗很差的產品需求

• 補丁包評估方法

  經過工具檢測開發提交的代碼

  三方及時溝通，爲什麼修改，影響範圍，測試須要作的

  最後確認要發送補丁包，書寫郵件告知相關負責人補丁包內容緣由影響範圍等

產品功能複合需求，產品驗收經過，進入code freeze狀態，開發打包發線上環境（通常公司除了測試環境還有會有預發環境模擬）

07

實際項目篇

• 主要涉及到你簡歷所寫的項目，舉幾個例子自動化，大家怎麼作的，你負責的是哪塊業務

• 主要考察你自動化技術水平，同時涉及到的一些技術點會順帶着一塊兒問出來，好比分層自動化，接口自動化。

• 有沒有使用編程作一些工具或者工具二次開發等

• 團隊協做如何處理問題的，你項目中你遇到困難如何解決的，還有有沒有作的很差的地方如何改進。

• 項目架構相關的，如今架構都是web／app－站點層－服務層－數據層（待續）