通常状态下，任何系统都无法在没有定期测试检查的情况下始终顺畅运行。但尽管如此，定期测试系统仍被很多企业忽视。汽车停在仓库里两年后还可以正常发动吗？如果可以，只能说你走运，其实IT系统和汽车发动机一样，举个简单的例子，要是企业没有定期测试和维护相关系统，站点故障切换很难成功。
　　对企业来说，完全放弃测试显然很危险。但如果测试系统的方法不能如实反映出系统的真实使用情况，同样非常危险。下面七条规则则可以帮助企业更可靠地完成系统测试，并确保测试的过程更充分地反映出系统真实状况。
　　第一条：执行真实测试
　　首先要确保你的测试尽可能接近实际情况。比如你要测试系统进行站点故障切换的能力，就务必要将测试系统与主站点完全隔离开来，在这样的环境下你可能会发现，整个程序的某些方面（如密码或程序本身）位于或正依赖于主站点的一些系统。
　　因此，最好的办法是将生产环境停运，然后进行测试，但显而易见这种做法很难得到企业管理层的支持。所以作为测试者就必须投入更多时间，用以确保测试系统没有依赖基础设施或服务。
　　第二条：加入人为因素
　　同样，在测试中加入人为因素也很重要。确保所有系统正常运行是一方面，但人员是否准备充分？他们是否记得自己要做什么？是否知道关键的说明文档位于何处、如何才能访问？是否能够察觉出紧急情况，并按你希望的方式给予回应呢？
　　由于企业想测试的系统大多用来应对突发事件，因此了解员工的响应时间以及他们在缺乏指导的情况下执行测试程序的能力，对企业而言与系统是否可靠同样重要。
　　第三条：观察对监控工具的影响
　　如果你足够幸运，被获准可以进行停运生产系统的测试，那么对于监控和警报工具的评估将非常重要，通过测试你可以了解到，它们提供的数据是否足以引导员工进行正确的处理，企业对此还需要进行哪些调整，以便更快速、轻松地发现并查明重大事故。
　　经验表明，调动工作人员、确定问题、决定如何应对这一系列举措所耗费的时间通常比系统恢复需要的时间多很多。而监控和警报工具的质量在整个过程的诊断环节中将起到重大作用。
　　第四条：使用说明文档
　　在进行测试时，要确保企业编制的说明文档（无论是文本文档还是图表），能够引导相关人员完成整个过程。一般情况下，灾难恢复方案等说明文档只编制一次，经由审查人员过目，而实际需要依赖该文档的人员却很少认真查看。如果你不是在一个非常简单的操作环境，就应该定期维护说明文档，并确保内容最新且准确，因为在发生事故时，人们往往首先去查看说明文档，因此确保它的准确性相对重要。
　　第五条：让非测试主管人员参与进来
　　即使你非常清楚测试的系统而不需要说明文档，也要设想这种情形：你分身无术，抽不开身，于是不太熟悉这些系统的人需要执行测试过程。对这些人来说，精心编制的说明文档至关重要。因此，让原本不负责相关系统的团队成员进行测试大有必要。这样一来，你不仅可以测试系统，还可以测试说明文档以及团队成员，看看他们是否为紧急情况下接过同事的任务作好了充分准备。
　　第六条：吸取经验教训
　　测试方案最重要的部分是测试完成后有哪些改进和提升。若是发现了系统、说明文档或团队的不足之处，就要确保他们在相关方面汲取了经验教训，这一点非常重要。如果测试顺利完成，则皆大欢喜，但多数情况下，往往是系统的某些部分需要修复、新的团队成员需要加强培训、说明文档需要更新等等。
　　第七条：重复整个流程
　　在完成整个测试过程，发现并修复可能存在问题的薄弱环节后，企业还需要重新测试一遍，即使你的测试没有发现任何问题。对企业而言，测试修复后的系统很重要，它能够帮助我们了解企业是否真正解决了问题。