技术篇

第10回 在软件开发各个阶段的测试任务

软件测试是软件开发过程中重要内容之一，是软件质量保证的关键。软件测试贯穿软件产品开发的整个生命周期，如第二章V模型图2-1所示，软件测试和软件项目同时开始，从产品的需求分析审查到最后的验收测试，直至软件发布。

从测试实际的前后过程来看，软件测试的过程是由一系列的不同测试阶段所组成，这些软件测试的步骤分为：需求分析审查、设计审查、单元测试、集成测试（组装测试）、功能测试、系统测试、验收测试、回归测试（维护）等。详细内容见下表。

第11回 集成测试的模式和方法

单元测试主要由开发人员完成，所以从测试人员工作来看，集成测试可能是具体测试实施的第一个阶段，虽然开发人员也比较多地参与集成测试。集成测试相对来说是挺复杂的，而且对于不同的技术、平台和应用，差异也比较大。不过，我们还是不得不面对它，保证系统集成成功，为后来的系统测试打下基础。

集成测试简单的表现形式就是每日构建（Daily Build）, 保证Build构建成功，也就是保证软件的组件或单元能组装成一个系统。每日构建是一个很好的实践，被许多软件公司采用。

集成测试，更多是和开发环境融合在一起，在编程过程中去实现，如MS Visual Studio.NET ，Borland JBuilder IDE， Compuware OptimalJ的集成开发/测试环境。更正确的说法，集成测试发要追溯到设计阶段。当设计数据接口(DB，XML等）、组件接口、应用接口(API)之时，我们就要审查接口的规范性、一致性等，就已经开始了集成测试。

集成测试阶段，测试方法是动态变化的，从白盒测试方法向黑盒测试方法逐渐过渡。在自底向上集成的早期，白盒测试方法占较大的比例，随着集成测试的不断深入，这种比例在测试过程中将越来越少，渐渐地，黑盒测试慢慢占据着主导地位。

集成模式是软件集成测试中的策略体现，其重要性是明显的，直接关系到测试的效率、结果等，一般要根据具体的系统来决定采用哪种模式。集成测试基本可以概括为以下两种：

• 非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求一次全部组装起来所要的系统，然后进行整体测试。
• 渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个模块结合进来测试。

非渐增式测试时可能发现一大堆错误，为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能引入新的错误，新旧错误混杂，更难断定出错的原因和位置。与之相反的是渐增式集成模式，程序一段一段地扩展，测试的范围一步一步地增大，错误易于定位和纠正，接口的测试亦可做到完全彻底。两种模式中，渐增式测试模式虽然需要编写的Driver或Stub程序较多、发现模块间接口错误相对稍晚些，但渐增式测试模式还具有比较明显的优势。

在实际测试中，应该将两种模式有机结合起来，采用并行的自顶向下、自底向上集成方式，而形成改进的三明治方法。而更重要的是采取持续集成的策略，软件开发中各个模块不是同时完成，根据进度将完成的模块尽可能早的进行集成，有助于尽早发现缺陷，避免集成阶段大量缺陷涌现。同时自底向上集成时，先期完成的模块将是后期模块的桩程序，而自顶向下集成时，先期完成的模块将是后期模块的驱动程序，从而使后期模块的单元测试和集成测试出现了部分的交叉，不仅节省了测试代码的编写，也有力于提高工作效率。

如果不采用持续集成策略，开发人员经常需要集中开会来分析软件究竟在什么地方出了错。因为某个程序员在写自己这个模块代码时，可能会影响其它模块的代码，造成与已有程序的变量冲突、接口错误，结果导致被影响的人还不知道发生了什么，缺陷就出现了。随着时间的推移，问题会逐渐恶化。通常，在集成阶段出现的缺陷早在几周甚至几个月之前就已经存在了。结果，开发者需要在集成阶段耗费大量的时间和精力来寻找这些缺陷的根源。如果使用持续集成，这样的缺陷绝大多数都可以在引入的第一天就被发现。而且，由于一天之中发生变动的部分并不多，所以可以很快找到出错的位置。这也就是为什么进行每日构建软件包的原因所在。所以，持续集成可以提高软件开发的质量与效率。

在现实中，集成测试和单元测试所处的情形相似，测试不彻底、不充分，没有各种接口参数、各类接口数据进行充分测试。如果系统的架构的层次不清楚，这种问题会更严重。目强许多开放系统都支持API，其集成测试的内容就更多了，除了API手册的内容正确性验证之外，还要模拟用户调用API的各种Scenario，后者在编程技术、对产品的各类应用要很好掌握，才能做好测试。

第12回 功能测试和适用性测试的标准

软件的功能测试往往被认为是测试中的相对简单工作，缺乏技术，只是"Mouse-driven"。实际上，软件功能测试，一方面依赖于不断积累的的经验，另方面功能测试也是离不开技术，包括环境设置、功能实现的理解。如果结合测试自动化、白盒或灰盒测试方法等，测试的效率会更高。

适用性测试，往往可以和 功能测试结合起来做。但适用性主要是用户体验的评估活动，需要外部不同的各类人员参加。用户体验，对软件的生命力、市场影响和客户满意度的影响是非常重要的，越来越受到企业的重视。在微软公司，就设立了12个专门用于适用性的测试。在国外，也有专业公司（如 UE Group - http://www.theuegroup.com/, Genesis - http://www.genesishci.com/）帮助软件企业运作适用性测试，组织大量的、不同的用户进行体验测试。

功能测试一般须在完成集成测试后进行，而且是针对应用系统进行测试。功能测试是基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否都能正常使用、是否实现了产品规格说明书的要求、是否能适当地接收输入数锯而产生正确的输出结果等。功能测试，包括用户界面测试、各种操作的测试、不同的数据输入、逻辑思路、数据输出和存储等的测试。对于功能测试，针对不同的应用系统，其测试内容的差异很大，但一般都可归为界面、数据、操作、逻辑、接口等几个方面，如：

• 程序安装、启动正常，有相应的提示框、适当的错误提示等；
• 每项功能符合实际要求；
• 系统的界面清晰、美观；菜单、按钮操作正常、灵活，能处理一些异常操作；
• 能接受正确的数据输入，对异常数据的输入可以进行提示、容错处理等；
• 数据的输出结果准确，格式清晰，可以保存和读取；
• 功能逻辑清楚，符合使用者习惯；
• 系统的各种状态按照业务流程而变化，并保持稳定；
• 支持各种应用的环境，能配合多种硬件周边设备，与外部应用系统的接口有效；
• 软件升级后，能继续支持旧版本的数据

软件产品以软件的客户为出发点，好的用户界面，除了正确性和实用性之外，还包括另外5个要素：符合标准和规范、直观性、一致性、灵活性、舒适性、。

1. 符合标准和规范：软件在现有的平台上运行，通常标准是已经确立的（如MAC或者WINDOWS），这些规则和约定也是功能测试的依据。这些标准和规范是在大量实践基础上、随着时间而沉淀下来的、方便用户的各种规则和约定，如软件菜单格式、快捷键、复选框和单选按钮的界面，使用提示信息、警告信息或者严重警告信息等特定场合。

2. 直观性：首先了解所需的功能或期待的响应明显，并在预期的地方出现。其次要考虑用户界面的组织和布局是否合理、界面是否洁净、不拥挤以及是否有多余的功能，是否太复杂难以掌握等因素。

3. 一致性：软件自身的一致性以及软件与其他软件的一致性。字体和界面的各元素风格是否一致是比较容易判定的，而较难的一致性判断体现在用户操作方式上。用户习惯于将某一程序的操作方式带到另一个程序中使用。例如在WINDOWS平台客户已经习惯用Ctrl+C表示复制操作的，而在软件中将复制操作的快捷键定义为其它键，必定会给用户造成挫败感，难以接受。

4. 灵活性：软件可以选择不同的状态和方式，完成相应的功能。但灵活性也可能发展为复杂性，太多的状态和方式的选择增加的不仅仅是用户理解和掌握的困难程度。多种状态之间的转换，增加了编程的难度，更增加了软件测试的工作量。

5. 舒适性：人们对舒适的理解各不相同，但总体上要求恰当的表现、合理的组织、色调和谐、必要的提示或等。

第13回 负载、性能测试和容量测试的关系和区别

对于软件应用系统，仅仅从功能上满足用户的需求是不够的，还需要从性能、可用性等方面更好地满足客户的需要。

尤其对于实时软件系统、嵌入式系统和在线服务系统，这方面要求更高些。这就要求我们要做好系统的压力测试、性能测试、容量测试，以保证系统能提供良好的高性能、高可用性，让客户满意。

1．强度测试或压力测试

强度或压力测试是在一种需要异常数量、频率或资源的方式下，执行可重复的负载测试，以检查程序对异常情况的抵抗能力，找出性能瓶颈。异常情况,主要指那些峰值、极限值、大量数据的长时间处理等，包括：

• 连接或模拟了最大（实际或实际允许）数量的客户机；
• 所有客户机在长时间内执行相同的、性能可能最不稳定的重要业务功能；
• 已达到最大的数据库大小，而且同时执行多个查询或报表事务
• 当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；
• 运行可能导致虚存操作系统崩溃或大量数据对磁盘进行存取操作的测试用例等。

压力测试可以分为稳定性测试和破坏性测试：

• 稳定性压力测试。在选定的压力值下，持续运行24小时以上的测试。通过压力测试，可以考察各项性能指标是否在指定范围内，有无内存泄漏、有无功能性故障等。
• 破坏性压力测试。在压力稳定性测试中可能会出现一些问题，如系统性能明显降低，但很难暴露出其真实的原因。通过破坏性不断加压的手段，往往能快速造成系统的崩溃或让问题明显的暴露出来。

在压力测试中，会给程序加上一些跟踪机制（如log、日志等），然后查看监视系统、服务器等性能的日志文件是必要的，找出问题出现的关键时间或检查测试运行参数，通过分析问题或参数从而有目的地调整测试策略或测试环境，使压力测试结果真实地反映出软件的性能。

2．性能测试

系统的性能指标，一般赢在产品需求文档中有明确定义，有三种形式描述软件系统的性能指标：

• 给出产品性能的主要指标，如在100000记录中查询一个特定数据的时间为0.5秒。
• 以某个已发布的版本为基线，如比上一个版本的性能提高30-50%。
• 和竞争对手的同类产品比较。

性能测试，根据其目的分为：

• 产品性能质量测试，通过测试，决定产品是否达到产品规格书所要求的性能指标（非功能性需求）
• 基准值测试，通过对当前产品的性能测试，确定产品具体的性能指标，建立性能指标基准。基准值，作为后继产品发布的性能参考（在新版本中，性能指标要求只升不降）或和竞争对手产品比较的参考。
• 性能规划测试，通过不断的测试，确定所需要的硬件配置（内存、CPU、网络等）、软件配置，以满足实现定义的性能指标要求。这种测试，对于软件系统的部署是非常有意义的。同时，也可以进一步了解硬件参数、软件参数对系统性能的影响程度，从而保证系统具有很好的扩充性或事先制定较好的系统增容的计划。

性能测试的方法，主要有：

• 稳定压力加载，一次性将负载加到某个水平，持续一段时间，也称为flat测试。
• 逐渐加载或交替加载到某个负载水平，也称为“ramp-up”测试。
• 峰谷测试，确定从系统高峰时间的负载转为几乎空闲、再攀升到高负载这样峰值交替情况下的系统性能状态/指标。这种测试兼有容量测试的特点或属于容量测试的一部分。

性能测试，一般都通过测试工具来模拟人为的操作而进行。性能测试的重点在于测试环境的建立、前期数据的设计与后期数据的分析。因为性能测试需要获得一定特定条件下(如100、200、500、1000个实时的连接)的系统占用资源（CPU、内存等）数据或系统行为表现，而且还要依靠测试工具或软件系统记录下这些指标变化的数据结果。例如，如果对一个Browser/Server结构的网络实时在线的培训系统软件进行测试，系统性能焦点是在不同数量的并发连接下，服务器的CPU、内存的占用率、客户端的响应时间等，如表1所示。

表1 HTTP连接性能表

测试过程中，并发连接的不断增加（负载的增加）在系统性能上的表现越来越明显。在系统性能测试时，加载过程中，每到一个测试点时须让系统平稳运行一段时间后再获取数据，以消除不同测试点的相互影响。从表中可以看出，同样是300个用户，1′300与60′5的性能表现差别很大，加载的方式对系统性能影响也较大，所以，尽量模拟不同的加载方式来进行系统的性能测试。除此之外，还可以测试TCP、HTTPS等不同连接方式下的数据,进行比较。通过比较和分析，可以清楚知道系统的性能状况，以及什么样的条件下系统性能达到最佳状况、什么地方是性能的瓶颈。性能测试要求测试环境应尽量与产品运行环境保持一致，应单独运行，尽量避免与其他软件同时使用。

3．容量测试

通过性能测试，如果找到了系统的极限或苛刻的环境中系统的性能表现，在一定的程度上，我们完成了负载测试和容量测试。容量可以看作系统性能指标中一个特定环境下的一个特定性能指标，即设定的界限或极限值。

容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。对软件容量的测试，能让软件开发商或用户了解该软件系统的承载能力或提供服务的能力，如某个电子商务网站所能承受的、同时进行交易或结算的在线用户数。知道了系统的实际容量，如果不能满足设计要求，就应该寻求新的技术解决方案，以提高系统的容量。有了对软件负载的准确预测，不仅能对软件系统在实际使用中的性能状况充满信心，同时也可以帮助用户经济地规划应用系统，优化系统的部署。

4．压力测试、容量测试和性能测试的关系

压力测试可以看作是容量测试、性能测试和可靠性测试的一种手段，不是直接的测试目标。压力测试的重点在于发现功能性测试所不易发现的系统方面的缺陷。而容量测试和性能测试是系统测试的主要目标内容，也就是确定软件产品或系统的非功能性方面的质量特征，包括具体的特征值。容量测试和性能测试更着力于提供性能与容量方面的数据，为软件系统部署、维护、质量改进服务，并可以帮助市场定位、销售人员对客户的解释、广告宣传等服务。

压力测试、容量测试、性能测试，测试的方法相似、相通，在实际测试工作中，往往结合起来进行，以提高测试效率。一般会设置专门的性能测试实验室，完成这些工作。即使用虚拟的手段模拟实际操作，所需要的客户端有时还是很大的，所以性能测试实验室的投资较大。对于许多中小型软件公司，可以委托第三方完成性能测试，可以很大程度上降低成本。

第14回 容错性测试和安全性测试

容错性测试和安全性测试容易被忽视，但这两项测试越来越现实其重要性，容错性对系统的稳定性、可靠性影响很大，而随着网络应用、电子商务、电子政务等越来越普及的同时，安全性越来越重要。容错性测试和安全性测试，相对来说，是比较难的，需要得到足够关注，需要得到设计人员、开发人员的更多参与。

1．容错性测试

容错性测试包括两个方面的测试：

• 输入异常数据或进行异常操作，以检验系统的保护性。如果系统的容错性好的话，系统只给出提示或内部消化掉，而不会导致系统出错甚至崩溃。
• 灾难恢复性测试。通过各种手段，让软件强制性地发生故障，然后验证系统已保存的用户数据是否丢失、系统和数据是否能很快恢复。

关于自动恢复测试，需验证重新初始化、检查点、数据恢复和重新启动等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。
从容错性测试的概念可以看出，容错测试是一种对抗性的测试过程。要测试软件出现故障时，如何进行故障的转移与恢复有用的数据。故障转移（Failover）是确保测试对象在出现故障时，能成功地将运行的系统或系统某一关键部分转移到其它设备上继续运行，即备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务，不影响用户的使用。要进行故障转移的全面测试, 一个好的方法是将测试系统全部对象用一张系统结构图描绘出来, 对图中的所有可能发生的故障点设计测试用例。例如，系统设计架构图中，如果存在单点失效的关键对象，就是设计的重大缺陷。

2．安全性测试

在进行安全测试时，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如：

• 想方设法截取或破译口令；
• 专门开发软件来破坏系统的保护机制；
• 故意导致系统失败，企图趁恢复之机非法进入；
• 试图通过浏览非保密数据，推导所需信息等等。

安全性一般分为两个层次，即应用程序级别的安全性和系统级别的安全性，针对不同的安全级别，其测试策略和方法也不相同：

• 应用程序级别的安全性，包括对数据或业务功能的访问，在预期的安全性情况下，操作者只能访问应用程序的特定功能、有限的数据。其测试是核实操作者只能访问其所属用户类型已被授权访问的那些功能或数据。测试时，确定有不同权限的用户类型，创建各用户类型并用各用户类型所特有的事务来核实其权限，最后修改用户类型并为相同的用户重新运行测试。
• 系统级别的安全性，可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问，包括对系统的登录或远程访问。其测试是核实只有具备系统和应用程序访问权限的操作者才能访问系统和应用程序。

第15回 回归测试的风险性和有效性之平衡策略

在软件生命周期中，会由于增加新的功能或增强原有的功能、修正所发现的缺陷而修改软件，一旦软件被修改了，就可能引起新的缺陷，使原来工作正常的功能出现了问题。回归测试的目的就是在程序有修改的情况下保证原有功能正常的一种测试策略和方法，因为这时的测试一般不需要进行从头到尾的全面测试，而是根据修改的情况和由修改引起的影响面来进行有效的测试。另一方面看，由于扩充和维护的测试用例库可能变得相当庞大，每次回归测试都重新运行完整的测试用例包变得不切实际，时间和成本约束也不允许。所以，需要根据软件修改所影响的范围，从测试用例库中选择相关的测试用例，构造一个优化的测试用例组来完成回归测试。

回归测试的价值在于它是一个能够检测到回归错误的受控实验。当测试组选择缩减的回归测试时，有可能忽略了那些将揭示回归错误的测试用例，而错失了发现回归错误的机会。然而，如果采用了代码相依性分析等安全的缩减技术，就可以决定哪些测试用例可以被删除而不会影响回归测试的结果。选择回归测试方法应该兼顾测试风险（覆盖面）和有效性两个方面，根据项目实际情况，达到平衡。

• 基于风险选择测试，基于一定的风险标准来从测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试，而跳过那些次要的、例外的测试用例或那些功能相对很稳定的模块。运行那些次要用例即便发现缺陷，这些缺陷的严重性也较低。
• 基于操作剖面选择测试。如果测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。
• 再测试修改的部分。当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及被修改的或新加的代码。在允许的条件下，回归测试尽可能覆盖受到影响的部分。这种方法可以在一个给定的预算下最有效的提高系统可靠性，但需要良好的经验和深入地代码分析。

回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都可能需要进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极限编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。

第16回 不容忽视的安装或部署测试

安装测试是指按照软件产品安装手册或相应的文档，在一个和用户使用该产品完全一样的环境中或相当于用户使用环境中，进行一步一步的操作完成安装的过程所进行的测试。

安装测试可以分为

• 全新安装，待安装的软件包是完整的，包含了所有的文件。
• 升级版本安装，部分文件构成的软件包。
• 补丁式安装，很小的改动或很少文件的更新，软件版本不变
• 系统运行环境改变，性能调优，只改参数，没有软件文件的变化。

即使对升级安装，实际也是有差别的，一种是完全替换原来版本，另外一种就是保持多种版本共存，后者的难度会更大些。不管是哪一种情况，用户数据得到保护，包括完整性、一致性的验证，是非常重要的。系统迁移，也可以并入安装测试。安装测试也可以根据软件所属特征来划分：

• 客户端软件安装
• 服务器安装
• 整个网络系统安装

安装测试主要进行以下三个方面的测试：

• 环境的不同设置或配置：强调用户的使用环境，考虑各种环境的因素的影响，如一个完全崭新的、非常干净的操作系统或应用系统之上去进行某个产品的安装，或者是考虑各种硬件借口的要求。
• 安装文档的准确性。进行安装测试时，必须一步一步地完全按照文档去做（如拷贝文档指令，粘贴到系统安装相应地方），不能下意识地使用已有的经验去纠正安装不对的地方。
• 安装的媒体制作是否有问题，包括最后制做时可能会丢了一个文件，或感染上计算机病毒等。

安装测试有时容易被忽略，如果没做好，其损失依然很大，如必须换回全部安装盘、或重印安装手册、或加重技术支持负担，所以安装测试也是重要的一个测试阶段。

软件部署逻辑、物理设计完成后，必须通过验证才能进入实施阶段。部署设计的验证首先是在实验室环境中进行，也就是和软件的系统测试结合起来做，包括性能测试、安装测试等，这被称为软件部署的试验性系统验证。实验室环境还不是真正产品运行的环境，部署设计的进一步验证需要在实际的运行环境中进行，这就是原型系统的验证。Beta测试，将系统（试用版）有限地部署给选定的一组用户，以确定其能否满足业务要求，所以可以被看作原型系统验证的一部分。

软件部署的试验性系统和原型系统验证完成之后，实际也宣告了软件部署的实施结束。软件部署的验证和实施的过程一般包括以下步骤：

• 开发试验性系统 (构建网络和硬件基础结构、安装和配置相关的软件)
• 根据测试计划/设计执行安装测试、功能测试、性能测试和负载测试
• 测试通过，开始规划原型系统
• 完成原型系统的网络构建、软硬件的安装和配置
• 数据备份或做好可以恢复(Roll-back)的准备
• 将数据从现有应用程序迁移到当前解决方案
• 根据培训规划,培训部署的管理员和用户
• 完成所有的部署

在这些过程中，保证系统和用户数据的不丢失是非常重要的，大家都知道，数据比系统更为重要。

部署测试的进一步说明

试验性部署测试和原型部署测试的目的是，在测试条件下尽可能确定部署是否既能满足系统要求，又可实现业务目标。理想情况下，功能性测试可以模拟各种部署方案以完成所需要执行的测试用例，并且定义相应的质量标准来衡量其符合性。负载测试衡量在峰值负载下的测量性能，通常使用一系列模拟环境和负载发生器来衡量数据吞吐量和性能。对于没有明确定义、缺乏原始数据积累的全新系统，功能性测试和负载测试尤其重要。

通过测试能够发现部署设计规范存在的问题，可能需要返回先前的部署设计阶段，重新设计或修正设计，再进行试验性部署测试，直至没有问题，才向原型系统展开部署。测试原型部署时，也可能会发现部署设计中存在问题，同样需要返回先前的部署设计阶段。如果发生这种情况，其代价相当大，并严重影响产品发布的时间表。所以，软件部署设计的评审是非常重要的，应避免任何严重设计的问题被忽视。这样，试验性部署测试和原型部署测试所发现的问题，就可以通过软硬件的配置调整就可以解决，如增加内存、参数修改等。

实际运行系统的部署，通常分阶段进行，有助于隔离、确定和解决服务可能在实际运行环境中遇到的问题，特别是对会影响大量用户的大型部署具有尤其重要的意义。分阶段部署可以先向一小部分用户部署，然后逐步扩大用户范围，直至将其部署给所有用户。分阶段部署也可这样进行：先部署一定类型的服务，然后逐步引入其余类型的服务。所以，软件实际运行系统的部署过程被分为两个重要阶段LA ( Limited Available)和GA ( General Available)。由于测试永远不可能完全模拟生产环境，并且已部署解决方案的性质会发生演进和改变，因此应继续监视部署的系统，以确定是否有需要调整、维护或修补的部分。