題外話：前端
終於又提筆了。一直都記得博客園，偶爾看到評論，偶爾也會翻看舊的文章。一直沒有寫是由於這段時間裏有些忙碌，學習測試方法分析，自動化編程，發佈流程環境管理，測試提效，學習和積累是一個漫長的過程，以及暫時沒有找到能夠單獨成文寫出來的內容。web
此次文章講到的內容，是如何從一個測試角度看待發布流程和環境管理這些在功能測試前應該先了解的基礎。chrome
1、環境數據庫
開發環境：編程
一般表示最低環境，由代碼開發人員直接使用和維護，是代碼最超前版本的一個環境。後端
測試環境：瀏覽器
開發人員確認代碼分支在開發環境自測沒有問題後，提交測試環境進行測試。app
測試環境對代碼和系統已經集成，能夠供測試人員進行功能模塊測試，集成測試，系統測試，測試環境有獨立的數據庫和帳號權限管理系統，由測試人員使用和管理，功能型bug通常在測試環境中暴露較多。工具
預發佈環境(Pre)：學習
測試人員確認代碼在測試環境通過測試用例測試沒有問題後，提交預發佈環境進行測試。
預發佈環境做爲上線前的最後一套環境，全部的功能和配置，數據庫都已經與線上環境高度類似，僅准入本次須要上線的功能代碼。測試人員使用該環境能夠實現大面積的功能測試，該環境比較容易出現不一樣jar包的依賴和版本匹配問題。預發佈環境測試沒有問題的代碼能夠直接將該代碼分支提交上線。
預發佈環境不常見，通常在比較大，項目相對複雜的環境會特別搭設預發佈環境，甚至有公司會搭多套預發環境供上線前使用。預發環境能夠獨立創建數據庫，階段遷移一些線上數據做爲預發環境的測試數據；也能夠直接連線上數據庫測試，但這種方式須要注意髒數據的產生。
線上環境：
最高環境，直接面向用戶。
2、部署
1）Application的版本管理：
一般被不少測試忽略的一點，就是檢查當前測試的包的版本號。若是版本號與開發最新提供有誤，須要查看最近一次部署是否成功。
2）新代碼分支部署進測試環境主幹代碼的方式：
模式1：合併後測試。開發人員A與B的代碼分支同時merge進app，提早解決衝突後，再進入測試環境供測試人員測試。
模式2：單個模塊測試後退出環境。開發人員A代碼分支能夠先上到測試環境，測試人員測試完成後，再將A代碼分支退下，提交B代碼分支測試，每一個分支獨立管理，上線前再整理所有須要上線的分支代碼。
3）上線後的全部代碼須要merge到開發環境，保證後續全部代碼都基於線上代碼開發，避免版本漏洞。
4）發佈計劃：
當先後端代碼都須要上線/資源存在依賴關係時，須要安排application的發佈順序，如：前端的邏輯依賴後端代碼，必須先發布後端，再發布前端。
3、工具
1）showip
showip工具在瀏覽器右下角直接展現當前頁面的IP地址，在測試中能夠快速查看當前訪問機器的版本號，以IP地址判斷當前訪問的環境是否正確。
https://chrome.google.com/webstore/detail/agoljmemkbciolpigpabjfkagboolkcj
2）URL Redirect
Redirect工具能夠快速重定向某些資源的url地址，以方便在某些環境測試的時候須要用到另一些環境的資源。
https://chrome.google.com/webstore/detail/kpdinddojclpdndplpblgckkfepjplie
（以上小工具均爲chrome插件，很是快捷使用和安裝）