問題1:測試是否真實有效?——測試有效性
第一個關鍵問題,我想知道我的測試是否都真實有效。乍看上去像個偽問題,其實不然。可以捫心自問一下:我能保證軟件所有的測試都是有效的測試嗎?不見得吧……對這個問題心里有底的測試人員值得好好表揚一下。基于真實經驗和數據不難得出結論,有效測試的比例并不高,甚至在某些場景下,測試人員都沒有考慮過“大量執行的測試是否真的有效”這個問題。
如何評估測試有效性呢?可以從測試策略、測試反饋、可測性等角度來逐一盤點。
測試策略
測試金字塔
首先評估測試策略的有效性,可按照測試分層模型“測試金字塔”來逐層盤點:
1. 總共分幾層:采取哪些測試
2. 各層占多大比例:測試重點
3. 各層測試目標:不同的測試服務于不同的測試目標
4. 各層覆蓋要求:不同測試應覆蓋哪些問題,覆蓋率的要求
然后評估測試用例和用例集的有效性:
1. 不管是手工測試用例還是自動化測試用例,每個測試都需要是有效的測試
2. 不同的測試用例集能真實的服務于不同的測試目標
3. 消除重復的測試或各層之間重復覆蓋的測試點,避免浪費
4. 測試覆蓋相對完備:不片面追求覆蓋率數值,而強調對業務場景的覆蓋程度
5. 建立測試下沉機制:在金字塔上層發現缺陷,評估是否從下層逃逸,如是應在下層補測試
測試反饋
為了使測試能有效的反饋代碼質量,適量的測試應在合適的時機進行,且能有效反饋代碼質量,并能起到門禁作用,避免低質代碼流入下游。解釋一下這句話中的關鍵信息:
1. 適量的測試:不同測試應有不同量級的用例被執行,保證覆蓋的情況下越少越好
2. 合適的時機:不同的測試可按需周期測、隨時測,或放到流水線上時時跑著
3. 有效反饋:合理預期,正確斷言,確保能真實反饋軟件表現
4. 門禁作用:當測試不通過時應及時截斷,避免低質代碼繼續流轉
可測性
軟件可測性指被測軟件在給定測試環境下,可支持測試的程度。軟件可測性有較多參考因素,如:可控制、可觀測、隔離性、可讀性、自動化程度等。軟件可測性是確保測試有效性的必要條件,當可測性較高時,測試有效性才有可能維持較高的水平。
一般當聊到可測性時,可能會根據測試類型的不同做以下區分:
1. 前端可測性:指軟件對前端測試的支持程度,如UI規范、前端代碼規范等
2. 后端可測性:指軟件對后端測試的支持程度,如高內聚低耦合,提供測試接口、執行步驟可控可觀測等
3. 完善的日志系統:提供可觀測、可追蹤的日志系統,便于快速定位問題
便于觀測的日志系統
問題2:測試能否高效執行?——測試效率
當確保了測試有效性,就需要關注測試執行的效率如何了。畢竟是測試基于有限時間窗的活動,所以我們不光要追求測試都是有效的,還追求能高效的執行這些測試。而這又依賴于環境和設施的底層支持,以及持續的關注和改進測試執行效率的具體行動。
測試環境支持
我們對測試環境的使用過程可大致分為以下步驟:
準備測試資源 → 測試環境部署 → 測試服務部署 → 環境驗證 → 環境使用 → 環境銷毀
實際工作場景中,測試環境往往是阻礙測試效率的一大難題。為了達成不同的測試目標,測試所需要的環境、數據、集成情況可能都不一樣,我們期望測試環境能“專款專用”,有效隔離,避免不同測試種類、不同測試人員、不同實踐活動、不同測試數據之間相互掣肘。
吐槽測試環境
理想豐滿,現實骨感。當測試人員在申請環境資源時,經常遇到各種阻礙,如環境資源的高成本,或者環境申請的長鏈復雜流程。測試人員期待的環境支持應滿足以下幾個條件:部署和維護成本低、按需擴展、即用即拋,不同測試間的環境和數據隔離,讓測試人員能夠從各種繁雜的排查環境問題中真正解脫出來,聚焦業務測試。
想要新環境?不存在的
測試基礎設施
想要獲得較高的測試效率,必不可少的關鍵因素是持續集成。測試效率要想提高,需要相對理想的測試策略:少量的手動探索式測試 + 大量的自動化回歸測試 + 基于需求的專項測試,這其中大量的自動化回歸測試就需要有效集成到持續集成流水線中去。可按照以下檢查點來評估:
1. 有大量有效的自動化測試
2. 自動化測試添加到持續集成流水線
3. 基于每次代碼提交的測試,如核心模塊的單元測試,或核心業務流程的回歸測試,應加到對應服務的pipeline中作為獨立step,有效反饋提交代碼的質量
4. 其他業務回歸類的自動化測試,也需要定期頻繁執行,關鍵時間節點必執行
5. 有測試執行的可視化報表或監控機制,確保問題及時被處理
除了持續集成,有效的測試也依賴于測試套件的快速準備,服務于不同測試目標的數據生成,以及測試工具或平臺級的支持。
測試執行效率
不論測試的環境和設施支持是否完備(畢竟這不只是測試的決策),測試人員都需要持續的持續的關注和改進測試效率:
1. 手工探索:是否有助于在有限時間內發現缺陷,探索執行的測試是否需要加到常規用例中
2. 自動化測試:執行周期合理,執行時長相對穩定,通過率維持一定水平
問題3:測試價值體現在何處?——測試價值
內建質量
如果說以前測試的職責是發現軟件的缺陷,那么現在我們聊的質量內建,其實是發現和糾正流程的缺陷。任何可能降低軟件質量的工作方式,也可以是我們關注和改進的對象。而在質量內建的過程中,測試人員貢獻的最大價值就是幫助全團隊建立質量意識,由“測試和質量是QA的事兒”轉變為“測試和質量是大家的事兒”。思維的轉變是最難的,但也是一旦轉變發生了,就會在各個工作點滴中迅速匯集效果的根本。
全程質量內建
暴露風險
測試的另一個重要職責是充分暴露風險。這里的風險有三類:質量風險、交付風險和生產環境風險。
通過缺陷建模、缺陷數據分析、根因分析和缺陷預防等實踐,測試人員可以充分了解質量風險,從而對即將投產的軟件進行質量風險上的預測。這種基于歷史經驗的預判有助于降低生產環境的質量風險。
在以往和測試人員交流的過程中,大家表示對風險的干預程度可能較低。但其實這里測試人員的價值在于充分的暴露風險:需要把風險點是什么、測試人員給出的預判、潛在風險可能產生的損失、風險干預的手段和因此產生的成本等等這些信息,全部同步給團隊,并在團隊進行風險干預時進行一定的輸入和引導。
測試人員的職責:識別和暴露風險
捍衛門禁
測試人員的話語權體現在對質量門禁的捍衛上。人當有所為,有所不為,團隊也一樣。測試人員一定要捍衛質量門禁,不通過就是不通過,需要明確給出測試結論,盡量避免任何模棱兩可的質量結論。
一些明確的質量結論示例:
l “某功能經過充分的測試和相關回歸,測試通過,可以上線。上線后需觀測……”
l “時間過緊,某功能只經過驗收標準的測試,尚未充分的回歸和探索,不建議在當前熱更上線。可以安排在下次熱更上線,我們就有充分的時間完成測試。”
l “如不可抗力必須上線,可能面臨的質量風險有……建議采取以下幾種措施進行干預和快速恢復,上線后建議相關角色持續觀測……,確保第一時間捕捉線上問題。”
質量門禁需要捍衛,如果有原因導致門禁失效,那也是團隊共同決策的結果,團隊整體需共同承擔質量風險,并盡所有人的努力把損失降到最低。