最近一直在思考關于測試的三個關鍵問題應該是什么，目前有了初步的假設和解決思路，姑且先寫下來，以拋磚引玉，尋求更多反饋和探討。
問題一：測試是否真實有效？——測試有效性
第一個關鍵問題，我想知道我的測試是否都真實有效。乍看上去像個偽問題，其實不然?？梢話行淖詥栆幌拢何夷鼙ＷC軟件所有的測試都是有效的測試嗎？不見得吧……對這個問題心里有底的測試人員值得好好表揚一下。基于真實經(jīng)驗和數(shù)據(jù)不難得出結論，有效測試的比例并不高，甚至在某些場景下，測試人員都沒有考慮過“大量執(zhí)行的測試是否真的有效”這個問題。
如何評估測試有效性呢？可以從測試策略、測試反饋、可測性等角度來逐一盤點。
測試策略
首先評估測試策略的有效性，可按照測試分層模型“測試金字塔”來逐層盤點：
- 總共分幾層：采取哪些測試
- 各層占多大比例：測試重點
- 各層測試目標：不同的測試服務于不同的測試目標
- 各層覆蓋要求：不同測試應覆蓋哪些問題，覆蓋率的要求
然后評估測試用例和用例集的有效性：
- 不管是手工測試用例還是自動化測試用例，每個測試都需要是有效的測試
- 不同的測試用例集能真實的服務于不同的測試目標
- 消除重復的測試或各層之間重復覆蓋的測試點，避免浪費
- 測試覆蓋相對完備：不片面追求覆蓋率數(shù)值，而強調(diào)對業(yè)務場景的覆蓋程度
- 建立測試下沉機制：在金字塔上層發(fā)現(xiàn)缺陷，評估是否從下層逃逸，如是應在下層補測試
測試反饋
為了使測試能有效的反饋代碼質(zhì)量，適量的測試應在合適的時機進行，且能有效反饋代碼質(zhì)量，并能起到門禁作用，避免低質(zhì)代碼流入下游。解釋一下這句話中的關鍵信息：
- 適量的測試：不同測試應有不同量級的用例被執(zhí)行，保證覆蓋的情況下越少越好
- 合適的時機：不同的測試可按需周期測、隨時測，或放到流水線上時時跑著
- 有效反饋：合理預期，正確斷言，確保能真實反饋軟件表現(xiàn)
- 門禁作用：當測試不通過時應及時截斷，避免低質(zhì)代碼繼續(xù)流轉
可測性
軟件可測性指被測軟件在給定測試環(huán)境下，可支持測試的程度。軟件可測性有較多參考因素，如：可控制、可觀測、隔離性、可讀性、自動化程度等。軟件可測性是確保測試有效性的必要條件，當可測性較高時，測試有效性才有可能維持較高的水平。
一般當聊到可測性時，可能會根據(jù)測試類型的不同做以下區(qū)分：
- 前端可測性：指軟件對前端測試的支持程度，如UI規(guī)范、前端代碼規(guī)范等
- 后端可測性：指軟件對后端測試的支持程度，如高內(nèi)聚低耦合，提供測試接口、執(zhí)行步驟可控可觀測等
- 完善的日志系統(tǒng)：提供可觀測、可追蹤的日志系統(tǒng)，便于快速定位問題
問題二：測試能否高效執(zhí)行？——測試效率
當確保了測試有效性，就需要關注測試執(zhí)行的效率如何了。畢竟是測試基于有限時間窗的活動，所以我們不光要追求測試都是有效的，還追求能高效的執(zhí)行這些測試。而這又依賴于環(huán)境和設施的底層支持，以及持續(xù)的關注和改進測試執(zhí)行效率的具體行動。
測試環(huán)境支持
我們對測試環(huán)境的使用過程可大致分為以下步驟：
準備測試資源 → 測試環(huán)境部署 → 測試服務部署 → 環(huán)境驗證 → 環(huán)境使用 → 環(huán)境銷毀
實際工作場景中，測試環(huán)境往往是阻礙測試效率的一大難題。為了達成不同的測試目標，測試所需要的環(huán)境、數(shù)據(jù)、集成情況可能都不一樣，我們期望測試環(huán)境能“?？顚Ｓ谩保行Ц綦x，避免不同測試種類、不同測試人員、不同實踐活動、不同測試數(shù)據(jù)之間相互掣肘。
理想豐滿，現(xiàn)實骨感。當測試人員在申請環(huán)境資源時，經(jīng)常遇到各種阻礙，如環(huán)境資源的高成本，或者環(huán)境申請的長鏈復雜流程。測試人員期待的環(huán)境支持應滿足以下幾個條件：部署和維護成本低、按需擴展、即用即拋，不同測試間的環(huán)境和數(shù)據(jù)隔離，讓測試人員能夠從各種繁雜的排查環(huán)境問題中真正解脫出來，聚焦業(yè)務測試。
測試基礎設施
想要獲得較高的測試效率，必不可少的關鍵因素是持續(xù)集成。測試效率要想提高，需要相對理想的測試策略：少量的手動探索式測試 + 大量的自動化回歸測試 + 基于需求的專項測試，這其中大量的自動化回歸測試就需要有效集成到持續(xù)集成流水線中去?？砂凑找韵聶z查點來評估：
- 有大量有效的自動化測試
- 自動化測試添加到持續(xù)集成流水線
- 基于每次代碼提交的測試，如核心模塊的單元測試，或核心業(yè)務流程的回歸測試，應加到對應服務的pipeline中作為獨立step，有效反饋提交代碼的質(zhì)量
- 其他業(yè)務回歸類的自動化測試，也需要定期頻繁執(zhí)行，關鍵時間節(jié)點必執(zhí)行
- 有測試執(zhí)行的可視化報表或監(jiān)控機制，確保問題及時被處理
除了持續(xù)集成，有效的測試也依賴于測試套件的快速準備，服務于不同測試目標的數(shù)據(jù)生成，以及測試工具或平臺級的支持。
測試執(zhí)行效率
最后，不論測試的環(huán)境和設施支持是否完備（畢竟這不只由測試來決策），測試人員都需要持續(xù)的持續(xù)的關注和改進測試效率：
- 手工探索：是否有助于在有限時間內(nèi)發(fā)現(xiàn)缺陷，探索執(zhí)行的測試是否需要加到常規(guī)用例中
- 自動化測試：執(zhí)行周期合理，執(zhí)行時長相對穩(wěn)定，通過率維持一定水平
問題三：測試價值體現(xiàn)在何處？——測試價值
內(nèi)建質(zhì)量
如果說以前測試的職責是發(fā)現(xiàn)軟件的缺陷，那么現(xiàn)在我們聊的質(zhì)量內(nèi)建，其實是發(fā)現(xiàn)和糾正流程的缺陷。任何可能降低軟件質(zhì)量的工作方式，也可以是我們關注和改進的對象。而在質(zhì)量內(nèi)建的過程中，測試人員貢獻的最大價值就是幫助全團隊建立質(zhì)量意識，由“測試和質(zhì)量是QA的事兒”轉變?yōu)椤皽y試和質(zhì)量是大家的事兒”。思維的轉變是最難的，但也是一旦轉變發(fā)生了，就會在各個工作點滴中迅速匯集效果的根本。
暴露風險
測試的另一個重要職責是充分暴露風險。這里的風險有三類：質(zhì)量風險、交付風險和生產(chǎn)環(huán)境風險。
通過缺陷建模、缺陷數(shù)據(jù)分析、根因分析和缺陷預防等實踐，測試人員可以充分了解質(zhì)量風險，從而對即將投產(chǎn)的軟件進行質(zhì)量風險上的預測。這種基于歷史經(jīng)驗的預判有助于降低生產(chǎn)環(huán)境的質(zhì)量風險。
在以往和測試人員交流的過程中，大家表示對風險的干預程度可能較低。但其實這里測試人員的價值在于充分的暴露風險：需要把風險點是什么、測試人員給出的預判、潛在風險可能產(chǎn)生的損失、風險干預的手段和因此產(chǎn)生的成本等等這些信息，全部同步給團隊，并在團隊進行風險干預時進行一定的輸入和引導。
捍衛(wèi)門禁
測試人員的話語權體現(xiàn)在對質(zhì)量門禁的捍衛(wèi)上。人當有所為，有所不為，團隊也一樣。測試人員一定要捍衛(wèi)質(zhì)量門禁，不通過就是不通過，需要明確給出測試結論，盡量避免任何模棱兩可的質(zhì)量結論。
一些明確的質(zhì)量結論示例：
- “某功能經(jīng)過充分的測試和相關回歸，測試通過，可以上線。上線后需觀測……”
- “時間過緊，某功能只經(jīng)過驗收標準的測試，尚未充分的回歸和探索，不建議在當前熱更上線?？梢园才旁谙麓螣岣暇€，我們就有充分的時間完成測試?！?/li>
- “如不可抗力必須上線，可能面臨的質(zhì)量風險有……建議采取以下幾種措施進行干預和快速恢復，上線后建議相關角色持續(xù)觀測……，確保第一時間捕捉線上問題?！?/li>
質(zhì)量門禁需要捍衛(wèi)，如果有原因?qū)е麻T禁失效，那也是團隊共同決策的結果，團隊整體需共同承擔質(zhì)量風險，并盡所有人的努力把損失降到最低。
寫在最后
關于本文內(nèi)容，我還在持續(xù)地思考和迭代。我想知道何以測試人員普遍缺乏價值感，可能大部分源于所做的事情并沒有意義。怎樣給測試這件事情賦予意義呢？期望完成這個思考過程能幫助我找到答案。
下期預告：關于質(zhì)量的三個關鍵問題。
——————————————————————————————————————————
推薦文章
1.《測試用例的一些“真相”與“事實”》
2.《精益測試》
3.《測試人員的價值》
4. 《SubcutaneousTest》
