每天閱讀30分鐘-阿里測試之道讀書筆記(三)(四)
日期:2025-07-31
頁碼:21-25
關鍵詞:#代碼門禁 #測試本質
?? 核心知識卡片
軟件測試中的噪聲
核心:與你的測試目標無關,但卻可能干擾測試結果的因素;識別并控制噪聲,是保證測試可信度的關鍵
如何控制:1、隔離測試環境(虛擬機、容器或測試專用服務器) 2、控制變量:讓每次測試都在相同條件下執行 3、使用mock,避免依賴不穩定或外部系統 4、增加樣本量
今日讀書感悟:
? 1、反射弧短。書中說沒有度量就沒有改進,而在這本書中認為-軟件測試的度量反射弧越短越好,書中也舉了很多例子。
? 給出了反射弧的衡量標準:1、反饋的前置等待時間 2、反饋本身的耗時。
這個在我的工作中,其實表現的非常具體,例如在某客戶的產品對接中,客戶會要求我直接不干別的,就是配合開發對某個嚴重問題,進行在線復現+對開發所作出的修改進行即可驗證------這就是縮短了反饋部分的前置等待時間。假如他要走正常流程,那么先去合入到Daily-build線上,然后再出,刷版本,驗證問題-分配到我頭上時,我有要去跟客戶對接安排資源······一系列的等待成本大大延長了反射弧的時間。
日期:2025-08-4
頁碼:25-34
關鍵詞:#自動化穩定重要性 #提高自動化穩定性
?? 核心知識卡片
自動化穩定性難點
核心:1、同時執行用例相互影響 2、人對測試環境的影響 3、測試環境底層基建的不穩定 4、測試環境的臟數據 5、測試用例有問題
后果:1、失敗用例排查工作量大 2、對自動化測試喪失信任和信息(很多失敗用例可能僅是草草看一眼,說是環境問題而不繼續排查) 3、許多問題被掩蓋了自動化難點解決方案
高頻測試:
1、持續對master或head打包 2、高頻發布
? ---好處: 1、縮短反饋弧,功能回歸更快 2、識別和確認小概率問題(一天一次容易漏掉小概率BUG(自我解釋是數據或測試環境異常),每小時一次,連續三次失敗,測試環境異常則解釋不通) 3、高頻倒逼人工環節自動化隔離:
1、不同的測試活動之間盡量做到不相互影響。(可分為硬隔離與軟隔離,但無明確分界線)
? ---好處:1、減少噪聲 ,消除測試批次運行時彼此影響 2、提高效率:會產生全局影響性的測試,再隔離的環境里并發執行用完即拋:
原則:”測試環境是短暫的“------長時間存在的測試環境存在:1、臟數據 2、累積的測試數據未清理 3、配置的漂移-----都影響到測試的穩定性
? ---用完即拋好處:1、解決環境問題,減少臟數據 2、倒逼優化測試環境 3、提高資源的流動能力
? ---要求我們:1、環境搭建能力強 2、自動化不應該依賴一個長期存在的環境 3、日志要保存好關閉自動重跑:
今日讀書感悟:
? 1、今天的感觸頗深的是:隔離
因為我的測試環境中,涉及到一些用例確實是非常影響整體測試環節的,一旦失敗,可能造成整個測試環境其他所有用例的一致失敗。這導致了80%以上的自動化測試可能都是白費功夫?
當時的我并沒有看這本書,但不約而同地采用了書中所提到的隔離,即把這些對測試影響很大的用例人為遷移到物理隔離的另一臺機器上單獨跑。
? 其他的步驟對我來說其實感悟還是沒有那么深刻,因為這邊的自動化只有我一個人,所以導致了一個人要是去維護用完即拋+高頻是完全不現實的內容。外加作為供貨廠商來說,交付才是首位,反而對于這些的提升是次要的。這可能也是這個行業的悲哀吧

浙公網安備 33010602011771號