一.概述
1.软件测试定义两面性
2.测试的生命周期
测试需求分析-->测试设计-->测试计划-->测试执行-->质量评估
3.软件测试过程：
需求评审和设计评审是验证软件产品的需求定义和设计实现，验证所定义的产品特性是否符合客户的期望、系统的设计是否合理、是否具有可测试性以及满足非功能质量特性的要求。这个阶段主要通过对需求文档、设计文档等阅读、讨论，从中发现软件需求工程和系统设计中所存在的问题 。
单元测试的对象是程序系统中的最小单元---模块或组件上，在编码阶段进行，针对每个模块进行测试，主要通过白盒测试方法，从程序的内部结构出发设计测试用例，检查程序模块或组件的已实现的功能与定义的功能是否一致、以及编码中是否存在错误。多个模块可以平行地、对立地测试，通常要编写驱动模块和桩模块 单元测试一般由编程人员和测试人员共同完成。
集成测试，也称组装测试、联合测试、子系统测试，在单元测试的基础上，将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的模块之间问题 两种集成方式：一次性集成方式和增殖式集成方式。
功能测试一般须在完成集成测试后进行，而且是针对应用系统进行测试。功能测试是基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否都能正常使用。
系统测试是将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试，包括恢复测试、安全测试、强度测试和性能测试等。
验收测试的目的是向未来的用户表明系统能够像预定要求那样工作，验证软件的功能和性能如同用户所合理期待的那样 。
安装测试是指按照软件产品安装手册或相应的文档，在一个和用户使用该产品完全一样的环境中或相当于用户使用环境中，进行一步一步的安装操作性的测试。
软件测试与开发关系：
二.需求和设计评审
1. 产品需求审查是软件开发重要环节之一，也是测试活动之一，即静态测试——需求验证。借助需求审查保证用户需求在市场/产品需求文档及其相关文档中得到准确、完整、无歧义的反映，并使各类开发人员在需求理解上达成一致。
2.测试需求：
测试目标取决于软件质量需求，而这种需求分为功能性需求和非功能性需求，功能性的需求相对容易确定，非功能性的测试需求难以确定。
- 在制定测试计划之前，必须清楚测试需求
- 明确测试需求的优先级
- 测试需求分解得越细，对测试用例的设计质量越有帮助
- 详细的测试需求还是衡量测试覆盖率的重要依据
- 测试需求是规划具体项目资源和时间的基础。
3.功能性测试需求
（1）功能性测试需求主要是根据产品规格说明书来检验被测试的系统是否满足软件各方面的功能的使用要求，包括用户界面的友好性。
- 程序安装、启动正常，有相应的提示框、错误提示
- 各项功能符合设计要求，正常运行并输出正确结果
- 功能逻辑合理，并能处理各种异常操作
- 能接受正确的数据输入，输出结果准确，格式清晰
- 系统的各种状态按照业务流程而变化并保持稳定
支持各种应用环境，能配合硬件设备
（2）功能测试需求分析
了解需求范围-->明确目标用户-->分析功能步骤-->挖掘隐藏需求
- 了解需求想要做什么，要完成哪些功能模块
- 需求目标是谁？不同的用户角色，功能和权限是否一样？
- 要完成功能，用户需要哪些步骤
- 挖掘隐藏需求
4.用户界面及其显示要求
用户界面是和用户进行交互的窗口，其友好程度直接影响用户对于软件产品或软件服务的满意度。良好的用户体验，简单、方便和明了，让用户舒畅、愉悦
- 通用框架、浮动窗口和文字等整体布局合理
- 文字显示正常，且内容格式正确、美观。
- 色彩协调，风格前后一致， 文字标记和超链接可以打开和跳转成功
5.非功能性需求
非功能性质量需求，包括系统性能、安全性、兼容性、扩充性，其测试需求会因不同的项目类型差异较大。
- 客户端软件，如字处理软件、媒体播放软件等占用较少资源，在容错性、兼容性等方面要求高。
- Web应用系统对性能、安全性等有很高要求 客户端/服务器应用系统。
- 大型复杂企业级系统。
6.测试人员在需求评审中作用
需求评审归为静态测试范畴，包含了文档评审和技术评审双重内容，通常通过正式的评审会议来进行。而测试人员主要起着评审员的作用，检查需求定义是否合理和清楚。
- 明确自己的角色和责任
- 熟悉评审内容，为评审做好准备
- 针对问题阐述观点，而非针对个人
- 从客户角度想问题，多问几个为什么
- 在会前或会后提出自己建设性的意见
- 对发现的问题跟踪到底
- 针对需求文档等报告问题
7.设计审查
1）成功的产品开发和演化依赖于体系结构恰当的选择。软件设计一般可以分为体系结构设计和详细设计。测试人员参与设计评审保证需求能在设计中得到准确和完整的表示，也就是保证产品规格说明书的质量。
- 系统架构的审查
- 设计规格说明书的审查
- 系统部署设计的审查
- 多层次审查:high-level low-level
2）系统架构设计的审查
系统架构设计的基本要求就是保证系统具有高性能、高可靠性、高安全性、高扩展性和可管理性 。系统架构设计评审就是保证这些特性在设计中得到充分考虑。
3）组件设计的审查
- 功能和接口定义正
- 算法的有效性和优化
- 合理的数据结构、数据流和控制流
- 可测试性 等
4）系统部署设计的审查
系统部署设计的审查是基于软件服务的质量目标，用来审查软件部署的目标、策略是否合理，是否得到彻底的执行
- 着重是否服从和遵守部署设计的技术规范
- 逻辑设计的审查
- 物理设计的审查
- 可用性设计的审查
- 可伸缩型设计的验证
- 安全性设计的验证
三.测试用例设计
1.测试用例（test case）是可以被独立执行的一个过程，这个过程是一个最小的测试实体，不能再被分解。测试用例也就是为了某个测试点而设计的测试操作过程序列、条件、期望结果及其相关数据的一个特定的集合。
2.测试用例的元素：
3.如何设计出高质量的测试用例
- 客户需求导向的设计思路
- 责任到人
- 灵活的设计方法
- 测试用例设计不能局限于输入数据 尽量避免含糊的、冗长的或复杂的测试用例
- 尽量将具有相类似功能的测试用例抽象并归类
4.良好测试用例的特征
- 可以最大程度地找出软件隐藏的缺陷
- 可以最高效率的找出软件缺陷
- 可以最大程度地满足测试覆盖要求
- 既不过分复杂、也不能过分简单 使软件缺陷的表现可以清楚的判定
- 测试用例包含期望的正确的结果
- 待查的输出结果或文件必须尽量简单明了
- 不包含重复的测试用例
- 测试用例内容清晰、格式一致、分类组织
5.测试用例设计步骤
6.测试用例的创建
建立合适的、可扩展的测试用例框架，从而借助这个框架能有效地组织众多的测试用例，包括对测试用例的分类、清晰的层次结构等。
7.测试用例套件
测试套件是由一系列测试用例并与之关联的测试环境组合而构成的集合，已满足测试执行的特定要求。通过测试套件，将服务于同一个测试目标、特定阶段性测试目标或某一运行环境下的一系列测试用例有机地组合起来
.
四.单元测试
1.单元测试方法：
单元测试主要采用白盒测试方法，辅以黑盒测试方法。白盒测试方法应用于代码评审、单元程序检验之中，而黑盒测试方法则应用于模块、组件等大单元的功能测试之中。
2.黑白盒测试方法：
黑盒测试方法（Blake-box Testing），是把程序看作一个不能打开的黑盒子，不考虑程序内部结构和内部特性，而是考察数据的输入、条件限制和数据输出，完成测试。
白盒测试方法（White-box Testing），也称结构测试或逻辑驱动测试。白盒测试方法是根据模块内部结构了解，基于内部逻辑结构，针对程序语句、路径、变量状态等来进行测试，检验程序中的各个分支条件是否得到满足、每条执行路径是否按预定要求正确的工作。
驱动程序（driver），对底层或子层模块进行（单元或集成）测试时所编制的调用被测模块的程序，用以模拟被测模块的上级模块
桩程序（stub），也有人称为存根程序，对顶层或上层模块进行测试时，所编制的替代下层模块的程序，用以模拟被测模块工作过程中所调用的模块。
3.白盒测试方法的用例设计
语句覆盖，使得程序中每一条可执行语句至少被执行一次
分支覆盖，使得程序中每一个分支都至少被执行一次
|
节点① |
N < 0 : 如N= -1， -2， …， -10， … |
|
N >= 0: 如N=1，2， …， 10， … |
|
|
节点③ |
(K<N) and (R<=Max) 成立 （True） |
|
(K<N) and (R<=Max) 不成立 （False） |
|
|
节点⑤ |
R<= Max |
|
R> Max |
N= -2，Max = 10: 覆盖①②③④③④③⑥
N= 5，Max = 1: 覆盖①②③④③④③⑦
分支覆盖VS语句覆盖
条件覆盖，程序中每一个条件至少有一次被满足
条件覆盖 vs. 分支覆盖
条件覆盖不能保证分支覆盖，例如设计两个测试用例N= 1、Max = -1和N= 0、Max = 1
(K<N) and (R<=Max)＝.T. 的分支没有被覆盖
设计两个测试用例N= 3、Max = 10和N= -1、Max = 0，即覆盖了所有条件，也覆盖了所有分支
路径覆盖，对程序模块的所有独立的基本路径至少要测试一次
路径覆盖就是设计所有的测试用例，来覆盖程序中的所有可能的执行路径。基本路径测试法是在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例的方法。设计出的测试用例要保证被测试程序的每个可执行语句至少被执行一次。
示例：
确定基本路径获得测试用例：
环路复杂性：
图形矩阵：
4.代码审查
代码审查的目的就是为了产生合格的代码，检查源程序编码是否符合详细设计的编码规定，确保编码与设计的一致性和可追踪性
代码规范性的审查
- 代码规范性的审查将助于更早地发现缺陷，代码质量的提高，而且可以帮助程序员遵守规则、养成好的习惯，以达到预防缺陷的目的
- 代码风格和编程规则两者不可缺一，都应列入代码评审的范围里
- 命名规则 、缩进与对齐 、注释 和函数处理 等。
5.集成测试
非渐增式测试模式
采用大棒集成方法,先是对每一个子模块进行测试（单元测试阶段），然后将所有模块一次性的全部集成起来进行集成测试 。
因为所有的模块一次集成的，所以很难确定出错的真正位置、所在的模块、错误的原因。这种方法并不推荐在任何系统中使用，适合在规模较小的应用系统中使用。
非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。
渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进
驱动程序/驱动模块（driver），用以模拟被测模块的上级模块。驱动模块在集成测试中接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印出相应的结果。
桩程序/桩模块（stub），也有人称为存根程序，用以模拟被测模块工作过程中所调用的模块。桩模块由被测模块调用，它们一般只进行很少的数据处理，例如打印入口和返回，以便于检验被测模块与其下级模块的接口来测试。
自顶向下法(Top-down Integration)
自底向上法(Bottom-up Integration)
微软VSTS的单元测试
Visual Studio Team System（VSTS）是一套工具集，全面整合了软件设计、开发、测试、部署和人员协作工具，其开发版（Development Edition）提供了静态分析、代码剖析、代码涵盖以及其它单元测试所需的功能特性。
- 创建单元测试项目。
- 设置项目引用。
- 添加适当的测试类（一个或多个）。
- 生成主干的单元测试框架（Unit Test Framework）类和属性。
- 创建单个测试方法。
- 创建适合特定接口的逻辑
五.自动化测试
自动化测试（automated test）是相对手工测试（manual test）而存在的一个概念，由手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替。 测试工具的使用是自动化测试的主要特征
六.功能测试
1.功能测试，依据产品设计规格说明书完成对产品功能进行操作，以验证系统是否满足用户的功能性需求
2.等价类法
等价类是某个输入域的子集，在该子集中每个输入数据的作用是等效的
将程序可能的输入数据分成若干个子集，从每个子集选取一个代表性的数据作为测试用例
在分析需求规格说明的基础上划分等价类，列出等价类表
3.有效等价类是有意义的、合理的输入数据，可以检查程序是否实现了规格说明中所规定的功能和性能
无效等价类和有效等价类相反，即不满足程序输入要求或者无效的输入数据构成的集合
（设计测试用例时，要同时考虑这两种等价类。因为软件不仅要能接收合理的数据，也要能经受意外的考验。经过正反的测试才能确保软件具有更高的可靠性。）
4.确定等价类的方法
在输入条件规定了取值范围或值的个数的情况下，则可以确立一个有效等价类和两个无效等价类。
（2）边界值计方法
程序的很多错误发生在输入或输出范围的边界上，因此针对各种边界情况设置测试用例，可以更有效地发现缺陷。
设计方法： 确定边界情况（输入或输出等价类的边界） 选取正好等于、刚刚大于或刚刚小于边界值作为测试数据
（3）因果图法
在实际应用的测试之中，经常碰到多种条件及其组合的情况 通过因果图，可以建立输入条件和输出之间的逻辑模型，从而比较容易确定输入条件组合和输出之间的逻辑关系，有利于设计全面的测试用例
输入与输出关系：
E约束（异）：多个条件中至少有一个条件不成立，即Ci不能同时为1。
I约束（或）：多个条件中至少有一个条件成立，即Ci不能同时为0。
O约束（唯一）；多个条件中必须有一个且仅有一个条件成立，即Ci中只有一个为1
R约束（要求）：一个条件对另一个条件有约束，如C1是1，C2也必须须是1。
设计步骤：
分析软件规格说明书中的输入输出条件并划分出等价类，将每个输入输出赋予一个标志符
分析规格说明中的语义，通过这些语义来找出多个输入因素之间的关系。
找出输入因素与输出结果之间的关系，将对应的输入与输出之间的关系关联起来，并将其中不可能的组合情况标注成约束或者限制条件，形成因果图。
由因果图转化成决策表，任何由输入与输出之间关系构成的路径，形成决策表的一列 将决策表的每一列拿
实例（1）
根据因果图，就可以转化为判定表。这里根据条C2 与C3、C4与C5的E约束（互斥），可以减少组合
决策表方法：
一个决策表由“条件和活动”两部分组成，也就是列出了一个测试活动执行所需的条件组合。所有可能的条件组合定义了一系列的选择，而测试活动需要考虑每一个选择。
条件桩，列出问题的所有条件
动作桩：列出可能针对问题所采取的操作
条件项：针对所列条件的具体赋值（可取真值和假值）
动作项：列出在条件项组合情况下应该采取的动作
规则：任何一个条件组合的特定取值及其相应要执行的操作
功能图法：
每个程序的功能通常由静态说明和动态说明组成，静态说明描述了输入条件和输出条件之间的对应关系，而动态说明描述了输入数据的次序或者转移的次序。
功能图法就是为了解决动态说明问题的一种测试用例的设计方法
功能图由状态迁移图（state transition diagram，STD）和逻辑功能模型（logic function model， LFM）构成
状态迁移图，描述系统状态变化的动态信息——动态说明，由状态和迁移来描述，状态指出数据输入的位置（或时间），而迁移则指明状态的改变
如何设计测试用例？
功能图法设计测试用例，就是如何覆盖软件所表现出来的所有状态，可以转化为两个层次的测试用例
从功能逻辑模型（决策表或因果图）导出局部测试用例，即设计测试用例覆盖某个状态的各种输入数据的组合
从状态迁移图导出整体的测试用例，以覆盖系统（程序）控制的逻辑路径
功能图法是综合运用黑盒方法和白盒方法来设计测试用例，即整体上选用白盒方法——路径覆盖、分支和条件覆盖等，而局部上选用的是黑盒方法——决策表或因果图方法
七.系统测试
1.用户的需求可以分为功能性需求和非功能性需求，而非功能性的需求被归纳为软件产品的各种质量特性，如安全性、兼容性和可靠性等 系统测试就是针对这些非功能特性展开的，就是验证软件产品符合这些质量特性的要求，从而满足用户和软件企业自身的非功能性需求。所以，系统测试分为负载测试、性能系统、容量测试、安全性测试、兼容性测试和可靠性测试等
2.负载测试过程
- 确定所要模拟的角色及其对应的关键业务操作路径。
- 确定输入/输出参数，制定负载测试方案。
- 准备测试环境，并完成相应的测试脚本的开发。
- 设计具体的测试场景，如负载水平、加载方式等。
- 执行测试，监控输出参数，如数据吞吐量、响应时间、资源占有率等。
- 对测试结果进行分析。
- 结果不满意，需要调整测试场景，进入下一个循环。
输入参数：
负载测试是通过模拟用户的操作方式来考察系统的行为，所以人们肯定会问：如何模拟用户的行为？
- 并发用户数、并发连接数等。
- 思考时间（think time），用户发出请求之间的间隔时间 加载的循环次数或持续时间 每次请求发送的数据量。
- 加载的方式或模式，如均匀加载、峰值交替加载等
输出参数：
- 数据传输的吞吐量（Transactions）
- 数据处理效率（Transactions per second）
- 数据请求的响应时间（Response time）
- 内存和CPU使用率 连接时间（Connect Time）、发送时间（Sent Time）
- 处理时间（Process Time）、页面下载时间
- 第一次缓冲时间
- 每秒（SSL）连接数
- 每秒事务总数、每秒下载页面数
- 每秒点击次数、每秒HTTP 响应数
- 每秒重试次数
3.一些常见的性能问题
- 资源泄漏，包括内存泄漏
- 资源瓶颈，内部资源（线程、放入池的对象）变得稀缺
- CPU使用率达到100%、系统被锁定等
- 线程死锁、线程阻塞等
- 数据库连接成为性能瓶颈
- 查询速度慢或列表效率低
- 受外部系统影响越来越大
4.压力测试：
压力测试是在系统（如CPU、内存和网络带宽等）处于饱和状态下，测试系统是否还具有正常的会话能力、数据处理能力或是否会出现错误，以检查软件系统对异常情况的抵抗能力，找出性能瓶颈、功能不稳定性等问题
5.兼容性测试
是在特定的或不同的硬件、网络环境和操作系统平台上、不同的应用软件之间，验证软件系统能否正常地运行，以及能否正确存取原先版本的用户数据所进行的测试
- 与硬件兼容
- 与操作系统、平台的兼容
- 与数据库系统的兼容
- 与浏览器的兼容
- 与第三方系统的兼容
- 与内部业务系统的兼容
- 与自身系统的不同版本的用户数据兼容等
向后兼容是指新发布的软件版本可以使用该软件的以前版本所产生的数据。
向前兼容是指在设计和开发软件一个新版本时，考虑如何和未来版本的数据兼容。
八.总结
软件测试定义：在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。
软件测试过程：通常按照测试阶段分为单元测试、集成测试、确认测试、系统测试、验收测试、回归测试、Alpha测试、Beta测试。
单元测试，又称模块测试，是针对软件设计的最小单位 ─ 程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。
1. 单元测试的内容
(1) 模块接口测试
* 在单元测试的开始，应对通过被测模块的数据流进行测试。测试项目包括：
– 调用本模块的输入参数是否正确；
– 本模块调用子模块时输入给子模块的参数是否正确；
– 全局量的定义在各模块中是否一致
* 在做内外存交换时要考虑：
– 文件属性是否正确；
– OPEN与CLOSE语句是否正确；
– 缓冲区容量与记录长度是否匹配；
– 在进行读写操作之前是否打开了文件；
– 在结束文件处理时是否关闭了文件；
– 正文书写/输入错误，
– I/O错误是否检查并做了处理。
(2) 局部数据结构测试
* 不正确或不一致的数据类型说明
* 使用尚未赋值或尚未初始化的变量
* 错误的初始值或错误的缺省值
* 变量名拼写错或书写错
* 不一致的数据类型
* 全局数据对模块的影响
(3) 路径测试
* 选择适当的测试用例，对模块中重要的执行路径进行测试。
* 应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。
* 对基本执行路径和循环进行测试可以发现大量的路径错误。
(4) 错误处理测试
* 出错的描述是否难以理解
* 出错的描述是否能够对错误定位
* 显示的错误与实际的错误是否相符
* 对错误条件的处理正确与否
* 在对错误进行处理之前，错误条件是否已经引起系统的干预等
(5) 边界测试
* 注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。
* 如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。
2. 单元测试的步骤
* 模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其它模块。
– 驱动模块 (driver)
– 桩模块 (stub) ── 存根模块
* 如果一个模块要完成多种功能，可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。
* 对支持某些标准规程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。
集成测试，也叫组装测试、联合测试
1. 一次性集成方式(big bang)
* 它是一种非增殖式组装方式。也叫做整体拼装。
* 使用这种方式，首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。
2. 增殖式集成方式
* 这种集成方式又称渐增式集成
* 首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统
* 在集成的过程中边连接边测试，以发现连接过程中产生的问题
* 通过增殖逐步组装成为要求的软件系统。
(1) 自顶向下的增殖方式
* 这种集成方式将模块按系统程序结构，沿控制层次自顶向下进行组装。
* 自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。
* 选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能。
(2) 自底向上的增殖方式
* 这种集成的方式是从程序模块结构的最底层的模块开始集成和测试。
* 因为模块是自底向上进行组装，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以直接运行子模块得到。
* 自顶向下增殖的方式和自底向上增殖的方式各有优缺点。
* 一般来讲，一种方式的优点是另一种方式的缺点。
(3) 混合增殖式测试
* 衍变的自顶向下的增殖测试
– 首先对输入/输出模块和引入新算法模块进行测试；
– 再自底向上组装成为功能相当完整且相对独立的子系统；
– 然后由主模块开始自顶向下进行增殖测试。
* 自底向上-自顶向下的增殖测试
– 首先对含读操作的子系统自底向上直至根结点模块进行组装和测试；
– 然后对含写操作的子系统做自顶向下的组装与测试。
确认测试，又成有效性测试。
1. 进行有效性测试（黑盒测试）
* 有效性测试是在模拟的环境 (可能就是开发的环境) 下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。
* 首先制定测试计划，规定要做测试的种类。还需要制定一组测试步骤，描述具体的测试用例。
* 通过实施预定的测试计划和测试步骤，确定
– 软件的特性是否与需求相符；
– 所有的文档都是正确且便于使用；
– 同时，对其它软件需求，例如可移植性、兼容性、出错自动恢复、可维护性等，也都要进行测试
* 在全部软件测试的测试用例运行完后，所有的测试结果可以分为两类：
– 测试结果与预期的结果相符。这说明软件的这部分功能或性能特征与需求规格说明书相符合，从而这部分程序被接受。
– 测试结果与预期的结果不符。这说明软件的这部分功能或性能特征与需求规格说明不一致，因此要为它提交一份问题报告。
2. 软件配置复查
软件配置复查的目的是保证软件配置的所有成分都齐全；
各方面的质量都符合要求；
具有维护阶段所必需的细节；
而且已经编排好分类的目录。
应当严格遵守用户手册和操作手册中规定的使用步骤，以便检查这些文档资料的完整性和正确性。
系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
验收测试，以用户为主的测试
应交付的文档有：
– 确认测试分析报告
– 最终的用户手册和操作手册
– 项目开发总结报告。
软件测试方法：是指测试软件的方法。如，兼容性测试、UI测试、冒烟测试、随机测试、本地化能力测试、国际化测试、安装测试、卸载测试、白盒测试、黑盒测试、自动化测试、端到端、性能测试、负载测试、压力测试、强迫测试、健全测试、衰竭测试、恢复测试、安全测试、接口测试。
兼容性测试，指测试软件是否可以被成功移植到指定的硬件或软件平台上。
1，浏览器兼容测试
2，分辨率兼容测试
硬件兼容：与整机兼容、与外设兼容
软件兼容：操作系统/平台、应用软件之间的兼容、不同浏览器的兼容、数据库的兼容、软硬件配合兼容
数据兼容：不同版本间的数据兼容、不同软件间的数据兼容
UI测试，是指软件中的可见外观及其底层与用户交互的部分。
用户界面的风格是否满足客户要求
文字是否正确
页面是否美观
文字，图片组合是否完美
操作是否友好
包括菜单，对话框及对话框上所有按钮，文字，出错提示，帮助信息 (Menu 和Help content)等方面的测试。
冒烟测试的对象是新编译的每一个需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。
随机测试，没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段，是保证测试覆盖完整性的有效方式和过程。重点对一些特殊点情况点、特殊的使用环境、并发性、进行检查。尤其对以前测试发现的重大Bug，进行再次测试，可以结合回归测试一起进行。
本地化能力测试，指不需要重新设计或修改代码，将程序的用户界面翻译成任何目标语言的能力。
典型错误包括：字符的硬编码（即软件中需要本地化的字符写在了代码内部），对需要本地化的字符长度设置了固定值，在软件运行时以控件位置定位，图标和位图中包含了需要本地化的文本，软件的用户界面与文档术语不一致等。
国际化测试，指验证软件程序在不同国家或区域的平台上也能够如预期的那样运行，而且还可以按照原设计尊重和支持使用当地常用的日期，字体，文字表示，特殊格式等等。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语（可选）的混合字符。
安装测试，是确保软件在正常情况和异常情况下，例如，进行首次安装、升级、完整的或自定义的安装都能进行安装的测试。异常情况包括磁盘空间不足、缺少目录创建权限等场景。核实软件在安装后可立即正常运行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装，安装代码提供安装一些程序能够运行的基础数据。
卸载测试，是对软件的全部、部分或升级卸载处理过程的测试。主要是测试软件能否卸载，卸载是否干净，对系统有无更改，在系统中的残留与后来的生成文件如何处理等。还有原来更改的系统值是否修改回去。
白盒测试，是把测试对象看作一个打开的盒子。利用白盒测试法进行动态测试时，需要测试软件产品的内部结构和处理过程，不需测试软件产品的功能。白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。其中逻辑覆盖包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖。
常用工具有：Jtest、VcSmith、Jcontract、C++ Test、CodeWizard、logiscope。
黑盒测试，根据软件的规格对软件进行的测试，以用户的角度，通过各种输入和观察软件的各种输出结果来发现软件存在的缺陷，而不关心程序具体如何实现的一种软件测试方法。
常用工具有：Autorunner、winrunner
自动化测试，使用自动化测试工具来进行测试，这类测试一般不需要人干预，通常在GUI、性能等测试和功能测试中用得较多。通过录制测试脚本，然后执行这个测试脚本来实现测试过程的自动化。
常用工具有QTP、Testcomplete、Autorunner和TAR等。
端到端，涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话，用网络通讯，或与外部硬件、应用系统或适当的系统对话。端到端架构测试包含所有访问点的功能测试及性能测试。端到端架构测试实质上是一种"灰盒"测试，一种集合了白盒测试和黑盒测试的优点的测试方法。
性能测试，是在交替进行负荷和强迫测试时常用的术语。理想的“性能测试”(和其他类型的测试)应在需求文档或质量保证、测试计划中定义。性能测试一般包括负载测试和压力测试。通常验证软件的性能在正常环境和系统条件下重复使用是否还能满足性能指标。或者执行同样任务时新版本不比旧版本慢。一般还检查系统记忆容量在运行程序时会不会出现内存泄露(memory leak)。比如，验证程序保存一个巨大的文件新版本不比旧版本慢。
负载测试，测试一个应用在重负荷下的表现。例如测试一个 Web 站点在大量的负荷下，何时系统的响应会退化或失败，以发现设计上的错误或验证系统的负载能力。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。
压力测试，压力测试是一种基本的质量保证行为，它是每个重要软件测试工作的一部分。压力测试的基本思路很简单：不是在常规条件下运行手动或自动测试，而是在计算机数量较少或系统资源匮乏的条件下运行测试。通常要进行压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽等。一般用并发来做压力测试。
强迫测试，是在交替进行负荷和性能测试时常用的术语。也用于描述对象在异乎寻常的重载下的系统功能测试之类的测试，如某个动作或输入大量的重复，大量数据的输入，对一个数据库系统大量的复杂查询等。
健全测试，是指一个初始化的测试工作，以决定一个新的软件版本测试是否足以执行下一步大的测试能力。例如，如果一个新版软件每5分钟与系统冲突，使系统陷于泥潭，说明该软件不够“健全”，不具备进一步测试的条件。
衰竭测试，是指软件或环境的修复或更正后的“再测试”。可能很难确定需要多少遍再次测试。尤其在接近开发周期结束时。自动测试工具对这类测试尤其有用。
恢复测试，是测试一个系统从如下灾难中能否很好地恢复，如遇到系统崩溃、硬件损坏或其他灾难性问题。恢复测试指通过人为的让软件（或者硬件）出现故障来检测系统是否能正确的恢复，通常关注恢复所需的时间以及恢复的程度。恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化（reinitialization）、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。
安全测试，是测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。这可能需要复杂的测试技术。安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如：
①想方设法截取或破译口令；
②专门定做软件破坏系统的保护机制；
③故意导致系统失败，企图趁恢复之机非法进入；
④试图通过浏览非保密数据，推导所需信息，等等。
接口测试，测试系统组件间接口的一种测试。要进行接口，需要完善的文档进行保障，没有测试文档，接口测试将寸步难行，接口测试将增加开发过程规范化产出，而规范化产出也保证了项目质量