在大家日常测试工作中，有一类测试项目想必大家不愿意接手，接手后常常不知所措，毫无针对性，那就是基础软件类升级项目。那么，经过几次基础软件升级项目的洗礼，我以近期做过的sybase数据库升级为例，与大家分享一下自己的测试经验。虽然sybase数据库现在很少用到，但背后分析的逻辑是相通的。即便只有某一点能帮助大家理清和拓宽思维，那么我此次的分享也算非常有价值了。

　　面对基础软件类升级项目，即使我们未被告知任何有用的信息，不要迷茫，发挥测试人员的能动性去了解以下信息：

　　1.与项目经理确认是大版本还是小版本升级，升级后是否需要重编译。如确认为大版本，那么就会涉及到程序重编译。那么所耗费的人力就可能大大增加了，可能涉及到全量交易回归。如确认为小版本升级，也可分析是大版本基础上靠前还是靠后的版本，越靠后可能风险越小。如sybase数据库升级为小版本升级不需要重编译，同时与sybase厂商沟通小版本升级属于该大版本靠后的小版本升级，按历史经验来看，此类小版本升级不涉及大功能改动，那么可能此类升级风险较小，不需要耗费较多人力参与。

　　2.明确基础软件升级后的版本是否对操作系统兼容，与其他一些基础类软件兼容，如不兼容则需排查生产版本。经问询发现sybase升级对部分老旧操作系统不兼容或存在bug，但排查后发现所涉及各系统的生产操作系统版本都已升级，所以不存在此问题。

　　3.在业界和公司内部进行了解，是否有已针对该基础软件进行升级并投产运行的情况，升级后有无问题。对此公司内部有系统已进行投产，且未发现问题。业界很少用sybase服务了，所以业界未发现有sybase升级并投产的。

　　4.确认是什么原因进行升级。如因出现生产问题还是厂商自发进行的功能优化。在Sybase升级项目中我们问询项目支持部门后得知是因出现生产问题需要进行升级。公司内部某系统生产环境sybase中一个用于日志截断的time controller组件停止运行导致日志无法截断，并且无法清除日志导致日志缓存空间吃满，最终引起sybase服务异常停止。经过sybase服务器重启后time controller正常工作，应用重新启动正常工作。

　　5.确认为何会引发该问题。关于Time controller组件停止服务，与该系统的开发和相关环境支持同事一起沟通得知此问题与应用无关，sybase厂商明确表示该场景为极其偶发的情况才会有，与交易逻辑和性能无关。

　　6.确认如何复现该问题，经以上问询得出该问题无法在测试环境复现的判断。那么测试就回到回归测试的范畴中去了。

　　7.明确基础软件升级是如何改动，优化逻辑是什么。与sybase厂商沟通得到回复优化逻辑国内厂商无权获得，由国外总部进行的优化。由此测试团队判断出此次测试为无针对性回归测试。同时团队也得到厂商提供的新版程序buglist，如有可能，可与厂商和开发一起探讨该类buglist是否与应用有关。（一般buglist为底层功能修复，很少体现在应用层面）

　　综上，咱们可以对原本一无所知的软件升级项目做到比较充分的了解。对测试方案和测试范围也能有一个划定。在sybase升级中因无法复现问题，也不了解优化逻辑，我们结合公司内部其他系统的升级后投产运行情况以及本系统重要性等进行回归测试范围划定（包括批量交易），功能测试回归了本系统的核心交易，性能测试回归中挑选高频交易，因涉及日志缓存空间吃满的问题，所以跑8小时疲劳测试，此外对前后优化做性能比对测试。最后以上测试方案邮件发送开发和其他项目支持部门共同确定。

　　同时，在项目测试完成后，我们也建议在对于投产后的监控端，是否可以增加针对基础类软件相关的异常指标作为监控指标，严密监控软件适配情况。在sybase升级中我们建议添加time controller报错、sybase日志缓存为监控指标，如复现该日志无法截断问题可以及时得到告警并解决。

　　以上就是我对基础软件升级项目测试经验的总结，欢迎各位一起探讨。

作者：张涵宇   

来源：51Testing软件测试网原创