企業級測試能力提升培訓總結
背景
2023.5.27-2023.5.28
公司組織了麥思博的企業級測試能力提升培訓.
兩天12個小時的培訓, 課時非常滿.
講師是 上海交大畢業的 茹炳晟 老師.
課程上有過多次互動, 我這邊也拿到了講師的一本贈書.
擔心自己年齡越來越大記性越來越差,所以想把這次培訓的一些內容簡單總結一下.
備忘.
培訓的主要內容
1. UI自動化
2. API自動化
3. 性能測試
4. 測試服務架構
5. 部分遷移AI,數據相關的測試技術.
培訓裏面記住的一些重點-1
1. 關於軟件研發的發展
傳統業務是大魚喫小魚
軟件業務是快魚喫慢魚
軟件業其實是一門不是很規範的手工業.
存在很多問題, 當然了也是因爲存在的問題多,纔有測試的立足之地.
第二天還講解到了一個十萬塊的邊界值檢查的案例.
其實我感受很深刻. 不成熟不規範的手工業很大的缺陷就是 你付出的多了 木秀於林風必摧之
會情不自禁的進入內卷. 在管理不正規的企業內卷帶來的往往不是自己得提高, 而只是管理者的政績.
還有同僚的排斥.
培訓裏面記住的一些重點-2
2. 關於研發猛將的理解:
善戰者無赫赫之功，善醫者無煌煌之名
很多看起來處處救火的人,畢竟是高績效的員工.
防患於未然纔是優秀傑出的員工.
公司裏面也存在這樣的情況. 很多時候很多人不聽取別人的建議.
樂於在問題出現時出面救火, 顯示自己的能力, 表現自己的忠心和勤奮.
培訓中老師講解必須有CTO研發負責人進行復盤.
不是最終boss帶領下的覆盤都會出現偏頗與甩鍋.
這一點我感覺航空航天的問題歸零是真的很有必要的. 一個問題如果不打破砂鍋問到底
早晚生產都會死給大家看.
很多事故,都是一個個不起眼的小細節導致最終的崩潰.
培訓裏面按記住的一些重點-3
3. 很多新工具
3.1 UI測試裏面的 recheck-web 可以實現記錄部分頁面的對象的所有屬性,
在腳本中屬性出現變化時動態獲取正確的對象.
我這邊沒研究過,但是可能對存儲和CPU的消耗會比較大
3.2 web page performance test
可以對網頁進行性能測試時,給出結論.
這個可以進行一下私有化的部署和搭建. webpagetest_3.0.zip
3.3 LLM的一些工具.比如自動化測試用例生成,腳本生成, 這一塊我沒有研究過.
培訓時正好也在處理一個項目問題. 這一塊培訓我吸收的不太好.
3.4 契約測試
茹老師說,使用契約測試之後,測試腳本只需要之前腳本的三分之一.
很早之前我看過契約測試, 但是我感覺這一塊對研發的技術和人品要求極高.
適合服務穩定不會需求變動多的場景. 我們這邊產品的變動驚天動地..研發給不出一個合適的契約數據.
3.5 混沌測試
沒有講解具體的內容. 我們這邊跟建超老師學習過chaos blade 等兩個工具.
感覺更多的是模擬網絡延遲. 阻塞,丟包. 以及可以模擬磁盤等故障來實現故障注入.
核心是要控制爆炸半徑. 不能讓一個人拖死所有人.
3.6 微服務治理與測試
滴滴的微服務有5000多個, 已經沒有人能夠了解所有微服務的調用了. 理論上必須有統一日誌平臺
統一跟蹤和可觀測性. 隨着微服務的越來越深入. 可測試性是非常重要的. 沒有可測試性就沒有可以發版的信息.
3.7 性能測試
重點說了下 併發測試與相應時間. 茹老師是LR等軟件的資深架構師. 對測試工具的使用很有經驗.
我理解併發測試是數據正確性測試, 性能測試, 功能測試, 與極限測試的統稱.
3.8 LLM,chatgpt的工具集成. 這一塊沒有深入講解. 需要繼續學習.
主要有一些code brush,以及代碼自動補齊, 測試用例,測試腳本自動生成等內容.
等等其他內容.
培訓裏面按記住的一些重點-4
4. 誰是質量的第一負責人
誰設計誰開發誰部署誰on-call
優秀的傑出的產品不是測試出來的, 是設計,是開發,是精心養育出來的.
代碼都是千人千面
相同人在不同心情下的代碼質量也是不一樣的.
代碼規範, 尤其是一個完美的代碼樣例是非常關鍵的.
研發依據一個完善的樣例進行開發, 他的代碼往往不會有很多低級問題.
沒有經過培訓和錘鍊的研發,會寫錯很多低質量的垃圾代碼.
測試是QA是用來保證產品下線的. 他只能保證產品最壞的情況
但是客戶需要的是產品最佳的情況. 這一塊需要大家一起努力.
培訓立即朱的一些重點-5
5. 性能測試與環境
性能環境主要講解了一些概念.
我理解最重要的是各種基線的處理.
我這邊獲取服務器最好是通過類似於
SPECJVM2008,SPECCPU2006,FIO,redis-benchmark,sysbench,unixbench,lmbench
等等工具進行一些基線數據的獲取.
而且最好的是在測試之前,對測試環境的晚上, 早上10點, 下午三點左右進行基線獲取.
虛擬化平臺儘量要獲取超售以及硬件平臺的基礎情況. 避免出現說不清楚的問題.
性能測試也是如此, 最好是模擬超長時間下的 性能表現, 不僅僅要模擬高峯,還要模擬低谷和退出的場景
要視始爲終,從頭就要重視.做好測試場景規劃,測試數據規劃纔可以.
也講解了一些其他的概念
配置測試, load test
性能測試的核心是要摸到產品的天花板.
我理解性能測試其實就是<長空之王>裏面的試飛員.
要驗證各種天氣(硬件),高度(配置),最高最低速度(TPS基線和RT極限),然後給後來的使用者一些指導意見.
而且性能測試與試飛員一樣, 一次儘量只修改一個變量, 不要修改太多變量進行測試.
多個變量會導致結果的較難分析. 對應的性能測試來收變量太多了, 需要長時間的準備和實施,
常見的參數有: 數據庫配置,類型, 數據庫參數. 磁盤類型, io優化程度. 事務類型.
應用的數據庫連接池大小, 線程池大小, jvm的內存. jvm的gc算法. linux的tcp內核參數.
負載均衡的算法. 數據量的大小.等等等等.
性能測試其實也分兩種. 一種是取長板, 一種是取短板
長板主要是用於驗證修改的一些特性, 是產品優化的方向. 是產品的熱點和賣點
短板主要是用於發現產品的性能瓶頸, 保證產品在最差的情況下能夠滿足客戶的SLA,SLO等概念.
長板與短板都重要, 沒有長短可能沒有新客戶. 短板太差老客戶都會流失.
其他總結
多參與一些培訓挺好的. 更重要的是應該將培訓中遇到的工具進行落實.
只學習不幹, 或者是隻看不練都是不可取的.
回想工作這些年, 我這邊也就參與過公司外的一兩次培訓. 大部分都是自己學習.
基本上都是靠自己.
靠自己雖然很充實,但是很累, 也沒人會看到你的價值.
其實看公司對一個人好不好和看另一半對你好不好是一樣的
舍不捨得給你時間. 舍不捨得給你錢. 舍不捨得給你未來. 舍不捨得給你發展
餅不是未來.
