近期，公司部分老业务系统为了提升系统的性能及安全性，需要升级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升级的质量把控方案。
其他文章可以关注微信公众号测试架构师养成记,还有资料可以领哦~
