测试.net文章

2010-04-22 12:07 宝宝合凤凰阅读(286) 评论(0) 收藏举报

第12章 Web应用测试

Web应用测试是Web应用程序在开发过程中，以及开发完毕后进行的功能及性能测试，以保证程序开发的正确性和有效性。本章主要对有关Web应用测试方面的内容进行介绍.

本章主要内容

Web应用测试概述
定义测试需求
创建测试用例
定义商务网站的测试场景
创建并发布测试计划文档
Microsoft Visual Studio Team Test Edition
单元测试
Web测试
商务网站性能测试
发布测试结果

12.1 Web应用测试概述

在Web应用程序开发过程中及开发完毕发布之前，都需要对其进行测试，以保证其功能和性能达到预定要求。在Visual Studio Team Test版本中，Web应用测试主要包括单元测试、负载测试、Web测试、手动测试、顺序测试和一般测试等。

单元测试是一种编程测试，主要对其中的功能进行测试，以保证各个功能模块的实现。

Web测试也称为声明性Web测试，由一系列HTTP请求组成，通过发出HTTP请求在协议层工作，可用于性能测试和压力测试。

负载测试由一系列Web测试或单元测试组成，这些测试会在存在多个模拟用户的情况下运行一段时间，主要用于测试程序的同时服务能力。负载测试可用于以下几种测试类型。冒烟测试，确定在短时间内负载较小时应用程序如何执行；压力测试，确定在较长时间内负载较大时应用程序是否能成功运行；性能测试，确定应用程序的响应能力；容量计划测试，确定在各种容量下应用程序如何执行。

手动测试是与文本文件或Microsoft Office Word 2003及更高版本兼容的文件，它描述测试目的并且包括测试人员需要遵循的步骤的顺序列表，通常在需要运行的测试很难或不可能实现自动化时，或者测试过程的特定时刻用于修改或检查测试环境时，可以选择手动测试。需要注意的是，只有在使用 Microsoft Office Word 2003 或更高版本时，才可以创建 Word 格式的测试；不能远程运行手动测试，也不能从命令行运行手动测试。

顺序测试指的是包含要以特定顺序运行的其他测试的一种测试。在“测试管理器”和“测试视图”窗口中，顺序测试显示为单个测试。顺序测试可包含除负载测试之外的任何测试类型。

一般测试是Visual Studio Team Test版本中测试的一种简单形式的扩展；允许运行除预定义测试类型（包括 Web 测试、负载测试、单元测试、手动测试和顺序测试）以外的其他测试，如以前的测试和自定义测试。

在下面的研究内容中，主要对其中的单元测试、Web测试和性能测试进行详细介绍。在介绍这几种测试之前，先了解一下测试需求、测试用例、测试场景的有关内容。

12.2 定义测试需求

测试需求主要是基于需求规格说明书进行定义，主要包括定义功能测试需求和非功能测试需求。

12.2.1 功能测试需求

功能性需求指的是应用程序能够具体实现的功能方面的需求，即有具体的完成内容的需求。比如，一个商务网站中，用户注册、登录，商品价格更新，购物车结算等功能。只有实现这些功能，网站才能正常工作，才能对请求进行服务，在测试该网站功能时，都需要对这些功能进行测试。对这些功能方面进行测试的需求，属于测试中的功能测试需求。在功能测试过程中，主要针对产品需求说明书中的功能进行测试，验证所提出的功能是否符合需求，是否存在冗余功能、是否遗漏了功能等。

在应用程序的功能测试需求方面，主意考虑以下几个方面的内容：

测试目的；

测试环境，即硬件、软件环境；

主要功能，主要是需要实现的核心功能，以及这些功能的实现条件和实现手段等；

辅助功能，主要是核心功能以外的功能，但对整个应用程序的运行有重要影响，如数据管理、人员管理和日志管理等。

12.2.2 非功能测试需求

非功能性需求指的是不包括具体动作内容的需求，如系统稳定程度，页面响应速度，外观设计、系统的可维护性和可扩展性等内容。非功能性需求尽管不具体实现某些功能，但对网站的成功与否有重大影响，如果事先缺乏很好的非功能性需求定义，可能会淹没功能性需求给用户带来的价值。比如，网站响应速度非常慢，就不会有人耐心等待；网站要求用户输入太多内容，也不会有人喜欢；网站的可维护性差，将会给维护人员带来不便。总之，非功能性需求也是应用程序开发设计所要考虑的一项重要内容。

在对应用程序非功能方面进行测试时，主要要考虑以下方面内容。

应用程序的内在功能，主要指的是为功能性需求，以及程序本身正常运行所必需的功能。比如，用户管理、数据管理、帮助和升级等功能，这些功能通常不是用户提出的。

应用程序的可扩展性与可维护性功能，主要指的是在技术或业务发生变化时，该应用程序的功能能否方便地进行扩展或改变，能否易于维护。如果一个程序可扩展性与可维护性功能较差，则一旦出现外部变化，该程序将不再适用，导致其生命力较短。

应用程序的技术适应性与应用适应性功能，主要指的是在不进行系统设计修改的前提下程序对技术与应用需求的适应能力，通常表现在可配置能力方面。比如，技术条件（网络条件、硬件条件和软件系统平台条件等）、应用方式（界面的变化、功能的剪裁）发生变化时，程序能否继续正常使用。

应用程序的响应时间，主要指的是程序的响应速度，当对外提供服务时，如果响应速度太慢，将影响正常使用。在测试时，要在较大负载下对程序响应时间进行测试，以保证能够正常使用。

应用程序的故障处理，主要指的是在程序正常运行过程中，发生灾难性故障，程序应如何处理的功能。应测试故障恢复时间，故障恢复状态等方面的内容

12.3 创建测试用例

测试用例是建立在测试需求的基础上，对特定测试项所创建的测试。

12.3.1 创建测试用例概述

测试用例通常的一种说法是，指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。其内容主要包括测试目标、测试环境、输入数据、测试步骤、预期结果和测试脚本等，并形成测试用例文档。

测试用例是软件测试的核心。利用测试用例，可以减少软件开发过程中人为因素的影响，保证软件质量。在测试用例设计过程中，随着测试的进行和软件版本更新，测试用例也将日趋完善。测试用例是测试工作的指导，是软件测试必须遵守的准则，更是软件测试质量稳定的根本保障。

测试用例在软件测试中具有如下作用。一是指导测试的实施。在实施测试时，测试人员一定要严格按照测试用例项目和测试步骤逐一实施测试，并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档；二是规划测试数据的准备。在实践中，测试数据与测试用例是分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。测试数据包括正常数据及边缘数据和错误数据；三是指导编写测试脚本的“设计规格说明书”。为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本，测试脚本的设计规格说明书就是测试用例；四是给出评估测试结果的度量基准。在对软件测试完成后，需要对测试结果进行评估，并编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化结果，如测试覆盖率、测试合格率等，采用测试用例作度量基准更加准确、有效；五是提供分析缺陷的标准。通过收集缺陷，对比测试用例和缺陷数据库，分析出是漏测还是缺陷复现。若漏测则反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量的目的。

一个测试用例实际上就是通过设定输入数据，运行被测试函数，然后判断实际输出是否符合预期。其中，输入数据是测试用例的核心。输入数据指的是被测试函数所读取的外部数据及这些数据的初始值。外部数据实际上就是除了局部变量以外的其他数据，包括参数、成员变量、全局变量、IO媒体。IO媒体是指文件、数据库或其他储存或传输数据的媒体。对于某些函数，需要从文件或数据库中读取数据，则文件或数据库中的原始数据也属于输入数据。预期输出指的是函数返回值及其写入外部数据的结果值。

在输入数据中，包括正常输入、边界输入和非法输入。正常输入指的是对函数来说输入正常取值范围以内的数据，以测试函数正常功能；边界输入指的是正常取值范围边界的数据，以验证函数在临界状态的敏感程度；非法输入指的是输入正常取值范围以外的数据，或者使代码不能正常工作的数据，以验证函数处理错误的能力，是否能够正常报错，是否能够恢复等功能。

在设置测试用例时，主要有两种设置方法：功能指导法和路径分析法。功能指导法指的是按照软件功能来设计测试用例，只要遍历软件的每一功能即可。这种方法对于编制测试用例比较简捷，只要按照软件功能进行设置即可，但对于操作复杂的模块，其各功能的实施相互影响、紧密相关，按照功能设置测试用例难免有所遗漏，此时用路径分析法比较合适。路径分析法是根据程序运行路径进行设置测试用例的一种方法，这种方法最大的优点就是能够有效避免遗漏一些功能测试。但对于路径数量较大的模块，特别是组合路径呈几何增长的模块，采用该方法将无法使用。目前，通常采用这两种相结合的方法进行设置测试用例。

在设计测试用例时，测试用例分为基本事件、备选事件和异常事件。设计基本事件的用例，应参照用例设计规格说明书，根据功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。设计备选事件和异常事件的用例，则要复杂和困难得多，并要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。如何设计完整的测试用例，并最终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计。

在设计测试用例过程中，还应包括其他方面的一些工作，如测试用例的评审、更新和管理等问题。

12.3.2 发布测试用例文档

测试用例文档基本由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档和概述等。测试用例部分逐一显示各测试用例。每个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果（含判断标准）、出口准则和注释等。以上内容涵盖了测试用例的基本元素：测试索引、测试环境、测试输入、测试操作、预期结果和评价标准等。

12.4 创建并发布测试计划文档

软件测试是一项有计划、有组织、有系统的软件质量保证活动。为了规范软件测试内容、方法和过程，在对软件进行测试之前，必须创建测试计划，编写软件测试计划文档，以保证软件测试的有效、顺利进行。

在《ANSI/IEEE软件测试文档标准829-1983》中，测试计划被定义为：“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。”

软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流和风险分析等内容。借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通、跟踪和控制测试进度，应对测试过程中的各种变更。

对于测试计划的制作，一般来说在测试需求分析前制作总体测试计划书，在测试需求分析后制作详细测试计划书。测试计划的编写是一项系统工作，编写者必须对项目了解，对测试工作所接触到的方方面面都要有系统地把握，因此一般情况下由具有丰富经验的项目测试负责人进行编写。在制定测试计划时，一般要遵循以下原则。

制定测试计划应尽早开始。

制定测试计划时，要有明确的测试目标。

保持测试计划的灵活性，测试计划的灵活性为持续测试提供很好的支持。

要坚持“5W”规则，明确测试内容与过程。其中，“5W”规则指的是“What（做什么）”、“Why（为什么做）”、“When（何时做）”、“Where（在哪里）”、“How（如何做）”。这样可以帮助测试人员理解测试的目的（Why），明确测试的范围和内容（What），确定测试的开始和结束日期（When），指出测试的方法和工具（How），给出测试文档和软件的存放位置（Where）。

保持测试计划简洁和易读，避免测试计划的“大而全”，即测试计划文档包含详细的测试技术指标、测试步骤和测试用例，篇幅冗长，重点不突出。最好就是把详细的测试技术指标包含到独立创建的测试详细规格文档中，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。

尽量争取多渠道评审测试计划。

计算测试计划的投入，制定测试计划时一定要注意测试计划的费用情况，要量力而行。
在制定测试计划时，由于不同软件公司的背景不同，测试计划文档也略有差异。实践表明，制定测试计划时，使用正规化文档通常比较好。下面给出IEEE软件测试计划文档模版。该模版根据IEEE829－1998软件测试文档编制标准制定，共包含以下16个大纲要项，分别是：

测试计划标识符；

介绍；
测试项；
需要测试的功能；
方法（策略）；
不需要测试的功能；
测试项通过/失败的标准；
测试中断和恢复的规定；
测试完成所提交的材料；
测试任务；
环境需求；
职责；
人员安排与培训需求；
进度表；
潜在的问题和风险；
审批
当测试计划文档制作完毕后，经评审通过后，可以交付测试团队根据测试计划实施对软件的测试。

12.5 Microsoft Visual Studio Team Test Edition

对于任意一个企业，构建和维护日益复杂的信息技术（IT）解决方案面临着更多挑战。比如，在信息交流方面，由于大型程序必须要由团队来协作实现，因此团队中不同成员之间的良好沟通和交流成为程序开发成功的关键；在工具捆绑方面，尽管在 SDLC 工具领域中已经大量使用了捆绑手法，但仅仅是捆绑工具集合，而不是工具集成，由于角色限制，非集成工具（无法支持工具间的自动数据流）之间就产生了矛盾；在程序开发过程中，开发人员在许多生命周期过程中既是最关键的一环，又是最薄弱的一环，不适合团队成员（特别是整个开发团体）工作风格的过程，将遭遇到明显地阻力。

Visual Studio Team Test Edition是Microsoft为解决日益复杂的应用程序设计、开发和部署等整个生命周期问题而开发的一个版本。在团队开发方面，扩展和提供了以下功能。

信息交流：Visual Studio Team Test Edition实现了更好的信息交流功能。

集成的工具：Visual Studio Team Test Edition通过尽早地为开发人员提供他们需要用于识别和解决质量问题的工具，使更多的产品缺陷在还未构成危害之前即被发现并解决。

简化的、集成的工作流和过程：Visual Studio Team Test Edition对 SDLC 过程的支持是内置的，使得对工作流的支持是无缝的。通过将过程集成到团队成员日常使用的基本工具中，大大消除了过程采纳的障碍，并使自动收集跨职能的项目标准成为可能，而无须实施人工报告的相关开销。

增加的投资回报：Visual Studio Team Test Edition提供了一个具有成本效益的解决方案，从而通过使用跨所有SDLC工具的广泛集成，实现对软件开发生命周期的管理，提供了一个友好的环境来帮助开发团队提高效率，而无须掌握不必要的、复杂的概念和僵化的工具。

在集成方面，Visual Studio Team Test Edition通过将SDLC工具集成到UI级别的表面，提高了团队工作效率并增强了项目的可预见性。集成包括用户界面集成，即对于开发人员而言，可以在他们当前的开发环境中使用某些活动（例如，单元测试、工作项跟踪、代码剖析和代码分析）；数据集成，即通过使用一个公共的跨工具集的数据仓库，解决了在大多数 SDLC 工具中建立数据仓库的问题，并启动了一个聚合的项目状态视图，团队根据能够收集到的规则来管理项目；过程集成，即工具行由项目开始时选择的过程决定，通过将过程与工具相集成，可以确保在项目各阶段之间或各种项目角色之间避免丢失任何内容，且过程集成并不增加工作量，而通常能够降低与 SDLC 中所采纳过程相关的开销。

在扩展性方面，Visual Studio Team Test Edition提供基本的平台，让所有提供商能够以一种普通的、公众可理解的形式交换信息，其设计基础是扩展性模型，主要体现在集成的3个层次，即UI、数据和过程。在用户界面方面，Visual Studio Team Test Edition利用现有的 Visual Studio Industry Partner（VSIP）计划，将补充的产品和服务插入到 Visual Studio 集成开发环境（IDE）之中；在数据扩展性方面，Visual Studio Team Test Edition利用 Visual Studio Team Foundation Core Services（TFCS）将这些工具集成在一起，TFCS提供一组能够将工具集成在一起的工具，无须工具间的紧密耦合。对于数据收集，TFCS还能够将第三方工具用于由Visual Studio Team System使用的数据仓库中。在过程扩展性方面，Visual Studio Team Test Edition是一个灵活的工具集，使用方法论模版来定义每个项目将遵循的过程。Microsoft的Global Solution Integrator合作伙伴将提供他们自己的方法论模版产品，或者也可以自己创建模版。过程扩展性允许自定义工作项类型、签入策略、自定义报告，以及项目管理模版。

Visual Studio Team Test Edition提供了支持整个软件开发团队的工具。对于架构师，Visual Studio Team Test Edition包括集成、高效的工具，用于直观地构建面向服务的解决方案，这些解决方案从部署环境的初始状态开始设计。对于开发人员，Visual Studio Team Test Edition为开发人员提供高级的静态分析、代码剖析、代码涵盖，以及单元测试工具，使团队能够在整个生命周期中尽早、频繁地规划质量。对于项目管理人员，Visual Studio Team Test Edition提供一套基于软件项目管理人员已知内容的项目管理工具，即Microsoft Excel、Microsoft Project 和 Windows SharePoint Services。与 Microsoft Office集成后，项目管理人员不再需要手工将数据从这些应用程序映射到供工程团队使用的数据。项目站点提供仪表盘式的项目状态视图，以及向下追溯风险承担者的功能。丰富的报告提供了从整个常规的团队工作流中收集的规则。自定义项目过程基于业界公认的实践来驱动生命周期。对于团队开发，Visual Studio Team Test Edition还提供团队协作工具，使组织能够不费吹灰之力即可管理并跟踪过程和软件项目的运行状况。Portfolio Explorer 将可从项目站点获得的这些相同的项目工作产品集成到 Visual Studio IDE，从而让团队能够进行有效的访问。另外，还提供一个可扩展的工作项跟踪系统和企业级别的源代码管理。

利用Visual Studio Team Test Edition，使得开发团队更加便于协作，减少了开发过程中的复杂程度，节约了开发时间和开销。

============================================================

http://book.51cto.com/art/200806/76719.htm

12.6 单元测试

单元测试是一种编程测试，主要对软件中一个或互相关联的一组程序单元进行测试，通常在编程阶段进行。单元测试可以使用 Visual C#、Visual Basic和Visual C++中的任何一种语言编写测试代码。在测试过程中，单元测试通过直接调用类的方法并传递相应的参数来执行其他源代码。如果测试中包括了 Assert 语句，可以测试得到的值是否与期望的值相符。单元测试方法位于测试类中，测试类则存储在源代码文件中。

12.6.1 VSTS单元测试概述

单元测试的生成有两种方法：一是自动生成，二是手动编写。无论使用何种方式生成单元测试，测试类和所有测试方法都通过属性加以标识。用 [TestClass()] 属性标记每个测试类；用[TestMethod()] 属性标记测试方法；另外，还有[TestInitialize()] 和 [TestCleanup()]等属性。标记有 [TestInitialize()] 的方法主要实现单元测试运行环境的准备，目的是为单元测试的运行建立已知状态。运行完某个测试后，可通过标记有 [TestCleanup()] 的方法将环境返回到已知状态。在自动生成单元测试时，上述属性是在生成单元测试时自动分配的；如果是手动编写单元测试代码，则必须自行在类和方法中添加上述属性。

此外，单元测试代码的测试类还有一个重要属性，即TestContext 属性。该属性包含如下信息：当前正在运行的单元测试的名称、部署目录、日志文件的名称；对于数据驱动型测试，还包括所连接到的数据库等。该属性返回一个 TestContext 实例。

对于ASP.NET应用程序，其单元测试可对ASP.NET站点或项目中的方法进行测试。ASP.NET 单元测试和其他单元测试的不同之处在于其中运行测试的进程。ASP.NET 测试在生成测试代码的生产代码（自动生成单元测试的代码）环境中运行。为此，可以选择 IIS，也可以选择 ASP.NET Development Server。当在 Web 服务器进程中运行测试时，可以访问与该进程关联的所有环境，如 Page 对象。创建 ASP.NET 单元测试的方法也有两种：一是自动生成；二是通过配置现有单元测试使其作为 ASP.NET 单元测试运行。下面主要对ASP.NET 单元测试的自动生成方法进行介绍。

12.6.2 创建单元测试

对于一个ASP.NET 网站，生成其单元测试的过程如下。

（1）在网站项目中添加“类”。在“解决方案资源管理器”中用鼠标右键单击该网站，单击【添加新项】命令，打开“添加新项”对话框，如图12-1所示。在该对话框中选择“类”模版，输入名称，选择“Visual C#”语言，单击【添加】按钮。

（点击查看大图）图12-1 添加新项

（2）在弹出的“Microsoft Visual Studio”对话框中，询问是否要在 App_Code 文件夹中放置新类，单击【是】按钮，如图12-2所示。要注意的是不能从 .aspx 文件或 App_Code 之外的其他文件夹的代码中生成测试。

（点击查看大图）图12-2 新类放置于App_Code 文件夹

（3）打开添加的类文件，在类文件中用鼠标右键单击该类，选择【创建单元测试】命令，如图12-3所示。

（点击查看大图）图12-3 创建单元测试

（4）打开“创建单元测试”对话框，在“筛选器”中选择所要显示的内容，在“输出项目”中选择“创建新的Visual C#测试项目”，单击【设置】按钮，在“设置”对话框中设置名称，如图12-4所示。

（点击查看大图）图12-4 “创建单元测试”对话框

（5）展开代码，选择需要测试的类，如图12-5所示。

（点击查看大图）图12-5 选择类中的方法

（6）选择【设置】按钮，定义测试生成设置，如图12-6所示。

（点击查看大图）图12-6 测试生成设置

（7）单击【确定】按钮，定义测试项目的名称，如图12-7所示。

（点击查看大图）图12-7 测试项目名称设置

（8）系统将生成如下测试代码和项，如图12-8所示。

（点击查看大图）图12-8 单元测试成功

（9）编辑单元测试代码，如下所示，可以看出其中的属性标识。

// 以下代码由 Microsoft Visual Studio 2005 生成。
// 测试所有者应该检查每个测试的有效性。
using Microsoft.VisualStudio.TestTools.UnitTesting;
using System;
using System.Text;
using System.Collections.Generic;
using Microsoft.VisualStudio.TestTools.UnitTesting.Web;
namespace TestPro
{
/// <summary>
///这是 Class1 的测试类，旨在
///包含所有 Class1 单元测试
///</summary>
[TestClass()]
public class Class1Test
{
private TestContext testContextInstance;
/// <summary>
///获取或设置测试上下文，上下文提供
///有关当前测试运行及其功能的信息。
///</summary>
public TestContext TestContext
{
get
{
return testContextInstance;
}
set
{
testContextInstance = value;
}
}
#region 附加测试属性
// 
//编写测试时，可使用以下附加属性:
//
//使用 ClassInitialize 在运行类中的第一个测试前先运行代码
//
//[ClassInitialize()]
//public static void MyClassInitialize
(TestContext testContext)
//{
//}
//
//使用 ClassCleanup 在运行完类中的所有测试后再运行代码
//
//[ClassCleanup()]
//public static void MyClassCleanup()
//{
//}
//
//使用 TestInitialize 在运行每个测试前先运行代码
//
//[TestInitialize()]
//public void MyTestInitialize()
//{
//}
//
//使用 TestCleanup 在运行完每个测试后运行代码
//
//[TestCleanup()]
//public void MyTestCleanup()
//{
//}
//
#endregion
/// <summary>
///AddFunction (double, double) 的测试
///</summary>
[TestMethod()]
[HostType("ASP.NET")]
[AspNetDevelopmentServerHost("%PathToWebRoot%\\
WebTest", "/WebTest")]
[UrlToTest("http://localhost/WebTest")]
public void AddFunctionTest()
{
object target = TestPro.Class1Accessor.CreatePrivate();
TestPro.Class1Accessor accessor= new TestPro.
Class1Accessor(target);
double a = 0; // TODO: 初始化为适当的值
double b = 0; // TODO: 初始化为适当的值
string expected = null;
string actual;
actual = accessor.AddFunction(a, b);
Assert.AreEqual(expected, actual, "Class1.AddFunction 
未返回所需的值。");
Assert.Inconclusive("验证此测试方法的正确性。");
}
/// <summary>
///AdjugeString (string) 的测试
///</summary>
[TestMethod()]
[HostType("ASP.NET")]
[AspNetDevelopmentServerHost("%PathToWebRoot%\\
WebTest", "/WebTest")]
[UrlToTest("http://localhost/WebTest")]
public void AdjugeStringTest()
{
object target = TestPro.Class1Accessor.CreatePrivate();
TestPro.Class1Accessor accessor= new TestPro.
Class1Accessor(target);
string str = null; // TODO: 初始化为适当的值
double expected = 0;
double actual;
actual = accessor.AdjugeString(str);
Assert.AreEqual(expected, actual, "Class1.AdjugeString 
未返回所需的值。");
Assert.Inconclusive("验证此测试方法的正确性。");
}
}
}

（10）保存代码，完成创建单元测试操作。

12.6.3 执行单元测试

当创建了单元测试之后，可以在【测试】主菜单中，选择【启动选定的测试项目（不调试）】选项，如图12-9所示，执行当前打开的单元测试。

图12-9 启动单元测试

测试过程及结果如图12-10所示。

(点击查看大图）图12-10 单元测试过程

12.7 执行Web功能测试

Web功能测试是功能测试的一项重要内容，主要通过HTTP请求发送测试Web功能选项。

12.7.1 VSTS Web 功能测试使用概述

Web测试也称为声明性Web测试，由一系列HTTP请求组成，通过发出HTTP请求在协议层工作。Web测试不运行JavaScript。可以通过在浏览器会话中记录活动来创建Web测试，还可以使用Web测试编辑器手动构建Web测试。

Web测试具有如下的优点。一是可以创建用于广泛测试目的的Web测试；二是可以创建执行Web应用程序的功能测试；三是可以创建数据驱动的测试；四是可以创建并运行可以测试应用程序性能的测试；五是可以使用.NET语言进行测试创作、调试和测试扩展。

在Web测试中，可以自动处理以下操作。一是包括VIEWSTATE在内的隐藏字段相关性；二是重定向；三是从属请求；四是身份验证；五是通过HTTPS/SSL确保安全。另外，使用Web测试查看器，可以查看和调试要验证的Web测试。

12.7.2 创建Web功能测试

创建Web功能测试的步骤如下。

（1）用鼠标右键单击“解决方案”，选择【添加】→【新建项目】选项，如图12-11所示。

(点击查看大图）图12-11 新建项目

（2）在打开的“添加新项目”窗体左边的“项目类型”中，选择“Visual C#”下的“测试”节点，在右边的“模版”中选择“测试项目”，输入项目名称和保存位置，单击【确定】按钮，如图12-12所示。

(点击查看大图）图12-12 选择测试项目

（3）将测试项目添加至解决方案中后，用鼠标右键单击该项目，然后选择【添加】→【Web测试】选项，如图12-13所示。

(点击查看大图）图12-13 添加Web测试

（4）Web测试添加至项目中，如图12-14所示。

(点击查看大图）图12-14 Web测试添加至测试项目中

12.7.3 运行Web功能测试

若Web测试编辑器未打开，双击Web测试文件，将打开Web测试编辑器，单击【运行测试】按钮，如图12-15所示。

(点击查看大图）图12-15 允许Web测试

系统将显示“Web 测试查看器”，如图12-16所示。

(点击查看大图）图12-16 Web测试过程

12.8 执行商务网站性能测试

性能测试是一项非功能测试，VSTS提供了Web性能测试的相应工具，支持创建性能测试用例。

12.8.1 VSTS Web性能测试概述

Web性能测试指的是针对与Web相关的应用系统进行的性能测试，包括压力测试、负载测试、并发测试、强度测试、大数据量测试、可靠性测试和配置测试等测试种类。通过性能测试，可以检验程序的应用性能是否能够满足要求。对于一个成功的网站，除了功能能够满足要求外，性能是影响其成功应用的另一个重要因素。比如，数据处理时间过长，用户无法忍受；同时提供服务的数量较少，容易出现故障等，这些都是其性能测试的测试范围。

Web性能测试是和功能测试紧密联系在一起的，主要是由于很多性能问题都是由软件自身功能缺陷引起的。如果程序功能不完善或代码运行效率低下，通常会带来一些性能问题。因此，在功能测试顺利实现的前提下，可以更好地保证性能测试的进行。

在Web性能测试中，为了衡量测试结果，通常利用一些指标进行衡量。比如，请求提交时间，即客户机浏览器与网站进行连接并传输用户提供的数据所需的时间；服务器处理时间，即请求被一台或多台服务器处理所需的时间；响应时间，即处理请求后，将页面或数据返回给用户，传输这些页面或数据所需的时间；延迟时间，即一个动作发出到第一个响应回应之间的时间；用户感知延迟时间，即用户动作发出到内容最初显示之间的时间；带宽，即每单位时间内可传输的流量；工作负载，即一段时间内，Web接收的输入量。

在Web性能测试过程中，以负载测试为主要测试，主要检测系统的服务能力。VSTS提供了Web应用程序的负载测试，下面主要对Web应用程序的负载测试进行介绍。

12.8.2 创建Web性能测试

创建Web性能测试的步骤如下。

（1）在【测试】主菜单中，选择【新建测试】选项，如图12-17所示。

（2）在打开的“添加新测试”窗体中，选择“负载测试”模版，输入测试名称，若不存在测试项目，可在“添加到测试项目”下拉框中选择“创建新的Visual C#测试项目”，如图12-18所示。

图12-17 新建测试

(点击查看大图）图12-18 添加负载测试

（3）单击【确定】按钮。在打开的“新建测试项目”窗体中，输入测试项目的名称，单击【创建】按钮，即成功创建测试项目，如图12-19所示。

图12-19 设定新建测试项目名称

（4）在打开的“新建负载测试向导”中，如图12-20所示，利用该向导即可创建出负载测试。

（5）执行负载测试，如图12-21所示。

(点击查看大图）图12-20 负载测试创建向导

(点击查看大图）图12-21 负载测试视图

12.8.3 运行Web性能测试

在负载测试视图中，单击【运行测试】按钮，即可运行负载测试，如图12-22所示为测试正在运行。

(点击查看大图）图12-22 负载测试运行过程

如图12-23所示为测试过程中测试结果的界面。

(点击查看大图）图12-23 负载测试测试结果

12.8.4 监视Web性能

在测试结果界面中，可以通过不同的按钮来监视整个测试过程，以及不同的测试结果。如图12-24所示为以表的形式监视测试过程。

（点击查看大图）图12-24 负载测试过程中的表

如图12-25所示为以关系图的形式可以形象地看出测试过程中的负载情况。

（点击查看大图）图12-25 负载测试过程中的关系图

如图12-26所示为测试的摘要。

（点击查看大图）图12-26 负载测试过
程中的摘要

如图12-27所示可以看到各种计数器的工作情况，通过右键菜单可以将计数情况在关系图中进行显示。

（点击查看大图）图12-27 负载测试过程中的计数器

12.9 发布测试结果

在发布测试结果之前，需要注意的是，在测试结果发布之后，将驻留在称为操作存储区的 SQL Server 数据库中，操作存储区驻留在 Team Foundation Server 计算机上，只有安装了团队资源管理器且 Visual Studio 用户会话连接到 Team Foundation Server 计算机之后才能发布测试数据。在该存储区中，可存储各种类型的测试结果数据，包括代码覆盖率等信息。在发布测试结果时，必须发布整个测试运行结果或多个测试运行结果，不能发布运行子集测试结果。

发布测试结果的基本过程如下。

（1）在【测试】菜单上选择【窗口】→【测试结果】命令，显示“测试结果”窗口，如图12-28所示。

(点击查看大图）图12-28 选择【测试结果】命令

（2）在“测试结果”窗口工具栏上单击【发布】，打开“发布测试结果”对话框，选择要发布的每个测试运行旁边的复选框，选择关联的内部版本号，选择平台和版本风格，如“发布”或“调试”，若要在发布的数据中包括代码覆盖率数据，选中“包括选定运行的代码覆盖率数据”，单击【确定】按钮，即将所选运行的测试数据发布到操作存储区中。

（3）可以导出测试结果，在“测试结果”窗口工具栏上单击【导出测试运行结果】命令，如图12-29所示，在打开的对话框中输入导出路径，即可将所选的测试结果导出到文件。

(点击查看大图）图12-29 导出测试运行结果

第13章企业级应用的发布与部署

本章主要内容

系统编译与发布概述

创建网站的部署图

执行部署

13.1 系统编译与发布概述

系统编译与发布是在系统编码之后执行的一项基本操作。编译是用于生成可执行代码，发布是将编译之后的可运行版本发布到服务器，以供用户使用。

13.1.1 编译网站

为了使所编写的网站应用程序代码能够发布使用，必须对代码进行编译。在编译中，ASP.NET 将代码翻译成Microsoft中间语言（MSIL）。运行时，MSIL 将运行在 .NET Framework 的上下文中，.NET Framework 会将 MSIL 翻译成 CPU 特定的指令，以便计算机上的处理器运行应用程序。应用程序通过编译可以提供代码运行速度，增加代码安全性和稳定性。由于MSIL语言支持任何 .NET 语言，因此可以在代码中使用最初用其他语言编写的程序集，如在用 C# 编写的网页中添加使用 Visual Basic 编写的.dll 文件的引用。

在用户首次请求网站的资源时，ASP.NET 将自动编译应用程序代码和任何依赖资源。通常，ASP.NET 为每个应用程序目录（如 App_Code）创建一个程序集，并为主目录创建一个程序集。如果一个目录中的文件是用不同编程语言编写的，将为每种语言分别创建程序集。

ASP.NET 还提供了预编译选项，通过这些选项，可以在部署网站之前先进行编译，或者在部署网站之后，但在用户请求该网站之前进行编译。
预编译指的是在用户首次请求资源（如网站的一个页）时，将动态编译ASP.NET网页和代码文件。编译后的页和代码文件将会被缓存，以提高随后对同一页提出的请求的效率。ASP.NET还可以预编译整个站点。通过预编译，可以加快用户的响应时间；可以在用户看到站点之前识别编译时错误；可以创建站点的已编译版本，并将该版本部署到成品服务器，而无须使用源代码。

在ASP.NET中，提供了两个基本的预编译站点选项。一是预编译现有站点，可以提高现有站点的性能并对站点执行错误检查；二是针对部署预编译站点，可以将该输出部署到成品服务器中。另外，可以预编译一个站点，使它成为只读的或可以更新的站点。

1．预编译现有站点

预编译现有站点，也称为就地预编译。对于经常更改和补充网页及代码文件的站点，通过预编译可以提高网站性能。在执行就地预编译时，将编译所有 ASP.NET 文件类型，HTML 文件、图形和其他非 ASP.NET 静态文件将保持原状。在预编译过程中，编译器为所有可执行输出创建程序集，并将这些程序集放在 %SystemRoot%\Microsoft.NET\ Framework\Temporary ASP.NET Files 文件夹下的特殊文件夹中。随后，ASP.NET 将通过此文件夹中的程序集来完成页请求。由于提供了缓存功能，当再次预编译站点时，将只编译新文件或更改过的文件（或那些与新文件或更改过的文件具有依赖关系的文件）。

2．针对部署预编译站点

针对部署进行预编译将以布局形式创建输出，其中包含程序集、配置信息、有关站点文件夹的信息，以及静态文件（如HTML文件和图形）。编译后，可以使用Windows XCopy命令、FTP、Windows安装等工具将布局部署到成品服务器。布局在部署完之后将作为站点运行，且ASP.NET将通过布局中的程序集来完成页请求。

针对部署进行预编译有两种方式：一是仅针对部署进行预编译；二是针对部署和更新进行预编译。

当仅针对部署进行预编译时，编译器实质上将基于正常情况下在运行时编译的所有ASP.NET源文件来生成程序集。其中包括页中的程序代码、.cs和.vb类文件，以及其他代码文件和资源文件。编译器将从输出中移除所有源代码和标记。在生成的布局中，为每个.aspx文件生成编译后的文件（扩展名为.compiled），该文件包含指向该页相应程序集的指针。要更改网站（包括页的布局），必须更改原始文件，重新编译站点并重新部署布局。唯一的例外是站点配置，可以更改成品服务器上的Web.config文件，而无须重新编译站点。此选项不仅为页提供了最大程度的保护，还提供了最佳的启动性能。

当针对部署和更新进行预编译时，编译器将基于所有源代码（单文件页中的页代码除外），以及正常情况下用来生成程序集的其他文件（如资源文件）来生成程序集。编译器将.aspx文件转换成使用编译后的代码隐藏模型的单个文件，并将它们复制到布局中。

13.1.2 发布网站

在发布网站时，Visual Studio会编译网站中的可执行文件，并将输出写入指定文件夹中。发布网站同简单地将网站复制到目标Web服务器相比，具有以下优点。一是通过预编译可以发现任何编译错误，并在配置文件中标识错误；二是使单独页的初始响应速度更快，如果不先编译页就将其复制到网站，则将在第一次请求时编译页，并缓存其编译输出，导致速度较慢；三是不会随网站部署任何程序代码，从而为文件提供了一项安全措施。

在发布网站前，需要检查原始站点的配置，一是记下远程位置上需要的所有设置，如连接字符串、成员资格设置及其他安全设置等设置；二是记下需要在已发布网站上更改的所有设置，如在发布网站后禁用调试、跟踪及自定义错误等。因为配置设置是继承而来的，所以可能需要查看Web.config文件或SystemRoot\Microsoft.NET\Framework\version\ CONFIG目录中的Machine.config文件，以及应用程序中的所有Web.config文件。

发布网站的第一步是预编译网站，实际执行的编译过程与通常在浏览器中请求页时发生的动态编译的编译过程相同。预编译器从页产生程序集，包括标记和代码。它同时还编译App_Code、App_GlobalResources、App_LocalResources和App_Themes文件夹中的文件。预编译过程完成时，得到的输出被写入指定的文件夹中。可以通过使用文件传输协议（FTP）或通过HTTP，将输出写入任何在文件系统中可以访问的文件夹中。
发布网站的具体步骤如下。

（1）在【生成】菜单上单击【发布网站】命令，弹出“发布网站”对话框，如图13-1所示。

(点击查看大图）图13-1 发布网站

（2）在“发布网站”对话框中的“目标位置”处，可将网站输出写入本地文件夹或共享文件夹、FTP站点，或者通过URL访问的网站，但必须具有在目标位置创建和写入的权限。

（3）若想要在发布网站之后更改.aspx文件的布局（而非代码），请选择“允许更新此预编译站点”复选框。

（4）若要使用密钥文件或密钥容器命名具有强名称的程序集，请选择“对预编译程序集启用强命名”复选框，然后单击【确定】。

（5）发布状态显示在任务栏中。根据连接速度、站点的大小和内容文件的类型，发布时间可能不同。发布完成后，即显示“发布成功”状态。

（6）进行站点所需的所有配置更改。

13.2 创建网站的部署图

当执行部署时，可以利用VSTS工具创建网站部署图，借助部署图，实现对网站的部署。

13.2.1 VSTS 逻辑中心设计器

逻辑数据中心设计器主要用于创建相互连接的逻辑服务器的关系图，以及描述数据中心策略和逻辑结构的模型。借助该设计器，程序架构师可以指定和配置数据中心的服务器类型、许可的通信类型、特定的通信路径，以及支持的服务类型等。逻辑数据中心设计器也与 Visual Studio完全集成。但逻辑数据中心关系图的创建与应用程序开发过程无关。这些关系图保存为 .lsad文件，并可以由部署在同一目标环境中的其他分布式系统重用。

在前面系统逻辑设计这一章中，介绍逻辑中心设计器的工具箱控件，可以将它们添加到关系图中，其中逻辑服务器表示数据中心中的应用程序主机，包括 Windows客户端服务器、Web 服务器（IIS 服务器）、SQL Server和通用服务器。其中的通用服务器只是为了达到记录的目的，并考虑到要进行建模的数据中心中存在其他类型的服务器。在逻辑服务器原型中，除通用服务器外，都定义一组用于配置服务器的设置和约束。在每个逻辑服务器中，都指定了两个通信协议终结点，以设置不同服务器之间的通信路径。通过服务器终结点，还可以指定服务器和跨区域发送或接收通信服务器之间所允许的通信协议。

在工具箱中，还包括区域及区域终结点。区域表示数据中心的通信边界，区域终结点表示区域和服务器之间的连接点。通过区域终结点，可以确定允许进出该区域的通信协议的类型。

如图13-2所示，在该关系图中，设置了两个区域，区域1表示前端，区域2表示服务端。在区域1中，有两个客户端，在区域2中，有一个Web服务器和一个数据库服务器。客户端通过网络向服务器请求服务，服务器根据请求内容，从数据库中提取数据后发送至客户端，以响应用户请求。

（点击查看大图）图13-2 VSTS逻辑中心设计器

13.2.2 VSTS 部署设计器

部署设计器主要用于创建网站程序系统的部署配置，并可以根据数据中心的逻辑表示形式对该配置进行验证。验证可以确认系统中的所有应用程序是否都绑定到逻辑服务器，然后检查应用程序是否符合逻辑数据中心关系图中指定的应用程序约束。验证也可以确认逻辑服务器是否符合应用程序连接关系图和系统关系图中指定的宿主约束。此外，验证还可以确保所需的通信路径存在，并确定是否存在正确的通信协议，以及这些协议是否在应用程序和主机服务器之间兼容。所有的验证错误都显示在Visual Studio错误列表中，该列表为更正和调整错误提供了一种简单的导航机制。双击错误列表中的某项错误时，部署设计器将打开相应的关系图，选择适当的应用程序或逻辑服务器，并导航到适当的设置，从而可以对其进行更正。这样就能够在部署之前（甚至在完全实现系统之前）更正配置错误。通常，部署设计器由程序开发人员和架构师使用。

根据逻辑数据中心关系图生成的部署图如图13-3所示，可以通过上下文菜单进行关系图验证。

(点击查看大图）图13-3 部署设计器

13.3 执行部署

当创建了部署图之后，可以执行部署。VSTS能够完成网站的基本部署操作。

13.3.1 利用Visual Studio 2005部署工程部署网站

在Visual Studio 2005中，部署网站主要包括以下几方面内容。

1．生成页或网站

生成页或网站可以帮助发现编译时的错误，并对错误进行定位。生成页主要指的是Visual Studio 仅编译当前页及其依赖项，而生成网站将对站点所有页的代码进行编译，其过程与在浏览器中请求页时发生的任务相同。对页和网站的生成操作不会产生可部署的程序集。生成页或生成网站在【生成】菜单中选择相应的选项即可实现，如图13-4所示。

图13-4 发布网站

2．发布网站

如果要将站点编译为可部署的程序集和其他文件，可以选择发布站点。发布与生成具有相同的编译步骤，如前所述，发布站点可以将输出保存到一个文件夹及其子文件夹中，并可将该文件夹及其子文件夹部署到成品服务器中。

另外，通过将网站中的所有文件复制到成品服务器中，无须编译即可部署站点。当用户从成品服务器请求页时，ASP.NET 将动态编译站点，有效地执行与 Visual Studio 中的生成过程相同的步骤。

3．向网站添加文件

Visual Studio中的网站是基于目录的，在打开某个网站时，Visual Studio将打开的文件夹中的所有文件（无论在文件系统中、Internet信息服务（IIS）应用程序中，还是在FTP站点上）都视为该网站的组成部分。在向网站添加文件时，某些类型的文件需要添加至相应的目录中，如浏览器定义文件（.browser）只能在 App_Browsers 应用程序子目录中创建。

将文件添加到网站的过程比较简单，基本过程为如下。

（1）在网站项目上单击鼠标右键，选择【添加新项】命令，打开“添加新项”对话框。

（2）在“添加新项”对话框的“Visual Studio 已安装的模版”下，选择要添加的文件类型。

（3）如果要添加的文件类型启用了“语言”列表，则选择文件要使用的编程语言的名称，在同一网站中可以使用不同编程语言来创建文件（页）。

（4）如果希望页代码在单独的文件中，请确保选择了“将代码放在单独的文件中”复选框；如果希望将代码和标记保存在同一文件中，请清除该复选框。

（5）在“名称”框中，输入文件的名称，然后单击【添加】按钮，即实现文件的添加，添加的文件显示在视图窗口中。

4．创建网站子目录

可以向网站添加一些特殊的目录，以实现相应功能，如主题功能。创建网站子目录步骤如下。

（1）在网站项目上单击鼠标右键，选择【添加 ASP.NET 文件夹】选项。

（2）在可用文件夹的列表中，单击要创建的文件夹的名称，如图13-5所示。

图13-5 添加文件夹

5．将现有网页添加到网站项目

在网站开发过程中，可以将现有的网页添加到网站中，以提高开发效率。将现有网页添加到网站中的步骤如下。

（1）在网站项目上单击鼠标右键，选择【添加现有项】选项。打开“添加现有项”对话框。

（2）在“添加现有项”对话框中，浏览到要添加的网页所在的目录，选择该页，然后单击【打开】按钮，该网页即添加到了网站项目中。添加现有文件时，文件被复制到项目，而不是以引用的方式添加的。因此，如果在项目中更改该文件，原始文件仍可保持不变。

13.3.2 配置Web.config文件

在ASP.NET应用程序中，Web.config文件是一个XML文本文件，也是ASP.NET Web 应用程序的配置信息，可以出现在应用程序的每一个目录中。使用 ASP.NET 的Web.config配置文件，可以配置整个服务器、ASP.NET 应用程序或单独的页。当新建一个Web应用程序后，默认情况下会在根目录自动创建一个默认的Web.config文件，包括默认的配置设置，所有的子目录都继承它的配置设置。如果想修改子目录的配置设置，可以在该子目录下新建一个Web.config文件。它除了提供从父目录继承的配置信息以外，还可以重写或修改父目录中定义的设置。

创建Web.config文件的步骤如下。

（1）首先确认Web.config文件是否已经创建，可以通过在“解决方案资源管理器”中，单击【刷新】图标的方法来确认。

（2）在网站名称上单击鼠标右键，选择【添加新项】选项。

（3）在“模版”窗口中，单击“Web配置文件”，文件名称应为Web.config，也可以为该文件提供其他名称，.config文件扩展名可防止ASP.NET下载相应文件，如图13-6所示。

（4）单击【添加】按钮，即将Web.config文件添加至网站中，然后可以将其打开进行编辑。

（点击查看大图）图13-6 添加配置文件

（5）编辑Web.config文件，如对于企业短信收发平台，编辑其文件内容如下所示。主要配置了数据库的连接信息。

<?xml version="1.0"?>
<configuration>
<appSettings>
<!--此处设置数据库连接字符串-->
<add key="ConnectionString" value="server=localhost;database=
EAMS;User ID=sa;password=yjs;Connect Timeout=0"/>
<!-- <add key="ConnectionString" value="server=localhost;uid=
sa;pwd=;database=EAMS"></add>-->
<!--
<add key="DataBaseConnectionString" value="server=localhost;database=
EAMS;User ID=wangtao;password=wang"></add>
-->
</appSettings>
<system.web>
<compilation defaultLanguage="c#" debug="true">
<compilers>
<compiler language="c#" type="Microsoft.CSharp.
CSharpCodeProvider,System, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=B77A5C561934E089" extension=
".cs" compilerOptions="/d:DEBUG;TRACE"/></compilers>
<assemblies>
<add assembly="System.Design, Version=2.0.0.0, Culture=
neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
<add assembly="System.Management, Version=2.0.0.0, Culture=
neutral, PublicKeyToken=B03F5F7F11D50A3A"/></assemblies>
</compilation>
<authentication mode="Forms">
<forms name="hotop100" loginUrl="Login.aspx">
</forms>
</authentication>
<customErrors mode="Off"/>
<!--
<customErrors defaultRedirect="errorpage.htm" mode="On">
<error statusCode="404" redirect="error404.aspx"/>      
</customErrors>
-->
<!--
<sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;uid=sa;pwd=" cookieless=
"false" timeout="120"/>
-->
<sessionState mode="InProc" stateConnectionString="tcpip=
127.0.0.1:42424" sqlConnectionString="data source=127.0.0.1;
uid=wangtao;pwd=wang" cookieless="false" timeout="1200"/>
<globalization requestEncoding="gb2312" responseEncoding="gb2312"/>
<xhtmlConformance mode="Legacy"/></system.web>
</configuration>

13.3.3 部署.NET框架

为使.NET Framework应用程序可以在某台特定的计算机上运行，该计算机上必须安装有.NET Framework。由于Visual Studio引导程序与Visual Studio .NET安装程序和部署项目集成在一起，因此可以只创建一个安装程序，用它来自动检测目标计算机上是否存在.NET Framework，并根据需要进行安装。

下面给出创建安装项目的步骤。

（1）在【文件】菜单中选择【新建】→【项目】命令，打开“新建项目”对话框。在该对话框的左边选择“其他项目类型”中的“安装和部署”，在右边的“模版”中选择“安装项目”模版，输入名称，单击【确定】按钮，即创建了一个安装项目，如图13-7所示。