• 1.《云設計工具前端性能測試建設及實踐》
• 2.《手淘AIOps實戰-消息全鏈路智能監控》
• 3. 《質量-監控體系建設》
• 4. 《質量效能改進三板斧》

趁著下班空閑的一會時間回顧了一下12.19日參加的杭州第六屆測試沙龍的收獲，四個議題，收獲多多，大概整理了一下，明確一下一些內容的方向。

image

1.《云設計工具前端性能測試建設及實踐》

• 主講人： 尋跡 酷家樂 質量效能部
• 收 獲：從0到1建設一項測試領域所需要的流程，以及測試落地時候所需要做的事情。
• 詳 情：

1. 要有對測試產品完善的認知，產品解決什么問題？用戶場景是什么樣子？新增的測試領域能為用戶帶來什么體驗？方便制定測試目標。
   2. 對測試產品的技術架構有清晰的認識，方便測試工作中技術方案的制定以及測試工作中所采用的技術手段。
   3. 參考業界同行在這個領域是怎么做的？移植到自己的產品進行調整優化，完善出屬于自己產品的測試方向。
   4. 針對于制定的測試方向和自己業務的難點進行一一對應，然后進行問題細分，制定不同方向的測試指標。

• 具體的建設流程如下：

流程

• 其他：
  期間聽眾提問了三個問題,都是和UI自動化相關的內容，大意是遇到一些UI界面上鋸齒要怎么處理，由此可鑒一部分測試關注點更注重在功能實現的環節上。

2.《手淘AIOps實戰-消息全鏈路智能監控》

• 主講人： 阿里巴巴-董福銘（吾銘）、黃俊（豆豆）
• 收 獲： 自己在下一階段的規劃里也有關于日志監控的內容，相當于幫忙點了一盞明燈，瞻仰一下前沿的同行們對于日志這塊是怎么處理的。
• 細 節：
  1. 日志協議統一。我們這里的業務有多種協議，涉及后臺服務，前端應用，智能設備，智能硬件。想去查詢日志的時候，需要到各個角落里去收集查看，如果有統一的日志協議，的確是可以上送平臺，做集中處理。
  2. 高度不同，領悟不到啊，我多加油！！！

3. 《質量-監控體系建設》

• 主講人： 王靜文 有贊

• 收 獲： 對監控的一個整體認識。

  
  
  image
• 細 節：
  1. 監控的4個黃金指標
     1. 延遲：服務處理某個請求所需要的時間。
     2. 流量：使用系統中的某個高層次的指標針對系統負載需求所進行的度量。
     3. 錯誤：請求失敗的速率。
     4. 飽和度：服務容量有多滿，比如CPU，IO，內存等等
  2. 告警信息規范。上面聊到了下一階段有做日志監控的想法，所以這個規范對我來說還是比較及時的。
     1. 告警標題。精簡并且有指導性，提升處理效率。
        示例：服務名稱-上送時間
     2. 告警級別。設置合理的告警級別 info?warn?critical?
        示例：報警等級， 這里有一個要明確的點是：要和后臺人員制定好日志打印規則，不然全部是info是沒有意義的
     3. 告警原因。信息明確，告警規則清楚。
        示例：規劃是報警日志上下20條
     4. 告警人提醒：開發，運維，測試。
        示例：企業微信發送項目群
     5. 響應規范。誰在響應？什么問題？影響什么場景？什么用戶？處理方式是什么？

4. 《質量效能改進三板斧》

• 主講人： 賀達 E簽寶
• 收 獲：

  1. 對電子簽名業務以及產業鏈的了解（借PPT里的一張圖），一個極其小眾的業務類型，比我現在負責的公交業務類型還小眾。
     image
  2. 前輩是怎么用兩年的時間把一個團隊從一窮二白的囧到鳥槍加大炮，一個團隊崛起的歷程，值得借鑒的地方有很多很多。
  3. 認識到自己對自動化工作方向的錯誤（最大的收獲）。
• 細 節：
  1. 自動化方向的錯誤。市面上常見的測試框架
     1. pytest/unitest（負責用例執行）+SQL/yaml/Excel（用例存儲）+Allure(報告展示)+鉤子（郵件/釘釘/企業微信通知)+Jenkins/Gitlab（CI）+request（模擬HTTP請求，其他協議另選模塊）
     2. Httprunner（負責用例執行）+yaml(用例存儲)+其他
     3. pytest/unitest（負責用例執行）+rebotfarmwark（負責用例編寫）+其他
     4. Testng+httpclient+Allure+SQL/yaml/Excel（用例存儲）+鉤子（郵件/釘釘/企業微信通知)+Jenkins/Gitlab（CI）
     5. Testng+restassured（模擬HTTP請求）+ExtentTestNGIReport（報告）+其他

之前我在選擇和練手如上的這些框架的時候，第一反應就是減少使用者的代碼量，盡量可以在SQL，Excel,Yaml等格式的文檔中直接編寫用例，為了實現這個效果，盡可能的做出異常判斷，但是，遠遠沒有JMeter做的完善。

JMeter是可以實現零代碼實現接口自動化，有自定義需求的時候也可以通過jar包來實現擴展，那么，自己寫自動化腳本的意義在哪？

在看到如下的對比過程中，突然意識到一個事情：

選型

測試是一個技術崗位，日常工作中不應該去減少代碼量，甚至應該去增加代碼量，只有這樣，才能逐漸理解開發所實現的邏輯，也可以擺脫測試只是點點點的崗位，進一步還可以實現codereview的目標，擺脫鄙視鏈末端。從這個角度來看，我之前的自動化方向一直就是錯的。

那么自動化的意義在哪？提效，盡可能的提高測試同學來編寫自動化腳本的質量與速度，提供排查手段，發現錯誤迅速定位，提高排查問題的能力（自己踩的坑還要自己填），附帶珍藏的自動化測試架構圖！

image

image

• 2. PPT里的介紹的開源工具鏈接,一身技術來源于網絡（菜是原罪），還是要歸還于網絡的。
• 3. 質量紅線的設計思路以及實施方案。目前在我的團隊里邊很難推動這個事情，就先看看了，需要的時候及時借鑒。

• 4. 數據工廠的解決方案，膜拜一下大佬，真的是用了一個很巧的思路并且成本很低來解決數據工廠的難點。

     
     
     image

竟然是通過flask+swagger的方式來解決，swagger的UI是修改過的，這樣才貼合自身的業務，甚至于swagger的原始數據也應該是做了修改。但是，這么一種解決方案，極大的降低了測試不用又搞前端，又搞后端的形式，再膜拜一遍，這種方式是真的巧，有空的時候試著實現一下。

image

• 5. 照著敲了一遍示例代碼，發現學了Java之后對之前Python的一知半解理解的更透徹了一點。之前對于私有變量（private），特殊變量是沒什么感受的，知道有這么一回事，但是沒用過，抄了一下代碼，發現還能這么玩，受教了，截圖中有個調試工具，蠻好用的，推薦一下。

     
     
     附調試