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

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

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

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

  • 主講人: 尋跡 酷家樂 質量效能部
  • 收 獲:從0到1建設一項測試領域所需要的流程,以及測試落地時候所需要做的事情。
  • 詳 情:
  1. 要有對測試產品完善的認知,產品解決什么問題?用戶場景是什么樣子?新增的測試領域能為用戶帶來什么體驗?方便制定測試目標。
    1. 對測試產品的技術架構有清晰的認識,方便測試工作中技術方案的制定以及測試工作中所采用的技術手段。
    2. 參考業界同行在這個領域是怎么做的?移植到自己的產品進行調整優化,完善出屬于自己產品的測試方向。
    3. 針對于制定的測試方向和自己業務的難點進行一一對應,然后進行問題細分,制定不同方向的測試指標。
  • 具體的建設流程如下:
流程
  • 其他:
    期間聽眾提問了三個問題,都是和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
    1. PPT里的介紹的開源工具鏈接,一身技術來源于網絡(菜是原罪),還是要歸還于網絡的。
    1. 質量紅線的設計思路以及實施方案。目前在我的團隊里邊很難推動這個事情,就先看看了,需要的時候及時借鑒。
    1. 數據工廠的解決方案,膜拜一下大佬,真的是用了一個很巧的思路并且成本很低來解決數據工廠的難點。


      image

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


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


      附調試
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容

  • 測試發現bug 開發不認為是bug的時候你怎么辦? 說法一: 1、首先明確開發說不是bug的理由。 2、如果是需求...
    忘生__dd4f閱讀 823評論 0 0
  • 成為一名優秀的Android開發,需要一份完備的知識體系[https://github.com/Android-A...
    字節跳不動閱讀 3,472評論 0 15
  • 久違的晴天,家長會。 家長大會開好到教室時,離放學已經沒多少時間了。班主任說已經安排了三個家長分享經驗。 放學鈴聲...
    飄雪兒5閱讀 7,550評論 16 22
  • 今天感恩節哎,感謝一直在我身邊的親朋好友。感恩相遇!感恩不離不棄。 中午開了第一次的黨會,身份的轉變要...
    迷月閃星情閱讀 10,602評論 0 11
  • 可愛進取,孤獨成精。努力飛翔,天堂翱翔。戰爭美好,孤獨進取。膽大飛翔,成就輝煌。努力進取,遙望,和諧家園。可愛游走...
    趙原野閱讀 2,760評論 1 1