标签：进一步 修改 质量 结构 系统测试 迭代 关于 完全 成功率
由于近段时间，公司有个项目频繁出现软件发布后发现有问题，需要回滚。问题的原因很多，可能是运维配置问题、测试环境差异问题、漏测问题、修改范围评估不足导致旧功能有问题等等。因此，项目组提到了预发布测试的想法。从而引发了我对预发布测试的深入思考（之前有思考过做，但由于各种原因没落实执行）。
项目组提出的预发布测试简单来说就是测试人员模拟运维人员进行部署和配置的测试、然后进行版本规划功能的测试和热门功能的测试，确保软件发布生产环境后运行没有问题。正如一千个人的眼里就有一千个哈姆雷特，其实每一家公司的预发布测试的实施目的和实施过程都不完全一样。本人就以自身公司为例子进行思考。
当预发布测试说将要推行时，一些基层的测试人员就有想法了：
1、关于部署和配置过程本身不属于测试范围，软件运维的工作，有时候软件运维各种配错了导致问题出现，现在却变成测试人员要来检验部署和配置的过程。
2、测试环境测试过了，为什么还要在预发布环境测试一遍，测试工作量的重复投入了，测试人力资源成本大了。
3、热门功能是之前上线功能，当前版本没有改动，为什么还要测试一遍，测试工作量又增大。
4、本身项目的版本迭代周期就短，就快，而且测试时间长期一直被挤压，现在又多加一个测试环节。甚至于，本来该项目测试就要加班加点，又弄一个测试环节出了，怎么破。
那么，作为测试的管理者，就需要对这个流程进行深入思考，和判断是否要做了同时也要做好下面的工作。
首先，预发布环境是一个什么环境？预发布环境其实生产环境，只不过是服务是另外独立部署（为了不影响线上），如果涉及数据库结构的改动会提前在测试环境做好测试和评估。预发布测试是属于测试的一个环节，在系统测试之后发布上线前，也就是上线前的最后一次生产环境测试。
1）解决测试环境与生产环境的差异，提前发现问题，使得上线后尽可能的避免出现问题
2）验证运维部署和配置的过程会不会存在问题，配置类的交付是否齐全，有助于运维工作的畅顺
3）版本功能和旧功能的线上验证，保障版本运行正确正常，提前发现开发对版本影响范围评估不足而导致旧功能有问题
4）在生产环境验证可以弥补某些无法在测试环境中执行的用例，提高测试执行覆盖率
1）测试人力成本（主要成本）
2）运维人力成本（有些环境需要运维人员协助完成，如环境的部署等）
3）出差成本（主要因为有些项目公司内没有环境，需要出差到现场进行测试）
4）延误常规测试任务
5）多部门沟通协调成本（关于实施部署这块，需要跟软件运维、硬件运维，甚至产品部、市场部的去沟通协调，落实测试环境和测试数据问题）
既然项目组已经提出想法，首先要考虑这个环节做了能不能解决问题，有没有收益。
首先，对于测试，工作量的增加了，但测试手段也增加了，一些在测试环境没测试出来的问题提前发现了，进一步保障的软件上线的质量。
再者，对于运维，测试人员在预发布环节把部署、配置和功能都”演练“了一次，后续工作顺畅了，同时运维自身的功能验证或者也省了。
最后，对于近段时间频繁爆发问题，预发布测试手段确实能解决问题（如版本影响范围评估不足、运维交付和配置检验、无法执行的用例等），提高版本发布的成功率。
每个公司都会有自身的各方面考虑，究竟值不值得做在这里不会妄下定论，最好结合目前项目组的实际情况、资源情况、市场情况等来得出质量保障的最优解，综合考虑。
标签：进一步 修改 质量 结构 系统测试 迭代 关于 完全 成功率
原文地址：http://www.cnblogs.com/whylaughing/p/7596866.html
