部署出现问题需要更改桌面镜像，对一些企业来说可能是一场灾难。这就是要做更新测试以及准备一个回滚的重要性所在。

在将更新部署到虚拟桌面之测试前需要进行测试，有一个回滚策略来确保员工的生产能力是至关重要的。

新的桌面生成需要在它们发布前进行测试。生产之前不充分的更新测试意味着你将在生产中完成测试，这样将会对桌面和员工的工作产生不良影响。从另一方面来说，测试工作迅速完成也非常重要。如果测试过程耗时太久，你可能还需要在最后迁移到生产之前来一次全新的测试。

尽管如此，有时也很难知道要做多少测试工作。支持不同类型和数量的桌面将影响你必须去做不同测试。

主镜像更新

像Citrix Provisioning Server和VMware View Composer这样的技术有一个好处就是可以快速的部署更新。你可以给一组人交付同一个镜像，这要比分开部署更新数百个桌面更快、更高效。

当你将一个好的更新部署到桌面，所有的人都用同一个镜像，这时每个桌面都工作得很好。但是，如果这个更新中有问题，那么将会中断企业内所有的桌面。足够的更新测试将会降低大规模中断以及回滚的风险。

你需要做的测试数量取决于你想要更新的虚拟桌面池的规模。更新一个20用户的桌面池是很简单的，如果更新过程出现任何问题，都可以很容易将桌面回滚到之前的镜像。回滚是个不错的功能，因为它允许你撤销更新就像你第一次做的一样容易。但是，如果你部署更新到较大的用户群，那么推送和回滚将会花费很长时间。

向几百个桌面推送一个新镜像将会花费几个小时；将此更新部署到几千个桌面将会花费更长时间。回滚到之前的镜像也会需要相同的时间，所以规模是很重要滴。

它可以智能的计划在非高峰时间段推送，尽量减少对用户生产效率的负面影响，但是回滚你是无法选择的。计划外的回滚将影响用户的工作，所以，你要支持更多的桌面，就要做更彻底的更新测试。

专用与随机桌面

专用桌面的更新测试与随机桌面的更新测试区别是很大的。

专用池测试是很容易的，因为你可以更新和测试单个虚拟桌面。值得测试的是一个用户账户分配给每一个专用池。按照这一点，更新一个虚拟机，然后用一个员工测试这个更新。一旦这个测试用户通过，你就可以更新一些试点用户的虚拟机。

很多组织都有一组员工比较认可，而且能够跟上更新的步伐。这些员工通常比其他员工了解更多的IT知识，而且这些还可以在其他人罢工之前更好报告问题。一旦这些用户验证了这个更新，就可以准备全面部署了。

随机桌面需要不同的方法来测试更新，这儿是没办法在一个浮动桌面池内测试一个特定的桌面的，但是你可以用一个镜像池。复制一份生产池，但是前提是只有少数的桌面。这个是测试人员的池，然后试点员工将使用这个池来测试更新。再次，一旦试点用户同意了新的版本，你就可以将其部署到其他人上了。

完整克隆更新

完整克隆虚拟机更新跟更新物理PC一样。每一个虚拟机是一个单独的镜像，所以每一个都需要它自己的更新。更新固定镜像的风险就是，很难说这个更新将会对用户的自定义设置做什么。

另一方面，如果一个更新毁掉一个桌面，但是它对其他桌面是没有任何影响的。完整克隆桌面是单独的；它们需要修补——更新——都是作为单独的对象。

无论你支持什么样的桌面，重要的是要记住时刻关注你推送完更新后的后台，以及时刻准备好去做一个紧急回滚。大量的用户发现即使做再仔细的测试，还是会发现有问题存在。