《阿里測試之道》閱讀筆記

日期：2025-07-29
頁碼：1-21
關(guān)鍵詞：#測試角度 #經(jīng)驗教訓(xùn)思考

?? 核心知識卡片

智能效能并非矛盾
核心：智能效能并不是一對矛盾，不是一個硬幣的正反面，而是一個人的兩條腿，缺一不可

捍衛(wèi)者
核心：質(zhì)量人不僅是系統(tǒng)質(zhì)量的捍衛(wèi)者，也是用戶體驗的捍衛(wèi)者
案例：阿里的測試技術(shù)覆蓋軟件服務(wù)的整個生命周期，前端發(fā)布管控和移動端線上質(zhì)量保障、A/B測試平臺和性能監(jiān)測平臺，性能分級與自動降級、智能推薦流程，把用戶體驗做到了極致。

測試技術(shù)體系
橫向（項目周期）：需求分析、測試分析、用例編寫管理、測試執(zhí)行、BUG管理、持續(xù)集成、灰度測試、線上測試
縱向（測試類型）：功能測試、性能測試、可靠性測試、安全測試、用戶體驗測試

今日讀書感悟：

? 說的自動化的困境部分，確實是非常透徹與深刻。是目前經(jīng)常能遇到并且為之煩惱的問題。

日期：2025-07-30
頁碼：21-25
關(guān)鍵詞：#代碼門禁 #測試本質(zhì)

?? 核心知識卡片

代碼門禁
核心：1、公共分支，禁用git push，只允許通過pull request來提交代碼 2、研發(fā)平臺對提交到公共分支的pull request執(zhí)行檢驗（編譯、單元測試、接口級別測試）
優(yōu)化：1、縮短時間-測試執(zhí)行時間不超過10分鐘（保證質(zhì)量+維護(hù)開發(fā)體驗） 2、提高穩(wěn)定性

測試本質(zhì)
核心：測試的本事是反饋-代碼是不是好的-不同需求對于好的標(biāo)準(zhǔn)不同。總的說，測試是為了提供質(zhì)量反饋
案例：1、代碼門禁中，根據(jù)單元測試和接口測試結(jié)果，判斷是否可以接受代碼提供決策依據(jù) 2、功能回歸的測試結(jié)果，判斷當(dāng)前代碼推進(jìn)到預(yù)發(fā)布和灰度驗證階段提供決策依據(jù) 3、預(yù)發(fā)布與灰度驗證結(jié)構(gòu)，判斷當(dāng)前版本代碼是否能部署到線上環(huán)境

測試反饋能力
本質(zhì)：我的理解，就是測試對一個Bug（單子），提出的質(zhì)量的保證。測試的質(zhì)量和效能？
三個維度：縮短提供反饋的時間------BUG快速暴露 降低提供反饋的成本-------BUG暴露成本低 反饋可信度高----無效BUG少
對于測試的不斷優(yōu)化,就在這三個維度中進(jìn)行提升.縮短時間是關(guān)鍵!

今日讀書感悟：

? 1、有趣的部分。我看到代碼門禁的章節(jié)中。有一個bug jail的內(nèi)容很有意思。講的是一個開發(fā)如果有很多高優(yōu)先級的BUG長時間不修復(fù)。代碼門禁就會把他關(guān)到bug jail 中，不允許其開發(fā)新的功能-即不允許他進(jìn)行pull request合并。對應(yīng)到我目前的情況可能是DI值的高低？這個感覺確實是一個能有效降低項目DI值的做法，不過這個貌似對開發(fā)不太友好??

? 2、測試本質(zhì)部分。這個引起了我一部分的思考，目前從我公司這邊的角度來說也是對應(yīng)的。冒煙用例--審核這個基本功能過不過關(guān)，BVT用例----是否可以大量投人力進(jìn)入測試？BUG驗證，由提單人進(jìn)行問題的回歸。驗證過后才會合入到主線包中。 說本質(zhì)也就是保證每一筆合入的代碼，都能正常滿足產(chǎn)品所對應(yīng)的需求。深刻啊······

? 3、測試反饋能力這個部分,確實是非常精準(zhǔn)地定位了測試的最核心----BUG