软件测试14类
软件测试是指使用人工或者自动的手段来运行或测定某个软件产品系统的过程，其目的是在于检验是否满足规定的需求或者弄清预期的结果与实际结果的区别。本文主要描述软件测试的类型。
1 数据和数据库完整性测试
数据与数据库完整测试是指测试关系型数据库完整性原则以及数据合理性测试。
数据库完整性原即：
主码完整性：主码不能为空；
外码完整性：外码必须等于对应的主码或者为空。
数据合理性指数据在数据库中的类型，长度，索引等是否建的比较合理。
在项目名称中，数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时，不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS)，还需要进行深入的研究，以确定可以支1持测试的工具和技术。
比如，有两张表：部门和员工。部门中有部门编号，部门名称，部门经理等字段，主码为部门编号；员工表中有员工编号，员工所属部门编号，员工名称，员工类型等字段，主码为员工编号，外码为员工所属部门编号，对应部门表。如果在某条部门记录中部门编号或员工记录员工编号为空，他就违反主码完整性原则。如果某个员工所属部门的编号为##，但是##在部门编号中确找不到，这就违反外码完整性原则。
员工类型如下定义：0：职工，1：职员，2：实习生。但数据类型为Int，我们都知道Int占有4个字节，如果定义成char(1).就比原来节约空间。
2 白盒测试
白盒测试是基于代码的测试，测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量，一般黑盒测试由项目经理在程序员开发中来实现。白盒测试分为动态白盒测试和静态白盒测试
2.1 静态白盒测试
利用眼睛，浏览代码，凭借经验，找出代码中的错误或者代码中不符合书写规范的地方。比如，代码规范中规定，函数必须为动宾结构。而黑盒测试发现一个函数定义如下：
Function NameGet(){
….
}
这是属于不符合开发规范的错误。
有这样一段代码:
if (i<0) & (i>=0)
…
这段代码交集为整个数轴，IF语句没有必要
I=0;
while(I>100){
J=J+100;
T=J*PI;
}
在循环体内没有I的增加,bug产生。
2.2 动态白盒测试
利用开发工具中的调式工具进行测试。比如一段代码有4个分支，输入4组不同的测试数据使4组分支都可以走通而且结果必须正确。
看一段代码
if(I<0){
P1
}else{
P2
}
在调试中输入I=-1,P1程序段通过， P2程序段未通过，属于动态黑盒测试的缺陷
3.功能测试
功能测试指测试软件各个功能模块是否正确，逻辑是否正确。
对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确，以及业务规则的实施是否恰当。此类测试基于黑盒技术，该技术通过图形用户界面 (GUI) 与应用程序进行交互，并对交互的输出或结果进行分析，以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。
比如一个对电子商务系统，前台用户浏览商品-放入购物车-进入结账台，后台处理订单，配货，付款，发货，这一系列流程必须正确无误的走通，不能存在任何的错误。
4.UI测试
UI测试指测试用户界面的风格是否满足客户要求，文字是否正确，页面美工是否好看，文字，图片组合是否完美，背景是否美观，操作是否友好等等
用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外，UI 测试还可确保 UI 中的对象按照预期的方式运行，并符合公司或行业的标准。包括用户友好性，人性化，易操作性测试。UI测试比较主观，与测试人员的喜好有关
比如：页面基调颜色刺眼；用户登入页面比较难于找到，文字中出现错别字，页面图片范围太广等都属于UI测试中的缺陷，但是这些缺陷都不太严重。
5.性能测试
性能测试主要测试软件测试的性能，包括负载测试，强度测试，数据库容量测试，基准测试以及基准测试
5.1负载测试
负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。
在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。
比如，在B/S结构中用户并发量测试就是属于负载测试的用户，可以使用webload工具，模拟上百人客户同时访问网站，看系统响应时间，处理速度如何？
5.2强度测试
强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。
实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足，测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源（如数据库锁或网络带宽）而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
比如：一个系统在内存366M下可以正常运行，但是降低到258M下不可以运行，告诉内存不足，这个系统对内存的要求就是366M。
5.3数据库容量测试
数据库容量测试指通过存储过程往数据库表中插入一定数量的数据，看看相关页面是否能够及时显示数据。
数据库容量测试使测试对象处理大量的数据，以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如，如果测试对象正在为生成一份报表而处理一组数据库记录，那么容量测试就会使用一个大型的测试数据库，检验该软件是否正常运行并生成了正确的报表。做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录，计算相关页面的调用时间。
比如，在电子商务系统中，通过insert customer 往user表中插入10 000数据，看其是否可以正常显示顾客信息列表页面，如果要求达到最多可以处理100 000个客户，但是顾客信息列表页面不能够在规定的时间内显示出来，就需要调整程序中的SQL查询语句；如果在规定的时间内显示出来，可以将用户数分别提高到20 000 , 50 000, 100 000进行测试。
5.4基准测试
基准测试与已知现有的系统进行比较，主要检验是否与类似的产品具有竞争性的一种测试。
如果你要开发一套财务系统软件并且你已经获得用友财务系统的性能等数据，你可以测试你这套系统，看看哪些地方比用友财务系统好，哪些地方差？以便改进自己的系统，也可为产品广告提供数据。
5.5竞争测试
软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。比如：一台机器上即安装您的财务系统，又安装用友财务系统。当CPU占有率下降后，看看是否能够强过用友财务系统，而是自己的系统能够正常运行？
6. 安全性和访问控制测试
安全性和访问控制测试侧重于安全性的两个关键方面：
应用程序级别的安全性，包括对数据或业务功能的访问
系统级别的安全性，包括对系统的登录或远程访问。
6.1应用程序级别的安全性
可确保：在预期的安全性情况下，主角只能访问特定的功能或用例，或者只能访问有限的数据。例如，可能会允许所有人输入数据，创建新账户，但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性，测试就可确保“用户类型一”能够看到所有客户消息（包括财务数据），而“用户二”只能看见同一客户的统计数据。
比如B/S系统，不通过登入页面，直接输入URL,看其是否能够进入系统？
6.2系统级别的安全性
可确保只有具备系统访问权限的用户才能访问应用程序，而且只能通过相应的网关来访问。
比如输入管理员账户，检查其密码是否容易猜取，或者可以从数据库中获得？
7.故障转移和恢复测试
故障转移和恢复测试指当主机软硬件发生灾难时候，备份机器是否能够正常启动，使系统是否可以正常运行，这对于电信，银行等领域的软件是十分重要的。
故障转移和恢复测试可确保测试对象能成功完成故障转移，并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。
故障转移测试可确保：对于必须持续运行的系统，一旦发生故障，备用系统就将不失时机地“顶替”发生故障的系统，以避免丢失任何数据或事务。
恢复测试是一种对抗性的测试过程。在这种测试中，将把应用程序或系统置于极端的条件下（或者是模拟的极端条件下），以产生故障（例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字）。然后调用恢复进程并监测和检查应用程序和系统，核实应用程序或系统和数据已得到了正确的恢复。一定要注意主备定时备份
比如电信系统，突然主机程序发生死机，备份机器是否能够启动，使系统能够正常运行，从而不影响用户打电话？
物过刚则易折
8.配置测试
又叫兼容性测试。配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中，客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如，应用程序、驱动程序等而且在任何时候，都可能运行许多不同的软件组合，从而占用不同的资源。（如浏览器版本，操作系统版本等）
下面列出主要配置测试
8.1浏览器兼容性
测试软件在不同产商的浏览器下是否能够正确显示与运行；
比如测试IE，Natscape浏览器下是否可以运行这套软件？
8.2操作系统兼容性
测试软件在不同操作系统下是否能够正确显示与运行；
比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件？
8.3硬件兼容性
测试与硬件密切相关的软件产品与其他硬件产品的兼容性，比如该软件是少在并口设备中的，测试同时使用其他并口设备，系统是否可以正确使用.
比如在INTER,舒龙CPU芯片下系统是否能够正常运行？
这样的测试必须建立测试实验室，在各种环境下进行测试。
9.安装测试
安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如，进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。
安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装，安装代码提供安装一些程序能够运行的基础数据。
10.多语种测试
又称本地化测试，是指为各个地方开发产品的测试，如英文版，中文版等等，包括程序是否能够正常运行，界面是否符合当地习俗，快捷键是否正常起作用等等，特别测试在A语言环境下运行B语言软件（比如在英文win98下试图运行中文版的程序），出现现象是否正常。
本地化测试还要考虑：
l 当语言从A翻译到B，字符长度变化是否影响页面效果。比如中文软件中有个按键叫“看广告”，翻译到英文版本中为 “View advertisement”可能影响页面的美观程度
l 要考虑同一单词在各个国家的不同意思，比如football在英文中为足球，而美国人使用中可能理解为美式橄榄球。
l 要考虑各个国家的民族习惯，比如龙个美国中被理解邪恶的象征，但翻译到中国，中国人认为为吉祥的象征。
11.文字测试
文字测试测试软件中是否拼写正确，是否易懂，不存在二义性，没有语法错误；文字与内容是否有出入等等，包括图片文字。
比如：“比如，请输入正确的证件号码！”何谓正确的证件号码，证件可以为身份证，驾驶证，也可为军官证，如果改为“请输入正确的身份证号码！”用户就比较容易理解了。
12.分辨率测试
测试在不同分辨率下，界面的美观程度,分为800*600，1024*768，1152*864，1280*768，1280*1024，1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率，而在其他分辨率下也都能可以运行。
13发布测试
主要在产品发布前对一些附带产品，比如说明书，广告稿等进行测试
13.1说明书测试
主要为语言检查，功能检查，图片检查
语言检查：检查说明书语言是否正确，用词是否易于理解；
功能检查：功能是否描述完全，或者描述了并没有的功能等；
图片检查:：检查图片是否正确
13.2宣传材料测试
主要测试产品中的附带的宣传材料中的语言，描述功能，图片
13.3帮助文件测试
帮助文件是否正确，易懂，是否人性化。最好能够提供检索功能。
13.4广告用语
产品出公司前的广告材料文字，功能，图片，人性化的检查
14 文档审核测试
文档审核测试目前越来越引起人们的重视，软件质量不是检查出来的，而是融进软件开发中来。前置软件测试发越来越受到重视。请看一个资料：
文档审核测试主要包括需求文档测试，设计文档测试，为前置软件测试测试中的一部分。
14.1需求文档测试
主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现；
14.2设计文档测试
测试设计是否符合全部需求以及设计是否合理。
总结
据美国软件质量安全中心2000年对美国一百家知名的软件厂商统计，得出这样一个结论：软件缺陷在开发前期发现比在开发后期发现资金，人力上节约90%；软件缺陷在推向市场前发现比在推出后发现资金，人力上节约90%。所以说软件的缺陷应该尽早发现。不是所有的软件都要进行任何类型的软件测试的，可以根据产品的具体情况进行组装测试不同的类型。
参考文献
《Rational统一过程模型》
《软件测试》
黑盒测试方法
软件测试方法在不同的书籍中可能有不同的分类，不同的叫法和不同的解释。比如，从测试人员角度看，可分为手动测试和自动测试。从源代码的角度可分为单元测试和功能测试。从理论定义来分，可分为黑箱测试，白箱测试和灰箱测试。这里要讨论的基本软件测试方法主要侧重于软件功能的黑箱测试方法：
功能测试（Functionality Test），
可接受性测试（Acceptance Test），
用户界面(User interface或UI)测试，
Ad hoc一般指‘探讨或开放’型测试，
边界条件测试（Boundary Condition），
性能测试（Performance Test），
回归测试（Regression Test），
强力测试（Stress Test），
配置和安装测试（Configuration and Setup Test），
兼容性测试（Comparability Test），
国际化支持测试（International Sufficiency）
本地化语言测试（Localization）。
功能测试：验证测试软件功能能否正常按照它的设计工作。看运行软件时的期望行为是否符合原设计。比如，测试Microsoft Excel插入->符号的功能包括测试能够在Microsoft Excel所选单元格中正确地插入符号并且显示正确符号？能否正确显示使用不同的字体的符号？
可接受性测试：是在把测试的版本交付测试部门大范围测试以前进行的对最基本功能的简单测试。因为在把测试的版本交付测试部门大范围测试以前应该先验证该版本对于所测试的功能基本上比较稳定。必须满足一些最低要求。比如不会很容易程序就挂起或崩溃。如果一个新版本没通过可测试性的验证，就应该阻拦测试部门花时间在该测试版本上测试。同时还要找到造成该版本不稳定的主要缺陷并督促尽快加以修正。
用户界面测试：分析软件用户界面的设计是否合乎用户期望或要求。它常常包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息（Menu 和Help content）等方面的测试。比如，测试Microsoft Excel中插入符号功能所用的对话框的大小，所有按钮是否对齐，字符串字体大小，出错信息内容和字体大小，工具栏位置/图标等等。
‘探索或开放’型的测试：不是按部就班的按照一个又一个正式的测试用例来进行，也不局限于测试用例特定的步骤。这种测试是测试人员在理解该软件功能的基础上运用灵活多样的想象力和创造力去模拟用户的需求来使用该软件的多种功能。通常涉及很多的测试用例或者通过更复杂的步骤来使用该软件。
边界条件测试：是环绕边界值的测试。通常意味着测试软件各功能是否能正确处理最大值，最小值或者所设计软件能够处理的最长的字符串等等。
性能测试是：通常验证软件的性能在正常环境和系统条件下重复使用是否还能满足性能指标。或者执行同样任务时新版本不比旧版本慢。一般还检查系统记忆容量在运行程序时会不会流失（memory leak）。比如，验证程序保存一个巨大的文件新版本不比旧版本慢。
回归测试：根据修复好了的缺陷再重新进行的测试。目的在于验证以前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。通常确定所需的再测试的范围时是比较困难的，特别当临近产品发布日期时。因为为了修正某缺陷时必需更改源代码，因而就有可能影响这部分源代码所控制的功能。所以在验证修好的缺陷时不仅要服从缺陷原来出现时的步骤重新测试，而且还要测试有可能受影响的所有功能。因此应当鼓励对所有回归测试用例进行自动化。
强力测试(压力测试)：它通常验证软件的性能在各种极端的环境和系统条件下是否还能正常工作。或者说是验证软件的性能在各种极端环境和系统条件下的承受能力。比如，在最低的硬盘驱动器空间或系统记忆容量条件下，验证程序重复执行打开和保存一个巨大的文件1000次后也不会崩溃或死机。
集成与兼容性测试：验证该功能能够如预期的那样与其他程序或者构件协调工作。兼容性经常意味着新旧版本之间的协调，也包括测试的产品与其它产品的兼容使用。比如用同样产品的新版本时不影响与用旧版本用户之间保存文件，格式，和其他数据等操作。
装配/安装/配置测试：验证软件程序在不同厂家的硬件上，所支持的不同语言的新旧版本平台上，和不同方式安装的软件都能够如预期的那样正确运行。比如，把英文版的 Microsoft Office 2003安装在韩文版 的Windows Me 上，再验证所有功能都正常运行。
国际化支持测试：验证软件程序在不同国家或区域的平台上也能够如预期的那样运行，而且还可以按照原设计尊重和支持使用当地常用的日期，字体，文字表示，特殊格式等等。比如，用英文版的 Windows XP 和 Microsoft Word 能否展示阿拉伯字符串？用阿拉伯版的 Windows XP 和 阿拉伯版的Microsoft Word 能否展示阿拉伯字符串？又比如，日文版的Microsoft Excel对话框是否显示正确翻译的日语？一旦来说执行国际化支持测试的测试人员往往需要基本上了解这些国家或地区的语言要求和期望行为是什么。
本地化语言测试：要验证所有已计划要发布的不同语言版本软件如预期的那样被正确地翻译成当地语言。这类测试一般包括验证菜单，对话框，出错信息，帮助内容等所有用户界面上的文字都能够显示正确翻译好的当地文字。
软件测试过程模型
目前主流的开发模型主要有：瀑布模型、原型模型、螺旋模型、增量模型、渐进模型、快速软件开发(RAD)以及Rational统一过程(RUP)等，这些模型对于软件开发过程具有很好的指导作用，但是，非常遗憾的是，在这些过程方法中，并没有充分强调测试的价值，也没有给测试以足够的重视，利用这些模型无法更好地指导测试实践。软件测试是与软件开发紧密相关的一系列有计划的系统性的活动，显然软件测试也需要测试模型去指导实践。下面对主要的模型做一些简单的介绍。
V模型
V模型是最具有代表意义的测试模型。在传统的开发模型中，比如瀑布模型，人们通常把测试过程作为在需求分析、概要设计、详细设计和编码全部完成后的一个阶段，尽管有时测试工作会占用整个项目周期的一半的时间，但是有人仍然认为测试只是一个收尾工作，而不是主要过程。V模型的推出就是对此种认识的改进。V模型是软件开发瀑布模型的变种，它反映了测试活动与分析与分析和设计的关系，从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系，如模型图中所示，图中的箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。
V模型的软件测试策略既包括低层测试又包括了高层测试，低层测试是为了源代码的正确性，高层测试是为了使整个系统满足用户的需求。
V模型指出，单元和集成测试是验证程序设计，开发人员和测试组应检测程序的执行是否满足软件设计的要求；系统测试应当验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标；由测试人员和用户进行软件的确认测试和验收测试，追溯软件需求说明书进行测试，以确定软件的实现是否满足用户需求或合同的要求。
V模型存在一定的局限性，它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后的一个阶段，主要是针对程序进行测试寻找错误，而需求分析阶段隐藏的问题一直到后期的验收测试才被发现。
W模型
1、W模型建立
V模型的局限性在于没有明确地说明早期的测试，不能体现“尽早地和不断地进行软件测试”的原则。在V模型中增加软件各开发阶段应同步进行的测试，被演化为一种W模型，因为实际上开发是“V”，测试也是与此相并行的“V”。基于“尽早地和不断地进行软件测试”的原则，在软件的需求和设计阶段的测试活动应遵循IEEEstd1012-1998《软件验证和确认(V&V)》的原则。
一个基于V&V原理的W模型示意图如下所示：
2、W模型应用
相对于V模型，W模型更科学。W模型可以说是V模型自然而言的发展。它强调：测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。这样，只要相应的开发活动完成，我们就可以开始执行测试，可以说，测试与开发是同步进行的，从而有利于尽早地发现问题。以需求为例，需求分析一完成，我们就可以对需求进行测试，而不是等到最后才进行针对需求的验收测试。
如果测试文档能尽早提交，那么就有了更多的检查和检阅的时间，这些文档还可用于评估开发文档。另外还有一个很大的益处是，测试者可以在项目中尽可能早地面的规格说明书中的挑战。这意味着测试不仅仅是评定软件的质量，测试还可以尽可能早地找出缺陷所在，从而帮助改进项目内部的质量。参与前期工作的测试者可以预先估计问题和难度，这将可以显著地减少总体测试时间，加快项目进度。
根据W模型的要求，一旦有文档提供，就要及时确定测试条件，以及编写测试用例，这些工作对测试的各级别都有意义。当需求被提交后，就需要确定高级别的测试用例来测试这些需求。当概要设计编写完成后，就需要确定测试条件来查找该阶段的设计缺陷。
W模型也是有局限性的。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动。同样的，软件开发和测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可以正式开始下一个阶段。这样就无法支持迭代、自发性以及变更调整。对于当前很多文档需要事后补充，或者根本没有文档的做法下(这已成为一种开发的文化)，开发人员和测试人员都面临同样的困惑。
H模型
1、H模型建立
V模型和W模型均存在一些不妥之处。首先，如前所述，它们都把软件的开发视为需求、设计、编码等一系列串行的活动，而事实上，虽然这些活动之间存在相互牵制的关系，但在大部分时间内，它们是可以交叉进行的。虽然软件开发期望有清晰的需求、设计和编码阶段，但实践告诉我们，严格的阶段划分只是一种理想状况。试问，有几个软件项目是在有了明确的需求之后才开始设计的呢？所以，相应的测试之间也不存在严格的次序关系。同时，各层次之间的测试也存在反复触发、迭代和增量关系。其次，V模型和W模型都没有很好地体现测试流程的完整性。
为了解决以上问题，提出了H模型。它将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。
2、H模型应用
H模型的简单示意图如下所示：
这个示意图仅仅演示了在整个生产周期中某个层次上的一次测试“微循环”。图中的其他流程可以是任意开发流程。例如，设计流程和编码流程。也可以是其他非开发流程，例如，SQA流程，甚至是测试流程自身。也就是说，只要测试条件成熟了，测试准备活动完成了，测试执行活动就可以(或者说需要)进行了。
概括地说，H模型揭示了：
●软件测试不仅仅指测试的执行，还包括很多其他的活动。
●软件测试是一个独立的过程，贯穿产品整个生命周期，与其他流程并发地进行。
●软假测试要尽早准备，尽早执行。
●软件测试是根据被测物的不同而分层次进行的。不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。
在H模型中，软件测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。
其他模型
1、X模型
介绍另外一种测试模型，即X模型，其目标是弥补V模型的一些缺陷。
软件测试X模型如下图所示：
X模型的基本思想是由Marick提出的，Marick对V模型最主要的批评是V模型无法引导项目的全部过程。他认为一个模型必须能处理开发的所有方面，包括交接、频繁重复的集成以及需求文档的缺乏等。Maricke认为一个模型不应该规定那些和当前所公认的实践不一致的行为。
X模型左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后，将进行频繁的交接，通过集成最终合成为可执行的程序。这一点在图的右上方得以体现，而且这些可执行程序还需要进行测试，已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。
同时，X模型还定位了探索性测试，即如图中右下方所示。这是不进行事先计划的特殊类型的测试，诸如“我这么测一下，结果会怎么样”，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
Marick对V模型提出质疑，也是因为V模型是基于一套必须按照一定顺序严格排列的开发步骤，而这很可能并没有反映实际的实践过程。因为在实践过程中，很多项目是缺乏足够的需求的，而V模型还是从需求处理开始。
Marick也质疑了单元测试和集成测试的区别，因为在某些场合人们可能会跳过单元测试而热衷于直接进行集成测试。Marick担心人们盲目地跟随“学院派的V模型”，按照模型所指导的步骤进行工作，而实际上某些做法并不切合实用。
2、前置测试模型
前置测试模型，它是将测试和开发紧密结合的模型，该模型提供了轻松的方式，可以使你的项目加快速度。
前置测试模型如下图所示：
前置测试模型体现了以下的要点：
●开发和测试相结合：前置测试模型将开发和测试生命周期整合在一起，标识了项目生命周期从开始到结束之间的关键行为。并且标识了这些行为在项目周期中的价值所在。如果其中有些行为没有得到很好的执行，那么项目成功的可能性就会因此而有所降低。如果有业务需求，则系统开发过程将更有效率。我们认为在没有业务需求的情况下进行开发和测试是不可能的。而且，业务需求最好在设计和开发之前就被正确定义。
●对每一个交付内容进行测试：每一个交付的开发结果都必须通过一定的方式进行测试。源程序代码并不是唯一需要测试的内容。图中的椭圆框表示了其他一些要测试的对象，包括可行性报告、业务需求说明，以及系统设计文档等。这同V模型中开发和测试的对应关系是一致的，并且在其基础上有所扩展，变得更为明确。
●在设计阶段进行测试计划和测试设计：设计阶段是作测试计划和测试设计的最好时机。很多组织要么根本不作测试计划和测试设计，要么在即将开始执行测试之前才飞快地完成测试计划和测试设计。在这种情况下，测试只是验证了程序的正确性，而不是验证整个系统本该实现的东西。
●测试和开发结合在一起：前置测试将测试执行和开发结合在一起，并在开发阶段以编码---测试---编码---测试的方式来体现。也就是说，程序片段一旦编写完成，就会立即进行测试。一般情况下，先进性的测试是单元测试，因为开发人员认为通过测试来发现错误是最经济的方式。但也可参考X模型，即一个程序片段也需要相关的集成测试，甚至有时还需要一些特殊测试。对于一个特定的程序片段，其测试的顺序可以按照V模型的规定，但其中还会交织一些程序片段的开发，而不是按阶段完全地隔离。
●让验收测试和技术测试保持相对独立：验收测试应该独立于技术测试，这样可以提供双重的保险，以保证设计及程序编码能够符合最终用户的要求。验收测试既可以在实施的第一步来执行，也可以在开发阶段的最后一步执行。前置测试模型提倡验收测试和技术测试沿循两条不同的路线来进行，每条路线分别地验证系统是否能够入预期设想的那样进行正常工作。这样，当单独设计好的验收测试完成了系统的验证时，我们即可确信这是一个正确的系统。
测试模型的使用
前面我们介绍了几种典型的测试模型，应该说这些模型对指导测试工作的进行具有重要的意义，但任何模型都不是完美的。我们应该尽可能地去应用模型中对项目有实用价值的方面，但不强行地为使用模型而使用模型，否则也没有实际意义。
在这些模型中，V模型强调了在整个软件项目开发中需要经历的若干个测试级别，而且每一个级别都与一个开发级别相对应，但它忽略了测试的对象不应该仅仅包括程序，或者说它没有明确地之处应该对软件的需求、设计进行测试，而这一点在W模型中得到了补充。W模型强调了测试计划等工作的先行核对系统需求和系统设计的测试，但W模型和V模型一样也没有专门对软件测试流程予以说明，因为事实上，随着软件质量要求越来越为大家所重视，软件测试也逐步发展成为一个独立于软件开发部的组织，就每一个软件测试的细节而言，它都有一个独立的操作流程。比如，现在的第三方测试，就包含了从测试计划和测试案例编写，到测试实施以及测试报告编写的全过程，这个过程在H模型中得到了相应的体现，表现为测试是独立的。也就是说，只要测试前提具备了，就可以开始进行测试了。当然，X模型和前置测试模型又在此基础上增加了许多不确定因素的处理情况，因为在真实项目中，经常会有变更的发生，例如需要重新访问前一阶段的内容，或者跟踪并纠正以前提交的内容，修复错误，排除多余的成分，以及增加新发现的功能等。
因此，在实际的工作中，我们要灵活地运用各种模型的优点，在W模型的框架下，运用H模型的思想进行独立地测试，并同时将测试与开发紧密结合，寻找恰当的就绪点开始测试并反复迭代测试，最终保证按期完成预定目标。
X模型的基本思想是由Marick提出的，但首先是Marick不建议要建立一个替代模型。Robin F·Goldsmith引用了一些Marick的想法，并重新经过组织，形成了“X模型”。其实并不是为了和V模型相对应而选择这样的名字，而是由于其它一些原因：X通常代表未知，而Marick也认为他的观点并不足以支撑一个模型的完整描述，但其中已经有一个模型所需要的一些主要内容，其中也包括了象探索性测试（exploratory testing）这样的亮点。
X模型示意图
Marick对V模型的最主要批评是V模型无法引导项目的全部过程。他认为一个模型必须能处理开发的所有方面，包括交接，频繁重复的集成，以及需求文档的缺乏等等。
Marick认为一个模型不应该规定那些和当前所公认的实践不一致的行为。X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序。(右上半部分），这些可执行程序还需要进行测试。已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。
由上图中可见，X模型还定位了探索性测试（右下方）。这是不进行事先计划的特殊类型的测试，诸如“我这么测一下结果会怎么样？”，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。
然而，关注于这样的低级别的行为可能会引起不同的议论。一个模型和一个单独的项目计划有所不同。模型不应该描述每个项目的具体细节，模型应该对项目进行指导和支持。当然，代码的交接也可以简单地认为是一种集成的形式。而V模型也并没有限制各种创建周期的发生次数。
Marick和Graham都一致认同，应该在执行测试之前进行测试设计。Marick建议：“在你掌握相关知识时进行设计，在你手头有交付内容时进行测试。”X模型包含了测试设计的步骤，就象使用不同的测试工具所要包含的步骤一样，而V模型没有这么做。但是，Marick的例子提示，X模型在这层意义上看也并不是一个真的模型，取而代之的是，应该允许在任何时候选择使用测试设计步骤。
Marick对V模型提出质疑，也因为V模型基于一套必须按照一定顺序严格排列的开发步骤，而这很可能并没有反映实际的实践过程。
尽管很多项目缺乏足够的需求，V模型还是从需求处理开始。V模型提示我们要对各开发阶段中已经得到的内容进行测试，但它没有规定我们要取得多少内容。如果没有任何的需求资料，开发人员知道他们要做什么吗？我主张在X模型和其它模型中都需要足够的需求并至少进行一次发布。虽然在没有模型的情况下也必须正常工作，但一个有效的模型，可以鼓励很多好的实践方法的采用。因此，V模型的一个强项是它明确的需求角色的确认，而X模型没有这么做，这大概是X模型的一个不足之处。
Marick也质疑了单元测试和集成测试的区别，因为在某些场合人们可能会跳过单元测试而热衷于直接进行集成测试。Marick担心人们盲目地跟随“学院派的V模型”，按照模型所指导的步骤进行工作，而实际上某些做法并不切合实用。我已经尽自己的努力把Marick的关于需要很多具有可伸缩性的行为的期望结合进了X模型，这样，X模型并不要求在进行作为创建可执行程序（图中右上方）的一个组成部分的集成测试之前，对每一个程序片段都进行单元测试（图中左侧的行为）。但X模型没能提供是否要跳过单元测试的判断准则。
X模型填补了V模型和X模型的缺陷，并可为测试人员和开发人员带来明显的帮助。