作者：歸鄉云
?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 這玩意兒，
加油吧，測驗人！路就在腳下，成功就在明天！
未來的你肯定會感謝現在拼命的自己！
給大家推薦一個軟體測驗技術交流群：1079636098 群友福利免費領取
愿你我相遇，皆有所獲！ 歡迎關注微信公眾號：程式員一凡
1.免費領取一份216頁軟體測驗工程師面試寶典檔案資料，
2.軟體測驗學習路線以及相對應的視頻學習教程免費分享！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/250486.html
標籤：其他