2020 年過的很快，眨眼間就到了 2021 年。最近看了幾篇行業同僚的年終總結，想著自己也要回顧過往，總結得失，看看能否指明自己接下來一年前進的方向，于是有了這篇文章。

直接從主題開始說起，要講清楚 “如何體現測試工程師的價值” 這件事，我們分三個層面來談，即 Why、What、How。

Why
為什么要談論這件事，因為工作中會面臨很多棘手的情況，無法直接體現測試工作的價值。比如，發現的 Bug 越多是不是代表隱藏的 Bug 越少，產品質量越好，不一定；發現的 Bug 很少是不是代表隱藏的 Bug 越多，產品質量不好，也不一定。拿這個例子舉例是因為測試工程師日常的絕大多數工作都在于此，如果平時工作很努力，但是產品質量卻不是很理想，會讓人產生挫敗感，從而自我懷疑，我到底有沒有價值。

What
那么測試工程師的價值是什么，最重要的是保證產品質量。但是這里又有一個問題，把整個產品質量拋給測試團隊來兜底是不可取的，測試團隊只能保證產品質量的下限，產品質量的上限是整個團隊共同努力的結果。撇開質量這一點，另一點則是效率，也是老生常談的測試開發比了，如何做得既快又好，是體現自身價值的關鍵。

How
圍繞著既快又好這一關鍵點，接下來我會結合過去這一年的工作經驗，來談談我們的工作是如何開展的，哪些做得好的需要繼續保持，哪些做得不好的需要改進。

3.1 從流程上談質量

?

上圖描述的是我們一個需求的生命周期，黃色部分是我作為團隊里的一個 Member 日常需要負責的工作。解釋下 “PFB” 即 Preview Feature Branch，因為同時會有很多個需求在進行開發，所以會有很多個分支在測試，最后將一個版本內的所有需求合進版本分支。

在需求終審結束后，測試需要及時輸出測試用例，以及提供 P0 用例用于開發自測，保證提測后主流程暢通，至于如何制定提測標準暫且不表。

Test PFB 環境測試結束后，會有一個 QA UAT PFB 驗收環節，該流程主要是為了保證交付的 UAT 版本質量，此前因為 UAT 分支無人管理而頻遭投訴，無奈之下只能投入部分人力進行質量控制。

接下來到了發版階段，需要進行 Staging 回歸測試，Liveish 環境驗證，再部署到 Live 環境，則該版本需求生命周期結束。

為了保證迭代速度，每個版本之間都是間隔并行的。什么意思呢，假設有 A B C 三個版本，C 版本的需求本周處于測試階段，而上一版本 B 的需求本周處于 UAT 階段，上上版本 A 的需求則本周需要發版。

細心的同學可能會發現，一個需求要在多個環境中重復測試，即使質量有所提升，但對 QA 來說是非常痛苦的，且沒有太多人力可以投入，所以目前在 UAT 和 Staging 階段對于新需求只保證主流程，舊功能則依靠自動化保證質量。

3.2 從效率上談質量

?

上圖是我們接口自動化平臺的主要功能，QA 在平臺中編寫接口自動化用例后，即可用于日常監控和版本回歸，從而盡可能減輕一部分重復工作。編寫的用例要求盡可能適用于 4 個環境，且需要隨著產品迭代不斷增加新功能的用例，保證覆蓋足夠多的場景。

自動定位系統的作用是如果有用例失敗，根據請求的全局唯一 Trace-ID，去對應容器中將日志搜索出來，寫入用例的結果中，以便于 QA 定位問題，減少查日志的工作耗時。

PIC(Person In Charge) 系統則是配置了各個模塊對應的 DEV PIC，如果有用例失敗，則會自動發送郵件提醒 DEV 處理。為了避免打擾，以及誤報的情況發生，此處增加了人工確認環節，目前并沒有開啟自動發送郵件功能。

整個平臺的初衷是想結合接口自動化打造一套監控體系，一是保證各環境的穩定性，二是可以避免日常測試工作因為依賴方的各種問題造成的阻塞。但實際情況卻并沒有因此改善，首先對于監控任務中失敗的用例，QA 完全沒時間去處理其為何失敗，其次依賴方的問題目前仍舊要靠私下解決。所以目前平臺最大的價值還是在于 Staging 階段的自動化回歸。

3.3 從創新上談質量

?

如今測試左移右移概念提及的比較多，核心思想有兩點，一是盡可能早的發現問題，二是時刻監控產品質量。

第一點，從 3.1 的流程圖中，參與需求終審和組織用例評審都是為了確保產品，開發，測試對需求的理解達成一致，盡可能避免產品設計和功能實現不一致的情況發生。

上圖中，黃色部分是我們當前已開展的工作。靜態代碼掃描其實是有做的，結合 GitLab 的掃描插件在 Commit & Merge 時進行掃描，但目前形同虛設，并沒有人關注掃描結果。

單元測試，實際上完全依賴于開發對于自己的代碼是否有 Ownership，我認為依靠 QA 去做單元測試是不現實的，且效率非常低。除非說實現 TDD(測試驅動開發) 模式，拋開 TDD 不談，光推行單元測試就是一個非常難的事情。

接口測試，由于目前已經有比較完善的用例集，想把接口測試結果作為條件之一放進提測標準中。但是目前接口測試沒有集成到 Jenkins 中，且提測標準應該達到多少通過率，如果達不到，失敗的用例又該誰來處理，想來想去發現這些事還是落到了 QA 身上，實在是分身乏術。

代碼覆蓋率，曾經有嘗試過，結合 Coverage.py 做了一個 Demo，也算是實現了想要的功能。但是不太了解 Python 項目的構建方式，如何融入 Gunicorn 中，如何接入項目代碼中也沒搞清楚，且后來團隊技術棧由 Python 切換到 Golang，由此被擱置。

線上日志監控，當前主流的做法是 ELK，即 Elasticsearch、Logstash、Kibana 三者結合，分別負責日志的搜索、存儲和展示。但實際上這些仍舊是不夠的，ELK 只是提供了一個日志搜索平臺，真正要做到監控，還需要 Node Exporter、Prometheus、Grafana 三者合作，收集日志中的數據進行展示，如接口 Latency、QPS、200、400、500 等等。

總結

對自己的工作進行了一番梳理和回顧，能改進的地方還有很多，能做的事情也還有很多。一方面因為自身能力不足，另一方面也因為時間有限，許多地方仍舊沒有做好，希望新的一年能夠有所進步。

彩蛋：可能有小伙伴疑惑沒有提及到性能測試、兼容性測試、UI 自動化這些。UI 自動化有在實踐，但還沒有真正派上用場，是一個做不好可能會有負收益的活；由于我就職于電商公司，每次大促前會有性能測試；兼容性測試由于 UI 自動化沒開展，自然無法結合 UI 自動化做兼容性測試，處于放棄狀態，雖然我也搗鼓過 STF 這玩意兒。

如果你
①從事功能測試，想進階自動化測試

②在測試界混了1、2年，依然不會敲代碼

③面試大廠卻屢屢碰壁

那下面的這些資料應該會對你有幫助

這份資料，對于【軟件測試】的朋友來說應該是最全面最完整的備戰資料，為了更好地整理每個模塊，我也參考了很多網上的優質博文和項目，力求不漏掉每一個知識點，這些資料也陪伴了我的每一刻自學之路，希望也能幫助到你

關注公眾號：程序員二黑，即可領取軟件測試全套資料合集
?

總結

以上是生活随笔為你收集整理的程序人生丨如何体现测试工程师的价值的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。