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.免費領取乙份216頁軟體測試工程師面試寶典文件資料。
測試工程師面試經驗
01.為什麼要在乙個團隊中開展軟體測試列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況,根據他們選擇測試用例.例如,在單元測試時曾列出的許多在模組中常見的錯誤.以前產品測試中曾經發現的錯誤等,這些就是經驗的總結.還有,輸入資料和輸出資料為0的情況.輸入 為空格或輸入 只有一行.這些都是容易發生錯...
滲透測試工程師從業經驗
這周參加360的補天大會聽了一位滲透大佬的分享，感覺獲益匪淺。1 客戶系統，之前做過滲透測試，我們要怎麼做？深入了解客戶系統，一絲不苟發現系統深層次漏洞。2 客戶系統，部署了防火牆，我們要怎麼做？可以繞過防火牆進行測試，比如通過內部wifi的手段等。客戶已有的安全防護，不一定安全，很容易被繞過。3 ...
測試工程師如何「攻城」 上
python程式設計學習資源乾貨 python selenium框架web的ui自動化 python unittest框架api自動化 資源和 免費送啦 測試工程師的基本功有哪些？作為一名測試工程師，我們首先要學會並理解測試工程師的基本技能是什麼，相信很多入坑的朋友要麼是報班學習了一套軟體測試技能，...