可以使用要求和体系结构模型来帮助组织系统及其组件的测试。 这种做法有助于确保测试对用户和其他利益干系人很重要的要求，并且有助于在需求更改时快速更新测试。 如果使用Microsoft测试管理器，则还可以维护模型和测试之间的链接。
若要查看哪些版本的 Visual Studio 支持这些功能，请参阅 体系结构和建模工具的版本支持。
系统和子系统测试
系统测试 （也称为 验收测试）意味着测试用户的需求是否得到满足。 此类测试涉及系统的外部可见行为，而不是内部设计。
扩展或重新设计系统时，系统测试非常有价值。 它们有助于避免在更改代码时引入 bug。
计划对系统进行任何更改或扩展时，从在现有系统上运行的一组系统测试开始会很有帮助。 然后，可以扩展或调整测试以测试新要求，对代码进行更改，然后重新运行完整的测试集。
开发新系统时，可以在开发开始后立即开始创建测试。 通过在开发每个功能之前定义测试，可以采用非常具体的方式捕获要求讨论。
子系统测试将相同的原则应用于系统的主要组件。 每个组件都独立于其他组件进行测试。 子系统测试侧重于组件用户界面或 API 上可见的行为。
从需求模型派生系统测试
可以在系统测试和要求模型之间创建和维护关系。 若要建立此关系，请编写与要求模型的主要元素相对应的测试。 Visual Studio 可让你在测试与模型的各个部分之间创建链接，从而帮助你保持这种关系。 有关要求模型的详细信息，请参阅 模型用户要求。
为每个用例编写测试
如果使用Microsoft测试管理器，可以为要求模型中定义的每个用例创建一组测试。 例如，如果你有一个用例 Order a Meal（包括“创建订单”和“向订单添加项目”），则可以针对这些用例的整体和更详细的情况创建测试。
这些准则可能很有用：
每个用例应有多个测试，用于主要路径和异常结果。
在要求模型中描述用例时，定义其后置条件更为重要，即实现的目标，而不是详细描述用户遵循的过程以实现目标。 例如，“订购餐”的后置条件可能是餐厅正在为客户准备一顿饭，而客户已支付。 后置条件是测试应验证的条件。
根据后置条件中的各个子句进行单独测试。 例如，为通知餐厅订单和从客户收取付款创建单独的测试。 这种分离具有以下优势：
要求的不同方面的变化经常独立发生。 通过以这种方式将测试分为不同的方面，可以更轻松地在需求更改时更新测试。
如果开发计划先实现用例的一个方面，则可以在开发过程中单独启用测试。
在设计测试时，请将测试数据选择与代码或脚本分开，以确定是否实现了后置条件。 例如，简单算术函数的测试可能是：输入 4;验证输出是否为 2。 相反，将脚本设计为：选择输入;将输出本身相乘，并验证结果是否为原始输入。 此样式使你可以改变测试输入，而无需更改测试的主体。
将测试链接到用例
如果使用测试管理器设计和运行测试，则可以根据要求、用例或用户情景工作项来组织测试。 可以将这些工作项链接到模型中的用例。 这样，便可以快速跟踪测试的要求更改，并帮助跟踪每个用例的进度。
将测试链接到用例
在测试管理器中，创建一个要求，并在其上建立一个测试套件。
您创建的需求是 Team Foundation Server 中的一项工作项。 它可能是用户情景、要求或用例工作项，具体取决于项目与 Team Foundation 一起使用的过程模板。 有关详细信息，请参阅 关于敏捷工具和敏捷项目管理。
将要求工作项链接到模型中的一个或多个用例。
在用例图中，右键单击用例，然后单击“ 链接到工作项”。
将验证用例的测试用例添加到测试套件中。
通常，每个用户情景或要求工作项都会链接到模型中的多个用例，每个用例将链接到多个用户情景或要求。 这是因为每个用户的故事或要求涵盖了一组开发多个用例的任务。 例如，在项目的早期迭代中，可以开发客户可从目录中选择项目并交付项目的基本用户情景。 在以后的迭代中，情况可能是用户在完成订单时支付费用，供应商在发送货物后收到这笔钱。 每个故事都会在 Order Goods 用例的后置条件中添加一个子句。
可以通过在用例图上针对每个子句单独写注释的方式，创建从需求到后置条件子句的独立链接。 可以将每个注释链接到要求工作项，并将注释链接到关系图上的用例。
基于需求类型的基准测试
要求模型的类型（即类、接口和枚举）描述了用户如何思考和传达其业务的概念和关系。 它仅排除与系统内部设计相关的类型。
根据这些要求类型设计测试。 这种做法有助于确保讨论对要求所做的更改时，可以轻松地将更改与测试中必要的更改相关联。 这样就可以直接与最终用户和其他利益干系人讨论测试及其预期结果。 这意味着，用户的需求可以在开发过程之外得到维护，并避免围绕设计中可能的缺陷进行意外的测试设计。
对于手动测试，这种做法涉及遵守测试脚本中要求模型的词汇。 对于自动测试，这种做法涉及使用要求类关系图作为测试代码的基础，以及创建访问器和更新器函数以将要求模型链接到代码。
例如，要求模型可能包括菜单、菜单项、顺序和它们之间的关联类型。 此模型表示由餐餐订购系统存储和处理的信息，但不表示其实现的复杂性。 在工作系统中，在数据库中、用户界面和 API 中，每种类型都有几种不同的实现。 在分布式系统中，每个实例的多个变体可能同时存储在系统的不同部分。
若要测试用例（如“将项添加到顺序”），测试方法可以包含类似于下面的代码：
Order order = ... ; // set up an order
// Store prior state:
int countBefore = order.MenuItems.Count;
// Perform use case:
MenuItem chosenItem = ...; // choose an item
AddItemToOrder (chosenItem, order);
// Verify part of postcondition:
int countAfter = order.MenuItems.Count;
Assert (countAfter == countBefore = 1);
请注意，此测试方法使用要求模型的类。 关联和属性作为 .NET 属性实现。
若要执行此作，必须将类的属性定义为只读函数或访问器，这些函数或访问器可以访问系统以检索有关其当前状态的信息。 模拟用例（如 AddItemToOrder）的方法必须通过其 API 或用户界面下方的层来驱动系统。 测试对象的构造函数（如 Order 和 MenuItem）还必须驱动系统在系统中创建相应的项。
许多访问器和更新程序已通过应用程序的常规 API 提供。 但是，为了启用测试，可能需要编写一些其他函数。 这些附加访问器和更新器有时称为“测试工具”。 由于它们依赖于系统的内部设计，因此系统开发人员有责任提供它们，而测试人员则根据要求模型编写测试代码。
编写自动测试时，可以使用泛型测试来包装访问器和更新程序。
业务规则测试
某些要求与任何一个用例不直接相关。 例如，DinnerNow 业务允许客户从多个菜单中进行选择，但要求在每个订单中，所有选择的项目都来自单个菜单。 此业务规则可以表述为在需求类模型中关于“订单”、“菜单”和“项”之间关联的一个不变量。
此类的固定规则不仅控制当前定义的所有用例，还控制稍后将定义的任何其他用例。 因此，最好将其与任何用例分开编写，并独立于用例对其进行测试。
从模型中导出子系统测试
在大型系统的高级别设计中，可以识别组件或子系统。 这些表示可以单独设计或位于不同计算机上的部件，也可以是可采用多种方式重新组合的可重用模块。
你可以将相同的原则应用于每个主要组件，就像应用于完整系统一样。 在大型项目中，每个组件可以有自己的要求模型。 在较小的项目中，可以创建体系结构模型或高级设计以显示主要组件及其交互。 有关详细信息，请参阅 为应用的体系结构建模。
无论哪种情况，都可以在模型元素与子系统测试之间建立关系，就像在要求模型和系统测试之间建立关系。
使用提供接口和需求接口来隔离组件
标识组件在系统或外部服务的其他部分上拥有的所有依赖项，并将其表示为必需接口非常有用。 本练习通常会导致一些重新设计，使组件与设计的其他部分更加分离且易于分离。
这种分离的优点是可以通过使用模拟对象替换组件通常使用的服务来执行测试。 这些组件是为测试而设置的。 模拟组件提供组件所需的接口，使用模拟数据响应查询。 模拟组件构成了完整的测试工具的一部分，你可以连接到组件的所有接口。
模拟测试的一个好处是，你可以开发组件，而另一些组件将要使用的服务仍在开发中。
维护测试与模型之间的关系
在每周执行一次迭代的典型项目中，要求评审在每个迭代的开头附近进行。 会议讨论下一次迭代中要交付的功能。 可以使用要求模型来帮助讨论将要开发的作的概念、方案和序列。 业务利益干系人设置优先级、开发人员进行估算，测试人员确保正确捕获每个功能的预期行为。
编写测试是定义要求的最有效方法，也是确保人员清楚地了解所需内容的有效方法。 但是，虽然编写测试在规范研讨会期间需要很长时间，但创建模型的速度可以更快得多。
从测试的角度来看，要求模型可以被视为测试的速记。 因此，在整个项目中维护测试和模型之间的关系非常重要。
将测试用例附加到模型元素
如果项目使用测试管理器，则可以将测试链接到模型中的元素。 这样，便可以快速找到受要求更改影响的测试，并帮助跟踪已实现要求的程度。
可以将测试链接到所有类型的元素。 下面是一些示例：
将用例链接到执行它的测试。
将用例后置条件或目标的子句写入链接到用例的注释，然后将测试链接到每个注释。
在类图或活动关系图上的注释中编写固定规则，并将其链接到测试。
将测试链接到活动关系图或单个活动。
将测试套件链接到它测试的组件或子系统。
将测试链接到模型元素或关系
在测试管理器中，创建一个要求，并在其上建立一个测试套件。
您创建的需求是 Team Foundation Server 中的一项工作项。 它可能是用户情景、要求或用例工作项，具体取决于项目与 Team Foundation 一起使用的过程模板。 有关详细信息，请参阅 关于敏捷工具和敏捷项目管理。
将要求工作项链接到模型中的一个或多个元素。
在建模图中，右键单击元素、注释或关系，然后单击“ 链接到工作项”。
添加到测试套件，用于验证模型元素中表示的要求的测试用例。