~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
为什么要进行软件测试：为了保证软件质量。控制成本。确认可靠性。让企业具备国际竞争的实力。
软件测试的定义：（1）软件测试就是一系列活动，这些活动是为了评估一个程序或软件系统的特性或能力，并确定其是否达到了预期结果。（2）测试是为了发现错误而执行一个程序或者系统的过程。（3）使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清楚预期结果与实际结果之间的差别。（4）从一个通常的无限的执行域（集合）中选择合适的、有限的测试用例，对程序所期望的行为进行动态验证的活动过程。
测试和开发的关系：现在人们普遍认为软件测试贯穿着整个软件生命周期，从需求评审、设计评审开始，测试就介入到软件产品的开发活动或软件项目实施中。
软件测试和软件开发在整个软件开发生命周期中交互协作，自始至终一起工作，共同致力于同一个目标-按时、高质量地完成项目。
软件测试和软件开发的关系与所使用的软件开发模型有关。
测试和质量保证的关系：SQA与软件测试之间相辅相成，既存有包含又存有交叉的关系。
SQA指导、监督软件测试的计划和执行，督促测试工作的结果客观、准确和有效，并协助测试流程的改进。
而软件测试是SQA重要手段之一，为SQA提供所需的数据，作为质量评价的客观依据。
它们的相同点在于二者都是贯穿于整个软件开发生命周期的流程。
它们的不同之处在于SQA是一项管理工作，侧重于对流程的评审和监控，而测试是一项技术性的工作，侧重对产品进行评估和验证。
软件质量的内涵：是指软件产品满足规定的和隐含的与需求能力有关的全部特征和特性，它包括：
（1）软件产品质量满足用户要求的程度；
（2）软件各种属性的组合程度；
（3）用户对软件产品的综合反映程度；
（4）软件在使用过程中满足用户要求的程度；
软件缺陷的定义：（1）是指计算机系统或程序中存在的任何一种破坏正常运行能力的问题、错误、或者隐藏的功能缺陷、瑕疵，其结果会导致软件产品在某种程度上不能满足用户的需要。（2）从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
动态测试和静态测试：根据程序是否运行，测试可以分为动态测试和静态测试。
静态测试包括对软件产品的需求和设计规格说明书的评审、对程序代码的审查以及静态分析等。
动态测试是通过真正运行程序发现错误，通过观察代码运行过程，来获取系统行为、变量实时结果、内存、堆栈、线程以及测试覆盖等各方面的信息，来判断系统是否存在问题，或者通过有效的测试用例，对应的输入输出关系来分析被测程序的运行情况，来发现缺陷。
软件评审：是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。包括互为评审、走查和会议评审。
静态分析：就是对系统的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和仿真运行。
验证（verification）：是检验软件是否已正确地实现了产品规格说明书所定义的系统功能和特性。是否正确地做事。
有效性确认（validation）：检验产品功能的有效性，即是否满足用户的真正需求。是否做正确的事。
主动测试：在测试环境中，测试人员主动向被测试对象发送请求、或借助数据、事件驱动被测试对象的行为，从而验证被测试对象的反应或输出结果。
被动测试：软件产品运行在实际环境中，测试人员不干预产品的运行，而是被动地监控产品的运行，通过一定的被动机制来获得系统运行的数据，包括输入、输出数据。
白盒测试：也称结构化测试或逻辑驱动测试，也就是已知产品的内部工作过程，清楚最终生成软件产品的计算机程序结构及其语句，按照程序内部的结构测试程序，测试程序内部的变量状态、逻辑结构、运行路径等，检验程序中的每条通路是否都能按照预定要求正确工作，检查程序内部动作或运行是否符合设计规格要求，所有内部成分是否按规定正常运行。
黑盒测试：也称数据驱动测试方法，在测试时，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，测试人员针对软件直接进行测试，检查系统功能是否按照需求规格说明书的规定正常使用、是否能适当地接受输入数据而输出正确的结果等，检查相应的文档是否采用了正确的模板、是否满足规范要求。
单元测试：是在编码阶段、针对每个程序单元而进行的测试，其测试对象是程序系统中的最小单元-类、函数、模块或组件等。
集成测试：是在单元测试的基础上，按照设计要求不断进行集成而进行的相应测试，目的是发现单元之间的接口问题。
系统测试
（1）功能测试：是基于产品功能说明书、用户角度来对各项功能进行验证，以确认每个功能是否都能正常使用。
（2）非功能测试：是在实际运行环境或模拟实际运行环境之上，针对系统的非功能特性所进行的测试。
验收测试：基于需求规格说明书和用户信息，验证软件的功能和性能以及其他特性。
测试用例：是为了特定的测试目的而设计的测试条件、测试数据及与之相关的测试规程的一个特定的使用实例或场景。测试用例也可以被称为有效地发现软件缺陷的最小测试执行单元。
基于输入域的方法：通过对不同数据的输入，检查其输出的数据以判断测试是否通过的方法。
基于模型的方法：采用表格、符号等方式来定义问题和分析问题的方法。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
等价类划分法：基于对输入或输出情况的评估，然后划分成两个或更多子集来进行测试的方法。即它将所有可能的输入数据划分成若干个等价类，从每个等价类中选择一定的代表值进行测试。
根据规格说明书设计有效等价类
相对有效等价类设计无效等价类
设计测试用例：
有效等价类：尽可能多的覆盖
无效等价类：逐一覆盖
处理技巧：
（1）在输入条件规定了取值范围或者个数的前提下，则可以确定1个有效等价类和2个无效等价类
（2）在输入条件规定了输入值的集合或者规定了“必须如何”的条件下，可以确定1个有效等价类和1个无效等价类
（3）在输入条件是一个布尔量的情况下，可确定1个有效等价类和1个无效的等价类
（4）在规定了一组输入数据（包括n个输入值），并且程序要对每一个输入值分别进行处理的情况下，可确定n个有效等价类和1个无效等价类
（5）在规定了输入数据必须遵守的规则的情况下，可确定1个有效的等价类和若干个无效等价类
（6）在确定已知的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步划分为更小的等价类
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
边界值分析法：就是在某个输入输出变量范围的边界上，验证系统功能是否正常运行的测试方法。
边界值分析法常被看作是等价类划分法的一种补充，两者结合起来使用更有效。
设计测试用例：选择临界值及其附近的值来进行相关功能的测试。
（临界值是有效的，其附近的值是无效的）
处理技巧：
（1）如果输入条件规定了值的范围，则取刚刚达到这个范围的边界值，以及刚刚超过这个范围边界的值
（2）如果输入条件规定了值的个数，则用最大个数、最小个数、比最大个数多1个、比最小个数少1个的数等作为测试数据
（3）根据规格说明的每一个输出条件，分别使用以上两个规则
（4）如果程序的规格说明给出的输入域或输出域是有序集合（如有序表、顺序文件等），则应选取集合的第一个和最后一个元素作为测试数据。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
判定表法：对于多因素输入和输出，如果关系简单，根据某一个输入组合就能直接判断输出结果，而且每个输入条件或输出结果都可以用“成立”或“不成立”来表示，即输入条件和输出条件只有1和0两个取值，这时就采用判定表法来设计组合（测试用例）。判定表法是借助表格方式完成输入条件的组合设计，以达到完全组合覆盖的测试效果。
判定表制定一般经过下面4个步骤：
（1）列出所有的条件桩和动作桩
（2）填入条件项
（3）填入动作项，制定初始判定表
（4）简化、合并相似规则或者相同动作
规则：任何一个条件组合的特定取值及其相应要执行的操作。在判定表中贯穿条件项和动作项的一列就是一条规则。
动作：由动作桩表示。动作桩针对问题可能采取的操作。
判定表的优化：简化、合并相似规则或者相同动作。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
因果图法：借助图形，着重分析输入条件的各种组合，每种组合条件就是“因”，它必然有一个输出的结果，这就是“果”。
用因果图法生成测试用例的步骤：
（1）分析软件规格说明书中的输入输出条件并分析出等价类，将每个输入输出赋予一个标识符（C、E等）；分析规格说明书中的语义，通过这些语义来找出相对应的输入与输入之间、输出与输出之间关系。建立因果关系表
（2）将对应的输入输入之间，输入与输出之间的关系关联起来，并将其中不可能的组合情况标注成约束或者限制条件，形成因果图。可能有中间原因
（3）由因果图转化成判定表
（4）将判定表的每一列拿出来作为依据，设计测试用例
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
借助逻辑运算的各种组合来理解逻辑覆盖和路径覆盖
判定覆盖：基本思想是设计若干测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断真价值均曾被满足过。一个判定往往代表着程序的一个分支，所以判定覆盖也被称为分支覆盖
条件覆盖：基本思想是设计若干测试用例，执行被测程序后，要使每个判定中每个条件的可能取值至少满足一次
满足判定覆盖的不一定满足条件覆盖，满足条件覆盖的也不一定满足判定覆盖
判定-条件覆盖：设计足够的测试用例，使得判断条件中的所有条件可能取值至少执行一次，同时，所有判断的可能结果至少执行一次
即使满足判定-条件覆盖，and和or互换问题是无法被检测的，所以测试仍不够充分，所以才需要引入条件组合覆盖
条件组合覆盖：基本思想是设计足够的测试用例，使得判断中每个条件的所有可能至少出现一次，并且每个判断本身的判定结果也至少出现一次。它与条件覆盖的差别是它不是简单地要求每个条件都出现“真”与“假”两种结果，而是要求让这些结果的所有可能组合都至少出现一次。
条件组合覆盖也不能保证覆盖所有路径（因为如果有两个判断and和or，那么and和or的结果可能没有充分组合）
修改的条件/判定覆盖：
（1）每一个判断的所有可能结果都出现过
（2）每一个判断中所有条件的取值都出现过
（3）每一个进入点及结束点都执行过
（4）判断中每一个条件都可以独立地影响判断的结果
必要的测试条件组合包含三组（而不是四组）
基本路径覆盖：就是设计测试用例，来覆盖程序中所有可能的、独立的执行路径
基本路径测试法的步骤：
（1）程序流程图
（2）计算程序环路复杂度（为了求出基本的可执行路径的数量）：
1. 区域数目
2. 边界数目-节点数目+2
3. 判断节点数+1
（3）确定基本路径
（4）准备测试用例，确保基本路径组中的每一条路径被执行一次
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
功能图法：就是使用功能图形式化地表示程序的功能说明，并机械地生成功能图的测试用例。功能图模型由状态迁移图和逻辑功能模型组成
（1）状态迁移图用于表示输入数据序列以及相应的输出数据，由输入和当前的状态决定输出数据和后续状态
（2）逻辑功能模型用于表示在状态输入条件和输出条件之间的对应关系。逻辑功能模型只适合于描述静态说明，输出数据仅由输入数据决定。
结合程序流程图、状态迁移图和逻辑功能表设计测试用例
从逻辑功能表中，可以根据所有的输入输出以及状态来生成所需要的节点和路径，形成实现功能图的基本路径组合。这样就可以用基本路径覆盖法来设计测试用例。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
有限状态机：是一种用来进行对象行为建模的工具，其作用主要是描述对象在它的生命周期内所经历的状态序列，以及如何响应来自外界的各种事件。
有限状态机(Finite State Machine,FSM)模型包含5个元素：
（1）输入符号、（2）输出符号、（3）状态集合、（4）状态转移函数、（5）输出函数
扩展有限状态机模型包含6个元素，增加了一个初始状态，并将FSM模型中的“状态转换函数和输出函数”变为“变量集合和转移集合”
扩展有限状态机（Extended Finite State Machine,EFSM）模型在FSM模型基础上增加了动作和转移条件以处理系统的数据流问题，而FSM模型只能处理系统的控制流问题。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
W模型：是对V模型的改进，增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V模型组成，分别代表测试和开发过程，测试伴随着整个软件开发周期，而且测试的对象不仅是程序，还包括需求定义文档、设计文档等。
（1）需求分析定义——测试目标、需求评审
（2）系统、结构设计——测试计划、系统测试用例设计和环境、设计评审
（3）详细或程序设计——功能测试用例设计
（4）编码及单元测试——代码审查、单元测试
（5）缺陷修正——功能测试
（6）缺陷修正——系统测试
（7）缺陷修正——验收测试
测试过程和开发过程都贯穿软件过程的整个生命周期，它们是相辅相成、相互依赖的关系，概括起来有以下三个关键点：
（1）测试过程和开发过程是同时开始的，同时结束的，两者保持同步的关系
（2）测试过程是对开发过程中阶段性成果和最终的产品进行验证的过程，所以两者相互依赖。前期，测试过程更多地依赖于开发过程；后期，开发过程更多地依赖测试过程。
（3）测试过程中的工作重点和开发工作的重点，可能是不一样的，两者有各自的特点。不论在资源管理方面，还是风险管理方面，两者都存在着差异。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
脚本：是一组测试工具执行的指令集合，也是计算机程序的一种形式。脚本可以通过录制测试的操作产生，然后再做修改，这样可以减少脚本开发的工作量。也可以直接用脚本语言编写脚本。
在传统测试中受传统软件开发模型的影响，测试的流程经过测试计划、设计测试用例、执行测试用例这样经典的过程。测试用例可以看做是手工执行的脚本，而工具执行测试需要像程序代码那样的自动化测试脚本，把测试用例和自动化测试脚本都可归为测试的“脚本”。
基于脚本测试：传统测试多数情况都是先设计脚本，之前也没有可执行的程序，这段时间先完成设计，一旦程序可以运行，就可以进行大规模测试——基于脚本的测试执行。
探索式测试：强调测试的学习、设计和执行同时展开，也就是没有测试用例，而是靠头脑想，一面想一面测试。这里的“想”就是设计，在头脑中设计，但不需要通过文字来描述出来。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
软件测试学派
分析学派：认为软件是逻辑性的，将测试看作是计算机科学和数学的一部分，结构化测试、代码覆盖率就是其中一些典型的例子。
他们认为测试工作是技术性很强的工作，侧重使用类似于UML工具进行分析和建模
标准学派：从分析学派分离出来的，把测试看作侧重劣质成本控制并具有可重复标准的、旨在衡量项目进度的一项工作，测试是对产品需求的确认，每个需求都需要得到验证。
质量学派：软件质量需要规范，测试就是过程的质量控制、揭示项目质量风险的活动，确定开发人员是否遵守规范，测试人员扮演产品质量的守门员角色
上下文驱动学派：认为软件是人创造的，测试所发现的每一个缺陷都和相关利益者密切相关；认为测试是一种有技巧的心理活动；强调人的能动性和启发式测试思维。探索性测试就是典型代表
敏捷学派：认为软件就是持续不断的对话，而测试就是验证开发工作是否完成，强调自动化测试。
工厂学派：强调将测试任务演化为一系列的操作过程，然后这些操作过程自动化以后，获得廉价的劳动力来执行测试
控制学派：强调标准和依据标准建立的流程，相当于上面的标准学派
测试驱动学派：强调以代码为焦点的测试，且程序员执行测试，相当于敏捷测试
分析学派：为了评估软件质量而采用分析的方法，其中包括通过提高需求规格说明书的准确性、各种建模来提高可测试性
上下文驱动学派：强调适应软件开发及应用所处的环境。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
为何进行单元测试：
（1）软件中存在的错误发现得越早，则修改和维护的费用就越低，而且难度越小，所以单元测试是早期抓住这些错误的最好时机。
（2）从目前实践来看，软件单元测试和软件集成测试难以分离，往往是同时进行的，在单元测试中实际也包含接口测试，相当于集成测试的一部分工作。
代码评审
（1）代码互查：是日常工作中使用最多的一种代码评审方式，比较容易开展，相对自由
（2）代码走查：是一种相对比较正式的代码评审过程。
在此过程中，设计者或程序员引导小组部分成员通读编码，其他成员提出问题并对有关技术、风格、可能的错误、是否有违背开发标准/规范的地方进行评论。
走查过程中，由测试成员提出一批测试实例，在会议上对每个测试用例用头脑来执行程序，在纸上或黑板上演变程序的状态。
在这个过程中，测试用例并不起关键作用，它们仅作为怀疑程序逻辑与计算错误的参考。
大多数走查中，在怀疑程序的过程中所发现的缺陷比通过测试实例本身发现的缺陷更多。
编程者对照讲解设计框图和源码图，特别是对两者相异之处加以解释，有助于验证设计和实现之间的一致性。
（3）会议审查：是一种最为正式的检查和评估方法。它是用逐步检查源代码中有无逻辑或语法错误的办法来检测故障。
可以认为它是拿代码与标准和规范对照的补充，因为它不但需要软件开发者自查，还要组织代码检查小组进行代码检查。
代码检查小组通常由独立的主持人、程序编写小组、其他组程序员和测试小组成员组成。
首先，主持人提前把程序目录表和设计说明分配给小组各成员，小组成员在开会前先熟悉这些材料，然后开会。
会议过程：
1. 由程序编写小组成员逐句阐明程序的逻辑，在此过程中可由程序员或测试小组成员提出问题，追踪缺陷是否存在
2. 利用通用缺陷检查表来分析结论。主持人负责讨论沿着建设性方向进行，而其他人则集中注意力发现缺陷
3. 记录所有已确定的缺陷，在会议之后形成《评审报告》。在《评审报告》中必须写明错误的位置、类型、影响范围和原因等，评审报告需交给程序编写者并同时存档。
4. 审查小组根据代码审查的错误记录来评估该程序，决定是否需要重新进行评审。如发现太多缺陷，那么在修正缺陷后，可能需要再开评审会议
限时、不要现场修改代码
缺陷检查表：是把程序设计中可能发生的各种缺陷进行分类，以每一类列举尽可能多的典型缺陷，然后把它们制成表格，以供在会议中使用，并且在每次审议会议之后，对新发现的缺陷也要进行分析和归类，不断充实缺陷检查表。
走查 |
会议审查 |
|
准备 |
通读设计和编码 |
应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表 |
形式 |
非正式会议 |
正式会议 |
参加人员 |
开发人员为主 |
项目组成员包括测试人员 |
主要技术方法 |
无 |
缺陷检查表 |
注意事项 |
限时、不要现场修改代码 |
限时、不要现场修改代码 |
生成文档 |
会议记录 |
静态分析错误报告 |
目标 |
代码标准规范，无逻辑错误 |
代码标准规范，无逻辑错误 |
驱动程序：也称驱动模块，用以模拟被测模块的上级模块，能够调用被测模块。在测试过程中，驱动模块接收测试数据，调用被测模块并把相关数据传送给被测模块。
桩程序：也称桩模块，用以模拟被测模块工作过程中所调用的下层模块。桩模块由被测模块调用，它们一般只进行很少的数据处理，以便于检测被测模块与其下级模块的接口。
系统级功能测试：在系统集成过程之中或之后所进行的系统功能测试，不仅要考虑模块之间的相互作用，而且要考虑系统的应用环境，其衡量标准是实现产品规格说明书上所要求的功能，特别需要模拟用户完成从头到尾的业务测试，确保系统可以完成实现设计的功能，满足用户的实际业务需求
回归缺陷：虽然已发现的程序缺陷被修复了，但可能在其他受影响的区域出现新的软件缺陷，这样的缺陷称为回归缺陷。
回归测试：回归测试就是为了发现回归缺陷而进行的测试。
回归测试目的：是在程序有修改的情况下保证原有功能正常的一种测试策略和方法，因为这时的测试不一定要进行全面的测试，从头到尾测试一遍，而是根据修改的情况进行有效的测试。
性能测试：就是为了发现系统性能问题或获取系统性能相关指标而进行的测试。
一般在真实的环境中、特定负载条件下，通过工具模拟实际软件系统的运行及操作，同时监控性能各项指标，最后对测试结果进行分析来确定系统的性能状况，整个过程就是性能测试。
性能测试基本过程：
（1）确定性能测试需求。
包括确定哪些性能指标是要度量的，以及系统会承受哪些负载，确定系统最大负载和关键业务
（2）根据测试需求，选择测试工具和开发相应的测试脚本。
一般针对选定的关键业务操作来开发相应的自动化测试脚本，并进行测试脚本的数据关联和参数化。
（3）建立性能测试负载模型。
就是确定并发虚拟用户的数量、每次请求的数据量、思考时间、加载方式和持续加载的时间等。
（4）执行性能测试。
通过多次运行性能测试负载模型，获得系统的性能数据。
（5）提交性能测试报告。
包括性能测试方法、负载模型和实际执行的性能测试、性能测试结果及其分析等。
压力测试：也称为强度测试、负载测试。是模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能、可靠性、稳定性等。
压力测试的目的：就是在软件投入使用以前或软件负载达到极限以前，通过执行可重复的负载测试，了解系统可靠性、性能瓶颈等，以提高软件系统的可靠性、稳定性，减少系统的宕机时间和因此带来的损失。
容量测试：预先分析出反映软件系统应用特征的某项指标的极限值。知道了系统的实际容量，如果不能满足要求，就应该寻求新的解决方案，以提高系统的容量。若一时没有新的解决方案，就有必要在产品发布说明书上明确这些容量的限制，避免引起软件产品使用上的纠纷。如果实际容量已经满足要求，就能帮助用户建立对产品的信心。
安全性测试：就是全面检验软件在需求规格说明书中规定的防止危险状态措施的有效性和在每一个危险状态下的反应，对软件设计中用于提高安全性的结构、算法、容错、冗余、中断处理等方案进行针对性测试，并对安全性关键的软件单元和软件部件，单独进行加强的测试，以确认其满足安全性需求。
容错性测试：主要检查系统的容错能力，检查软件在异常条件下自身是否具有防护性的措施或者某种灾难性恢复的手段。
兼容性测试：
（1）软件兼容性测试：是指验证软件之间是否正确地交互和共享信息，包括同步共享、异步共享，还包括本地交互、远程通信交互。
（2）数据共享兼容性测试：为了获得良好的兼容性，软件必须遵守公开的标准和某些约定，允许与其他软件传输、共享数据。
（3）硬件兼容性测试：就是硬件配置测试
软件可靠性：是软件系统在规定的时间内及规定的环境条件下，完成规定功能的能力
软件可靠性测试：也称软件可靠性评估，指根据软件系统可靠性结构、寿命类型和各单元的可靠性试验信息，利用概率统计方法，评估出系统的可靠性特征量。
软件可靠性模型：即为预计或估算软件的可靠性所建立的可靠性结构和数学模型。
（1）软件可靠性结构模型：是依据系统结构逻辑关系，对系统的可靠性特征及其发展变化规律做出可靠性评价。此模型既可用于软件可靠性综合评价又可用于软件可靠性分解。
（2）软件可靠性预计模型：是用来描述软件失效和软件缺陷的关系，借助这类模型，可以对软件的可靠性特征做出定量的预计或评估
验收测试：
验收测试是在软件产品完成了功能测试和系统测试之后、产品发布之前所进行的软件测试活动。它是技术测试的最后一个阶段，也称为交付测试。
验收测试一般根据产品规格说明书，严格审查产品，逐行逐字地对照说明书上对软件产品所作出的各方面要求，确保所开发的软件产品符合用户预期的各项要求，即验收测试是检验产品和产品规格说明书的一致性。
同时，验收测试也可以称为现场测试，一般在实际的运行环境或用户的使用环境下进行，而且用户也参与到验收测试过程中。
验收测试过程：
（1）在需求分析阶段建立测试计划，了解软件功能和性能要求、软硬件环境要求等，并特别要了解软件的质量要求和具体的验收要求。根据软件需求和验收要求编制验收测试计划，制定需要测试的测试项，制定测试策略以及验收通过准则，并让客户参与计划评审，直至通过。
（2）建立测试环境，根据验收测试计划、项目或产品验收准则完成测试用例的设计，并经过评审。
（3）准备测试数据，执行测试用例，记录测试结果。
（4）分析测试结果，根据验收通过准则分析测试结果，做出验收是否通过及测试评价。
（5）提交测试报告。根据产品设计说明书、详细设计说明书、验收测试结果和发现的错误信息，评价系统的设计和实现，最终通过验收测试报告给予完整的、详细的描述。
软件本地化：是将一个软件产品按特定国家或语言市场的需要进行全面定制的过程，包括翻译、重新设计、功能调整以及功能测试、是否符合各个地方的习俗、文化背景、语言和方言的验证等。
软件国际化：指为保证所开发的软件能适应全球市场的本地化工作而不需要对程序做任何系统性或结构性变化的特性，这种特性通过特定的系统设计、程序设计、编码方法来实现。也就是说，完全符合国际化的软件产品，在对其进行本地化工作的时候，只要进行一些配置和翻译工作，而不需要修改软件的程序代码。
软件本地化和软件国际化的关系：是一个辩证的关系，本地化要适应国际化的规定。而国际化是本地化的基础和前提，为本地化做准备，使本地化过程不需要对代码做改动就能完成，或将代码修改降到最低限度。
全球化：是一个概念化产品的过程，它基于全球市场考虑，以便一个产品只做较小的改动就可以在世界各地出售。全球化可以看作国际化和本地化两者合成的结果。
作为国际化软件，要么在应用软件运行时可以动态切换某种国家或地区的语言，要么在应用软件启动前或启动时可以设置某种语言。
软件国际化标准：
（1）切换语言的机制
（2）与语言无关的输出接口
（3）与语言无关的输入接口和标准的输入协议
（4）资源文件的国际化
（5）支持和包容本地化数据格式
软件本地化基本步骤：
（1）建立一个配置管理体系，跟踪目标语言各个版本的源代码
（2）创建和维护术语表
（3）从源语言代码中分离资源文件或提取需要本地化的文本
（4）把分离或提取的文本、图片等翻译成目标语言
（5）把翻译好的文本、图片重新插入目标语言的源代码版本中
（6）如果需要，编译目标语言的源代码
（7）测试翻译后的软件，调整UI以适应翻译后的文本
（8）测试本地化后的软件，确保格式和内容都正确
测试自动化的内涵：自动化测试是相对手工测试而存在的一个概念，由手工逐个地运行测试用例的操作过程被测试工具或系统自动执行的过程所代替，包括输入数据自动生成、结果的验证、自动发送测试报告等。主要是通过所开发的软件测试工具、脚本等来实现，具有良好的可操作性、可重复性和高效率等特点。测试自动化是软件测试中提高测试效率、覆盖率和可靠性等的重要手段，也可以说，测试自动化是软件测试不可分割的一部分。
脚本技术：
（1）线性脚本：是录制手工执行的测试用例得到的脚本，这种脚本包含所有的击键、移动、输入数据等，所有录制的测试用例都可以得到完整的回放。
（2）结构化脚本：类似于结构化程序设计，具有各种逻辑结构，包括选择性结构、分支结构、循环迭代结构，而且具有函数调用功能。结构化脚本具有很好的可重用性、灵活性，所以结构化脚本易于维护。
（3）数据驱动脚本：将测试脚本和数据分离开来，测试输入数据存储在独立的数据文件中，而不是存储在脚本中。针对某些功能进行测试时，操作步骤是一样的，而输入数据是不一样的，相当于一个测试用例对应一组输入数据。这样，同一个脚本可以针对不同的数据输入而实现多个测试用例的自动执行，提高了脚本的使用效率和可维护性。在实现上，一般都在脚本中引入变量，通过变量来引用数据，脚本本身描述测试的具体执行过程。
（4）关键字驱动脚本：是数据驱动脚本的逻辑扩张，实际上是封装了各种基本的操作，每个操作由相应的函数实现，而在开发脚本时，不需要关心这些基础函数，直接使用已定义好的关键字，这样的好处是脚本编写的效率会有很大的提高，脚本维护起来也很容易。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~