|
|
|
按阶段展开测试是一种基本的测试策略，一般可分为单元测试、集成测试、确认测试、系统测试、验收测试这几个阶段，不同的测试阶段将制定不同的测试目标，采用不同的测试方法和技术，具有各自的特点。
|
|
|
|
|
|
单元测试是通过对每个最小的软件模块进行测试，对源代码的每一个程序单元实行测试，检查各个程序模块是否正确地实现了规定的功能，确保其能正常工作。
|
|
|
|
单元测试由开发人员执行，一般由模块单元开发者设计测试用例并修改缺陷。单元测试具有如下三种行为：
|
|
|
|
（1）单元测试是一种验证行为。验证程序中的每项功能的正确性为代码的重构提供了保障。
|
|
|
|
（2）单元测试是一种设计行为。软件设计阶段考虑如何实现软件的功能、性能和用户界面等，而不考虑实现的代码。单元测试关注于软件的具体功能实现是否符合需求设计，而不仅仅定位于代码的实现。
|
|
|
|
（3）单元测试是一种文档的行为。单元测试是函数或类等软件模块如何设计、实现和使用的最佳文档。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（4）单元测试确定变动后的代码对原代码的功能未做修改。
|
|
|
|
|
|
|
|
|
|
（8）单元测试支持变化，任何变化导致的失败情况均会被反映出来。
|
|
|
|
（9）单元测试准确地反映了代码设计，便于后期维护。
|
|
|
|
|
|
（1）单元测试是全部规范。单元测试本质上是种特定的测试方式，是系统的实现方法规范的补充，而不是整个规范。
|
|
|
|
（2）单元测试浪费时间。单元测试不会浪费太多的时间，反而会节省项目时间。
|
|
|
|
（3）单元测试只需使用测试工具就可完成。单元测试工具生成的测试用例往往无法对被测试的程序进行有效覆盖，必须进行人工检查。
|
|
|
|
（4）单元测试是针对代码进行的测试。单元测试依据详细设计报告设计测试用例，不仅仅只是对代码的测试。
|
|
|
|
|
|
|
|
（1）单元测试遵循《软件单元测试计划》和《软件单元测试说明》文档，根据详细设计编写单元测试用例，而不能根据代码编写单元测试用例。
|
|
|
|
（2）单元测试执行前先检查单元测试入口条件是否全部满足。
|
|
|
|
（3）单元测试必须满足一定的覆盖率，重要的接口函数必须做单元测试。
|
|
|
|
（4）单元测试在修改代码后修改测试用例，将全部单元测试用例进行回归测试。
|
|
|
|
|
|
（6）在单元测试完成后，记录《单元测试报告》，分析问题的种类和原因。
|
|
|
|
（7）单元测试始终在配置管理控制下进行，软件问题的修改必须符合变动规程的要求。
|
|
|
|
（8）单元测试文档、测试用例、测试记录和被测程序等齐全，符合规范。
|
|
|
|
|
|
单元测试主要针对程序模块进行测试，主要有5个任务：模块接口、局部数据结构、执行路径、出错处理和边界条件。
|
|
|
|
|
|
通过对被测模块的数据流进行测试，检查进出模块的数据是否正确。因此，必须对模块接口，包括参数表、调用子模块的参数、全局变量、文件I/O操作进行测试。具体涉及以下内容：
|
|
|
|
.模块接受输入的实际参数个数与模块的形式参数个数是否一致。
|
|
|
|
|
|
.输入的实际参数与模块的形式参数所使用的单位是否一致。
|
|
|
|
.调用其他模块时，所传送的实际参数个数与被调用模块的形式参数的个数是否相同。
|
|
|
|
.调用其他模块时，所传送的实际参数与被调用模块的形式参数的类型是否匹配。
|
|
|
|
.调用其他模块时，所传送的实际参数与被调用模块的形式参数的单位是否一致。
|
|
|
|
.调用内部函数时，参数的个数、属性和次序是否正确。
|
|
|
|
.在模块有多个入口的情况下，是否引用有与当前入口无关的参数。
|
|
|
|
|
|
.全局变量是否在所有引用它们的模块中都有相同的定义。
|
|
|
|
|
|
测试用例检查局部数据结构的完整性，如数据类型说明、初始化、默认值等方面的问题，并测试全局数据对模块的影响。
|
|
|
|
在模块的工作过程中，必须测试模块内部的数据能否保持完整性，包括内部数据的内容、形式及相互关系不发生错误。
|
|
|
|
局部数据结构应注意以下几类错误：不正确或不一致的类型说明；错误的初始化或默认值；错误的变量名，如拼写错误或书写错误；下溢、上溢或者地址错误。
|
|
|
|
|
|
测试用例对模块中重要的执行路径进行测试，其中对基本执行路径和循环进行测试往往可以发现大量的路径错误。测试用例必须能够发现由于计算错误、不正确的判定或不正常的控制流而产生的错误。
|
|
|
|
常见的错误有误解或不正确的算术优先级；混合模式的运算；错误的初始化；精确度不够精确；表达式的不正确符号表示。
|
|
|
|
针对判定和条件覆盖，测试用例能够发现的错误有：不同数据类型的比较；不正确的逻辑操作或优先级；应当相等的地方由于精确度的错误而不能相等；不正确的判定或不正确的变量；不正确的或不存在的循环终止；当遇到分支循环时不能退出；不适当地修改循环变量。
|
|
|
|
|
|
测试出错处理的重点是模块在工作中发生了错误，其中的出错处理设施是否有效。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
边界条件测试是单元测试的最后一步，必须采用边界值分析方法来设计测试用例。在为限制数据处理而设置的边界处，测试模块是否能够正常工作。
|
|
|
|
一些与边界有关的数据类型，如数值、字符、位置、数量、尺寸等，以及边界的第一个、最后一个、最大值、最小值、最长、最短、最高和最低等特征。
|
|
|
|
|
|
|
|
|
|
.数据流、控制流中刚好等于、大于、小于确定的比较值是否出现错误。
|
|
|
|
|
|
通常，单元测试在编码阶段进行，在源程序代码编制完成，经过评审和验证，确认没有语法错误之后，开始设计单元测试用例。
|
|
|
|
由于模块并不是一个独立的程序，在考虑测试模块时，同时要考虑与其有关的外界联系，因此使用一些辅助模块去模拟与被测模块相关的其他模块。辅助模块分为以下两种：
|
|
|
|
（1）驱动（Drive）模块。用于模拟被测试模块的上一级模块，相当于被测模块的主程序，用于接收测试数据，并把这些数据传送给被测模块，启动被测模块，最后输出实测结果。
|
|
|
|
（2）桩（Stub）模块。用于模拟被测模块工作过程中所调用的模块。桩模块一般只进行很少的数据处理，不需要把子模块的所有功能都带进来，但不允许什么事情也不做。
|
|
|
|
|
|
|
|
|
|
|
|
（3）达到了测试计划中关于单元测试所规定的覆盖率的要求。
|
|
|
|
（4）被测试的单元每千行代码必须发现至少3个错误。
|
|
|
|
|
|
（6）在单元测试中发现的错误已经得到修改，各级缺陷修复率达到标准。
|
|
|
|
|
|
1999年9月，火星气象人造卫星在经过41周4.16亿英里飞行后，在即将要进入火星轨道时失败了，为此，美国投资5万美元调查事故原因，发现太空科学家洛克希德·马丁采用的是英制（磅）加速度数据，而喷气推进实验室则采用的是公制（牛顿）加速度数据进行计算。如果他们进行了集成测试，事故本来是可以避免的。
|
|
|
|
在每个模块完成单元测试之后，需要着重考虑的一个问题是：通过什么方式将模块组合起来进行集成测试，这将影响到模块测试用例的设计、所用测试工具的类型、模块编码的次序、测试的次序以及设计测试用例的费用和纠错的费用等。
|
|
|
|
集成测试的主要目的是验证组成软件系统的各模块的接口和交互作用，一般不使用真实数据，可以使用一部分代表性的测试数据。在创建测试数据时，应保证数据能充分测试软件系统的边界条件。
|
|
|
|
|
|
|
|
非增量式集成测试采用一步到位的方法来进行测试，对所有模块进行个别的单元测试后，按程序结构图将各模块连接起来，把连接后的程序当做一个整体进行测试。
|
|
|
|
增量式集成测试具体包括自顶向下增量式测试和自底向上增量式测试。
|
|
|
|
|
|
自顶向下增量式测试按结构图自上而下进行逐步集成和逐步测试。模块集成的顺序是首先集成主控模块（主程序），然后按照软件控制层次结构向下进行集成。自顶向下的集成方式可以采用深度优先策略和广度优先策略，如下图所示。由图可知，深度优先顺序为T1->T2->T5->T8->T6->T3->T7->T4，广度优先顺序为T1->T2->T3->T4->T5->T6->T7->T8。
|
|
|
|
|
|
|
|
|
|
①以主模块为所测试模块兼驱动模块，而所有直属于主模块的下属模块全部用桩模块替换，并对主模块进行测试。
|
|
|
|
②采用深度优先或广度优先测试方式，用实际模块替换相应桩模块，再用桩代替它们的直接下属模块，从而与已经测试的模块或子系统组装成新的子系统。
|
|
|
|
|
|
④判断是否所有的模块都已经组装到系统中。如果是，则测试结束，否则，转到②。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.随着底层模块的不断增加，会导致底层模块的测试不充分，特别是被重用的模块。
|
|
|
|
.由于每次组装都必须提供桩，会使得桩的数目急剧增加，从而维护桩的成本也会快速上升。
|
|
|
|
因此，该方法适合采用结构化方法开发软件的体系结构相对比较简单的软件系统。
|
|
|
|
|
|
自底向上增量式测试是从“原子”模块（软件结构中最低层的模块）开始，按结构图自下而上逐步进行集成和测试。
|
|
|
|
|
|
|
|
②写一个驱动程序（用于测试的控制程序），协调测试数据的输入和输出。
|
|
|
|
|
|
④去掉驱动程序，沿软件结构由下向上移动，把子功能族组合成更大的功能族。
|
|
|
|
|
|
|
|
.虽然模拟中断或异常需要设计一定的桩模块，但总体上减少了桩模块的工作量。
|
|
|
|
|
|
.在测试初期，可以并行进行集成，相应地比使用自顶向下的方式效率高。
|
|
|
|
|
|
.随着集成到顶层，整个系统变得越来越复杂，对于底层的一些模块将很难覆盖。
|
|
|
|
|
|
下面给出了非增量式集成测试和增量式集成测试的比较结果。
|
|
|
|
（1）非增量式集成测试模式是先分散测试，然后集中起来一次完成集成测试。如果在模块的接口处存在错误，只会在最后的集成测试时一下子暴露出来。在非增量式集成测试时可能发现很多错误，但为每个错误定位和纠正非常困难，并且在改正一个错误的同时又可能会引入新的错误，从而更难断定出错的原因和位置；与此相反，增量式集成测试采用逐步集成和逐步测试的方法，测试的范围逐步增大，从而错误易于定位和纠正。因此，增量式集成测试比非增量式集成测试有比较明显的优越性。
|
|
|
|
（2）自顶向下测试的主要优点是逐步求精，从一开始让测试者了解系统的框架。它的主要缺点是需要提供被调用的模拟子模块，被调用的模拟子模块可能不能反映真实情况，因此测试有可能不充分。
|
|
|
|
（3）自底向上测试的优点在于，由于驱动模块模拟了所有调用参数，从而测试数据没有困难。其主要缺点在于，只有到最后一个模块被加入之后才能知道整个系统的框架。
|
|
|
|
（4）核心系统先行集成测试能保证一些重要功能和服务的实现，对于快速软件开发十分有效。如果采用此种模式的测试，则要求系统应能明确区分核心软件部件和外围软件部件，采用高频集成，借助于自动化工具实现测试。
|
|
|
|
总之，采用自顶向下集成测试和自底向上集成测试的方案较为常见。在实际测试工作中，应该结合项目的实际环境及各种测试方案适用的范围进行合理的选型。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（4）集成测试的策略选择应当综合考虑质量、成本和进度之间的关系。
|
|
|
|
|
|
（6）在模块与接口的划分上，测试人员应当和开发人员进行充分的沟通。
|
|
|
|
（7）当接口发生修改时，涉及的相关接口必须进行再测试。
|
|
|
|
|
|
|
|
在集成测试过程中的两个重要的里程稗是功能冻结和代码冻结的确定。这两个里程碑可界定出回归测试期的起止界限。
|
|
|
|
（1）功能冻结。经过测试，符合设计要求，确认系统功能和其他特性均不再做任何改变。
|
|
|
|
（2）代码冻结。理论上，在无错误时冻结程序代码，但实际上，代码冻结只标志系统当前版本的质量已达到预期的要求，冻结程序的源代码，不再对其做任何修改。这个里程碑设置在软件通过最终回归测试之后。
|
|
|
|
|
|
|
|
（1）测试的单元不同。单元测试是针对软件从基本单元（如函数等）所做的测试；而集成测试则是以模块和子系统为单位进行的测试，主要测试接口间的关系。
|
|
|
|
（2）测试的依据不同。单元测试是针对软件详细设计所做的测试，测试用例主要依据详细设计；而集成测试是针对高层（概要）设计所做的测试，测试用例主要依据概要设计。
|
|
|
|
（3）测试空间不同。集成测试的测试空间与单元测试和系统测试是不同的。集成测试也不关心内部实现层的测试空间，只关注接口层的测试空间，即关注的是接口层可变数据间的组合关系。
|
|
|
|
（4）使用的方法不同。集成测试关注的是接口的集成，和单元测试只关注每个单元不同，因此在具体的测试方法上也不同，集成测试在测试用例设计方面和单元测试有一定的差别。
|
|
|
|
|
|
|
|
按照集成构建计划及增量集成策略完成了整个系统的集成测试。
|
|
|
|
|
|
|
|
|
|
在集成测试中发现的错误已经得到修改，各级缺陷修复率达到标准。
|
|
|
|
|
|
确认测试又称为合格性测试，用来检验软件是否符合用户的需求。软件确认一般采用黑盒测试法，通过一系列证明软件功能和要求的测试来实现。
|
|
|
|
确认测试需制订测试计划和测试过程。测试计划应规定测试的种类和测试进度，测试过程主要定义一些特殊的测试用例，旨在说明软件与需求是否一致。确认测试着重考虑软件是否满足合同规定的所有功能和性能，文档资料是否完整。确认人机界面和其他方面（如可移植性、兼容性、错误恢复能力和可维护性等）是否令用户满意。
|
|
|
|
确认测试的结果只有两种可能，一种是功能和性能指标满足软件需求说明的要求，用户可以接受；反之，功能和性能指标不满足软件需求说明的要求，此时发现的错误一般很难在预定的工期内改正，因此往往需与用户协商，寻求一个妥善的解决办法。
|
|
|
|
确认测试过程的重要环节就是配置审查工作。配置审查的文件资料包括用户手册、操作手册和设计资料。其目的在于确保软件的所有文件资料均已编写齐全，用于支持日后软件的维护工作。
|
|
|
|
|
|
系统测试将软件与整个系统的硬件、外设、支持软件、数据和人员等结合起来，以需求规格说明为依据，在实际运行环境下进行测试。系统测试过程分为计划与准备、执行、返工与回归测试3个阶段，系统测试一般要完成功能测试、性能测试、恢复测试、安全测试、强度测试以及其他限制条件的测试。
|
|
|
|
系统测试由独立测试小组在测试组长的监督下进行，测试组长主要负责保证在质量控制和监督下使用测试技术执行系统测试。系统测试过程由一个独立的测试观察员来监控测试工作。
|
|
|
|
|
|
负载测试是通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。
|
|
|
|
|
|
（1）一次性加载。一次性加载某个数量的用户，在预定的时间段内持续运行。例如，在早晨上班的时间访问网站或登录网站的时间非常集中，基本属于扁平负载模式。
|
|
|
|
（2）递增加载。有规律地逐渐增加用户，每几秒增加一些新用户，交错上升。借助这种负载方式的测试，容易发现性能的拐点，即性能瓶颈。
|
|
|
|
（3）高低突变加载。某个时间用户数量很大，突然降到很低，过一段时间，又突然加到很高，反复几次。借助这种负载方式的测试，容易发现资源释放和内存泄露等问题。
|
|
|
|
（4）随机加载方式。由随机算法自动生成某个数量范围内变化的、动态的负载，这种方式可能是和实际情况最为接近的一种负载方式。虽然不容易模拟系统运行出现的瞬时高峰期，但可以模拟系统长时间的运行过程的状态。
|
|
|
|
|
|
压力测试又称为强度测试，是在强负载（加大数据量、大量并发用户等）下的测试，用于查看应用系统在峰值使用情况下的操作行为，目的是发现系统的功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。
|
|
|
|
微软测试实践经验表明，如果软件产品通过72小时压力测试，则在72小时后出现问题的可能性微乎其微。所以，72小时成为微软产品压力测试的时间标志。
|
|
|
|
负载测试与压力测试是两个很容易混淆的概念。负载测试是通过逐步增加系统负载，测试其变化，看最后在满足性能的情况下，系统最多能接受多大负载的测试。压力测试是在满足性能的情况下，能使系统处于失效的状态，通俗来说，就是发现在什么条件下，系统的性能会变得不可接受。
|
|
|
|
|
|
|
|
②简单压力缺陷修正后，增加系统的压力直到系统崩溃。
|
|
|
|
因此，负载压力测试的主要目的是度量应用系统的性能和扩展性。在实施并发负载过程中，通过实时性能监测来确认和查找问题，并针对所发现的问题对系统性能进行优化。负载压力测试工具能够对整个企业架构进行测试，通过这些测试，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。
|
|
|
|
|
|
软件可靠性是软件质量的一个重要标志。美国电气和电子工程师协会（IEEE）将软件可靠性定义为：系统在特定的环境下，在给定的时间内无故障地运行的概率。软件可靠性涉及软件的性能、功能、可用性、可服务性、可安装性，以及可维护性等多方面特性，是对软件在设计、生产以及在它所预定环境中具有所需功能的置信度的一个度量。
|
|
|
|
可靠性测试一般伴随着强壮性测试，是评估软件在运行时的可靠性，通过测试确认平均无故障时间（Mean Time to Failure，MTTF）、故障发生前平均工作时间（Mean-Time-To-First-Failure，MTTFF）或因故障而停机的时间（Mean Time To Repairs，MTTR）在一年中应不超过多少时间。可靠性测试强调随机输入，并通过模拟系统实现，很难通过实际系统的运行来实现。
|
|
|
|
|
|
安全性测试是测试系统在应付非授权的内部／外部访问、非法侵入或故意的损坏时的系统防护能力，检验系统有能力使可能存在的内／外部的伤害或损害的风险限制在可接受的水平内。可靠性通常包括安全性，但是软件的可靠性不能完全取代软件的安全性。安全性还涉及到数据加密、保密和存取权限等多个方面。
|
|
|
|
安全性测试需要设计一些测试用例试图突破系统的安全保密措施，检验系统是否有安全保密漏洞，验证系统的保护机制是否能够在实际中不受到非法的侵入。在安全测试过程中，测试者扮演成试图攻击系统的角色，尝试获取系统密码，利用能够瓦解任何防守的客户软件攻击系统；或者把系统“制服”，使别人无法访问。
|
|
|
|
安全性测试是要检验在系统中已经存在的系统安全性、保密性措施是否发挥作用，有无漏洞。破坏系统保护机构的主要方法有以下几种：
|
|
|
|
（1）正面攻击或从侧面、背面攻击系统中易受损坏的那些部分。
|
|
|
|
（2）以系统输入为突破口，利用输入的容错性进行正面攻击。
|
|
|
|
（3）申请和占用过多的资源压垮系统，以破坏安全措施，从而进入系统。
|
|
|
|
（4）故意使系统出错，利用系统恢复的过程，窃取用户口令及其他有用的信息。
|
|
|
|
（5）通过浏览残留在计算机各种资源中的垃圾（无用信息），以获取如口令、安全码和译码关键字等信息。
|
|
|
|
（6）浏览全局数据，期望从中找到进入系统的关键字。
|
|
|
|
（7）浏览那些逻辑上不存在，但物理上还存在的各种记录和资料等。
|
|
|
|
|
|
（1）检验和测试网络软件中涉及数据传输各部分的配量对安全的影响。
|
|
|
|
|
|
|
|
|
|
|
|
（6）HTML源码中是否有敏感的信息或没有必须出现的信息。
|
|
|
|
|
|
兼容性／配置测试用于测试软件与先前发布过的版本、有依赖关系的外部软件、运行的系统的各种版本和硬件平台的不同配置的兼容情况。
|
|
|
|
|
|
（1）检查版本是否兼容。检查新版本操作习惯与老版本是否兼容，目的是使老版本的用户很快地适应新版本的变化。
|
|
|
|
（2）检查数据格式是否兼容。数据格式有许多种形式，如文件格式、网络协议和共享数据等。例如，通信协议软件版本升级后，检查升级版本和老版本的通信协议是否一致等。
|
|
|
|
（3）检查系统调用的兼容性。检查系统的哪些功能依赖于系统调用，是否属于某个平台或版本独有，是否在不同平台上有差异。
|
|
|
|
（4）检查是否支持操作系统、数据库系统、硬件和软件平台。配置测试用例设计主要指软硬件环境配置的测试用例，检查计算机系统内各个设备或各种资源之间的相互关联和功能分配中的错误。
|
|
|
|
|
|
容错性测试是检查软件在异常条件下自身是否具有防护性措施或者灾难恢复手段。如当系统出错时，能否在指定时间间隔内修正错误并重新启动。可以把容错性测试看作是由系统异常处理测试和恢复测试组成的。
|
|
|
|
|
|
可用性是指系统正常运行的能力和用户接受的程度，一般用如下公式表示。
|
|
|
|
可用性=平均正常工作时间／（平均正常工作时间+平均修复时间）
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
（9）硬件故障（硬盘、控制器、网络设备、服务器、电源、内存和CPU）。
|
|
|
|
（10）环境问题（电源、冷却、火、洪水、灰尘、自然灾害）。
|
|
|
|
|
|
（1）使用集群。集群是指将至少两个系统连接到一起，像一个系统那样工作。当某一系统出现失效时，集群提供即时故障转移服务。
|
|
|
|
（2）使用网络负载平衡。当检测某服务器失败后，网络负载平衡自动将通信量重新分发给仍然运行的服务器。
|
|
|
|
（3）使用服务级别协议。可用性指标的期望服务级别要求达到4个或5个“9”。例如，“该应用程序应每周运行7天，每天24小时，年可用性为99.99%”是指全年不能正常工作的时间仅仅只有52分钟，不足1个小时。
|
|
|
|
（4）提供实时的监视。监视系统的工作负荷和失败数据，实时监视对于发现趋势和改善服务至关重要。
|
|
|
|
|
|
（6）检查所有的安全计划。安全性是确保应用程序服务只对有权使用系统的用户可用，还意味着使得应用程序使用的所有分布式组件和资源受到保护。
|
|
|
|
|
|
文档测试是指对软件开发、测试和维护过程中产生的所有文档的测试，包括对需求规格分析说明书、详细设计报告、系统设计报告、用户手册以及与系统相关的一切文档的审阅和评测。例如，系统需求分析和系统设计说明书中的错误将直接导致编码的错误，用户手册作为软件的一部分，将直接影响用户对系统的使用效果。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
验收测试在测试组的协助下，由用户代表执行。测试人员在验收测试工作中将协助用户代表执行测试，并和测试观察员一起向用户解释测试用例的结果。
|
|
|
|
|
|
验收测试完全采用黑盒测试技术，其主要任务是文档资料的审查验收、软件系统的功能测试、性能测试、强化测试、性能降级执行方式测试、检查系统的余量要求、安装测试以及用户操作测试。
|
|
|
|
|
|
事实上，开发人员不可能完全预见用户实际使用程序的情况。例如，用户可能错误地理解命令，或提供一些奇怪的数据组合等。因此，软件是否真正满足最终用户的要求，应由用户进行一系列“验收测试”，通常执行Alpha测试（α测试）和Beta测试（β测试），其目的是从实际终端用户的使用角度，对软件的功能和性能进行测试，以便发现可能只有是最终用户才能发现的错误。
|
|
|
|
Alpha测试是由一个用户在开发环境下进行的测试，也可以是公司内部的用户模拟实际操作环境下进行的受控测试，Alpha测试不能由程序员或测试员完成，Alpha测试发现的错误，在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其要注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始，或在模块（子系统）测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后开始。
|
|
|
|
Beta测试是多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，不由程序员或测试员完成；因而，Beta测试是在开发者无法控制的环境下进行的软件现场应用。在Beta测试中，一旦遇到问题应向开发者报告，开发者根据用户报告，做出修改后交付给全体用户使用：Beta测试着重于产品的支持性，包括文档、客户培训和支持产品的生产能力；当Alpha测试达到一定的可靠程度后，即可开始Beta测试。
|
|
|
|
|
|
回归测试是一种验证已变更的系统的完整性与正确性的测试技术，是指重新执行已经做过的测试的某个子集，以保证修改没有引入新的错误或者没有发现出于更改而引起之前未发现的错误，也就是保证改变没有带来非预期的副作用。
|
|
|
|
|
|
（1）当软件中所含错误被发现时，如果错误跟踪与管理系统不够完善，则可能会遗漏对这些错误的修改。
|
|
|
|
（2）开发者对错误理解得不够透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身，从而造成修改失败。
|
|
|
|
（3）修改还有可能产生副作用，导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误。
|
|
|
|
|
|
通常从下面5点比较回归测试与一般测试：测试用例的新旧、测试范围、时间分配、完成时间和执行效率。
|
|
|
|
（1）测试用例的新旧。一般测试主要依据系统规格说明书和测试计划，测试用例都是新的；而回归测试依据的可能是更改了的规格说明书、修改过的程序和需要更新的测试计划，因此测试用例大部分都是旧的。
|
|
|
|
（2）测试范围。一般测试的目标是检测整个程序的正确性；而回归测试的目标是检测被修改的相关部分的正确性。
|
|
|
|
（3）时间分配。一般测试所需时间通常在软件开发之前预算；而回归测试所需的时间（尤其是修正性的回归测试）往往不包含在整个产品进度表中。
|
|
|
|
（4）完成时间。由于回归测试只需测试程序的一部分，完成所需时间通常比一般测试所需时间少。
|
|
|
|
（5）执行效率。回归测试在一个系统的生命周期内往往要多次进行，一旦系统经过修改就需要进行回归测试。
|
|
|
