![ce90c050055bd2e370c59f387203925e.png](https://i-blog.csdnimg.cn/blog_migrate/72b22346a7510280121c62de2a081fe7.jpeg)
近期,公司部分老业务系统为了提升系统的性能及安全性,需要升级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升级的质量把控方案。
其他文章可以关注微信公众号测试架构师养成记,还有资料可以领哦~
![9c0da09f3086c57aac48d8c6c4024650.png](https://i-blog.csdnimg.cn/blog_migrate/95f879f092168d40b17c01c1d06a386c.jpeg)