第 1 章 — 简介和测试方法
发布日期： 4/1/2004 | 更新日期： 4/1/2004
本章将介绍《Microsoft 系统结构 (MSA) 企业数据中心 (EDC) 测试指南》中的所有文档。 本章还将描述 MSA EDC 测试的目的、所采用的测试策略以及《MSA EDC 构建指南》的发布标准。
本页内容
简介
《Microsoft 系统结构 (MSA) 企业数据中心 (EDC) 测试指南》由五章组成，其中记录了 MSA EDC 首次规定实施的实际测试策略，这是由 Microsoft 的测试实验室设计的。 《测试指南》提供如下详细信息：如何使用此 Prescriptive Architecture Kit 中的《MSA EDC 构建指南》来构建测试环境，以及如何通过功能测试和性能测试来验证结构。 它还包括有关资源规划和测试周期的信息，这些都是在测试实验室环境中完成 MSA EDC 结构测试所必需的信息。
各章简介
本节将描述构成本指南的各章。 每一章都包括所涵盖主题的简要。
第 1 章 — 简介和测试方法
本章首先描述测试目的和发布标准。 随后介绍在测试时所使用的测试过程、工具和方法。 本章还简要概述了每个重要的测试领域，这会有助于理解随后有关测试详细信息和测试结果的章节中的内容。
第 2 章 — MSA EDC 测试实验室环境和工具
本章描述了这些测试所使用的测试实验室环境，其中包括与规定的中央站点的配置偏差有关的详细信息；有关用来执行多站点企业模拟测试的非规定区域站点的信息；有关测试客户端硬件的配置；以及有关如何获取、安装和配置用在这些测试中的测试自动化软件的详细信息。
第 3 章 — 功能测试详细信息
本章描述详细的测试用例，并将它们组织成测试小节。 这一章还包含测试每个 EDC 组件的详细信息，包括所使用的全部测试用例的列表。
第 4 章 — 性能测试详细信息
本章描述运行每种负载测试所使用的方法，这些测试都在第 3 章“功能测试详细信息”中加以描述。 本章还详述了“常规”处理方案，该方案用来在 24 小时内测试在假定的公司环境中运行的所有组件。
第 5 章 — MSA EDC 测试结果
本章详述对各种 MSA EDC 服务进行负载测试的结果。 本章还提供有关“常规”处理方案的详细信息，以便帮助客户适当伸缩其站点。 这些信息包括对数值结果含义的讨论以及相关的图形和曲线。
读者
本指南是为审查 MSA EDC 的技术可信度或负责测试实际现场部署的人员（包括测试负责人和测试工程师）编写的。
样式约定
本指南使用以下样式约定和术语：
表 1 样式约定
|
粗体 |
完全按照显示内容键入的字符（包括命令和开关）。 用户界面元素也采用粗体。 |
|
斜体 |
代表变量的占位符，必须为其提供特定值。 例如，在相关的第一个用例中，Filename.ext 可以代表任何有效的文件名。 |
|
等宽字体 |
代码示例 |
|
%SystemRoot% |
装有 Windows 2000 操作系统的文件夹。 |
|
注意 |
向读者提示补充信息。 |
|
重要信息 |
向读者提示对完成任务不可或缺的补充信息。 |
MSA EDC 测试方法
本节提供有关 MSA EDC 测试中使用的总体测试方法的信息。 涵盖从测试目的到最终测试顺序等的所有内容。
测试目的
MSA EDC 的第一个测试实例具有多个目的。 第一个目的是确保用户能够依赖文档的指导来完成日常问题的处理，并与客户进行交互。 本文经过一致性检查，并且每个步骤都经过 MDS EDC 测试小组或者 Microsoft 或其合作伙伴组织的测试。 另一个目的是确保系统的各个组件能够协同工作，如文档中所述，至少具有一个级别的冗余以获得高可用性，在不影响系统发挥其功能的情况下，使用最高级别的系统和网络级安全，并且要确保在本地或从远端都可以管理系统。 最后，有必要了解所有关键的网络和操作系统服务在未经调整或优化的情况下可以达到的性能级别，除了要针对单个服务进行观察外，还要根据现实情况观察所有服务一起运行时的情况。
这些测试旨在排除实施 MSA EDC 结构时的大多数不确定性，以支持由 Microsoft 提供的解决方案，以及为个别客户开发的自定义解决方案。 这将节省 MSA EDC 文档用户的时间和成本，因为在知道基本的环境问题已得到解决之后，他们就能更方便地调试其应用程序。
测试策略
为了确保能根据《MSA EDC 构建指南》文档构建相同的环境来执行系统集成测试，MSA EDC 测试小组承担了系统顾问角色，并在执行任何其他测试之前，完全按照《构建指南》中编写的步骤从头构建系统。 导致系统功能丧失、危害安全性或可用性的文档错误将被记录为 bug（错误），并且会在下一轮测试之前纠正这些 bug。
为了检验所有 MSA EDC 文档的准确性，只要其他产品小组尚未对集成系统的功能进行测试，测试小组就会设计测试，以便验证文档中对功能陈述的正确性。 这些测试中的大多数测试都已成为系统总体构建验证测试 (BVT) 的一部分。 使用此方法就能测试结构文档和《构建指南》的一致性。
在系统通过 BVT 之后，必须测试它是否有集成问题，并确保可用性功能已准备就绪。 为了强制进行端对端集成并使组件间存在相关性，MSA EDC 测试小组设计了各种简单的用户和应用程序方案，并使用相应的试验应用程序和自动化负载客户端来对系统施压。 在试验的过程中，这些方案会激活环境中一组相互依赖的服务器和服务。 因而，集成和互操作性问题可能会立刻显现出来并得到解决。
在将这些 MSA EDC 区域提升至饱和或极高的负载级别之后，测试小组能够在各个系统组件中断服务时，在系统上应用相同负载的同时测试可用性。 每个冗余组件都将失败，这样它的备份组件将承担全部负载。 在承受过度负载的情况下进行这些测试会显露许多问题，如果只是在负载不大的情况下执行故障转移测试，这些问题将不会出现。
在单独验证每个使用负载方案之后，测试小组即可进入测试的最后一个阶段。此时，所有的测试方案将同时运行 24 小时。 这些方案旨在模拟假想的“实际”公司在其典型工作日内的通信模式。 在这些测试中，组件并未承受饱和的负载，而是根据业务活动的概况，以显示同时使用多个关键组件而造成的任何系统瓶颈为目的，在不断改变负载量的情况下一起运行。
与此同时，MSA EDC 测试小组与 Microsoft 安全专家都会进行安全性渗透测试，以确保 MSA EDC 能够防备已知的破环手段。
未测试部分
MSA EDC 测试小组未对一些测试领域进行试验。
由于 MSA EDC 是已发布的软件和硬件的集合，因此，测试小组假设构成 MSA EDC 环境的硬件和软件组件在被 MSA EDC 选用之前，已经通过充分的测试。 因而，在集成到统一的平台后，重点将放在这些组件的交互上。
由于 MSA EDC 是真实企业应用程序开发的起点，因此测试小组在很多方面并未尝试对性能或服务器平衡进行调整。 在增强环境中任一组件的性能时，有许多方法是互斥的，因此，只有在应用程序获得确认并已初步实施后，才能进行调整。
深入的安全渗透测试只能在操作系统服务和网络级别进行。 没有任何方法可以确切地预测哪些软件或额外的服务将在现场中 MSA EDC 的特定实例中运行。 MSA EDC 测试小组只能根据《构建指南》对基本的服务执行此测试。 由于不同行业的服务结构有着很大的区别，因此最终的安全性只能通过在 MSA EDC 的每个实例站点进行严格的编程实践、安全性审核和渗透测试来共同实现。
测试类型
为了设计完整的 MSA EDC 测试套件，测试小组对于所涵盖的每个方面都考虑以下测试类型：
| • |
构建、安装和配置测试。 这些测试以《构建指南》为中心。 它们只需完全遵循《MSA EDC 构建指南》的每一章，以确保被正确而清晰地记录。 此测试在所有其他正式测试之前进行，以便确保随后的测试阶段能够在完全依照文档配置的系统上进行。 观察这一系列测试的另一个好处是，能够确认构建文档与 MSA EDC Reference Architecture Kit 中《参考结构指南》的内容同步。 |
| • |
构建验证测试。 除了在构建、安装和配置测试中执行的验证以外，构建验证测试还旨在验证系统的构建是否遵循《构建指南》并坚持结构参考中记录的原则。 这些测试也十分有用，因为它们通常能显示出在构建过程中出现的人为错误。 |
| • |
可用性测试。此测试有助于确保在各种情况下，网络接口卡组合、网络负载平衡、Windows 群集和其他服务的主要或次要的可用性功能都可用且在正常工作。 可用性测试通常是让某个冗余组件失败，然后验证备份组件能够承担功能，而不致发生意外的服务中断。 在运行可用性测试时，先在目标服务器上加载较少的负载，之后再以接近饱和的负载重新运行。 |
| • |
管理功能测试。执行此测试的目的在于证明环境中具有适当的监视和警告机制。 每个组件集都有一套特有的监视标准，以及需要验证的命令功能。 另外，管理功能测试几乎都是通过管理员虚拟专用网 (VPN) 连接来执行的，以保证远程访问能力。 |
| • |
性能测试。 此测试是了解系统容量以及系统在重载情况下的行为所必需的。 在了解每个服务器或每组服务器以及所连接的硬件的容量之后，架构师可以做出更好的伸缩决策。 在了解系统在超高负载或者接近饱和时的行为之后，架构师就可以确定在无法接受响应速度变慢的情况下超容量的设计是否适当。 |
| • |
可伸缩性测试。可伸缩性测试以定性方式度量基础结构扩展的方便程度。 通常，可伸缩性测试用于确定系统的线性程度。即，在系统内组件的容量发生变化时，系统的容量也会发生相应的改变。 由于硬件清单的局限，一般测试并未包括可伸缩性测试。 因为在 MSA EDC 中，主要子组件的可伸缩性问题已经广为人知，并曾是许多技术出版物的主题，所以不将这些问题视为测试范围内的问题。 |
| • |
安全性测试。执行 MSA EDC 安全性测试的目的在于，确保只有具备相应授权的用户才能使用该结构的适用功能。 可使用两种方法来进行安全性测试：审核测试和渗透测试。 审核测试在构建验证测试阶段进行，这样可确保与安全有关的配置正确地记录在《构建指南》中，而且系统构建人员能够正确地予以执行。 渗透测试在系统构建完成以及所有的帐户策略和网络安全性已被应用并锁定之后执行。 渗透测试采用全面的方式，对结构中的每个深入防御层连续施加安全团体已知的黑客工具和方法，以探测其中的漏洞。 对于 MSA EDC，这些测试是由 MSA EDC 测试人员和一名 Microsoft 安全专家共同执行的。 |
| • |
备份和还原测试。 此测试旨在帮助生产支持人员确保已准备了足够的步骤，以便在灾难发生时还原系统。 在该结构中，不同的区域有不同的备份和还原需求。 每个区域都进行以下两种测试：高系统负载下的备份以及到空白系统的还原。 |
| • |
稳定性测试。 此测试旨在确保在进行长时间负载测试时，结构可以保持稳定。 此测试在第二个和第三个测试周期的末尾、在大多数 bug 被修复之后进行。 这种类型的测试会显露内存泄漏和其他累积错误情况。 |
测试顺序
只要测试始终从验证《构建指南》开始，并在随后进行构建验证测试，测试的实际顺序可以有一些弹性。 在该项目的正式测试阶段，测试小组执行了多个回合的正式测试。 每个测试回合都从空白服务器计算机开始。 测试小组遵照《构建指南》，逐一完成所有的阶段。 之后，测试就会进入上一节所描述的类型。
在测试回合中，测试小组使用两种方法。 第一种方法是以分段的方式构建整个系统，并在各段中包含协调的服务器组合以及其他提供操作系统 (OS) 和网络服务的硬件。 每一段都基于先前各段中提供的服务构建，以便在测试结束时，整个系统的构建与测试都会完成。 在每个测试段的执行期间，会针对该服务和硬件子集执行每种测试类型，以便在进行下一段之前，所涵盖的内容已经相当完整（其中包括初始负载测试以及负载下的可用性测试）。
执行第一个测试回合的目的在于，构建服务器的每一段并在 WAN 构建之前完成各项用于该段的测试。 在建立了中央站点和区域站点之间的 WAN 连接之后，执行每一段中剩余的测试用例以完成测试过程。 既然整个环境（包括两个站点之间的 WAN 连接）一次就能构建完成，因此无需在以后的回合中拆分测试用例。 在附录 3.1 到第 3 章 MSA EDC Test Case Files.exe 中的电子表格中，每个测试用例都被标记为单站点或多站点。
第一个测试回合旨在验证测试版所发布的文档和结构的质量。 因为侧重于测试版的发布，所以在完成测试之前，测试人员为消除所有高严重性的 bug 而做了极大的努力。
在使用此方法构建和测试整个环境之后，为了使环境更接近于在假想中运作的企业，测试小组会使用多个同时使用的用户方案，执行一套更为详尽的负载测试。
测试小组会使用第二种方法来执行后来的测试回合。 这一次，测试小组又会从头开始重新构建整个环境。 在整个《构建指南》宣告完成，以便所有的服务器和硬件设备都被安装和配置之后，才会执行其他测试。 此时，测试小组才会开始进行构建验证测试，并且按照段落顺序进行随后的测试类型。
对每个已修复 bug 的回归测试会在每个测试回合结束时执行。 第二个和第三个正式测试回合旨在成为第一个回合的完整端对端的回归。
发布标准
MSA EDC 的主要发布标准与尚未解决的 bug 的严重程度紧密相关。 测试会一直持续下去，直到所有可能阻止成功部署 MSA EDC 的 bug 得到解决从而通过测试验证。 只有在成功地纠正了在审查文档时发现的所有文档 bug 之后，才会发行 MSA EDC 文档。
Bug 的严重度
表 2 列出了用来指定 bug 严重度的准则：
表 2 严重度准则
|
1 |
| • |
Bug 阻挡构建或进一步的功能测试。 |
| • |
Bug 影响进行平行测试的另一个功能的进一步测试。 | |
| • |
系统不工作。 用户连系统内的重要部分也无法使用。 | |
|
2 |
| • |
文档中定义的步骤不可行。 |
| • |
功能或过程的结果或行为和预期结果（功能规范中记录的结果）相抵触。 |
| • |
功能或过程的结果或行为和逻辑上的预期结果相抵触。 |
| • |
缺少所记录的功能（在这种情况下，测试会受阻）。 |
| • |
文档缺少或不充分。 | |
如果符合下列条件，则严重度设置为 2：
| • |
用户无法用简单的解决办法来改善情况。 |
| • |
用户很难找到解决办法。 |
| • |
系统无法满足主要的业务需求。 | |
|
3 |
| • |
功能或过程被中断。 |
| • |
功能或过程的结果或行为和预期结果（功能规范中记录的结果）相抵触。 |
| • |
功能或过程的结果或行为和逻辑上的预期结果相抵触。 |
| • |
文档中有少许错误或不正确之处。 |
| • |
文字有拼写错误。 | |
如果符合下列条件，则严重度设置为 3：
| • |
用户可以用简单的解决办法来改善情况。 |
| • |
用户可以容易地找到解决办法。 |
| • |
Bug 不会让用户产生不愉快的体验。 |
| • |
仍能满足主要业务要求。 |
| • |
Bug 并不妨碍大部分其他测试用例。 | |
|
4 |
|
显然，并非此版本的产品 bug。 |
如上所述，这些标准以从 1 到 4 的严重度来度量，严重度为 1 表示最严重，严重度为 4 表示最不严重。 在 MSA EDC 文档发行之前，结构和文档都必须消除严重度为 1 或 2 的 bug，才能成功通过所有测试用例。
测试通过或失败的标准
如果实际测试结果符合为用例记录的预期结果，则测试用例可视为通过。 如果实际测试结果不符合预期结果，测试用例就会被视为失败，此时必须创建 bug 报告并针对该 bug 指定严重度分数。
如果测试用例失败，并不一定代表功能有缺陷。 例如，对项目文档的误解、不完整的文档或者不准确的文档都可能导致测试失败。 对于每次失败，都必须根据实际结果和项目文档中描述的结果进行分析，以便发现造成失败的原因。
进一步的通过标准如下：
| • |
所有过程都能毫无错误地运行。 |
| • |
所有过程都在可接受的时间（基于功能规范中定义的基准）内完成。 |
| • |
负载测试表明，已经建立了令人满意的容量级别，而且可在必要时采取适当的步骤来扩展系统。 |
小结
本章提供对《MSA EDC 测试指南》的概述。 它描述了在实验室环境中用来验证 MSA EDC 结构的测试方法和手段， 并为 MSA EDC 1.5 版定义了发布标准。
2002 Microsoft Corporation。保留所有权利。
软件测试基地论坛 -> WEB测试 -> [转帖] Microsoft 系统结构 (MSA) 企业数据中心 (EDC) 测试指南
