在项目级的质量防护体系逐步建立之后，原先那个只能保障基本功能和性能的版本级质量防护体系显得越来越起不到防护作用了，因为基本的功能和性能防护在前端比较完备的防护体系下基本也得到了守护。 那是不是不需要版本级质量防护体系呢？不是的，因为在后端的系统级测试中还在发现大量的系统级问题，怎么能把后端系统测试发现的问题提前到可能发现的时候呢？我们把后端的大量的系统测试用例有步骤的，系统的集成到我们的版本级构建体系中，形成我们的版本自动化工厂来自动生产接近面向交付的产品版本。

　　后端的系统测试移植到版本级构建体系中，原来以为是顺理成章，直接照搬可以了，但是实际操作下来却没有这么容易。为了保证版本级构建体系的自动运转，显然是移植后端的自动化系统测试用例，但是却不能直接照搬，因为后端系统测试与版本级自动化防护对用例执行时间、稳定性、人工干预程度都不一样。

　　首先是用例执行时间，在版本级后端系统测试的时候，整个版本的自动化系统测试用例可以在一周甚至一个版本开发小周期内执行完即可，对用例执行性能虽然有一定要求，但是对于集成到版本自动化构建体系中的自动化用例，需要执行数次，显然原来的用例执行速度是满足不了要求，那如何能解决这个问题呢？这里采用了两个方法来解决，一个是用例的并行执行，通过用例的并行执行改造，缩短执行时间。另外一个是采用分级化，对原有的自动化用例级按照特性维度进行系统整理，然后根据质量要求分成不同等级的用例集，对于基本一次的用例确保每天能达到执行数次的要求；对于次一级特性的质量防护用例做到可以执行一次，这些用例安排在每天晚上的的版本全面构建的时候执行；至于全面地版本特性防护用例集安排每执行，这样可以在一定程度上解决执行时间的问题。

　　其次是用例的执行稳定性和人工干预问题，在系统测试时候，因为有一定的人工干预，用例的执行稳定性不是很重要，但是集成到自动构建体系，因为是被构建系统自动调用，因此用例的稳定性则是首要地位，不能因为用例的不稳定导致构建体系出错。用例的稳定性提升主要要从用例脚本的稳定和环境的稳定性两方面入手，用例集只有达到99%以上的执行稳定性才能集成到版本构建体系中。另外因为是在自动构建体系中，用例在每日频繁执行，用例的执行结果判定也必须要由用例的脚本自动完成才行。