趁著下班空閑的一會時間回顧了一下12.19日參加的杭州第六屆測試沙龍的收獲,四個議題,收獲多多,大概整理了一下,明確一下一些內容的方向。
具體的PPT不知道官方允不允許放出來,就先不拋了,后面有回應的再加上分享的PPT1.《云設計工具前端性能測試建設及實踐》
- 主講人: 尋跡 酷家樂 質量效能部
- 收 獲:從0到1建設一項測試領域所需要的流程,以及測試落地時候所需要做的事情。
- 詳 情:
- 要有對測試產品完善的認知,產品解決什么問題?用戶場景是什么樣子?新增的測試領域能為用戶帶來什么體驗?方便制定測試目標。
- 對測試產品的技術架構有清晰的認識,方便測試工作中技術方案的制定以及測試工作中所采用的技術手段。
- 參考業界同行在這個領域是怎么做的?移植到自己的產品進行調整優化,完善出屬于自己產品的測試方向。
- 針對于制定的測試方向和自己業務的難點進行一一對應,然后進行問題細分,制定不同方向的測試指標。
- 具體的建設流程如下:
- 其他:
期間聽眾提問了三個問題,都是和UI自動化相關的內容,大意是遇到一些UI界面上鋸齒要怎么處理,由此可鑒一部分測試關注點更注重在功能實現的環節上。
2.《手淘AIOps實戰-消息全鏈路智能監控》
- 主講人: 阿里巴巴-董福銘(吾銘)、黃俊(豆豆)
- 收 獲: 自己在下一階段的規劃里也有關于日志監控的內容,相當于幫忙點了一盞明燈,瞻仰一下前沿的同行們對于日志這塊是怎么處理的。
- 細 節:
- 日志協議統一。我們這里的業務有多種協議,涉及后臺服務,前端應用,智能設備,智能硬件。想去查詢日志的時候,需要到各個角落里去收集查看,如果有統一的日志協議,的確是可以上送平臺,做集中處理。
- 高度不同,領悟不到啊,我多加油!!!
3. 《質量-監控體系建設》
- 主講人: 王靜文 有贊
-
收 獲: 對監控的一個整體認識。
image - 細 節:
- 監控的4個黃金指標
- 延遲:服務處理某個請求所需要的時間。
- 流量:使用系統中的某個高層次的指標針對系統負載需求所進行的度量。
- 錯誤:請求失敗的速率。
- 飽和度:服務容量有多滿,比如CPU,IO,內存等等
- 告警信息規范。上面聊到了下一階段有做日志監控的想法,所以這個規范對我來說還是比較及時的。
- 告警標題。精簡并且有指導性,提升處理效率。
示例:服務名稱-上送時間 - 告警級別。設置合理的告警級別 info?warn?critical?
示例:報警等級, 這里有一個要明確的點是:要和后臺人員制定好日志打印規則,不然全部是info是沒有意義的 - 告警原因。信息明確,告警規則清楚。
示例:規劃是報警日志上下20條 - 告警人提醒:開發,運維,測試。
示例:企業微信發送項目群 - 響應規范。誰在響應?什么問題?影響什么場景?什么用戶?處理方式是什么?
- 告警標題。精簡并且有指導性,提升處理效率。
- 監控的4個黃金指標
4. 《質量效能改進三板斧》
- 主講人: 賀達 E簽寶
- 收 獲:
-
對電子簽名業務以及產業鏈的了解(借PPT里的一張圖),一個極其小眾的業務類型,比我現在負責的公交業務類型還小眾。image
- 前輩是怎么用兩年的時間把一個團隊從一窮二白的囧到鳥槍加大炮,一個團隊崛起的歷程,值得借鑒的地方有很多很多。
- 認識到自己對自動化工作方向的錯誤(最大的收獲)。
-
對電子簽名業務以及產業鏈的了解(借PPT里的一張圖),一個極其小眾的業務類型,比我現在負責的公交業務類型還小眾。
- 細 節:
- 自動化方向的錯誤。市面上常見的測試框架
- pytest/unitest(負責用例執行)+SQL/yaml/Excel(用例存儲)+Allure(報告展示)+鉤子(郵件/釘釘/企業微信通知)+Jenkins/Gitlab(CI)+request(模擬HTTP請求,其他協議另選模塊)
- Httprunner(負責用例執行)+yaml(用例存儲)+其他
- pytest/unitest(負責用例執行)+rebotfarmwark(負責用例編寫)+其他
- Testng+httpclient+Allure+SQL/yaml/Excel(用例存儲)+鉤子(郵件/釘釘/企業微信通知)+Jenkins/Gitlab(CI)
- Testng+restassured(模擬HTTP請求)+ExtentTestNGIReport(報告)+其他
- 自動化方向的錯誤。市面上常見的測試框架
之前我在選擇和練手如上的這些框架的時候,第一反應就是減少使用者的代碼量,盡量可以在SQL,Excel,Yaml等格式的文檔中直接編寫用例,為了實現這個效果,盡可能的做出異常判斷,但是,遠遠沒有JMeter做的完善。
JMeter是可以實現零代碼實現接口自動化,有自定義需求的時候也可以通過jar包來實現擴展,那么,自己寫自動化腳本的意義在哪?
在看到如下的對比過程中,突然意識到一個事情:
測試是一個技術崗位,日常工作中不應該去減少代碼量,甚至應該去增加代碼量,只有這樣,才能逐漸理解開發所實現的邏輯,也可以擺脫測試只是點點點的崗位,進一步還可以實現codereview的目標,擺脫鄙視鏈末端。從這個角度來看,我之前的自動化方向一直就是錯的。
那么自動化的意義在哪?提效,盡可能的提高測試同學來編寫自動化腳本的質量與速度,提供排查手段,發現錯誤迅速定位,提高排查問題的能力(自己踩的坑還要自己填),附帶珍藏的自動化測試架構圖!
- PPT里的介紹的開源工具鏈接,一身技術來源于網絡(菜是原罪),還是要歸還于網絡的。
- 質量紅線的設計思路以及實施方案。目前在我的團隊里邊很難推動這個事情,就先看看了,需要的時候及時借鑒。
-
數據工廠的解決方案,膜拜一下大佬,真的是用了一個很巧的思路并且成本很低來解決數據工廠的難點。
image
-
竟然是通過flask+swagger的方式來解決,swagger的UI是修改過的,這樣才貼合自身的業務,甚至于swagger的原始數據也應該是做了修改。但是,這么一種解決方案,極大的降低了測試不用又搞前端,又搞后端的形式,再膜拜一遍,這種方式是真的巧,有空的時候試著實現一下。
-
照著敲了一遍示例代碼,發現學了Java之后對之前Python的一知半解理解的更透徹了一點。之前對于私有變量(private),特殊變量是沒什么感受的,知道有這么一回事,但是沒用過,抄了一下代碼,發現還能這么玩,受教了,截圖中有個調試工具,蠻好用的,推薦一下。
附調試
-