軟件測試工程師的職責是什麼

軟件測試工程師的職責是發現BUG，此外，如何體現我的價值？那麼咱們試想，只提出問題而不去解決，問題就永遠得不到閉環。因此，一個資深的測試人員的基本功應該是這樣的：深挖業務和功能需求，找出BUG，定位BUG，提出解決方案。這裏咱們就來講說，當咱們找到了BUG，應該把BUG提交給誰去解決，這屬於BUG定位的問題。

試想:

根據需求，用戶頭像應是圓形，但結果是方形，是誰的BUG？

保存用戶信息時，沒法保存成功，也沒有錯誤提示，最多是誰的BUG？

顯然，工做過程當中，咱們不可能把這些BUG提交給同一我的去解決。咱們應該至少區分出是前端仍是後端BUG，就好像時下流行的詞「垃圾分類」，通過BUG分類處理，整個團隊的效率都會有所提升。

 

1.什麼是前端/後端？

目前多數互聯網項目都是先後端分離開發的，那麼什麼是前端？什麼是後端？簡言之，前端側重於頁面設計，後端側重於服務開發。

好比要保存一個用戶信息，前端把界面顯示給用戶，讓用戶按需填寫，當用戶點擊「保存」按鈕時，數據會經過網絡被提交給後端服務，由後端服務處理是否須要進一步運算，而且把數據保存在哪個數據庫的哪一張表裏。

 

2.爲何要區分前端/後端BUG？

目前多數項目都是多人協做開發的，若是不能明確這個BUG是誰形成的，容易提交給錯誤的開發人員，會大大下降BUG的解決效率。

另外，若是團隊規模較大，或者由各地的項目組拼湊而成，勢必會增長溝通成本，這更須要咱們在相似禪道或者Jira等項目管理軟件中提交BUG時，先指明是誰的BUG，避免互相踢皮球的現象。

因此，爲了提升團隊效率，測試人員尤爲要作好BUG分類。

 

3.如何定位前端/後端BUG?

對於一個優秀的軟件測試工程師來講，區分BUG屬於前端仍是後端是尤其重要的。

頁面請求過程

弄清楚如何定位和分類BUG以前，須要瞭解一下頁面請求的過程，以 http 請求爲例，請求過程以下：

1.用戶在前端頁面操做，如點擊某個功能

2.頁面攜帶數據進行請求，訪問具體功能接口

3.由後端服務執行該接口相應的業務邏輯，如涉及數據，再去請求並組裝數據返回給前端

4.前端頁面進行渲染和展現對應的頁面和數據

 

先後端BUG各有什麼樣的特色？

• 前端BUG

      界面相關

      佈局相關

      兼容性相關

• 後端BUG

      業務邏輯相關

      性能相關

      數據相關

      安全性相關

定位BUG屬於前端仍是後端，有什麼方法？

這裏提供了幾個方法，能夠給你們一個思路，讓你們能在學習和工做中瞭解如何去區分BUG屬於前端仍是後端。

1. 經驗法

軟件測試人員應不斷精進本身的技能，負責的項目多了，天然對功能的實現過程有了解，也就明白如何分類BUG了。

例如：

網頁上的某個圖片的分辨率不對，若是咱們瞭解實現過程，能夠想到通常狀況下，是根據某個地址去服務器取圖片的，數據庫通常只保存地址，那麼圖片能正確顯示，就說明後端的基本功能是知足需求的。若是具體圖片分辨率有誤，最可能的緣由是前端顯示過程出了差錯。

 

2. 日誌查見解

當咱們發現一個BUG，並不肯定這個BUG屬於前端仍是後端，能夠查看後端服務的日誌，復現BUG時，查看日誌中有沒有相關信息。基本能夠認爲，若是日誌沒有輸出，極可能這個功能並無與後端交互，也就不存在後端的問題。反之，若是日誌有輸出，能夠進一步查看有無錯誤日誌信息，進一步分析。

 

3. 接口查見解

這種方法經常使用於查看是後端返回給前端的數據有誤，仍是前端顯示有誤。

大多數瀏覽器都有自帶的接口查看工具，如Chrome，FireFox等均可以經過F12開啓抓包，在NetWork中能夠看到當前頁面發送的每一個http請求。

經過Chrome看到的接口狀況以下

能夠在Response中查看響應數據

咱們須要對比經過後端接口拿到的數據和前端顯示的數據，來確認問題出在哪裏。若是數據錯了，頁面顯示是錯的，也是正常的，先從後端入手去解決。若是數據對了，可是顯示錯了，就須要問問前端的開發人員了。

 

4.經驗和總結

溝通很重要

咱們在定位BUG的過程當中，最不能忽略的一個問題是和開發人員的溝通，有時候忙活半天，不如一問一答。經驗和技術的成長也都離不開合理高效的溝通。

經驗和小結

出現樣式的問題基本都是CSS的BUG

出現文本的問題基本上都是html的BUG

出現交互類的問題基本上都是Javascript的BUG

其餘問題先溝通，再定位。