大廠的測試流程是什麼樣的？這篇文章告訴你！

一名測試工程師的學習之路，所有部落格連結已存放在該連結下：一個Tester

大廠測試流程是什麼樣的？這篇文章告訴你！

• • 一、評審階段
  • • 1.1 需求評審
    • 1.2 設計評審
    • 1.3 用例評審
    • • 1.3.1 功能用例評審
      • 1.3.2 聯調用例評審
  • 二、測試階段
  • • 2.1 冒煙測試
    • 2.2 功能測試
    • 2.3 聯調測試
    • 2.4 回歸測試
  • 三、釋出上線（預釋出->生産）

一、評審階段

1.1 需求評審

    一般在需求評審階段中，參與者至少會有

産品經理

、

開發

、

測試

。如果項目需求比較大、還會有

PMO、業務方、UI設計師等

參與到需求評審中。作為測試而言，在需求評審中，最需要做兩件事。

• 了解需求

  ：對于測試而言，我們需要在需求評審會議上了解需求，不要出現會上無問題，會後三連問的情況，這樣也比較耽誤産品的時間。

• 提出疑問

  ：因為産品的需求也不一定合理，我們要帶着問題參與到評審中。而且如果是新進入一個公司，對于公司的業務不太熟悉的時候，需求評審也是一個熟悉業務的好機會。

    需求評審階段，我們需要關注以下相關問題。

• 傳遞目标

  ：該需求面向的人群是誰？是外部使用者、供應商？還是公司内部商務、營運、客服使用。

• 傳遞計劃

  ：需求的上線計劃，驗收計劃，是否灰階，以及測試工作量的評估。

• 業務流程

  ：本次是新增的功能或流程？還是原有業務流程增加新的節點或是修改節點邏輯。

  

1.2 設計評審

設計評審

：就是開發在聽完産品的需求後，先編寫好

開發設計文檔

。然後根據項目的大小決定是否需要進行設計評審，如果隻是小的優化或功能，一般就不會進行設計評審，而對于比較大的項目，就會拉上産品、測試進行設計的評審。在設計評審中，

常常會發現開發對需求的了解與産品是不一緻的

。而作為測試而言，參與設計評審一是為了加深需求的了解，二是了解開發的設計，也要注意

開發的設計是否合理

。

    在設計評審中，測試一般需要關注以下相關的問題(不一定全面，可能會存在相關差異)。

• 流程設計圖

  ：開發設計的流程圖是否能達到産品需求的流程？

• 資料庫表設計

  ：是否新增表？是否需要分庫分表？如何保證唯一性？表字段預設值？是否需要添加索引？

• 接口

  ：接口層面分為本系統和上下遊系統。本系統：新增接口的調用方是誰？原有接口修改後是否影響上下遊業務？上下遊系統：調用其他系統接口或者被其他系統調用的接口，是否有對接？需要評估是否對接口負載有影響？一般核心域的核心接口，在有新增入參的情況下，也會根據線上情況進行不同入參下的性能測試，評估接口QPS是否能達到預期，防止上線後出現性能問題。

• 元件變更

  ：是否有配置變更，配置的預設值是否合理？是否有環境變量變更？相關元件是否有變更？

• 灰階

  ：是否有開關？灰階方案是什麼？是根據使用者灰階還是？

• 復原

  ：如果出現問題，復原方案是什麼？復原時相關域的復原順序是怎麼樣的？

  

1.3 用例評審

1.3.1 功能用例評審

功能用例評審

：測試人員在編寫好用例後，可以通過郵件的形式将發送給對應開發和産品，檢視用例場景是否有遺漏。一般開發和産品不怎麼看這個郵件的話，就可以抽了十多分鐘，拉上會議，進行一個當面的用例評審。

    如果是新入職的新人，一般是編寫好用例後，先發送郵件給産品、開發，抄送給本組的測試同僚，然後再拉上産品、開發進行一個當面的溝通。

1.3.2 聯調用例評審

聯調用例評審

：如果需求涉及到多個系統的話，一般是需要進行一個聯調用例評審。評審前一般是會先确定好本次需求的

主測試

，然後主測會編寫好

聯調文檔

。

    聯調用例評審會上會有以下幾件事需要做：

• 宣講用例

  ：主測宣講聯調的用例，各系統的測試檢視是否有場景遺漏，并進行補充。

• 确定分工

  ：相關基礎資料的準備交給對應系統。确定是否有本次需求系統無需變更，但是要協助聯調的系統，确定跟進人。

• 問題記錄

  ：對于聯調評審中無法确定的問題，進行記錄，後續跟進解決。

  

二、測試階段

2.1 冒煙測試

冒煙測試

：在開發提測後，就進入測試階段。首先進行冒煙測試，冒煙測試一般需要注意相關問題：

• 靜态代碼掃描

  ：進行靜态代碼掃描，是否有blocker、critical的代碼。

• 代碼編譯 & 服務部署

  ：測試分支進行開發代碼編譯和部署，檢視是否能編譯和部署成功。且部署成功後，一般會檢視環境中服務的日志，檢視有無明顯的報錯日志。

• 冒煙測試用例

  ：首先執行冒煙的自動化Case,然後根據自己設計的冒煙階段的用例，執行用例并測試。

    關于靜态代碼掃描、代碼編譯等，需要看所在公司對于相關測試平台的建設。例如我現在所在的公司，就是可以建立一個流水線，其中可以配置下面這些功能：

代碼編譯、單元測試、單元測試覆寫率、靜态代碼檢查、項目打包，鏡像烘焙、部署、系統測試(自動化代碼執行)

。是以一般開發提測後，就是執行一下對應的流水線，檢視代碼是否能編譯通過，靜态代碼掃描是否有問題，原先的自動化Case中的冒煙Case是否能通過等

    在冒煙測試過程中，我們需要有以下記錄：

• 用例上傳及執行

  ：上傳冒煙測試用例，并在執行用例後，記錄為用例已執行。

• BUG記錄

  ：如果冒煙Case不通過，提冒煙Bug給開發。

• 工時記錄

  ：記錄冒煙測試階段的使用工時。

• 補充冒煙自動化Case

  ：如果是接口域，根據情況看是否需要補充冒煙的自動化AT，有則補充自動化AT，分組設定為冒煙。

2.2 功能測試

功能測試

：在冒煙測試通過後，進行到功能測試。功能測試與冒煙測試的不同在于，

冒煙測試隻是先将主流程走了一遍，而功能測試需要考慮正常情況和異常情況下的所有情況

。在功能測試階段需要注意以下問題：

• 前置準備

  ：準備好基礎的測試資料，相關變更需要在測試環境中執行等。

• 用例執行

  ：根據用例設計執行功能測試部分的用例。一般而言，在功能測試階段，需要調用外部系統服務的話，采用

  Mock

  的方式，Mock外部系統的傳回，除去Mock外部系統的正常傳回，還要Mock逾時，抛出異常等異常情況。

• 預期結果

  ：測試用例執行的結果是否符合預期結果。

    在功能測試過程中，我們需要有以下記錄：

• 用例上傳及執行

  ：上傳功能測試用例，并在執行用例後，記錄為用例已執行。

• BUG記錄

  ：如果功能Case不通過，提功能測試階段Bug給開發。

• 工時記錄

  ：記錄功能測試階段的使用工時。

• 補充自動化Case

  ：補充本次需求的自動化Case。

• 功能測試報告

  ：發送功能測試報告，内容包括是否通過？遺留問題及風險點。

  

2.3 聯調測試

聯調測試

：一般隻有當需求涉及到多個系統的變更的時候，才需要進行聯調測試。而

聯調測試一般就是各系統将各自的服務部署再Staging聯調環境中後，模拟生産一樣，按照聯調用例走一趟實際的流程

。

    在聯調測試中，需要關注以下的點：

• 真實資料

  ：聯調的資料要是真實的資料，

  一定不能Mock資料！！！

  。而且不要直接修改資料庫、Redis中的資料

• 核心流程回歸

  ：對于原有的核心的流程，也要做到一定程度的回歸，防止對原有流程有影響。

• 聯調日報

  ：主測需要通過郵件的形式彙報整體聯調的進度，以及聯調進度的風險、聯調發現的問題等。

  

2.4 回歸測試

回歸測試

：在測試分支進行完功能測試後，在釋出上線前，開發合并代碼到dev、master分支後，分别進行一次回歸測試。回歸測試一般需要注意相關問題：

• 回歸時間

  ：一般而言，當有一個域需要在明天釋出，會在确定今天這個域沒有釋出、或這個域今天需要釋出上線的需要已經上線後，才讓開發合并代碼到dev分支或者master分支，待合并代碼後再進行回歸。

• 靜态代碼掃描

  ：代碼依次合并到dev、master分支後，進行靜态代碼掃描，確定沒有blocker、critical。

• SDK更新

  ：本域服務和依賴的外部服務需要更新為正式版，不使用SNAPSHOT版。

• 全量AT回歸

  ：針對接口域，會進行全量接口自動化AT的回歸，確定自動化Case沒有失敗的情況下才會進行下一步。

    在回歸測試過程中，我們需要有以下記錄：

• 用例上傳及執行

  ：上傳回歸測試用例，并在執行用例後，記錄為用例已執行。

• BUG記錄

  ：如果回歸時Case不通過，提回歸測試階段Bug給開發。

• 工時記錄

  ：記錄回歸測試階段的使用工時。

三、釋出上線（預釋出->生産）

    `預釋出環境連接配接的是真實生産的資料庫，是以回歸測試完成後，一般會先釋出到預釋出環境。待開發、産品驗收無問題後，才會釋出到生産環境。在這個過程中，需要注意以下幾方面。

• 依賴變更

  ：确定相關元件、配置、環境變量是否做了變更。在很多情況下，有些DB變更需要提前做，因為可能有的DB變更需要長達幾個小時，如果等到要釋出的時候，才想到要變更，可能今天就釋出不了了。

• 驗收

  ：一般而言，是先釋出到預釋出環境，待産品、開發驗收無問題，才會進行生産釋出。如果有問題，重新修改代碼再推預釋出再驗收。生産釋出完成後，産品也需要再進行一遍驗收。

• 釋出順序

  ：檢查釋出域的版本号是否為正式版，且要按照

  順序釋出

  。釋出系統可以做到子產品關聯，設定某一個域釋出完成之後，另一個域才能釋出。

• 釋出時間間隔

  ：根據域的重要性不同，生産伺服器機器數量也不同，是以釋出的時候會設定批次。而每個批次的釋出之間，最好進行一定時間的間隔。

• 日志監控

  ：在生産釋出的過程中，需要通過日志系統檢視有無異常日志，如果出現預期外的異常日志，需要和開發溝通後判斷是否需要復原。

• 告警監控

  ：通過釋出系統檢視是否有本域告警和上下遊告警，如果有，也需要找開發确認是否有影響，再決定是否復原。

• 復原

  ：如果出現核心流程的告警，或者不能确定的告警和異常情況下，一般會先直接進行復原操作。需要注意的是，需要注意復原的順序。如果由于復原前，造成相關異常資料，在復原後，還需要進行異常資料的處理。

寫在最後：以上就是一個大概的測試流程的總結，其中肯定也會有一些遺漏，各公司之間的測試流程也會有差異。是以覺得總結的還可以的，請

一鍵三連

！覺得還有要補充的，可以在下方留言！

如果我的部落格對你有幫助、如果你喜歡我的部落格内容，請

“點贊” “評論” “收藏”

一鍵三連哦！

【資源分享】

上面是我收集的一些測試相關的學習資料，有需要的朋友可以關注我的微信公衆号：【One Tester】免費擷取。共同學習，共同進步！