干货|测试人员如何助软件成功上线？如何建立一个好的部署计划？

听了公司大神的一个培训，讲的是Shell脚本编程，其实所有的编程语言的思路都是差不多的，语法上可能会有一些小的差别。对于不同的编程人员来讲，差异就在与编程人员自身的编程习惯和思考的是否全面，这些决定了程序的可读性和可重用性。大神说了一句话：“一个好的程序不在于功能有多炫，性能有多好，好的程序应该有很好的可读性和可重用性。其实学习知识并不难，难的是对知识的传承。”加我VX：atstudy-js 回复“测试”，进入 自动化测试学习交流群~~

最简单的办法是列一个包含下列各项的表格：

步骤编号

步骤描述

负责人

步骤持续时间

测试注意事项（如果适用的话）

其它信息（脚本、端点、证书等的路径）

测试的职责是什么呢？部署计划那一节提到的测试注意事项中可以包含关于如何验证的说明。但是假如部署计划非常庞大，信息繁杂。那么对于测试人员来讲更合理的做法是为测试相关的信息和数据创建一个单独的文档，主要包含以下内容：

• 针对版本里的新功能，在生产环境上的非入侵性的测试场景

• 可测的生产环境配置步骤的清单与说明，例如：

配置变更：POM.xml, IIS 等

与正确的服务端点集成

DB Schema/数据变更

• 数据迁移

验证新近的变更都已经被包含在最新的版本中

共享位置的访问

部署后服务器上的剩余空间（假如该验证没有被 AWS 自动化部署覆盖）

简短的性能测试

上面提到的一些配置变更测试在下文会有比较详尽的解释。配置变更依赖于项目的流程，它可能是个非常长的清单，包括从简单的配置文件变更到服务器本身的变更。但是我们还是就一些典型的例子来进行说明。

与正确的服务端点集成

这类测试本应很清楚，不需加以额外说明。但是如果被集成的服务同时有多个可用环境就比较棘手。要验证所使用的服务端点的正确性，最简单的办法就是运行一个会调用该服务的例子并校验配置文件。还有一个可选方案就是使用数据标记：给数据记录名加后缀，测试生产环境上的缺失记录等等。

DB Schema/数据变更

测试 DB Schema 变更和数据变更的方法不大一样。测试数据变更，我们可以通过界面或者返回值的验证来证明系统使用的是新数据。如果是 DB Schema 的改动，情况就有所不同。因为有些变化在界面上是不可见的，除非连接生产环境上的数据库，否则无法校验。而连接生产环境的数据库往往又是不被允许的。有时候，即便是存储过程的变更（新字段, 数据类型的变更等）有缺失，也不能立即被发现（有时候这些字段是在异常捕获的代码里用到的，而正常情况下系统都使用默认值）。

针对此类情况，测试人员要选择一些会使用到新字段或变更字段，而不是使用默认值的场景，来验证使用的代码是最新的。如果新版本中需要添加字段或是更改已有记录的值，通常比较稳妥的办法是去检验脚本的执行情况（通常，把该校验加入到自动化部署过程中所耗费的工作量要比手工运行一次脚本大的多）。由于数据库中数据量的差异，部署过程中一个常见的问题是，脚本执行时间在测试环境和生产环境上大不相同。不幸的是，没有一个完全可靠的办法去预测生产环境的执行时间，除非把生产环境的数据库完整复制到测试环境。

举两个例子，看看当类似的问题导致停服时间增加时该怎么处理：

1. 如果是 SQL DB，通常通过创建索引优化查询方案来提升脚本执行效率；

2. 如果是非 SQL DB（比如亚马逊的 AWS Dynamo），可能需要改变吞吐量，通过改变脚本来限制数据库的负载，改进脚本并优化数据库查询来降低对吞吐量的需求。

主分支/功能分支的合并：验证最后的变更都被包含在最新的版本中最基本的要求是，上一个通过测试的版本之后提交的每个变更都至少有一个测试场景与之相对应。

部署后服务器上的剩余空间（假如 AWS 自动化部署没有自动验证）有时应用的新版本需要进行线下更新，需要安装新软件，因此版本的规模就会大很多。对于这些情况，如果服务器没有配置剩余空间告警功能，那么在部署完成后至少要保留10GB的可用空间。

结论

正如前文提到的，生产环境的部署其实从第一行代码就开始了。满足所有的功能要求当然很重要，但开发和部署过程中应用程序的可测性同样重要。适当的日志、日志聚合功能、可用的文档、服务器配置的可检测性等所有的这些，将会使得开发、调试、测试和部署流程对所有人都变得更容易些。除此之外，相互尊重、良好的沟通和共同的目标对任何部署计划都很重要。

添加微信：atstudy-js  或者扫描下方二维码，备注“博客”邀请你进入Python自动化测试学习交流群~