一名QA的碎碎念

只要在互聯網一天，就繼續寫下去，這個是個人第一篇博客，碎碎唸吧

提問：

一、你印象深入的項目

接入abacus，至關於中國的中航信，拓展國際業務；單獨負責一個項目，從無到有，到豐富，這個項目本身真的當成了一個owner，花了不少心血；然並卵，因爲運營政策投放不到位，鋪的政策面太廣，致使用戶點擊次數不少，每次點擊都要調用lowfaresearch接口，這個接口八分錢，致使每個月offcie超流量，接口被停用了，開發另外一個接口，本身解析返回。。。這也讓我體會到，作好一個項目，須要多方的協調配合推進；

對於這個項目也想了不少，需求review自沒必要說了，環境搭建也沒必要說了，這個項目算是接口測試的一個典型吧，反正dubbo寫參數能碰到的問題我都碰到了，作了大量的接口調用的自動化，自動化的效果仍是很明顯的，到後面的小需求點一次就能測試並回歸整個主流程了；對項目的關鍵監控也梳理並遷移到wather上，方便快速定位問題；

可是沒考慮到的點仍是不少，主要是session管理的複雜性，session是有上限的，各類異常狀況下沒釋放怎麼辦，機器重啓怎麼辦，用戶請求量過大怎麼辦；最開始咱們開放公佈運價，並無這些問題，隨着開放私有運價，請求量增大，咱們鏈接境外的服務器網絡也不穩定，一系列問題開始暴露出來；最開始沒有作性能壓力測試是最大的緣由，還覺得本身當時作的實在是圓滿了；

哦，後來等接口穩定後還作了mock，畢竟，請求別人的接口要錢麼；

二、遺漏的bug都是由於什麼緣由

主要是一些優化，緣由是一些性能問題或者一些beta和線上的差距（數據量）沒有考慮到、還有就是效果不明顯：

譬如：有一個項目中用http線程池去調用，但因爲接口的報文長度超出它的限制，致使發送出錯；沒有形成故障，由於上線的時候先發了一臺，而後觀察了日誌，發現有問題就立馬回滾了；

還有一部分緣由是case覆蓋不全；

發佈出故障的不多，緣由是在發佈前三方定下了發佈步驟和回滾步驟，發一步，線上驗證和觀察一段時間，且每次先發一臺小流量機器灰度一下，無問題再分批發剩下的機器，無異常發佈下一步，若是出現問題則回滾，對於沒法回滾或者回滾成本比較高的狀況，通常都會作一個開關，出現問題則關上開關；

三、一個項目測試的流程

（1）需求review

（2）出checklist

（3）三方過case

（4）環境搭建

（5）codediff

（6）項目進度控制：進度日報、case執行、bugfree記錄和追蹤

（7）組間協調測試或者支持測試

（8）上線前準備：sql審覈 、線上機器申請權限、覈對線上配置、三方覈定發佈步驟、回滾步驟

（9）線上發佈、盯核心監控至少30分鐘；

四、項目測試中碰到的難點

測試方面，沒有數據本身造，本身mock，若是依賴別的組的系統，並且又沒有一個穩定的環境的時候，溝通成本就會比較高；

記得剛進來的時候，對java知之甚少，出現問題不曉得怎麼定位，登上服務器查看日誌的意識比較淡薄，被開發們鄙視，checklist也挖掘不出什麼點，只可以對着需求文檔左思右想，當時個人心裏是萬分受挫的；

在一次被人說不行之後，開始對懼怕的代碼抱着吞血的心態看，又有一個女同事耐心教我，到如今，可以對着代碼的改動點挖掘測試點了，可以閱讀代碼，可以看着服務器日誌本身定位問題，偶爾也debug一下，也寫寫代碼幫助測試，額，不過須要百度一下；其實能讀代碼寫代碼的QA幸福感會強一些，QA讀不懂代碼，就沒辦法和開發交流；

五、你以爲怎樣工做是最有效的？

清晰的作事邏輯，得當的作事方法、主動的作事態度，要跟公司的文化合拍；

六、怎麼作自動化測試的，怎麼想到去作的，效果怎麼樣，有推廣嗎

自動化測試有自動化工具的開發和工具的應用，我作的項目即是對工具的應用，可是在實際使用過程當中發現公司的自動化工具並不能知足需求，因而本身寫了些代碼進行擴展；

部門有段時間颳起了工具熱，大概是績效裏面有要求技術貢獻這一列吧，但說實話，qa本身作的一些工具，拓展性並不強，只能解決某一些項目的問題，碰到某些狀況沒法支持，因此一個很是棒的工具是支持多種情景的，作過很是充分的調研和規劃；QA可以本身寫一些工具可以提升測試效率，是很是值得確定的，但在推廣上有必定問題，能在公司技術部的框架上擴展，可以適用於當前的測試，我以爲會是一個更有效率的事情；

我負責的一個項目，接口測試特別多，並且大都是dubbo接口，接口調用之間有關聯關係：一個session要在全部接口使用且只有5分鐘的失效時間；測起來挺費事的，並且之後的迴歸測試又要從新調用16個接口；這種狀況下，我用公司的Qunit，本身擴展了一些本地類，將16個接口調用串聯起來，能夠作到點擊一次，自動調用16個接口跑完主流程，大大提升了效率，還把Qunit返回結果展現美化了一下，使其更清晰直接；若是這種作法應用到其餘項目上，思想是能夠複用的，即一鍵主流程；框架是能夠利用的；但主流程的case，都要針對項目去寫；

若是沒有特別棒的idea，我以爲發現測試過程當中的痛點，本身動手改造一下已有的資源，就已經很棒啦~

七、你以爲測試中最重要注意哪些點

測試最重要的是質量和效率，體如今項目上最主要有兩點：

第一：改動點的把控、風險控制：

（1）弄清涉及的系統，這裏得畫一下系統結構圖；

（2）codediff了，要清楚哪些方法哪些變量被改動，這些方法和變量在哪些地方被調用；更要在邏輯判斷中多問幾個if else，作異常處理，關鍵點打日誌，接口交互和業務指標監控記錄；

第二：進度的控制：

（1）項目開始測試前必定要有全面詳細的checklist，這會讓你把全部你覺得想明白了，實際上根本沒有細想明白的功能點弄清楚，會在心中造成比較詳細的系統應該是什麼樣子的，測試時主線會更加清晰；

（2）測試中要最早把主流程跑通，開始不要太扎到其中一個項目的詳細測試，這樣能夠更好的把握項目測試的難度和重點在哪裏；這裏能夠用到分層測試，就是經過造數據、mock把這部分的功能測了，推進測試的前進；這裏我本身還有一點作法：公司流程要求提測前就diff代碼，可是在碰到項目比較大而你對這個代碼又不十分了解的時候，這時候diff每每收不到很好的效果：開發要花很長時間給你講解代碼實現的細節；因此我會在跑完主流程，跑主流程的時候根據日誌本身熟悉一下代碼邏輯，而後去diff，這時候的目的就是熟悉各個接口的交互，瞭解詳細的改動點（改動了哪一個方法），補充測試點了；

（3）測試中對於大於3人日的項目，最好發測試進度日報，抄送相關人員，內容就是case的執行狀況和bug數，修復數，讓相關人員知道項目的進度，case的執行狀況也能更好的讓你清楚目前的進度；

 

八、linux經常使用指令

掌握最經常使用的各類查日誌的指令，查看機器性能的指令，其餘不經常使用的，等須要的時候百度之，知道什麼linux可以作什麼處理就好了，在苦逼兮兮的去作一件事情的時候，多想一想是否是有什麼指令能夠實現就行了，不經常使用的記不清呢；

九、測試工具的使用；

最經常使用的就是httprequester和fiddler了，httprequester能夠很方便發送各類請求測試接口，fiddler因爲本身測試界面比較少因此用的也不是特別多，通常用F12就解決了；

性能測試工具用的比較少，不過在培訓中仍是強調了的，這方面的意識仍是得重視起來；

十、個人測試方法：

 

測試前準備：

（1）最最開始，畫系統結構圖，弄清改動涉及幾個系統；每一個系統的哪一個功能改動了；

（2）經過wiki，查看代碼，弄清系統結構圖中交互不明白（數據怎樣取？直接讀數據庫仍是經過接口，數據怎樣同步？canal仍是定時任務？）的地方，找測試點；

（3）寫checklist；

測試中：

（1）先不用看日誌，像產品同樣跑主流程，（怎樣推進跑主流程：弄清測試怎樣去分層測，創造條件去測某一部分）

（2）主流程跑通後，看細節，覈對是否正確；

（3）根據主流程日誌梳理代碼實現，記錄關鍵日誌查詢方法；

（4）根據關鍵日誌本身diff代碼，開始畫邏輯流程圖；

（5）跟開發diff代碼，梳理邏輯，修正邏輯圖；

（6）繼續測試，注意各個if else 分支，測試覆蓋，模擬異常；

（7）對照流程圖，對比未覆蓋分支，測試基本完成；