近期，公司部分老業務系統爲了提升系統的性能及安全性，需要升級Tomcat到8.5.x版本。看似一個簡單的版本升級，但卻遇到了不少問題。
在容器升級後，碰到了兩個問題，現象及解決方案如下：
問題一：容器遷移完成後，啓動項目後報錯。
問題原因：項目是springboot框架實現，並且基於java8，修改配置啓動後，新war包並沒有實際進入Tomcat容器。
解決方案：通過mvn clean install後修復。
問題二：相應目錄權限不足，公司通過nginx反向代理了多個Tomcat容器，在請求路由過程中，ngnix需要訪問對應目錄的文件，但是沒有相關目錄執行權限。
問題原因：nginx和Tomcat分別通過不同用戶啓動，在Tomcat啓動腳本catalina.sh中默認設置了umask爲0027，把其他用戶的執行權限都取消了，通過修改umask值爲0022後完美解決。
那Tomcat升級結束後，測試需要如何入手來完成收尾工作呢？
我們可以從以下方面簡單展開一下：
1、Tomcat的變更記錄，可以簡單梳理一下。
1）重點在序列化和連接池模塊，是否有較大的變更，如果有，需要從請求處理、持久化和性能方面進行鍼對性測試，最簡單方法可以從報文對比入手；
2）在jar、類和方法被棄用方面，是否原有業務有依賴相關棄用類或者方法，如果有，可以提前準備官方推薦類及方法替代；
3）配置文件是否有參數變更或者刪除，如果有可以結合本身提前參考官方最佳實踐。
2、Tomcat的部署環境，需要確認後續內容。
1）Tomcat部署環境是否有變更；
2）部署測試環境變更（軟硬件兩方面）是否與產線環境類似，特別是目錄路徑、啓動用戶及相關權限是否一致，設置是否合理，例如出於安全考慮，大部分情況下，產線用戶權限比測試環境少的多；
3）啓動參數是否有變更等。
3、Tomcat的自身功能。Tomcat一般用於作爲servlet和jsp的容器，在互聯網公司，一般用於動態資源訪問的處理，所以需要關注服務是否正常啓動，是否可以正確處理http和https的各種請求，是否可以正確支持文件下載及上傳請求等。
4、Tomcat的上下文鏈路，在互聯網整個架構體系中，Tomcat作爲大部分層的默認容器，通常和nginx等配合使用，所以需要從nginx或者其他需要讀取Tomcat相關目錄的程序方面入手，例如前面的權限不足問題。
5、Tomcat升級流程完整順序，前後依賴要梳理清楚，做到上線過程中有條不紊，不會因爲順序錯亂導致未期錯誤。
6、Tomcat升級過程中，多版本並存對業務兼容性的影響，這個主要取決於後臺服務的發佈方案，是否存在新老版本Tomcat容器並存接受產線流量的情況，如果類似藍綠髮布，可以不考慮這種情況。
7、Tomcat升級業務監控大盤，是否確定了發佈時的監控大盤及監控方案，做到問題發生時，可以第一時間知曉，而不是客訴。
8、Tomcat升級失敗的回退方案，由於產線情況的複雜性，測試人員在測試環境只能儘可能保證絕大情形下的質量交付，如果未知錯誤發生時，需要第一時間回退，保證業務的連續性和穩定性，而不是業務的停頓。
9、Tomcat升級完成後，前端新舊版本應用及不同入口(例如安卓或者iOS等，甚至不同打包工具版本的差異)的兼容性，主要是序列化、反序列化及數據傳輸格式的差異可能會帶來未知錯誤。
以上是對於Tomcat升級的測試應對方案，可能部分同學會質疑不少內容已經超出了測試人員功能測試的範疇，但是測試的職責是保證業務持續穩定高質量的交付，而不僅僅只是保證最基礎的業務功能，這就需要測試右移，從開發和運維角度綜合考慮，全面構建Tomcat升級的質量把控方案。
其他文章可以關注微信公衆號測試架構師養成記,還有資料可以領哦~
