• 對的,可以朝這個方向調研學習,個人覺得學習完後可以結合你們那邊本身的業務技術特點,自己搞一個能夠适配你們的工具或平台,這個産出效果可能會更好

  • 稍微聊一下,doom引流回放是最明顯的能力,但是我個人在使用過程中認為其對于阿裡内部技術棧,尤其是中間件層的支持才是最強大的,對于這種引流能力,就算是讀操作,對兩套環境的效果也不是100%一緻的,比如可能會涉及讀操作但寫緩存,那寫緩存的場景都要mock掉,以及到寫操作,怎麼做到數據不被擊穿,隊列不被引流環境消費,這種才是最需要考慮的,說真就引流這點我感覺一個goreplay就夠用了,而且感覺doom也沒有大力的對外推,畢竟這個的由來嚴重依賴于阿裡的技術體系😂 😢 😓

  • 按照問題回答的話:業務測試能力和技術能力都很重要
    但有更重要的是質量服務思維,在ali的晉升,尤其是6到7的時候,無論業務測試能力很牛X,還是技術很牛X,思維不到位一樣是明年再來,樓主可以思考一下,現在你所擁有的能力是質效能力,那為什麼要做質效,假設業務都快死了,隻做質效工程化的事情業務就能活了?推薦樓主看看《麥肯錫問題分析與解決技巧》這本書,讀完之後再試試回過頭來思考你現在的問題,看看有沒有幫助

  • 測試開發與 XY 問題 at 2019年07月08日

    所以自己真的沒有100%的把握的情況下,還是先多方讨論,先針對問題讨論,不針對方案讨論,雖然在時間成本上有點耗,但起碼不會走彎路

  • 測試開發與 XY 問題 at 2019年07月07日

    受教了,做任何方案和設計确實要回歸到why這個點上,針對why點要有充分的論證

  • 關于線上監控的思考總結 at 2019年05月17日

    我已經換回上傳圖片資源到社區的資源服務了,應該正常了

  • 測試左移和開發賦能 at 2019年04月23日

    大廠在近些年做了很多測試左移的探索,以我所處的環境為例,在讨論的時候就有提到怎麼讓業務在有保障的前提下自我疊代,而達到研發自交付的效果,在這裡我們做了靜态代碼掃描,接口測試自動化,環境一體化,預演方案,線上引流回歸,全鍊路壓測,線上精準監控等測試工程化的措施,這裡的很多工具和平台不是全部為我們自己負責業務的測試團隊開發的,大部分是引用,有就拿來用,投入應用->得到數據-分析效果-賦能團隊,建立起來後疊代版本時研發隻要提交了代碼就有一體化的質量保證服務,測試人力的涉入就可以大大減少,但我就說句站在個人立場的話,等這些都做得很完善的時候,也就是你差不多也退場的時候了,比較悲觀的思考是:測試做到頭就是自我淘汰自我毀滅了

  • 看看這篇:#

  • 對于go get 去拿golang.org域,就算已翻也未必會成功,一般go的資源在gitlub上都會有,直接go get github地址,就會直接拉下來編譯好,然後改一下依賴路徑,比較曲線救國,但也是我這裡目前解決依賴問題的最直接方法😂 😅

  • 我太太的處境和你很像,我是男方,我太太也在家待業将近半年了,先不管行業不行業的問題,趁還沒有小孩,現在這段時間最好去實現一些原本占用工作時間但做了又可以提升能力的事,像我讓我老婆去學車去讀她專業相關的能力課程提升自己,能力到位了工作自然也來, 想起當初在老東家的時候,當時也是想招一位已婚未育的姐姐,當時大佬的想法是,如果她真有那麼符合我們部門的核心能力,生育上的問題也不是問題,而且就算找個已婚已育的,也難保她會二胎(再說下去我就要吐槽工作對女性的不公了),所以關鍵還是先把能力培養起來,轉行不是不行,關鍵是你的決心和執行力,凡事要做精,做精要時間和業務積累,所以不管轉不轉行或是不是創業,關鍵還是自己的核心能力,決心和執行力,這個好了啥都沒問題

廣州測試攻城獅,點蟲人,英文名Terry

http://m.juhua446633.cn|http://wap.juhua446633.cn|http://www.juhua446633.cn||http://juhua446633.cn