做一名能文能武的測試員，教你測試與開發溝通時的常勝秘籍

又到了招聘季，不少測試人員開始物色合適的機會，那麼在面試時都有什麼套路呢?

大部分的面試都是先“文”後“武”。

“文”呢，主要是問你一些測試的理論技巧、邏輯思維以及團隊之間問題的處理方式等等。

“武”呢，大體來說就是問你一些測試技能，包括一些測試工具、環境配置等等的使用。加我VX：atstudy-js 回覆“測試”，進入軟體測試學習交流裙~~

今日我們主要來說說測試的“文”，主要分為兩大部分：

1. 面對“開發說”，測試人員的完勝秘籍是什麼?

2. 作為一個專業測試，日常的測試標配工作流程具體是什麼?

第一篇：開發說

面試官問該類問題：一方面是考察面試人員的是否實際參與工作，一方面是考察面試人員的處理事務能力。

那麼，在日常測試工作中，如何高效、高情商地面對所謂的“開發說”呢?

1. 開發說：需求文件沒提到?

測試秘籍：人為判斷需求文件未提及的問題，jira提交【改進】給需求人員，讓產品確認並備註解決方案後轉移給對應的開發人員，並同步更新需求文件。

2. 開發說：上一版本留下的坑?

測試判斷：影響業務非基礎流程，影響使用者體驗。

測試秘籍：缺陷影響業務非基礎流程/影響使用者體驗，jira提交【低階-缺陷】給當前負責該模組的開發人員，要求開發備註缺陷原因以及解決方案。

3. 開發說：這個bug級別太高?加我VX：atstudy-js 回覆“測試”，進入軟體測試學習交流裙~~

測試秘籍：從阻塞耗時間，來判斷缺陷等級。

1)導致測試工作無法開展，且解決耗時較長(嚴重影響測試進度)的，定義為高階;

2)導致測試工作無法開展，可在短時間(不影響測試進度)內解決的，可適當降低缺陷等級;

3)導致部分工作無法開展，不影響其他流程，可適當降低缺陷等級;

4)原則上不予降級，但是開發出現異議，可協商等需求上線後的覆盤會議上進行二次討論。

4. 開發說：我自測了?

開發自測的質量，嚴重影響測試的工作量，提測的質量不過關，無形中增加了測試的工作負擔。

那麼如何保證開發自測和提測的質量呢?

測試秘籍：

1)實行開發自測用例，將1級用例指派給開發進行執行;

2)在提測前檢測開發是否執行自測用例;

3)提測後在日報彙報當日測試效果。

5. 開發說：不是我的問題?

在測試過程中，特別是測試前端時，開發經常習慣性的不排查問題，直接給測試人員說：這是api的問題。

所以測試在日常工作中，經常出現找前端開發，前端開發說是api的問題，找api開發說是前端問題。那麼作為一個專業的測試，如何減少這種不斷找bug主人的工作?

測試秘籍：

1)對比現象，同時對比安卓和ios：

a) 若是兩端均為錯誤，則大機率是api的問題，可以優先找api人員;

b) 若是僅有一端出現錯誤，則大機率是前端的問題，可以優先找前端開發。

2)學會看日誌：使用抓包工具或者公司內部的日誌平臺，直接定位是介面返回的資料異常，還是前端展示異常;

3) 提供定位日誌：給對應的開發人員。

6. 開發說：部署/安裝一下?

在測試過程中經常出現，開發解決一個bug，就會要求你部署一次程式碼或者重新安裝包，導致測試過程中不斷地部署、不斷地安裝，不僅影響個人測試，同時也會影響他人測試的準確性。

測試秘籍：

1)判斷缺陷嚴重程度：導致無法繼續測試的缺陷，可立即部署/更換安裝包;

2)非嚴重缺陷，則按以下方式處理：

a) 開發在缺陷jira上備註：修復的版本+修復內容+可能影響範圍;

b) 及時提交程式碼;

c) 完成a)+b)之後，開發人員及時再將缺陷【狀態變更：已解決+指派給對應的測試人員】。

測試人員可以階段性的對已解決的缺陷進行環境部署或安裝包替換後，再進行統一回歸驗收。

第二篇：測試姐們的日常標配

電腦手機都有低配置、標配、高配置的區分，那麼測試的日常規範也可以做個等級劃分。

測試流程及其不規範的測試日常是低配：直接開展測試

測試流程稍微規範點的測試日常勉強算是標配：需求-測試要點-上線

……

每一家公司的工作流程規範都不統一，以下是個人根據自我經歷整理出來的測試日常工作流程。

1. 參加需求評審會議

在需求會議前，測試人員需事先了解會議內容，並對疑問點進行標註。

在需求會議中，及時提問，在需求會議結束後，跟進確認會議上問題的解決方案。

2. 制定測試計劃

1)評估測試工作量;

2)確定測試環境：在哪一套環境上開展測試工作;

3)確定測試策略：新功能測試、相容性功能測試、歷史功能迴歸測試、升級測試等;

4)準備測試物料：提前預備測試資料，測試硬體環境(瀏覽器、手機等);

5)……

3. 設計測試用例

常見的設計測試用例，除了大家常說的參考需求文件和需求原型外，實際上，我們還需要參考以下內容。

1)UI設計效果：注意UI設計效果;

2)需求原型;

3)流程圖：銜接各個子系統之間的業務流轉，設計對應的場景型測試用例;

4)需求文件。

4. 評審測試用例

1)資訊同步：需求會議後變更的內容，在評審時再次同步給開發;

2)核心評審：需求文件未提及細節內容，著重提醒開發。

5. 執行測試

6. 測試日報：當日測試進度，阻塞問題等

7. 上線風險評估：評估是否滿足上線標準、遺留問題處置