软件测试
是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例(即输入数据及其预期的输出结果)，并利用这些测试用例去运行程序，以发现程序错误的过程。测试要以查找错误为中心，而不是为了演示软件的正确功能，不是为了评估软件或改正错误。
软件测试主要工作内容是验证（verification）和确认（validation）
软件 测试对象
包括源程序、目标程序、文档、数据。软件测试从软件生命周期的第一个阶段开始并贯穿整个的软件生命周期。因此需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序等等都应该是软件测试的对象。
软件测试分类：
人工测试：如个人复查，抽查和会审等
机器自动测试：又有不同的分类：
按照否关软件内部结构具体实现角度划
A.白盒测试B.黑盒测试 C.灰盒测试
按照软件发展进程按开发阶段划分
A.单元测试 B.集成测试 C.确认测试 D.系统测试 E.验收测试
白盒测试用例设计有如下方法:基本路径测试\边界值分析\覆盖测试\循环测试\数据流测试\程序插桩测试\变异测试.这时候依据就是详细设计说明书及其代码结构
黑盒测试用例设计方法:基于用户需求的测试\功能图分析方法\等价类划分方法\边界值分析方法\错误推测方法\因果图方法\判定表驱动分析方法\正交实验设计方法.依据是用户需求规格说明书,详细设计说明书。
软件测试用例基本元素：
软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果。
用例编号：测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则：
PROJECT1-ST-001 ，命名规则是项目名称+测试阶段类型(系统测试阶段)+编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。
测试标题：对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” .
重要级别：定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ;
测试输入：提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。
操作步骤：提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。
预期结果：提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过;反之则测试通过。
软件验收测试分为三类：
正式验收测试；
非正式验收测试其中包括α测试（由用户、测试人员、开发人员共同参与的内部测试。）
和β测试（内测后的公测，即完全交给最终用户测试。）
测试人员主要负责设计测试用例以及设计测试过程和脚本。
测试经理制定测试计划；测试经理组织开发人员评估测试活动。
代码评审人员一般由开发人员担任
需求文档测试：1、需求文档是否符合用户需求；2、需求文档是否符合逻辑；3、技术上是否能实现；
设计文档测试：测试设计是否符合全部需求以及设计是否合理。
设计系统测试计划需要参考的项目文档有（3个）：【软件测试计划】、【软件需求】是软件开发之前做好的，软件开发是根据这个做的，那么软件测试自然也需要参考该文件【迭代计划】是软件的某个周期的计划，自然也需要参考
而【可行性】是软件开发前做好，用于证明该计划可行的，没有必要参考。
白盒测试
白盒测试(White-boxTesting，又称逻辑驱动测试,结构测试),它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试主要用于软件验证。
对开发语言的支持：白盒测试工具是对源代码进行的测试，测试的主要内容包括词法分析与语法分析、静态错误分析、动态检测等。目前测试工具主要支持的开发语言包括：标准C、C++、Visual C++、Java、Visual J++等。
“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。
白盒测试划分为：逻辑覆盖测试和基本路径测试
1.语句覆盖：可执行语句至少被执行一次；
2.判定覆盖：每个判断的取真分支和取假分支至少经历一次；
如果某测试用例集实现了某软件的路径覆盖，那么它一定同时实现了该软件的判定覆盖。
3.条件覆盖：每个条件的取值至少满足一次；
4.判断条件覆盖：判断和条件都满足；
5.条件组合覆盖：每个条件的所有可能都至少出现一次，并且判定结果至少出现一次；
他与条件覆盖的区别：他不是简单要求每个条件出现“真”和“假”两种结果，而是要求这些结果所有可能至少出现一次；
6.路径测试：执行所有可能的执行路径；
7.基本路径测试：路径测试执行了每个路径，每个判定的结果肯定经历过一次
涉及路径测试的测试阶段有:单元测试和集成测试。
逻辑覆盖测试是通过对程序逻辑结构的遍历实现程序的覆盖。=》白盒测试
从覆盖源代码的不同程度可以分为以下六个标准：语句覆盖、判定覆盖（又称为分支覆盖）、条件覆盖、判定-条件覆盖（又称为分支-条件覆盖）、条件组合覆盖和路径覆盖。
黑盒测试是对软件已经实现的功能是否满足需求进行测试和验证，黑盒测试完全不考虑程序内部的逻辑结构和内部特性，只根据程序的需求和功能规格说明，检查程序的功能是否符合它的功能说明。主要研究需求规格说明和概要设计说明。
分类：有随机测试法，等价类划分，边界值测试，组合测试（因果图），正交试验设计法，错误推测法等。
错误推测法是指：在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。
等价类划分
所谓等价类是指输入域的某个互不相交的子集合，所有等价类的并集便是整个输入域。目的在于测试用例的无冗余性。
划分等价类 (1)有效等价类:检验程序是否实现了规格说明预先规定的功能和性能。
(2)无效等价类:检查软件功能和性能的实现是否有不符合规格说明要求的地方。
举例：有效等价类：1.长度为1-6；2.字符为‘0’-‘9’或者‘a’-‘z’或者‘A’-‘Z’
无效等价类：3.长度为0；4.长度大于等于7；5.含有英文/数字以外的字符
边界值分析：边界值分析是一种黑盒测试方法，也可以用于白盒测试，是对等价类分析方法的一种补充。
由长期的测试工作经验得知，大量的错误是发生在输入或输出的边界上。因此针对各种边界情况设计测试用例，可以查出更多的错误。
等值分析测试 黑盒测试最广的用例设计技术：等值分析测试=等价类划分+边界值分析测试
因果图（组合测试）方法简介
1.定义：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
2.因果图法产生的背景：
等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。
如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。
如果能够执行完美的黑盒测试，还需要进行白盒测试吗?
任何工程产品(注意是任何工程产品)都可以使用以下两种方法之一进行测试。
黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。白盒测试：已知产品的内部工作过程，可以通过测试证明每种内部操作是否符合设计规格要求，所有内部成分是否已经过检查。
软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误：
1、是否有不正确或遗漏的功能?
2、在接口上，输入是否能正确的接受?能否输出正确的结果?
3、是否有数据结构错误或外部信息(例如数据文件)访问错误?
4、性能上是否能够满足要求?
5、是否有初始化或终止性错误?
软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序状态，确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查：
1、对程序模块的所有独立的执行路径至少测试一遍。
2、对所有的逻辑判定，取“真”与取“假”的两种情况都能至少测一遍。
3、在循环的边界和运行的界限内执行循环体。
4、测试内部数据结构的有效性，等等。
以上事实说明，软件测试有一个致命的缺陷，即测试的不完全、不彻底性。由于任何程序只能进行少量(相对于穷举的巨大数量而言)的有限的测试，在未发现错误时，不能说明程序中没有错误。
静态测试和动态测试
通过运行程序测试软件称为动态测试.通过评审文档、阅读代码等方式测试软件称为静态测试。
在动态测试中,通常使用白盒测试和黑盒测试从不同的角度设计测试用例,查找软件代码中的错误.
静态测试方法是指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。
不要求在计算机上实际执行所测程序，主要以一些人工的模拟技术对软件进行分析和测试。静态测试包括代码检查、静态结构分析、代码质量度量等。它可以由人工进行，充分发挥人的逻辑思维优势，也可以借助软件工具自动进行。人工测试技术主要包含三种静态测试技术，分别是走查、审查和正式评审。
软件缺陷等级的划分可以用严重性和优先级来描述；
严重性：衡量缺陷对客户满意度的影响程度，分为
1,致命错误，可能导致本模块以及其他相关的模块功能异常，死机等问题；
2.严重错误，问题局限在本模块，导致模块功能失常或异常退出；
3.一般错误，模块功能部分失效；
4.建议模块，有问题提出人对测试模块的改进建议；
优先级：缺陷被修复的紧急程度；
1.立即解决（P1级）：缺陷导致系统功能几乎不能使用或者测试不能继续，需立即修复；
2.高优先级（P2级）：缺陷严重，影响测试，需优先考虑；
3.正常排队（P3级）：缺陷需要正常排队等待修复；
4.低优先级（P4级）：缺陷可以在有时间的时候被纠正；
针对缺陷采取怎样的管理措施?
1. 要更好的管理缺陷，必须引入缺陷管理工具，商用的或者开源的都可。
2. 根据缺陷的生命周期，考虑缺陷提交的管理、缺陷状态的管理和缺陷分析的管理。
3. 所有发现的缺陷(不管是测试发现的还是走读代码发现的)都必须全部即时的、准确的提交到缺陷管理工具中，这是缺陷提交的管理。
4. 缺陷提交后，需要即时的指派给相应的开发人员，提交缺陷的人需要密切注意缺陷的状态，帮助缺陷的尽快解决。缺陷解决后需要即时对缺陷的修复进行验证。这样的目的有两个：一个是让缺陷尽快解决;二是方便后面缺陷的分析(保证缺陷相关的信息准确，如龄期等)，这是缺陷状态的管理。 5. 为了更好的改进开发过程和测试过程，需要对缺陷进行分析，总结如缺陷的类别、缺陷的龄期分布等信息，这是缺陷分析的管理。
JUnit 是由 ErichGamma 和 KentBeck 编写的一个 回归测试 框架（ regressiontesting framework ）。 Junit 测试是程序员测试，即所谓 白盒测试 ，因为程序员知道被测试的软件如何（ How ）完成功能和完成什么样（ What ）的功能。 Junit 是一套框架，继承TestCase 类，就可以用 Junit 进行自动测试了。
单元测试集中在每个模块上，保证源代码的正确性，该阶段成为单元测试，主要用白盒测试方法。接下来是模块集成和集成以便组成完整的软件包。集成测试集中在证实和程序构成问题上。主要采用黑盒测试方法，辅之以白盒测试方法。
软件集成后，需要完成确认和系统测试。确认和系统测试提供软件满足所有功能、性能需求的最后保证。确认测试仅仅应用黑盒测试方法。验收测试旨在向软件的购买者展示该软件满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。
回归测试是在软件的维护阶段，对软件进行修改之后进行的测试，其目的是检验对软件的修改是否正确。
单元测试（unit testing），是指对软件中的最小可测试单元（软件基本组成单元）进行检查和验证。
测试重点是系统的模块，包括子程序的正确性验证等。
单元测试能发现约80%的软件缺陷。因为缺陷放大理论，在单元测试阶段发现的bug会在系统测试阶段被放大，放大倍数完全符合80/20理论。
对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
集成测试：集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。
实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。测试重点是模块间的衔接以及参数的传递等。
主要包括以下过程：1. 构建的确认过程。 2. 补丁的确认过程。 3. 系统集成测试测试组提交过程。 4. 测试用例设计过程。 5. 测试代码编写过程。 6. Bug的报告过程。 7. 每周/每两周的构建过程。 8. 点对点的测试过程。 9. 组内培训过程。
集成测试分类：分为渐增组装测试和非渐增组装测试。渐增组装测试，是测完一个再加上一个一起测试。非渐增组装测试，是一个一个的测试
集成测试：一种旨在暴露单元接口之间、组件/系统间 交互或协同工作时所存在的缺陷的测试
不同层次的集成测试：
- 软件单元与软件单元的集成测试
- 软件子系统和子系统的集成测试
- 软件系统和第三方系统的集成测试
- 软件系统和硬件的集成测试
集成测试最关键的在接口测试
系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。
测试重点是整个系统的运行以及与其他软件的兼容性。
包括：主要记住这些：功能测试（正确性，可靠性，易用性测试），性能测试（负载测试，压力测试，强度测试），容量测试，安全性测试等。
系统测试的16个策略：功能测试，性能测试，压力测试，容量测试，安全性测试，GUI测试，可用性测试，安装测试，配置测试，异常测试，备份测试，健壮性测试，文档测试，在线帮助测试，网络测试，稳定性测试
性能测试： 检查系统能力的最高实际限度，即软件在一些超负荷情况下的运行情况，是测试过程中不可或缺的一个环节，它是通过自动化脚本的测试工具模拟多种正常、峰值以及异常条件来对系统的各项性能指标进行测试。
恢复测试：是测试一个系统从如下灾难中能否很好地恢复，如遇到系统崩溃、硬件损坏或其他灾难性问题。 恢复测试指通过人为的让软件（或者硬件）出现故障来检测系统是否能正确的恢复，通常关注恢复所需的时间以及恢复的程度。
负载测试：用于验证应用系统在正常负载条件下的行为。在一定的工作负荷下，系统的负荷及响应时间。
负载测试是模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）【这些都是性能测试的数据指标】等，以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。所以可以检验系统的最高能力。
压力测试：适用于评估应用系统处于或超过预期负载的性能测试。
压力测试是在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。所以是检测超出负荷下的行为。系统的最高能力是压力测试，而负载测试是在超荷情况下的性能测试
强度测试：在一定的负荷条件下，在较长时间跨度内的系统连续运行给系统性能所造成的影响。
容量测试：容量测试目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限值状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。容量测试的目的是使系统承受超额的数据容量来发现它是否能够正确处理。容量测试是面向数据的，并且它的目的是显示系统可以处理目标内确定的数据容量。
验收测试：旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集.
合格通过准则是：1、软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。2、所有测试项没有残余一级、二级和三级错误。3、立项审批表、需求分析文档、设计文档和编码实现一致。4、验收测试工件齐全。
Alpha和bata测试属于验收测试
Alpha测试（alpha）由用户、测试人员、开发人员共同参与的内部测试。是指软件开发公司组织内部人员模拟各类用户对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。α测试的关键在于尽可能逼真地模拟实际运行环境和用户对软件产品的操作并尽最大努力涵盖所有可能的用户操作方式。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。Alpha测试可以从软件产品编码结束之后开始，或在模块(子系统)测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。有关的手册(草稿)等应该在Alpha测试前准备好。经过α测试调整的软件产品称为β版本。
bata测试（beta）内测后的公测，即完全交给最终用户测试。β测试是由软件的多个用户在实际使用环境下进行的测试，这些用户返回有关错误信息给开发者。测试时，开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用。在β测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告。β测试着重于产品的支持性，包括文档，客户培训和支持产品生产能力。只有当α测试达到一定的可靠程度时，才能开始β测试。它处在整个测试的最后阶段。同时，产品的所有手册文本也应该在此阶段完全定稿。是验收测试的一种。
回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。
目的是在程序有修改的情况下，保证原有功能正常的一种测试策略和方法。
说白了就是，我们测试人员在对程序进行测试时发现bug，然后返还程序员修改，程序员修改后发布新的软件包或新的软件补丁包给我们测试人员，我们就要重新对这个程序测试，已保证程序在修正了以前bug的情况下，正常运行，且不会带来新的错误的这样一个过程。一般情况下是不需要全面测试的，而是根据修改的情况进行有效的测试。