測試對於開發的重要程度不言而喻，經常聽到測試同事說，哎，那個誰誰，你這個有bug啊，你寫的啥程式碼啊，到處都有bug。
對於開發同學，是不是很崩潰，明明在我電腦上沒問題啊，我就改了一行程式碼啊，你用什麼資料測試的啊，等等問題，一部分是因為邏輯問題，但是更多的還是我們自測的覆蓋度不夠，例如空指標、異常資料情況、網路問題等等，程式的魯棒性有待增強，現在，我們來看看常用的測試上的一些概念，能幫助我們從開發、測試、部署整條鏈路，儘可能提前發現無論是邏輯問題，還是效能問題。
TDD
tdd（test driven development）測試驅動開發，屬於極限程式設計的核心概念，tdd的基本流程是紅、綠、重構，大致的流程是1。按照輸入/輸出的功能進行拆分，寫好一個測試用例；2。執行它，失敗了；3。再寫一個能讓測試透過的用例，執行測試用例；4。採用重構的方式，重構程式碼，成功執行單元測試。
但是，很多時候，還是很難做到所有功能都有測試用例的，大部分情況下，都是先寫程式碼，然後寫測試用例，再給測試同事，再有bug，然後反覆改，其實這其中就浪費了大量的時間和成本，換句話說，自己也會覺得煩，能夠一次解決的事情，為什麼要反覆呢，沒有嘗試tdd方式的小夥伴，可以嘗試下，畢竟，磨刀不誤砍柴工。
Junit
junit 常用註解
junit 斷言
junit是java語言中的一個單元測試框架，可以認為junit是tdd在java領域落地產品之一，上圖為junit常用註解和相關斷言，更多示例檢視官網——https：//junit。org/junit5/
效能壓力ab測試
這裡的效能壓力測試是指apache http server benchmarking tool，是用於測試web站一定併發下請求數目的qps和rt情況，例如簡單的ab -n1000 -c10 http：//www。sina。com。cn/index。html，大致資訊如下，主要是1000個請求，用10個併發去傳送，qps為118，rt為84ms（平均連線耗時27ms+處理耗時57ms），整體耗時8。4s。
其實還有很多壓測工具，例如apache開源的jmeter、loadrunner、tcpcpoy、nGrinder，效能壓測更關鍵的是你要明白，可能的瓶頸在哪裡，例如是cpu/記憶體/網路頻寬/磁碟還是依賴的其他服務等等，確定好可能存在的瓶頸，有目的地進行測試，從而提前發現問題，進而最佳化，官網參考——http：//httpd。apache。org/docs/2。0/programs/ab。html
全鏈路壓測
某公司全鏈路壓測示意圖
全鏈路壓測一般是在系統比較複雜或者對系統穩定性干擾因素可能過多的情況下，怎麼確保大流量情況下，提前預知系統的負載能力；
拿電商系統舉例，買家從開始選擇商品、下單、交易、選擇物流、支付，這一系列的環節中，可能涉及到例如cdn圖片、nginx閘道器、快取、db等各個環節，尤其在微服務盛行的當下，各個業務域都是領域模型劃分，rpc呼叫滿天飛，可能一個依賴的底層會員服務稍微波動50ms，就有可能導致整條買家鏈路全線崩潰，對於SLA服務要求5個9的來說，這是不可接受的。
全鏈路壓測需要全站各個業務域一起協同，要解決常見的幾個問題，例如如何在各個業務域以及中介軟體區分壓測流量和正常業務流量，如何協調這麼多業務域協同配合、保障不出現木桶的短板，如何在出現問題的時候、快速定位到是哪個業務域出現問題導致的，全鏈路壓測，這個詞聽著很美好的，做起來難度不小。
灰度釋出測試
灰度釋出 分流
灰度釋出簡單的說，就是根據一定的條件，將一部分流量劃分到老版本，一部分劃分到新版本，用於驗證新發布特性，常用的例如nginx層的rewrite進行流量的劃分，或者是服務端根據某個分流演算法返回不同的路徑給到前端進行分流等等
藍綠髮布測試
藍綠髮布是指透過兩組線上叢集，以冗餘的方式進行不停機的升級釋出，大致意思是一組服務成為綠組提供使用者服務，藍組進行升級完成後，流量透過負載轉向藍組，無誤後，再進行綠組的升級，有問題，則將流量重新打回綠組，保障系統可靠性。
思維先行，對於開發而言，先有tdd的概念，行動起來，再來整體看，從開發、測試、部署，為了系統的穩定性，我們可以來做哪些事情，保障SLA的5個9，沒有穩定性的1，再多的功能、技術，也是無用的。
