软件设计实现与测试
设计与实现
设计与实现的关系：软件设计和实现活动一般总存在重叠。软件设计是一个创造性的活动。
有时候会有一个独立的设计阶段，其中的设计会被 建模和文档化。而其他时候设计会存在于程序员的脑海中，或只是在白板或纸上大致地用草图画一下。设计和实现密切联系在一起，将设计和实现放在一起考虑。
7.1使用UML的 面向对象设计
一个面向对象系统由相互交互的对象组成。对象同时包括数据以及操纵这些数据的操作.现实世界实体和它们在系统中的控制对象之间经常存在清晰的映射。
从概念到详细的面向对象设计，需要做哪些事情?这几种设计的关系是什么？
1理解并定义上下文以及与系统外部的交互;（系统和环境之间的关系）2设计系统体系结构；（构建之间的关系）3识别系统中的主要对象；（识别通用对象类）4开发设计模型；（系统对象之间的静态、动态关系）5刻画接口。（构建之间的接口设计）
1、上下文交互
任何软件设计过程的第一个阶段都是理解所设计的软件与它的外部环境之间的关系。为什么这么重要？1、可以据此决定如何提供所需要的系统功能2、可以据此决定如何对系统进 行组织从而与环境进行通信3、理解上下文还可以帮助建立系统边界
上下文模型和交互模型的视图的关系：系统上下文模型和交互模型所呈现的关于系统及其环境之间关系的视图是互补的。上下文模型是一种结构化模型，其中展示了所开发的系统的环境中的其他系统。交互模型是一种动态模型，其中显示系统在使用时如何与环境进行交互。
一个系统的上下文模型可以使用关联来表示。
可以使用简单的框图来描述系统的环境。
系统与其环境之间的交互进行建模时可以使用抽象方法——用况模型。用况中的每一个都应当使用结构化自然语言进行描述。这有助于设计人员识别系统中的对象并让他们理解系统意图要做什么。
1、体系结构设计
需要识别构成系统的主要构件以及它们之间的交互，然后要使用一种体系 结构模式（例如，分层或客户-服务器模型）来设计系统的组织结构。
“监听器模型”是一种广泛使用的分布式系统体系结构风格，当通信子系统收到一个控制命令（例如关闭）时，其他每个子系统也将获得该命令, 这些子系统接收者会执行命令（例如，按照正确的方式关闭自身）。这一体系结构的关键优点是很容易支持不同的子系统配置，因为一条消息的发送者不需要指定接收该消息的特定子系统。
2、对象类识别
在设计过程的这个阶段之前，关于你所设计的系统中所包含的重要对象你应该已经有了一些想法。脑海中有了这些对象之后，便可以开始识别系统中的通用对象类。随着20世纪80年代的面向对象设计的发展，出现了不同的识别面向对象系统中对象类的方法。
识别对象类的方法：1.对所要构建的系统的自然语言描 述进行语法分析。对象和属性是名词; 操作和服务是动词。2.使用应用领域中有形的实体或事物、角色、事件、交互、位置、组织单元等。3.使用一种基于场景的分析方法，其中依次识别并分析系统使用的各种场景。
对象类识别：先识别（在这个设计过程阶段中，你应当关注对象自身，不需要考虑这些对象要如何实现。），再精化（一旦识别出这些对象后，可以再对这些对象设计进行精化。你会发现共性的特征，然后为系统设计继承层次）
3、设计模型
设计或系统模型，展示了一个系统中的对象或者对象类，还展示了这些 实体之间的关联和关系。一个设计模型所需要的详细程度取决于开发人员所使用的设计过程。敏捷开发用白板即可，基于计划的开发过程则需要详细的模型。
设计模型阶段重要的两件事：1、选模型2、决定详细程度
当使用UML来开发一个设计时，应当开发以下两类设计模型即可：
4、接口规格说明
设计接口的作用：使得对象和子系统可以并行设计。
接口在UML中可以用类图一样的表示法来刻画。然而，接口没有属性部分, 而名称部分应当包含UML构造型(sterotype)《interface》
接口中没有属性，只有操作
7.2设计模式
模式：是一种对于问题及其解决方案的本质的描述，从而使得解决方案可以在不同的环境中进行复用。是一种对于逐渐积累的智慧和经验的描述, 是一种对某个共性问题的经过成功尝试的解决方案。
模式中封装经验这一通用原则适用于任何类型的软件设计。面向对象设计的模式经常依赖于继承和多态等对象特征。
模式的四种基本元素：1、模式名称2、问题描述（动机、适用用性）3、解决方案（模式结构、参与者、结构、实现）4、效果
模式的分类：1、观察者模式。向多个对象告知一些其他对象的状态发生了 变化
2、门面模式。整理面向一些相关的且经常是增量地开发出 来的对象的接口
3、迭代器模式。为一个合集(collection)中的元素提供一种标 准的访问方式，不用考虑合集是如何实现的
4、装饰者模式。允许在运行时扩展一个已有的类的功能
观察者模式：定义对象间一种一对多的依赖关系，使得当每一个对象改变状态，则所 有依赖于它的对象都会得到通知并自动更新。
场景举例:在软件系统中经常会有这样的需求：如果一个对象的状态发生改变，某些与它相关 的对象也要随之做出相应的变化。比如，我们要设计一个自动部署的功能，就像 eclipse开发时，只要修改了文件，eclipse就会自动将修改的文件部署到服务器中。 一个对象要时刻监听着另一个对象，只要它的状态一发生改变，自己随之要做出相 应的行动。能够实现这一点的方案很多，但是使用观察者模式是一个主流的选择。
描述：将一个对象的状态的呈现与对象本身分开，允许为对象提供不同的呈现方式。当对象状态变化时，所有的呈现 都会自动得到通知并进行更新以反映变化。
问题描述：在很多情况下你都必须为状态信息提供多种呈现方式，例如，一个图形化呈现方式和一个表格呈现方式。 这些呈现方式再对信息进行规格说明时并不都是已知的。所有不同的呈现方式都应该支持交互，在状态发生变化时所 有呈现都必须更新。
这个模式的使用情形是，状态信息需要不止一种呈现方式，并且维护状态信息的对象不需要知道所使用的特定的呈 现格式。
解决方案描述：解决方案包括两个抽象对象Subject （主题，即被观察者）和0bject （观察者），以及两个继承了相 关抽象对象属性的具体对象ConcreteSubject （具体主题）和ConcreteObserver（具体观察者）。抽象对象包括适用于所 有情形的通用操作。需要呈现的状态在ConcreteSubject中进行维护，该对象继承了 Subject的操作从而允许该对象增加 和移除观察者（每个观察者对应一种呈现方式）以及在状态发生变化时发出通知。
ConcreteObserver维护了 ConcreteSubject状态的一份拷贝，并且实现了 Observer的Update。接口，该接口允许这些拷贝能 够被同步更新。ConcreteObserver自动呈现状态并在任何时候当状态更新时自动反映变化。
该模式的UML模型如下图所示。
影响：主题对象只知道抽象的观察者对象，而不知道具体类的细节。因此，这些对象之间的耦合被最小化了。由于缺 少这些知识，提高呈现性能优化可能无法实现。对主题对象的变化可能导致生成与之相关的针对观察者的一组更新， 而其中一些可能并没有必要。
存在的问题：1、很难提前知道是否会需要某个特定的模式。因此，在设计过程中使用模式经常要经过开发设计、体验问题、然后认识到可以使用某个模式 的过程。
2、模式是伟大的思想，但是为了有效地使用它们还需要一些软件设计经验。没有经验的程序员，即使他们已经读过模式的书，也总是会发现很难决定是否可以复用某个模 式或者是否需要开发一个特殊目的的解决方案。
复用可执行的构件时-受约束和限制，复用模式时思想的复用，没有那么多限制。
7.3实现问题
位置：系统实现是软件工程过程中的一个关键阶段，作用是创建软件的一 个可执行版本。
系统实现的两种方式:1、使用高层或底层编程语言开发程序。2、对通用的成品系统进行裁剪和适配以满足一个组织的特定需求
复用：件复用可以在多个不同的级别上发生
复用的好处：1、更快地开发系统2、风险和成本降低3、比新软件个不可靠
如何复用已有的知识和软件应当是 在开始一个软件开发项目时要考虑 的第一件事情
成本：1、时间成本。寻找可复用的软件以及评价其是否满足 需要所花费的时间成本2、金钱成本。在适用的情况下，购买可复用软件的成本3、集成成本。可复用软件元素相互之间集成（如果你正在使用不同来源的软件）以及与所开发的新代码相集成的成本。4、配置成本。适配和配置可复用软件构件或系统以反映正在开发的系统的需求的成本。
配置管理：配置管理是管理一个不断变化的软件系统的一般过程。
配置管理的目的是支持系统集成过程以使所有的开发者都可以（1）以一 种受控的方式访问项目的代码和文档，（2）找出代码和文档做了哪些修改，（3）以及对构件进行编译和链接来创建一个系统。
四个基本配置管理活动：1、版本管理：SVN、Git等工具。2、系统集成：GNU。3、问题追踪：Bugzilla。4、发布管理。
宿主机—目标机：
有时候，开放平台和执行平台是一样的，如Java开发；有时候，开放平台和执行平台是不一样的，如嵌入式系统和移动系统
开发平台上一般需要哪些工具来支持软件工程过程？
1. 一个允许开发人员创建、编辑和编译代码的集成编译器以及语法制导的 编辑系统；
2. 一个语言调试系统；
3. 图形化编辑工具，例如编辑UML模型的工具；
4. 可以自动在程序的新版本上运行一组测试的测试工具，例如JUnit；
5. 支持重构和程序可视化的工具；
6. 管理源代码版本以及集成和构建系统的配置管理工具。
部署时的问题：一、嵌入式系统：目标机就是单台计算机，很直观
二、分布式系统：相关构件部署到哪些特定平台上需要考虑以下问题：1、一个构件的硬件和软件需求2、系统的可用性需求3、构件通信
7.4开源开发
开源开发是一种软件开发方法，其中软件系统的源代码被公开并邀请志愿者参加开发过程。假设：代码将由一个小的核心小组而不是代码的用户进行控制和开发。在实践中，成功的开源系统仍然依赖于一个核心开发人员小组来控制软 件的变更。
举例：Linux系统、Java、Eclipse、Tomcat、MySQL、等
使用开源程序的好处:1、便宜甚至免费2、非常稳定
大多数成功的开源产品都是平台产品而不是应用系统，为什么？ 发布一个系统的源代码并不意味着来自更大范围内的社区的人们将要帮助进行开发, 因为可能对专业的应用系统感兴趣的开发者数量有限。
虽然开源软件开发的一个基本原则是，源代码应当是免费提供的，但是这并不意味着任何人都可以随心所欲地处置这些代码。
开源许可证：1、GPL如果你使用GPL许可 证下的开源软件，那么你必须让你的软件开源。2、LGPL编写链接到开源代码的构件而不用发布这些构件的源代码；修改了开源构件则需要发布3、BSD可以在所销售的私有系统中包含这些代码。如果你使用了开源构件，你必须承认这些代码最初的创造者
使用了开源代码的项目应做到以下几点:
1、建立一个系统来维护关于所下 载和使用的开源构件的信息
2、了解不同类型的许可证
3、了解构件的演化路径
4、进行关于开源软件的教育
5、建立审计系统
6、参与开源社区
软件测试
确认测试和缺陷测试之间的区别：确认测试，使用一组反映系统的期望使用方式的测试用例来测试系统是否正确运行。缺陷测试中优先考虑的是找到Ie中的输入，因为这些输入揭示了系统中的问题。缺陷测试，设计测试用例来暴露缺陷。确认测试包含使用Ie之外的正确输入的测试。
确认、验证和测试之间的关系：测试是更广阔的软件验证和确认(Verification andValidation,V&V)过程的一部分;软件验证是检查软件是否满足其所声明的功能性和非功能性需求的过程;确认的目的是确保软件满足客户的期望。（确认的东西要超出规格说明的内容，因 为需求陈述并不总是反映系统客户和用户的真实愿望或需要）
测试的目的：验证和确认过程的目的是建立软件系统“符合目的”的信心。 所需要的信心水平取决以下三个因素：1、软件目的。软件越关键，它的可靠性越重要。2、用户期望。随着一个软件产品的位置逐渐巩固，用户会期望它变得越来越可靠。3、市场环境。便宜甚至是免费、没有竞争对手时，用户可能会容忍较低的可靠水平。
审查和评审：除了软件测试，验证和确认过程还可以包括软件审查（inspection）和评审（review）。审查和评审分析并检查系统需求、设计模型、程序源代码，甚至所建议的系统测试。这些都属于“静态的”验证和确认技术，其中不需要执行软件来进行验证。
审查和测试：
审查的优势：与测试相比软件审查有如下3个优势：1、在测试过程中，一个错误可能会掩盖（隐藏）其他错误。一次审查会议可能会发现一个系统中的很多错误。2、一个系统的不完整版本可以在不需要额外成本的情况下进行审查。如果一个程序是不完整的，那么需要开 发特殊的测试装置来测试已有的部分。3、除了查找程序中的缺陷之外，审查还可以考虑范围更广阔的程序质量属性，例如，与标准的符合性、可移植性、可维护性等。
程序审查是一个比较老的思想，一些研究和实验已经表明审查在缺陷发现方面比程序测试更有效。
审查无法取代软件测试。审查不善于发现由于程序的不同部分之间的非预期交互、时间性问题或者系统性能上的问题而导致的缺陷。
一个商业化软件系统必须经历以下3个测试阶段：1、系统在开发过程中进行测试以发现bug和缺陷。（开发测试）2、一个独立的测试团队在系统发布给用户之前测试系统的完整版本。3、一个系统的用户或潜在的用户在他们自己的环境中测试系统。（用户测试）
开发测试：
开发测试含义：开发测试包括由开发系统的团队所执行的所有测试活动。
开发测试测试者：通常情况下是程序员，更加正式时有一个独立的测试小组。
开发测试阶段：开发测试包括如下3个阶段：1、单元测试。对各个程序单元或对象类进行测试。单元测试应当关注测试对象或方法的功能。2、构建测试。对多个不同的单元进行集成以创建一个复合构件。构件测试应当关注测试提供对构件功能的访问的构件接口。3、系统测试。对一个系统中的一些或全部构件进行集成并将系统作为一个整体进行测试。系统测试应当关注测试构件的交互。
一、单元测试：单元测试是测试程序构件（例如，方法、对象类）的过程。各个函数或方法是构件的最简单的形式。测试应当用不同的输入参数来调用这些程序。在测试对象类时，应当设计测试来实现对该对象所有特征的覆盖。测试所有操作、所有属性，这意味着应当模拟导致状态变更的所有事件。泛化或继承使得对象类的测试更加复杂。为了测试一个类的状态，可以使用状态图辅助测试。从原则上讲，应当测试每种可能的状态转换序列（即状态图的路径覆盖），虽然在实践中这可能相当昂贵。
只要有可能都应当尽量自动化单元测试。在自动化单元测试中，可以使用一个测试自动化框架，例如JUnit来编 写并运行程序测试。
一个自动化测试包括以下3个部分：1、设置部分。按照当前测试用例（即输入和期望输出）对系统进行初始化。2、调用部分。调用要进行测试的对象或方法。3、断言部分。将调用的结果与所期望的结果进行比较。如果断言结果是真，那么测试是成功的。
有时候你测试的对象会依赖于其它还没有实现的对象，或者调用数据库很慢，怎么办？------可以使用Mock对象。Mock对象与所模拟的外部对象具有同样的接口。访问这些Mock对象很快，不存在调用数据库和访问磁盘带来的额外开销。与之相似，Mock对象可以被用于模拟异常操作或稀有事件。
二、选择单元测试用例：测试很昂贵并且很耗时间，因此选择有效的单元测试用例是很重要的。 这里的“有效”意味着两件事情：1、测试用例应当显示出，当按照期望的方式使用时正在测试的构件做了期望它做的事情；2、如果构件中存在缺陷，那么测试用例可以揭示这些缺陷。
两种选择测试用例的策略：1、划分测试。识别出各个具有共同特性并且应当以同样的方式处理的输入分组。你应当从这些分组中的每一个中都选择测试用例。2、基于指南的测试。使用测试指南来选择测试用例。这些指南反映了程序员在开发构件时经常会犯的错误的经验。
等价划分的假设：
一个程序的输入数据和输出结果可以看作是具有共同特性的集合成员（如，整数、负数、菜单选择）。程序通常对一个集合中的所有成员都表现出近似的行为。由于这种等价行为，这些类有时候被称为“等价划分”（equivalence partition）或“等价域”。
一个关于测试用例选取的有效经验法则是，选取划分边界上的测试用例，再加上靠近划分中点的测试用例。其原因是设计者和程序员在开发一个系统时倾向于考虑典型的输入值。这些值可以 通过选取划分的中点来进行测试。边界值经常是非典型的。程序经常会在处理这些 非典型的值时发生错误。
黑盒测试：可以通过使用程序规格说明或用户文档，并且根据预测哪种类型的输入值最有可能发现错误的经验来识别划分。当使用一个系统规格说明来识别等价划分时，可以称为“黑盒测试”。
测试指南：指南封装了关于何种类型的测试用例能够有效发现错误的知识。例子：当你测试带有序列、数组或列表的程序时，可以帮助发现缺陷的指南通常包括以下这几项：1、使用只有单个值的序列来测试软件。2、在不同的测试中使用多个大小不同的序列。3、考虑让测试访问到序列中最前面、中间、最后面的序列。
一些通用的指南包括：1、选择迫使系统生成所有错误消息的输入；2、设计导致输入缓冲溢出的输入；3、多次重复同样的输入或输入序列；4、驱使生成非法的输出；5、驱使计算结果太大或太小。
三、构建测试
软件构件经常由多个经常由多个相互交互的对象组成。
测试复合构件应当关注显示构件接口的行为与其规格说明相一致。可以假设针对构件中的各个对象的单元测试都已经完成了。
假设构件A、B和C已经被集成到一起以创建一个更大的构件或子系统。测试用例并不是应用于单个构件而是通 过组合这些构件形成的复合构件的接口。
程序构件之间存在不同类型的接口，容易发生错误的接口的类型：1、参数接口。数据或者函数引用从一个构件传递到另一个。2、共享存储接口。构件之间共享一块存储。数据由一个子系统放在存储中，其他子系统从那里读取数据。3、过程式接口。一个构件封装了一组可以由其他构件调用的过程。对象和可复用构件有这种形式的接口4、消息传递接口。一个构件通过传递消息来从另一个构件那里请求获得服务。客户-服务器系统也是这样。
接口错误是复杂系统中最常见的一种错误形式之一。这些错误包括以下3种类型：1、接口误用2、接口误解。一个调用构件误解了所调用构件的接口的规格说明，并对它的行为做出了假设。所调用的构件行为与预期不符，从而导致调用构件中的非预期行为。3、时间性错误。这些错误在使用共享存储或消息传递接口的实时系统中发生。数据的生产者和消费 者可能以不同的速度运行。
接口测试指南：1、取值范围的极限边界的值可能解释接口的不一致性2、对于任何在接口上传递的指针，总是使用空指针参数测试接口3、过程接口调用时，设计故意导致构件失效的测试4、在消息传递系统中使用压力测试5、多个构件共享存储交互时，设计改变这些构件被激活的顺序的测试
有时候使用审查和评审而不是测试来寻找接口错误会更好。
四 、系统测试
开发过程中的系统测试包括集成构件以创建一个系统版本，然后测试集成后的系统。系统测试检查构件是否兼容、是否能正确交互，以及是否 能在正确的时间跨越接口传输正确的数据。系统测试显然与构件测试存在重叠。
在有些企业中，会由一个独立的没有参加过该系统设计和实现的测试团队来进行系统测试。
所有系统都有一些涌现性的行为。这意味着一些系统功能和特性只有当把构件放到一起时才会显现出来。
系统测试应当关注测试构成一个系统的构件和对象之间的交互，还可能会在可复用构件或系统与新构件集成时对它们进行测试，以确认它们是否如预期的一样运作。
由于用况关注交互，因此基于用况的测试是一种有效的系统测试方法。
如果开发了一个顺序图来建模用况实现，那么可以看到参与交互的对象或构件。
顺序图帮助设计人员设计出所需要的特定的测试用例，因为它显示了需要什么样的输入以及产生什么样的输出。
对于大多数系统，彻底的测试，即对每一个可能的程序执行序列都进行测试，是不可能的。
因此，测试必须基于所有可能的测试用例的一个子集。理想情况下，软件公司应当有如何挑选这一子集的策略。如：1、通过菜单访问的所有系统功能都应该进行测试。2、通过同样的菜单访问的功能组合必须进行测试。3、在任何提供了用户输入的地方， 所有的功能必须同时使用正确的和不正确的输入进行测试。
测试驱动的开发：
测试驱动的开发（Test-driven development，TDD）是一种软件开发方法，其中将测试和代码开发交织在一起。可以增量地开发代码以及开发一组针对该增量的测试。已经开发好的代码通过所有它的测试之前，不会开始开发下一个增量。
测试驱动的开发是作为XP（极限编程）敏捷开发方法的一部分被引入的。然而，测试驱动的开发现在已经得到了主流的认同，既可以用于敏捷过程又可以用于基于计划的过程。
该过程中的步骤如下：
1首先识别所需要的功能增量。
2为这个功能编写一个测试，并且将其实现为一个自动化测试。
3接下来运行该测试以及所有其他已经实现的测试。起初还没有实现该功能，因此新的测试会失败。 这是故意而为的，因为这表明该测试向测试集中增加了一些新东西。
4然后实现该功能并重新运行测试。
5一旦所有测试运行都成功了，就可以转而实现下一个功能了。
测试驱动的开发的好处：1、问题理解：帮助程序员阐明他们关于一个代码段实际上应该做什么的想法。2、代码覆盖：原则上讲，所编写的每个代码段都应当有至少一个相关的测试。3、回归测试：测试集随着程序的开发增量进行开发。回归测试可以确认程序的修改有没有引入bug。4、简化调试：当测试失败时，问题出现在哪里会很明显。小增量，容易定位。5、系统文档化。测试自身可以作为某种形式的文档来描述代码应该做什么。
测试驱动的开发在开发新的软件时最有价值，此时功能要么在新代码中实现、要么使用来自标准库中的构件来实现。
测试驱动开发效果不好的情形：1、如果复用大的代码或遗留系统，那么需要作为一个整体为这些系统编写测试，因为很难将它们分解为不同的可测试元素，增量的测试驱动开发也就不现实了。2、测试驱动的开发对于多线程系统效果可能也不好。不同的线程在不同的测试运行中可能会在不同的时间交织在一起，因此会产生不同的结果。
测试驱动的开发评价：驱动测试的开发目前已经是一种广泛使用的主流软件测试方法。也是一种更有效的软件开发方式。
发布测试：发布测试是指对一个系统在开发团队以外进行使用的一个特定发布进行测试的过程。通常是一个黑盒测试过程。
通常，系统发布是面向客户和用户的。然而，在一个复杂的项目中，发布也可能会面向开发相关系统的其他团队，如后续会准备对其进行销售的产品管理人员。
发布测试和系统测试有以下两个重要的区别：系统开发团队不应该负责发布测试。发布测试是一个确认检查的过程，其目的是确保一个系统满足它的需求，并且运行得足够好可以由系统客户进行使用。由开发团队进行的系统测试应当关注发现系统中的bug。
系统发布的目的是让系统的供应商确信系统足够好可以使用了。
1、基于需求的测试：好的需求工程实践的一个一般原则是需求应该是可测试的。基于需求的测试是一种系统性的测试用例设计方法。基于需求的测试是一种确认而非缺陷测试——试图展示系统已经适当地 实现了它的需求。
测试一个需求并不意味着只写一条测试就够了。通常不得不编写多个测试来确保已经很好地覆盖了该需求。
2、场景测试：场景测试是一种发布测试方法，即设想出典型的使用场景并使用这些场景来为系统开发测试用例。
一个场景是一个描述了系统可能的使用方式的故事。
场景应当是现实的；应该触发利益相关者的积极性；易于评估。
在使用基于场景的方法时，通常都会在同一个场景之中测试多个需求。 因此，除了检查确认单个需求，也应检查确认这些需求的组合没有造成问题。
3、性能测试：一旦一个系统已经完成了集成，那么就可以对涌现性属性（例如性能和可靠性）进行测试了。必须设计性能测试以确保系统可以处理预计承受的负载。
跟其他类型的测试一样，性能测试既关注展示系统满足其需求又关注发现系统中的问题和缺陷。
经验表明发现缺陷的一种有效方式是围绕系统的限制设计测试。---压 力测试
用户测试：用户测试很重要，即使已经进行了全面的系统测试和发布测试，来自用户工作环境的影响可能会对一个系统的可靠性、性能、可用性和鲁棒性产生重要的影响。
有3种不同类型的用户测试：1、α测试。一组经挑选的软件用户与开发团队密切配合工作，对软件的早期发布进行测试；用户可以提供关于实践的信息，从而帮助设计出更加现实的测试。2、β测试。向一组更大规模的用户提供一个软件的发布版本，允许他们在上面进行试验，并将他们所发现的问题报告给系统开发者；利用β测试发现软件与它的运行环境特性之间的交互。β测试也可以成为某种形式的市场营销。3、验收测试。客户对一个系统进行测试以确定其是否已经就 绪，是否可以从系统开发者那里接收过来并且在客户环境中进行部署。
验收测试过程所包含的如下6个阶段：1.定义验收准则。一般在系统的开发合同签署之前。验收准则应当成 为系统开发合同的一部分2.计划验收测试。建立一个测试日程表。3.设计验收测试用例。验收测试的目标应该 是同时测试系统的功能和非功能性特性。4.运行验收测试。协商的结果可能是有条件地接受系统。5.协商测试结果。必须就开发者将如何修复所发现的问题达成一致意见。6.接受或拒绝系统。开发者和客户要进行会谈以确定系统是否可以接受。
虽然原则上“用户参与”是一个很有吸引力的思想，但是它并不一定会得到高质量的系统测试。
用户参与敏捷团队会产生一些问题，因此许多公司将敏捷和更传统的测试方法混合使用。系统可能使用敏捷技术开发，但是完成一个主要的发布后会使用独立的验收测试来确定是否应该接受该系统。