杭州第六屆測試沙龍收穫梳理

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

具體的PPT不知道官方允不允許放出來，就先不拋了，後面有回應的再加上分享的PPT

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

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

• 詳 情：

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

• 具體的建設流程如下：

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

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

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

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

• 主講人： 王靜文 有贊
• 收 獲： 對監控的一個整體認識。
• 細 節：
  1. 監控的4個黃金指標 1) 延遲：服務處理某個請求所需要的時間。 2) 流量：使用系統中的某個高層次的指標針對系統負載需求所進行的度量。 3) 錯誤：請求失敗的速率。 4) 飽和度：服務容量有多滿，比如CPU，IO，記憶體等等
  2. 告警資訊規範。上面聊到了下一階段有做日誌監控的想法，所以這個規範對我來說還是比較及時的。 1) 告警標題。精簡併且有指導性，提升處理效率。 示例：服務名稱-上送時間 2) 告警級別。設定合理的告警級別 info?warn?critical? 示例：報警等級， 這裡有一個要明確的點是：要和後臺人員制定好日誌列印規則，不然全部是info是沒有意義的 3) 告警原因。資訊明確，告警規則清楚。 示例：規劃是報警日誌上下20條 4) 告警人提醒：開發，運維，測試。 示例：企業微信傳送專案群 5) 響應規範。誰在響應？什麼問題？影響什麼場景？什麼使用者？處理方式是什麼？

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

• 主講人： 賀達 E籤寶
• 收 獲：
  1. 對電子簽名業務以及產業鏈的瞭解（借PPT裡的一張圖），一個極其小眾的業務型別，比我現在負責的公交業務型別還小眾。
  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的目標，擺脫鄙視鏈末端。從這個角度來看，我之前的自動化方向一直就是錯的。

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

• 2. PPT裡的介紹的開源工具連結,一身技術來源於網路（菜是原罪），還是要歸還於網路的。
• 3. 質量紅線的設計思路以及實施方案。目前在我的團隊裡邊很難推動這個事情，就先看看了，需要的時候及時借鑑。
• 4. 資料工廠的解決方案，膜拜一下大佬，真的是用了一個很巧的思路並且成本很低來解決資料工廠的難點。

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

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