最近把在工作中所做的一些應用實踐分享出來和大家一起交流，先聊一下如何提高測試效率吧。測試效率就是測試產出和測試時間之比。假設測試產出是一個定值，那要提高測試效率，就是要縮短測試時間，那要怎麼才能提高測試效率呢？
關於如何提高軟件測試的效率目前我是這麼來做的：
第一，大家是否在工作中經常遇到這兩個情景：
1、上線前產品說這不是我想要的效果，這個邏輯不應該這樣，應該……噼裏啪啦一大堆，此刻開發和測試工程師心中一萬隻草泥馬瘋狂又無奈的奔騰着回眸一吐血…
2、測試根據自己對需求的理解提了幾個bug，開發回頭一口老痰說這根本不是個bug…
行業中有一個名詞叫做需求評審，需求評審這個環節的確可以解決部分諸如此類的問題，但隨着功能開發的繼續，可能會發生些變化，比如在需求評審前沒預料到的一些問題，具體例子就不舉了哈，大家一定都曾遇到過。
字不如表，表不如圖，所以在每個迭代開始前，我會要求每個測試工程師將自己負責的業務模塊快速根據需求畫出流程圖，並與產品、開發等相關人員進行二次確認。這個過程既是在梳理業務邏輯，又是將測試、產品、開發三方意識統一戰線；而且還可以評審出該功能可能會影響到某些功能等，可以使後續測試工作事半功倍。
第二，大家是否在工作中經常遇到這兩個情景：
1、後端開發修改了某個小bug，push代碼後需要經歷一段很漫長的構建才能拿到最新效果，尤其是到晚上上線的時候，之前本人經歷過只要構建需要等待30分鐘左右的時間，當時跳樓的心都有了。
2、APP 端呢，就是隻要一個小改動就得等待一個打包的時間去驗證，打包這個時間，誰打誰知道，要有這個時間可能已經完成驗證了。
果斷在本地搭建一套測試環境，那麼問題來了，在本地搭建環境如何確保測試環境的正確性呢？我們採用了Docker技術（Docker學習（一），Docker學習（二））。本地測試環境搭建好之後，測試與開發之間的配合就更加高效了，只要開發push代碼，測試切換至對應的分支pull一下本地重啓即可，媽媽再也不用擔心我找bug了~~
第三，到現在爲止需求也明確了，測試環境也OK了，下一步要提高效率的就是構造測試數據了，這裏我選用的是Jmeter，直接調用接口構造數據比手工在界面上操作效率能提高百倍不止。（《使用Jemeter對HTTP接口壓測》）
第四，舉個例子，比如在做APP端測試的時候需要截圖上傳至bug管理系統，一般大家會怎麼做呢？這裏我會寫一個簡單的Shell腳本來輔助完成（《Linux Shell腳本極簡入門》），如下：
第五，針對bug 報告我想大家應該都已經非常clear了，當出現issue時應該在全鏈路中尋找運行時的錯誤日誌以更便捷的來定位問題發生的位置、原因，進而使得我們可愛的開發工程師快速定位問題並解決；這個我想大家在實際工作中都是這麼操作的，目的只有一個就是：提高測試與開發工作的效率。看似也簡單實際上涉及到js、http、Linux日誌查看（如sed、grep、awk 《Linux測試常用命令集》）等技術點，如果大家對這些還不熟悉的話，我後續可以針對每個技術點單獨分享出來，大家一起交流。
第六，隨着互聯網業務快速的發展，作爲互聯網人是不是都感到壓力山大，我從最早的一個月一迭代到兩週、一週一迭代，到現在的每天每刻都在發佈，鬼知道我經歷了什麼…苦逼的是測試人，只要開發有一個字母的修改提交，測試就需要回歸整個系統，如果還像之前手工去跑回歸那麼結果只有一個：五一我在加班，中秋我在加班，好不容易一個十一小長假想幹點什麼的時候被leader 叫回公司加班orz（《自動化測試》）
