各种类型的测试
1. 单元测试
是对软件或硬件基本组成单元进行的测试。其测试对象是每个模块下的实现具体功能的单元，一般对应详细设计中描述的设计单位。在具体实现时，对应的是一个或一组函数，可能需要开发 测试驱动模块或者测试工具。单元测试属于早期测试，其侧重点在于发现程序设计或实现的逻辑错误，主要属于白盒测试的范畴。
2. 集成测试
对部分模块的组合测试，验证组成系统的各部件之间接口和集成问题，这里不同模块往往是分配给不同的程序设计开发人员。
3. 系统测试
针对全部需求说明进行黑盒测试，包括系统中所有部件。总体包括功能测试和性能测试两部分，功能测试是验证系统功能是否实现产品需求的测试过程，性能测试在验证是否实现产品需求的基础上，进一步测试系统的容错性、稳定性、异常处理能力、高强度输入处理能力等系统性能方面的测试过程。其侧重点在于考察功能的需求规格符合性、功能设计或实现的用户满意度，以及系统性能的稳定性，主要属于黑盒测试的范畴。
4. 验收测试
确定系统是否满足客户验收标准而执行的正式测试，测试的结果将决定客户是否接收该系统。
5. 验证和确认
按照CMMI的定义，验证关注工作产品是否恰当的反映了对应的需求，而确认是证明所提交的产品实现了用户的要求。据此，单元测试、集成测试和系统测试属于验证（Verification）的内容，而验收测试属于确认（Validation）的内容。
6. 回归测试
版本更改后重新进行的测试，测试时既要测试改动部分，也要测试受影响部分，回归测试的关键在于决定哪些测试必须被重复，以及测试工作的可重现性。
7. 冒烟测试
主要测试被测系统是否具有基本运行功能，如启动、加载、执行基本操作等。冒烟测试在采用每日构建的开发策略中可以对构建结果进行即时验证，也可以作为验证被测系统是否满足测试入口条件、达到测试就绪状态的方法。
8. 性能测试
一般情况下，软件项目中的需求、开发和测试工作总是过于关注系统的功能，直到后期才关注系统的非功能性问题。实践证明，这种方法会给系统带来隐患，增大产品失败的风险，在项目后期需要付出极大的努力进行改正。软件的非功能方面包括软件的性能、可维护性、可扩展性、安全性和可使用性等。其中性能测试在软件的质量保证中起着重要作用，它主要包括三个方面的测试内容：客户端性能测试、网络性能测试、服务器端性能测试。通常情况下，三个方面有效结合，可以达到对系统性能起全面的分析和瓶颈的预测。
9. 白盒测试
白盒测试也称为结构测试或者逻辑驱动测试，它是在知道产品内部实现过程的情况下，通过测试来检查产品内部动作是否按照规格说明书的规定正常进行。检验程序中的每条路径是否都能按预定要求正确工作，而不管它的整体功能。白盒测试的方法主要有逻辑驱动、路径测试等，主要用于产品验证。
10. 灰盒测试
介于白盒和黑盒测试之间的一种测试，关注输出对于输入的正确性，同时也关注程序内部表现，但这种关注不象白盒那么详细完整，只是通过一些现象、事件、标志来判断内部的运行状态，有时输出是正确的，但内部其实已经发生错误，因此需要采取这样的灰盒测试方法来发现此类问题。
12. 黑盒测试
也称为功能测试或数据驱动测试，它是在已知产品应该具有的功能的情况下，通过测试来检测每个功能是否都能正常使用，在测试时完全不考虑程序内部结构，只检查程序功能是否按照需求说明书的规定正常使用，程序是否能适当的接收输入数据而产生正确的输出信息，并保证外部信息（如数据库或文件）的完整性。
13. 敏捷测试
这个目前没有找到标准定义。一般理解，在采用敏捷开发模式的项目中进行的测试，称为敏捷测试。 需要大家再补充。
集成测试
1. 什么是集成测试？
集成测试又称为“组装测试”“联合测试”。集成测试遵循特定的策略与步骤 将已经通过单元测试的各软件单元（或模块）逐步组合在一起进行测试，以期望通过测试发现各软件单元接口之间存在的问题。
理论上，凡是两个单元（如函数单元）的组合测试都可以称为集成测试。实际操作中，通常集成测试的对象为模块级的集成和子系统间的集成，其中子系统集成测试又称为组件测试。
2. 为什么要进行集成测试？
（1）在单元测试与系统测试间起到承上启下的作用。
既能发现大量单元测试阶段不容易发现的接口类错误，又可以保证在进入系统测试前 及早发现错误，缩短错误修复时间。
（2）对被测系统而言，接口错误是最常见的错误。
单元测试通常是单人执行，而集成测试通常是多人执行或第三方执行。集成测试通过模块间的交互作用和不同人的理解和交流，更容易发现实现上、理解上的不一致和差错。
3. 集成测试内容
集成测试需要关注：
（1）穿越接口的数据是否会丢失
（2）一个模块的功能是否会对另一个模块的功能产生不利影响
（3）实现子功能的模块组合起来是否能够达到预期的总体功能
（4）全局数据结构的测试
（5）共享资源访问的测试
（6）单个模块的误差经过集成的累加效应
具体测试内容：
（1）集成功能测试
（2）接口测试（函数接口、消息接口）
（3）全局数据结构测试
（4）资源测试
（5）任务优先级冲突测试
（6）性能和稳定性测试
（7）软硬件接口测试
3.1 集成功能测试
（1）集成单元实现的功能，集成后的功能，考察多个模块间的协作，既要满足集成后实现的复杂功能，也不能衍生出不需要的多余功能（错误功能）。
（2）主要关注：
a. 被测对象的各项功能是否实现。
b. 异常情况是否有相关的错误处理。
c. 模块间的协作是否高效合理。
3.2 接口测试
（1）模块间的接口包括函数接口和消息接口。
（2）对函数接口的测试，需要关注函数接口参数的类型和个数的一致性、输入/输出属性的一致性、范围的一致性。
（3）对消息接口的测试，需要关注收发双方对消息参数的定义是否一致、消息和消息队列长度是否满足设计要求、消息的完整性如何、消息的内存是否在发送过程中被非法释放、有无对消息队列阻塞进行处理等。
3.3 全局数据结构测试
全局数据结构往往存在被非法修改的隐患，测试时需要关注：
（1）全局数据结构的值在两次被访问的间隔是可预知的。
（2）全局数据结构的各个数据段的内存不应被错误释放。
（3）多个全局数据结构间是否存在缓存越界。
（4）多个软件单元对全局数据结构的访问应采用锁保护机制。
3.4 资源测试
资源测试包括共享资源测试和资源极限测试。共享资源测试常应用于数据库测试和支撑的测试。
共享资源测试需要关注：
（1）是否存在死锁现象。
（2）是否存在过度利用情况。
（3）是否存在对共享资源的破坏性操作。
（4）公共资源访问锁机制是否完善。
资源极限测试关注系统资源的极限使用情况以及软件对资源耗尽时的处理，保证软件系统在资源耗尽的情况下不会出现系统崩溃。
3.5 任务优先级冲突测试
多任务环境中，需要测试任务优先级的合理性，需要考虑以下因素：
（1）实时性要求高的功能是否在高优先级任务中完成。
（2）任务优先级设计是否满足用户操作相应时间要求。
3.6 性能和稳定性测试
测试某个部件的性能指标，及时发现性能瓶颈。稳定性测试关注：
（1）是否存在内存泄漏而导致长期运行资源耗尽。
（2）长期运行后是否出现性能的明显下降。
（3）长期运行是否出现任务挂起。
4. 集成测试步骤
（1）测试计划：策略、方案、进度计划。
（2）设计和开发：测试规程、测试工具开发。
（3）测试执行：搭建环境、运行。
（4）测试评估：测试报告。
5. 集成测试注意事项
（1）集成测试活动必须纳入项目计划，并安排相应工作量。
（2）集成测试之前必须先做单元测试，而且单元测试对覆盖率应该有比较高的要求。
（3）做好集成测试，良好的组织非常重要，需要指定一个称职的集成测试组长。
（4）集成测试需要尽早考虑自动测试工具的开发。
系统测试
1. 什么是系统测试？
为了发现缺陷并度量产品质量，按照系统的功能和性能需求进行的测试。
（1）一般使用黑盒测试技术。
（2）一般由独立的测试人员完成。
（3）对于模块间交互性比较强的软件，还会有单独的集成测试，用来发现模块接口之间的错误。
2. 为什么要进行系统测试？
（1）确保产品完成了它所承诺或公布的功能，并且所有用户可以访问到的功能都有明确的书面说明。
（2）确保产品满足性能和效率的要求。
（3）确保产品是健壮的和适应用户环境的。
3. 系统测试内容
3.1 功能测试
目标：对产品的功能进行测试，检验是否实现、是否正确实现了产品功能。
方法：覆盖产品的所有功能。
工具：回归测试时可以使用工具。
3.2 性能测试
目标：对产品的性能进行测试，检验是否达标、是否能够保持产品性能。
方法：覆盖系统的性能需求，一般和负载测试结合使用。
工具：在需要大访问量时尤其需要使用工具。
3.3 负载测试
目标：在人为设置的高负载（大数据量、大访问量）情况下，检查系统是否发生功能或性能上的问题。
方法：人为生成大数据量，并使用工具模拟频繁并发访问。
工具：一般需要使用工具。
3.4 压力测试
目标：在人为设置的系统资源紧缺情况下，检查系统是否发生功能或者性能上的问题。
方法：人为减少可用的系统资源，如：内存、硬盘、网络、CPU占用、数据库响应时间。。
工具：一般需要使用工具。
3.5 疲劳测试
目标：在一段时间内（至少72小时）保持系统功能的频繁使用，检查系统是否发生功能或者性能上的问题。
方法：人为设置不同功能的连续重复操作。
工具：一般需要使用工具。
3.6 易用性测试
目标：检查系统界面和功能是否容易学习、使用方式是否规范一致，是否会误导用户或者使用模糊的信息。
一般与功能测试结合使用。
方法：可以采用用户操作、观察、反馈并评估的方式。
3.7 安装测试
目标：
a. 检查系统安装是否能够安装所有需要的文件/数据 并进行必要的系统设置；
b. 检查系统安装是否会破坏其他文件或配置；
c. 检查系统安装是否可以中止并恢复现场；
d. 检查系统是否能够正确卸载并恢复现场；
e. 检查安装和卸载过程的用户提示和功能是否出现错误。
有时安装测试作为功能测试的一部分。
3.8 配置测试
目标：在不同的硬件配置下，在不同的操作系统和应用软件环境中，检查系统是否发生功能或者性能上的问题。
方法：一般需要建立测试试验室。
3.9 文档测试
目标：检查系统的文档是否齐全，检查是否有多余文档，检查文档内容是否正确/规范/一致。
方法：一般由单独一组测试人员实施。
3.10 安全测试（包括病毒、加密、权限）
目标：
a. 检查系统是否有病毒；
b. 检查系统是否正确加密；
c. 检查系统在非授权的内部或外部用户访问或故意破坏时是否出现错误。
3.11 恢复测试
目标：在人为使系统发生灾难（系统崩溃、硬件损坏、病毒入侵等）情况下，检查系统是否能够恢复被破坏的环境或数据。
3.12 回归测试
目标：检查系统变更之后是否引入新的错误 或者 旧的错误重新出现，尤其是在每次构建之后和稳定期测试的时候。
工具：一般需要工具，而且依赖于测试用例和缺陷管理系统。
3.13 健全测试
目标：检查系统的功能和性能是否可以正常使用，来确定是否可以继续进行系统测试的其他内容。
方法：正常安装，并使用正常情况下的测试用例对主要功能进行测试，同时检查系统文档是否齐全。
3.14 交付测试
目标：关闭所有缺陷报告，确保系统达到预期的交付标准。
方法：一般需要结合回归测试，并谨慎处理新出现的故障。
交付测试也称为稳定期测试，有时候与系统测试独立划分。
3.15 演练测试
目标：在交付给用户之前，利用相似的用户环境进行测试。
3.16 背靠背测试
目标：设置一组以上的测试团队，在互相不进行沟通的情况下独立进行相同的测试项目，用来评估测试团队的效果并发现更多的错误。
3.17 度量测试
目标：在系统中 人为的放入错误，并根据被发现的比例来确定系统中遗留的错误数量。
3.18 比较测试
目标：与竞争产品及本产品的旧版本 测试同样的内容，来确定系统的优势与劣势。
比较测试属于系统测评的内容。
以上18种测试并不是每次进行系统测试都要执行的，而是在制定测试策略、测试计划时有不同的侧重点，这与测试目标、测试资源、系统特点和业务环境有关。
4. 一些有利于做好系统测试的提示
（1）所有的测试都应该追溯到用户需求。
软件测试的目标是发现错误，而最严重的错误（用户角度）是那些导致程序无法满足需求的错误。
（2）在测试工作真正开始之前，尽早开始测试计划。
（3）测试设计（测试用例设计）是做好测试的关键要素之一。
（4）Pareto原则适用于软件测试。Pareto原则表明测试发现的错误中的80%很可能起源于程序模块中的20%.
（5）如果不善于思考 你就不知道怎样有效进行测试，你不仅得不到功劳，也没人欣赏你的苦劳，你拥有最多的将只是疲劳。
性能测试
1. 性能测试定义
在验证是否实现软件系统规格的基础上，进一步验证待测系统的容错性、稳定性、异常处理能力、高强度输入处理能力等软件系统性能方面的测试过程。
- 性能测试类型
性能测试的目标主要是发现系统的性能瓶颈。根据性能测试所要达到的目标，性能测试可大体划分为如下几类：负载测试、压力测试、强度测试、大数据量测试、可靠性测试、竞争测试、配置测试、基准测试。
负载测试：用于在测试系统保持不变情况下，核实和评估系统在不同负载下操作极限的可接受性，评测包括负载及响应时间的特征，比如测试一个网站在不同负荷情况下的状况，以确定在什么情况下系统响应速度下降或是出现故障。
压力测试：经常可以与负载测试互相代替。这种测试是用来检查系统在下列条件下的情况：在非正常的巨大负荷下、某些动作和输入大量重复、输入大数、对数据库进行非常复杂的查询，等等。
强度测试：强度测试主要是为了检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。
大数据量测试：分为两种，一种是针对某些系统存储、传输、统计查询等业务进行大数据量的测试，另一种是与并发测试相结合的极限状态下的综合数据测试。作为专项的大数据量测试主要针对前者，后者尽量放在并发测试中。
可靠性测试：在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检查系统是否稳定。例如，可以施加使CPU资源保持70~90%使用率的压力，连续对系统加压运行8个小时，然后根据结果分析系统是否稳定。
竞争测试：一种性能测试，侧重于核实测试对象对于多个用户对相同资源（数据记录、内存等）的请求的处理是否可以接受的测试，比如对数据库操作的并发测试。
配置测试：在保持测试动作不变的条件下，测试 服务器性能随配置变化的可接受程度。
基准测试：该测试比较（新的或未知的）测试对象与已知的参照负载和系统的性能。
性能测试参考指标
根据性能测试的一般调查显示（性能参考）：
4秒以内： 用户可以接受
4-9秒： 30%用户选择离开
8-10秒： 60%用户选择离开
10秒以上：90%用户选择离开。
对于访问时间及并发有特殊要求的项目应明确提出要求，缺省情况下按照以上要求（50人并发）执行。性能测试场景设计
测试场景设计所要考虑的主要内容，就是模拟实际工作环境，以得到准确反映系统负荷量的模型，设计负荷量时需要考虑以下因素：
（1）负荷量时长：比如高峰时间的一小时或者一般工作日或者月末。
（2）测试变量：在性能测试中要改变的因子，比如改变用户数以了解反映时间在工作量增加时如何变化，最好一次只改变一个变量，以便在性能变化时，可以知道有关变化是由哪一变量引起的。在制定运行计划时设置测试变量。
（3）功能用户分类（用户组）：根据用户执行活动的类别将其分组。对于每个用户组，需要确定其用户数或组用户占总用户数的百分比。
（4）用户工作配置：用户进行的活动集和他们进行这些活动的频率。
（5）用户特征：用户执行一项事务前的暂停时间、输入速率和连续执行事务的次数。性能测试用例设计
性能测试用例的输入主要是补充性需求，补充性需求记录功能用例中不容易体现出来的系统需求，包括：
（1）法律法规方面的需求及应用标准。
（2）系统的质量属性，包括可用性、可靠性、性能需求及可支持性需求。
（3）其他需求，如操作系统、环境、兼容性以及设计约束。
在设计性能测试用例时，对于补充需求内阐明性能标准的各条说明都应确保至少要确定一个测试用例。
性能标准通常表示为时间/事务、事务量/用户或百分比的形式。此外，还需要确保已确定影响响应时间的特定条件，包括：
（1）数据库大小：多少条记录？
（2）工作量：同时执行操作的用户数量和类型，以及要同时执行的事务的数量和类型
（3）环境特征：硬件、网络、软件配置。
性能测试用例需要对测试执行场景进行描述，模拟实际生产环境的使用情况。
测试用例场景包括功能使用场景与环境模拟场景。功能使用场景是与系统测试用例中相对应的功能用例一致，而环境模拟场景则是描述执行性能测试的方式，比如采用多少用户执行，是否并发操作，迭代几次执行，执行多长时间等。
环境模拟场景又分为模拟真实生产环境与虚构生产环境场景。模拟真实生产环境场景是指采用测试工具模拟正常的生产环境进行执行，以测试在正常的生产环境使用压力情况下系统的表现；虚构生产环境场景则是指设计者设计特殊的场景专门用来发现系统瓶颈。
- 性能测试步骤
性能测试分为以下几个步骤：
（1）制定测试方案
（2）搭建测试环境
（3）准备测试数据
（4）编写测试脚本
（5）执行性能测试并记录测试结果
（6）分析测试结果，编写测试报告
（7）优化系统性能
确定性能测试范围：需要从项目当前的全部功能中抽取出部分常用功能或可能存在性能瓶颈功能作性能测试，必须是项目当前版本中已经实现的、且功能稳定的可测试内容。
确定性能测试目标：性能测试的目标是对被测功能的性能评价。性能目标的确定需要以下列条目为参考依据：（1）系统结构、软件架构（2）业务需求，需要详细了解每个被测功能的使用情况，用户数量及类型等，查询类功能需要明确基准测试数据量。（3）明确测试环境与实际生产环境的硬件配置差异。
制定性能测试方案：包括如下内容：（1）测试资源（2）测试工具（3）测试方法（4）环境影响因素（5）测试内容及目标（6）进度计划。
执行性能测试
（1）确定测试环境：环境稳定可用，只存在被测系统不允许其他系统部署使用，不允许其他人占用环境。
（2）准备测试数据：数据量要达到测试方案中规定的要求。
（3）准备测试脚本。
（4）执行性能测试。
测试注意事项：
(1)测试人员对性能测试申请范围内的功能进行相关设计、执行，需要注意的是对于测试范围内的功能，提交性能测试前需要保证通过功能测试，不存在功能故障，否则将无法进行性能测试。
(2)软件性能通常集中在关键功能部件上，最好首先提取出关键功能部件，进行重点测试。
(3)性能测试报告决定了后续软件改进步骤的启动/停止及执行深度，因此，测试人员需要对软件有深刻了解，测试用例设计合理，在执行期间需严格认真，注意观察数据，并核对、补充、调整测试项。
(4)测试结果分析需要多方位人员参与，但以开发人员为主。
(5)系统优化完毕后，新一轮测试中，可参照上一轮测试方案制定新的方案，对优化改进部分进行重点验证，如果发现相同的测试用例与上一轮的测试结果有较大差别，需要进行分析并查找原因。
- 性能测试实践
待补充.
