持续测试企业架构（软件测试体系架构）

在成功构建新的 IT 企业架构之后，就应该对该架构进行测试了。测试可以证明您和您的团队的辛苦工作没有付之东流。通过对新架构进行压力测试，您将了解架构的弱点在哪里，以及架构对企业的适应情况如何。

既然已经构建好自己的企业架构，您必须对其进行测试。新技术，尤其是处于前沿的技术，将具有一些需要解决的缺陷。测试信息技术 (IT) 架构应该面面俱到。测试应该包括硬件、应用程序和负责这些系统的人员。

测试是破坏东西并为之获得报酬的理想方法。虽然没有任何人希望自己的 IT 系统被破坏，但它们很可能会遭到破坏。通过测试常见故障，您可以帮助论证附加的冗余成本的合理性。在整个测试过程中，交流是非常重要的。提醒测试用户可能发生的问题以及在那些问题发生时应该做什么，这样有助于逐渐培养起对项目及其成员的信心。

在准备测试您的架构时，必须首先决定要测试什么内容。诸如将 CRT 监视器更换为平板显示器等简单的变更显然不需要严格的测试。但是新的光纤中枢应该用新的应用程序和硬件进行负载测试。与 IT 团队会谈以决定如何最好地花时间进行测试。

测试具有三个功能：测试使您可以确定新应用程序在生产环境中的执行情况将会如何，验证冗余在故障状态下的工作情况将会如何，以及帮助确定您的团队成员对问题的反应情况如何。应用程序测试可能是相当简单但是非常紧张的过程。应用程序可能具有数百个很少使用但是必须测试的功能。例如，会计应用程序具有一些在月末执行的与税收相关的任务，以及其他仅在年末执行的与税收相关的任务。最好在税务人员到来之前让这些功能可以正常工作。

在测试之前，展望、回顾以及从每个角度检查整个企业。考虑其优势和弱点。通过对整个企业的彻底评估，您将了解哪些系统需要最全面的测试。如果可能的话，测试应该仅涉及非生产系统。如果测试必须牵涉到生产系统，应该向管理人员说明对测试的需要以及为什么测试会影响活动的系统，并计划适当的停机时间。此外，应确保将要测试的任何活动系统存在良好的备份。通过还原到虚拟服务器并将数据集与活动的单元作比较来验证备份是否良好。

通过使用虚拟系统简化测试环境的创建。虚拟系统很容易建立、破坏和还原。首先创建一个标准服务器，并克隆该服务器以创建其他服务器。在安装任何应用程序之后，许多虚拟 PC 程序允许您创建当前设置的快照，以便于发生故障后还原。这样做的好处在于，您可以在数分钟而不是数小时内创建一个新服务器。

VMware 提供了用于创建自定义虚拟环境的广泛选择。您可以从不需要基础操作系统的专用虚拟机（virtual machine，VM）软件中做出选择，并且可以一次运行多个服务器。使用 VMware 的最大优点在于其具有与多个操作系统一起工作的能力、轻松的配置以及测试工具。

还可以使用几种网络模拟器来帮助测试新的配置和评估故障转移场景。虽然大多数模拟器是为认证测试准备工作而设计的，但是相对于购买实际硬件，模拟器能够以很低的成本构建虚拟服务器环境，从而提供极大的好处。

在新的企业架构已经为启动准备就绪的情况下，建立一个核心系统的检查清单，并列出那些需要测试的备份系统。从团队保留的文档中可以明显看出哪些是核心系统。核心系统将是组织赖以生存而不可或缺的硬件和软件。通常，此类系统包括关键服务器、网络中枢和诸如电子邮件及语音等消息部分，如图 1 所示。

此图没有显示完整的网络关系图中存在的详细信息；相反，其旨在突出显示对业务操作最至关重要的企业部分。

为新系统最可能出现的那些问题准备支持人员和用户，这样可以帮助减少帮助台呼叫。您的团队成员应该收集他们已经知道的问题（例如应用程序挂起）的列表，并构建已知修复方法的列表。

决定何时可以进行测试是最困难的麻烦事情之一。要在工作日期间寻找一个所有人都可以待命的时间可能相当棘手，因此下班后也许是不错的时间选择。但是，您可能会遇到来自不希望在工作上花更多时间的团队成员或不希望支付加班工资的老板的抵制。最好的平衡是决定运行测试所需的人员和执行测试的最佳时间。可以向其他团队成员分配“待命”职责，仅在需要时才让他们加入。

此时，您已经为新的架构选定了遵从性标准。有些系统具有特定的故障点，必须在投入生产运行之前对这些故障点进行测试。诸如防火墙或安全应用程序组件等项目需要在经过验证后才能支持实时数据。

构建应该测试的项目以及如何执行该测试的特定检查清单。附加的检查清单内容可以包括：

测试之前和之后的数据状况的屏幕截图。 单独的特定任务清单。 按执行任务的小组划分的检查清单。构建服务器硬件的小组可能与加载和配置应用程序的人员不同。

文档过程

测试将会积累文档。测试是将日常工作过程应用于新的 IT 架构。

您至少应该拥有三种类型的文档：历史记录、过程 和灾难恢复。第一种类型，即历史记录文档，应该包括有关架构中的一切是如何构建的详细信息。此文档应该包含工作流关系图和有关各个部分如何连接的说明。随着架构的发展，次要的细节可能会被遗忘——例如，某个文档可能解释了工资单软件连接到仓库数据库，因为订单采集人员的奖金与其数据采集的准确性挂钩（请参见图 2）。由于此设置对仓库数据库是透明的，仓库数据库管理员（database administrator，DBA）在做出更改前必须清楚该连接。

过程文档包括每日、每周或每月任务的检查清单。示例包括每日的磁带备份更换过程、检查日志或报告问题。有些系统可能需要例行的维护才能继续高效地运行。每日的过程一般分配给负责那些方面的特定人员或小组。拥有任务的详细步骤不仅有助于确保正确和按时地完成任务，而且还有助于让那些工作人员暂时替代其他人员。过程应该包括常见错误和如何纠正那些错误，以及用于向企业引入新硬件和应用程序的标准安装过程。由于此任务将经历多个小组的工作，因此您必须拥有特定于每个小组的文档。如图 3 所示的文档流程图可帮助列出先决条件和每个小组所负责的任务。

针对灾难的文档过程还应该包括在灾难开始时和灾难得到解决时应该通知谁。此类工作人员可以包括值班经理、部门主管，甚至包括公司的主要领导。

有关灾难恢复准备工作的资料已有很多。请参见参考资料以获得指向更多信息的链接。

文档是任何企业的一个有生命和不断发展的实体。随着 IT 结构的增长和变更，文档和测试过程也必须增长和变更。当文档变更时，您必须测试文档以确保其仍然是准确的。

假设在一年以后，您的公司升级了电子邮件软件。与以前的版本相比，这个新软件具有稍微不同的邮箱还原方法。如果没有在灾难恢复文档中更新这些变更，则会减缓工程师执行恢复的过程。这不仅导致工程师不愉快，而且等待电子邮件服务器的人员还可能对还原功能所花的时间长度非常不满。

通过计划安排全年中定期的架构组件测试，您可以更新和改进已经创建的文档。这些定期测试还可以培养支持人员的信心。因此，即使某个事故没有成规可循（并且大多数事故都没有成规可循），团队成员也拥有从测试中获得的经验，从而在压力下做出更好的决策。

审核您的测试结果会对整个企业的信心产生很大的影响。大多数测试仅由高级管理人员查看，这些人员可能就是控制资金的相同人员。通常，他们不是技术人员，因此对测试和结果的解释是非常有用的。

使用诸如 IBM® Rational® 等变更管理软件来跟踪应用程序变更可以对应用程序测试进行管理。诸如 Numara Track-It （参见 参考资料） 等帮助台应用程序可以生成报告，以评估何处正在出现新问题。此信息可用于创建更符合企业需要的测试。您可以创建测试来验证问题修复是永久性的，并且同样的问题不会重现。

不要担心产生负面结果的测试。在测试时，失败是一件好事情，因为失败发生在受控的环境中，而不是发生在生产过程中。利用失败作为学习机会。系统为什么会失败？该失败是否可以避免？是否存在可防止生产中发生失败的方法？此外，不要尝试在审核报告中隐藏失败情况。利用这些失败来强调来自于这些失败的成功。指出为什么没有在开发中预见到问题，或者团队在问题出现时的反应情况如何。

可能需要测试及其结果来满足对某些标准的遵从性义务，例如 Sarbanes-Oxley (SOX) 法案、Payment Card Industry (PCI) 或 Health Insurance Portability and Accountability Act (HIPAA)。这其中有些标准设定了必须保留测试结果的时间长度。取决于组织与其客户的关系，可能会对这其中一些测试结果进行共享。

您可能会疑惑，为什么要在此阶段为遵从性而费心呢？当您执行测试时，您是在测试遵从性标准。遵从性的目标不应该是达到 最低要求，而是超过 最低要求。

由第三方执行遵从性测试和审核可能比内部执行这些任务更有益。第三方将产生有关如何看待审核和遵从性的更中肯的观点。审核可在外部或在内部执行。外部测试一般是最容易的，因为大多数审核企业都可以从他们所在的位置执行测试，并且只需很少的设置。测试某些功能或事件的内部遵从性审核可能相当麻烦。第三方将需要了解 IT 状况，并且需要知道必须测试哪些组件。

使用信誉卓著的审核企业将会在共享结果时拥有更好的名望。诸如 Solutionary 或 Ambiron Trustwave 等公司（参见 参考资料）专业从事特定行业和遵从性的审核和测试。这些企业是用于确定您的特定行业需要哪些标准和测试的理想信息源。

由于没有任何两个架构是以同样的方式构建的，所以测试技术也不会是相同的。建立关键组件的测试指标需要花一些时间，因此应该与您的团队协商。一个很好的起点是使用 The Open Group （参见 参考资料）发布的 IT 架构指导原则。类似地，Tetworks （参见 参考资料） 推出了一个可测试应用程序的开放源代码工具箱。

有些测试可能需要特殊的考虑事项。如果电源发生故障，不间断电源（uninterruptible power supply，UPS）将接管电源。但是如何开发准确的测试呢？通常，答案是按制造商的说明行事。在此情况下，许多 UPS 都具有自测功能，此功能不会危害插入 UPS 的设备。

有些测试可能不像检查各个单独的组件那样简单。在不实际中断工作的情况下，您如何验证将生产流量切换到备份数据中心是否成功呢？通过仔细的规划和清楚的交流，您可以实现这样的测试，尽管该测试可能要在数小时以后才能完成。

另一个注意事项是测试将要花的时间长度。运行每个测试将要花多少时间？测试将在活动的系统上进行，还是在虚拟系统上通过数据还原来进行？如果测试是在活动的系统上进行的，应该计划相应的时间以修复测试可能导致的任何破坏，例如路由器或硬盘故障。有多个工具可用于帮助您的测试。有关详细信息，请参阅 参考资料。

使用以下里程碑来设定目标并保持您的 IT 企业项目不断向前推进：

设定目标：列出需要测试的内容和测试频率。设定要完成文档的最终期限；否则，文档可能无法完成。尤其是在测试发现过程中的错误之后，要确保更新文档。 管理：在整个过程中对测试进行管理。确保测试是按照既定的标准进行的，并与团队成员一起检查测试结果。 交流：与团队和管理人员进行有关为什么测试非常重要的交流。测试经常由于其他项目而获得很低的优先级，或者经常匆忙地投入生产应用。 维护资源： 评估团队成员拥有的技能集，并让他们测试各自专长的领域。最好还要对测试以及正常操作中涉及的其他人员进行交叉培训。这样做可以为团队成员提供在受控情形下对故障状态作出反应的机会。确保将测试添加到您的预算中。这可能意味着需要用于模拟器软件、测试设备的预算，如果需要在下班后测试生产设备，则还可能包括加班工资。预算成本还可能包括对工作人员的专业培训——如果他们需要有关不熟悉的操作系统或应用程序的速成培训的话。 确定是否需要外部服务：让外部团体执行审核也许是有意义的。专业的审核团体可以全面查找所有资源并提出正确的问题。如果当前没有适当的工具来执行详细的评估，则外部服务会尤为有用。 分配角色：现在工作已经展开。向各个团队成员分配最适合他们的任务，并让他们自由发挥。 维护文档：如果在开始本步骤之前还没有开始创建文档，现在应该开始了。收集操作规程、代码更改和帮助台规程。现在可能是让团队成员对他们实际所做的工作而不是雇佣他们来做的工作进行文档记录的理想时机。

使测试成为新架构的过程中的一项关键职能。良好的测试基础可以将新系统的功能和新系统背后的冗余集合在一起。测试您的新企业架构可以说明您和您的 IT 企业团队成员构建该架构所做的艰苦工作和贡献。

记住，测试中产生的失败是好事情。从失败中学习以加强您的团队的技能，并创建新测试以确定错误是否会再次出现。测试是对企业团队的作战训练。在整个测试阶段中，交流非常重要。让您的团队之外的成员随时了解何时将会进行测试。并非所有测试都将在正常工作时间中进行，因此要预先为测试时间甚至专用的测试设备做好计划和预算。密切记录架构变更，并构建测试过程来跟踪那些变更。

Michael Welsh 是一位拥有 15 年经验的 IT 专业人员，擅长于 IT 安全性、灾难恢复和网络方面的工作。他还拥有操作系统、硬件和诸如 Microsoft Exchange Server 等许多服务器端应用程序方面的渊博知识。Michael 为网站和企业撰写技术文章和文档。