软件版本的任何一次“变动”都是可怕的经历

　　也许您也曾有过这样的经历：千辛万苦的软件终于上线运行了，可是突然出现了业务需求的变化，您修改了一个模块，并且加班加点对这个模块进行了测试。新的版本在夜晚放入了生产系统——第二天清晨，故障电话淹没了一切。修改的模块甚至没有出问题，可是修改影响了其他的模块。

　　经济在发展，环境在变化，业务需求当然也会不断快速变化。应用软件系统必须能够适应这种变化——然而，每一次变动，我们将如何保证软件功能的正确性呢？

　　答案似乎是现成的——每一次变动后，进行有效的回归测试即可。然而为何可怕的经历还在不断上演？因为，完全的回归测试，几乎是不可能完成的任务。

　　为什么无法进行有效的回归测试

　　在每一个系统的开发阶段，都会有专门的测试团队和测试阶段。但是，没有哪个项目和机构能够长期维持住这样庞大的测试团队、忍受那样长期的测试时间。尤其是软件开发后期，几乎所有功能都已经开发完毕，某一个模块的修改，不可能花费如此巨大的精力，将所有的功能测试一遍。在软件投产之后，每一次变动、故障维护，任务都很紧迫，更加不可能重新执行开发阶段成百上千个测试案例。

　　要解决这个问题，需要采用最新的技术——自动回归测试技术

　　新一代的自动回归测试技术，帮助你摒弃“恐惧”

　　回归测试是软件质量保障的正确方法，问题是人工回归测试巨大的代价。而新一代的自动测试技术，使自动回归测试成为可能。通过构件化的自动测试框架、先进的自动测试工具，我们可以建设一个包含成百上千个测试案例的自动回归测试系统。

　　每一次软件的变动，在从开发环境发布到生产环境之前，必须先经过自动回归测试系统的检验——自动回归测试系统如同一群不知疲倦的测试团队，在几个小时内完成成百上千个测试案例，给出测试报告。只有变动的版本通过了“考验”，发布上线才是稳健之举。