测试术语：
黑盒测试：black-box ，功能测试、数据驱动测试，基于规格说明的测试，实际是站在最终用户的立场上，检验输入输出信息及系统性能指标是否符合规格，说明书中有关功能需求及性能需求的规定。
白盒测试：white-box，称为结构测试，逻辑驱动测试，基于程序本身的测试，着重于程序的内部结构和算法，通常不关心功能与性能指标。（把软件当一个透明的盒子，能看见软件内部的程序）
测试用例：就是设计一个情况，描述输入数据、动作、时间和一个期望的结果，其目的是确定应用程序的某个特性在这种情况下是否正确工作。
软件缺陷：软件功能未实现，性能不达标，难以理解，不易使用，运行缓慢或者（从测试的角度看）最终用户会认为不好。
软件测试4个定义：
正向思维：
出发点是使自己确信产品是能够正常工作的评价一个程序和系统的特性或能力，并确定它是否达到预期的结果，软件测试就是以此为目的的任何行为。
反向思维：
测试是为了发现错误而执行一个程序或者系统的过程。
测试是为了证明程序有错，而不是证明程序无错误。
一个好的测试用例在于它能发现以前未发现的错误。
一个成功的测试是发现了以前未发现的错误的测试。
IEEE定义的测试（官方定义）：
在规定条件下运行系统或构件的过程：观察和记录结果，并对系统或构件的某些方面给出评价。
分析软件项目的过程：检测现有状况和所需状况之间的不同，并评估软件项目的特性。
广义软件测试定义：
软件测试是对软件形成过程中的所有工作产品（包括程序以及相关文档）进行的测试，而不仅仅是对程序的运行进行的测试。（狭义软件测试只做这点）
软件测试的目的：（1句话记忆：尽可能早的找出软件产品中潜藏的缺陷，并确保其得以修复。）
☆☆☆☆☆以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，通过修正各种错误和缺陷保证软件质量，避免软件发布后由于潜在的软件错误和缺陷造成的隐患所带来的商业风险。☆☆☆ 同时利用测试过程中得到的测试结果和测试信息，作为后续项目开发和测试过程中改进的重要输入，避免在将来的项目开发和测试中重复同样的错误。采用更加高效的测试管理手段，提高软件测试的效率和产品的质量。
测试需要保证以下两点：
程序做了它应该做的事情
程序没有做它不该做的事
软件测试的对象：软件的定义：程序、数据、文档（需求文档、设计文档、帮助文档等）
软件测试过程管理理念：☆☆
尽早测试：
测试人员早期参与软件项目，及时开展测试的准备工作，包括编写测试计划、制定测试方案以及准备测试用例。尽早地开展测试执行工作，一旦代码模块完成就应该及时开展单元测试，一旦代码模块被集成成为相对独立的子系统，便可以开展集成测试，一旦有BUILD提交，便可以开展系统测试工作。
全面测试：
对软件的所有产品进行全面的测试，包括需求、设计文档、代码、用户文档等。软件开发及测试人员（有时也包括用户）全面的参与到测试工作中。
全过程测试：
测试人员要充分关注开发过程，对开发过程的各种变化及时做出响应。测试人员要对测试的全过程进行全程的跟踪。
常用软件测试方法分类：☆☆☆
按照开发阶段划分：
单元测试：
又称模块测试，是针对软件设计的最小单元（程序模块）进行正确性检验的测试工作。其目的在于检查每个程序单元是否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行的独立进行单元测试。（主要测试方法白盒测试，针对程序的代码片段测试）。
集成测试：
也叫组装测试或者联合测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。
确认测试：
也叫有效性测试。是在模拟的环境下，验证软件的所有功能和性能及其他特性是否与用户的预期要求一致。通过了确认测试之后的软件，才具备了进入系统测试阶段的资质。
系统测试：
系统测试是在真实的系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置连接，并最终满足用户的所有需求。
验收测试（也叫接受性测试）：
是软件产品检验的最后一个环节。按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。
按照测试技术划分：
黑盒测试：
通过软件的外部表现来发现其缺陷和错误。黑盒测试把测试对象看成一个黑盒子，完全不考虑程序内部结果和处理过程。黑盒测试是在程序界面处进行测试，它只是检查程序是否按照需求规格说明书的规定正常实现。
白盒测试：（又称结构测试）
通过对程序内部结构的分析、检测来寻找问题。白盒测试可以把程序看成装在一个透明的盒子里，也就是清楚了解程序结构和处理程序，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。
灰盒测试：
介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过表征性的现象、事件、标志来判断内部的运行状态。灰盒测试结合了白盒测试和黑盒测试的要素。它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。
按照代码运行划分：
静态测试：
指不实际运行被测对象，而只是静态地检查程序代码、界面或文档中可能存在错误的过程。
代码测试：主要测试代码是否符合相应的标准和规范。
界面测试：主要测试软件的实际界面与需求中的说明是否相符。
文档测试：主要测试用户手册和需求说明是否真正符合用户的实际需求。
动态测试：
指实际运行被测对象，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。所以我们判断一个测试属于动态测试还是静态测试，唯一的标准就是看是否运行程序。
按照软件特性分类：
功能测试：
是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需要。
逻辑功能测试
界面测试
易用性测试
安装/缺载测试
兼容性测试
性能测试：
功能的另一个指标，主要关注软件中某一功能在指定的时间、空间条件下，是否使用正常。软件的性能包括很多方面，主要有时间性能和空间性能两种。
其它分类：
回归测试：
是指对软件的新版本测试时，重复执行之前某一个重要版本的所有测试用例。
目的：1、验证之前版本产生的所有缺陷已全部被修复 2、确认这些修复没有引发新的缺陷。
冒烟测试：（也叫可测性测试）
是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
随机测试：（也叫随意性测试）
是指测试人员基于经验和直觉的探索性测试，其目的是模拟用户的真实操作，并发现一些边缘性的错误。
软件测试生命周期（基本流程）：☆☆☆☆
获取测试需求
↓
编写测试计划
↓
制定测试方案
↓
开发与设计测试用例
↓
执行测试
↓
提交缺陷报告
↓
测试分析与评审
↓
提交测试总结
↓
准备下一版本测试
扩展知识：
（1）Alpha 测试
Alpha 测试(α测试)是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，
Alpha测试不能由程序员或测试员完成。
Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。
目的是评价软件产品的功能、可使用性、可靠性、性能和支持。尤其注重产品的界面和特色。
Alpha测试可以从软件产品编码结束之后开始，或在模块(子系统)测试完成后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。
有关的手册(草稿)等应该在Alpha测试前准备好。
（2）Beta测试
Beta测试是一种验收测试。所谓验收测试是软件产品完成了功能测试和系统测试之后，在产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段，通过了验收测试，产品就会进入发布阶段。
验收测试一般根据产品规格说明书严格检查产品，逐行逐字地对照说明书上对软件产品所做出的各方面要求， 确保所开发的软件产品符合用户的各项要求。 通过综合测试之后，软件已完全组装起来，接口方面的错误也已排除，软件测试的最后一步——验收测试即可开始。验收测试应检查软件能否按合同要求进行工作，即是否满足软件需求说明书中的确认标准。
Beta测试由软件的最终用户们在一个或多个客房场所进行。与Alpha测试不同，开发者通常不在Beta测试的现场，因Beta测试是软件在开发者不能控制的环境中的“真实”应用。用户Beta测试过程中遇到的一切问题（真实在或想像的），并且定期把这些问题报告给开发者。接收到在Beta测试期间报告的问题之后，开发者对软件产品进行必要的修改，并准备向全体客户发布最终的软件产品。
测试用例基础概念：
什么是测试用例：☆☆☆
测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。
简单的说，测试用例就是设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的预期结果，如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示软件程序人员已经测出软件有缺陷，这时候就必须将这个问题标示出来，并且通知软件开发人员。软件开发人员接获通知后，将这个问题修改完成于下一个测试版本内。
软件测试工程师取得新的测试版本后，必须利用同一个用例来测试这个问题，确保该问题已经修改完成。这个过程称为“复测或返测”。（也叫回归测试）
一句话记忆：测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
使用测试用例的好处（目的）：
1、测试用例的使用使软件测试的实施突出重点，目的明确，可以避免盲目测试并提高测试效率。
2、在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度，缩短项目周期。
3、测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化，其效率也会不断攀升。
4、测试的“深度”与测试用例的数量成比例。由于每个测试用例反应不同的场景条件或经由产品的事件流，因而，随着测试用例数量的增加，对产品质量和测试流程的信心也会增强。
测试用例的特点：
测试用例通常根据它们所关联关系的测试类型或测试需求来分类，而且将随类型和需求进行相应的改变。最佳方案是为每个测试需求至少编制两种测试用例：一种测试用例用于证明该需求已经满足，称作正向测试用例；另一种测试用例反应某个无法接受、反常或意外的条件或数据，用于论证只有在所需条件下才能够满足该需求，这种测试用例称作反向测试用例。
一、测试用例设计
1、测试用例要素
测试用例编号2>测试名称3>测试标题4>预置条件5>优先级6>输入7>操作步骤8>预期输出9>实际输出10>参考SQL
2、参数分析表：
1>需求名称2>输入名称3>类型4>长度5>是否为空6>是否重复7>组成规则/
3、缺陷报告组成要素：
1>缺陷编号2>缺陷标题3>缺陷重现步骤4>截图5>缺陷状态6>严重程度7>优先级8>提交9>提交时间
4、测试范围列表：
需求编号、需求名称、测试类型、优先级、path
5、测试用例分析方法
等价类法
为什么要用等价类：因为测试数据无限多，但测试资源相对紧张，无法做到穷举测试，所以要找代表的数据进行测试。
优点：简单高效，能评估工作量一个功能n个输入框，至少要用N+1条设计用例，用例数最少用例的4~6倍。
缺点：测试用例比较随意，不一定能发现缺陷，每个输入功能输入相对独立如果输入之间存在关系则无法试用
边界值法
选取边界上的数值进行测试，因为边界上的值容易发现缺陷。
闭外开内
输出域覆盖法
针对界面上回显数据/默认数据，倒推输入数据，来检查界面上数据是否正确
判定表法
1>确定判断条件，提取条件桩。
2>列出所有可能的结果，提取动作桩
3>填入条件项
4>根据条件项找出对应的动作项
5>针对每一列写一条测试用例
注意事项：有些条件对应的动作可能不存在，不用写用例，之前覆盖过的也可省略不写。
正交试验法
需求特点：每个输入都给一些固定值，只是对每个输入的取值进行了组合验证，如果对测试的要求较高就需要吧每一种组合全部都要测试一遍 保证测试的全面性，但 用例条数太多，工作量较大。如果第产品要求只是验证每一种组合，可以采用两辆组合的方式，既保证了测试的全面性又能减少重复的组合次数从而提高工作效率，可以采用正交试验的方法。
设计思路：从大量的实验数据挑选合适的，有代表性的数据进行测试
步骤：1>根据需求列出所有输入参数
2>根据需求把每个输入参数的取值取值列出来
3>列出的参数及具体的取值画出因子状态表
4>用符号代替因子状态表
5>将替换后的因子状态表带入正交试验表
6>将符号替换成对应的文字
7>编写测试用例，一行对应一条测试用例。
优点:采用输入之间的两两进行组合，有效的减少了重复的两两组合既保证的全面性又能节约测试成本
缺点：要求输入之间必须独立，且没有逻辑关系。
Allpairs工具：
Dos命令：allpairs.exe xx.txt ->bb.txt
优点：快速生成测试用例
缺点：生成的用例数高于手工设计用例数量
状态迁移法
需求特点:输入之间存在制约/顺序关系,一个操作之后对应多个有条件的操作（从一种状态转到多个规定的状态）
步骤:
1>根据需求提取状态的名称（状态、输入的名称）
2>根据需求设计出业务矩阵
3>将业务矩阵转化成业务树（广度优先、深度优先）
4>编写测试用例，从根节点到叶子节点一条路径对应一条测试用例
优点:功能的有效节点可以全部覆盖
缺点：无法覆盖无效组合
使用范围：多个状态或输入取值，状态的变化或取值有规定的取值顺序，一个状态可以到达若干状态。
流程分析法
需求特点：多个界面多步操作多个输入框共同完成一个功能。
步骤：
1>从需求中找出所有的判断条件（如果、当、假如、若....注意：挖掘隐含条件）
2>将所有判定条件放入判定框内，画流程步骤图。
3>根据需求把所有正确的处理情况先画出来确定基本流。
4>再依据需求画出每个错误的分支作为备选流。
5>将用例流程图转化成测试用例，从开始到结束，一条路径对应一条测试用例
优点：既考虑了输入，也考虑了处理过程和输出结果
缺点：需要提前熟悉业务，测试数据不全用其他方法追加用例
场景法：适用于解决业务流程清晰的系统或功能。
原理：现在的软件几乎都是用事件触发来控制流程的。测试时，可以生动地描绘出事件触发的情景，有利于设计测试用例，同时使测试用例更容易理解和执行。
基本流：软件功能按照正确的事件流实现的一条正确流程。通常一个业务仅存在一个基本流，且基本流仅有一个起点和一个终点。
备选流：除了基本流之外的各支流，包含多种不同的情况。
因果图法
1>依据需求列出所有原因（条件/输入）
2>依据需求列出所有可能的结果（输出）
3>给原因和结果编号
4>按照需求画因果图
5>按照因果图画判定表
6>将不存在的判定删除剩余部分即为测试用例
输入域覆盖法
特殊值:主要是考虑输入的极值（业务边界：例如年龄（0,100]上点0,100离点1,101）整数的最大值：2的32次方减1最小值：负的2的32次方；电话号码。
长时间输入：对于没有限制输入长度的输入进行长时间输入以查看是否存在数据内存越界导致系统故障
异常分析法
针对系统罗列可能的故障/异常（断电、断网、硬件损坏、数据损坏、内存不足、强制停止、程序进行中强制点击取消）
错误猜测法
根据以往的经验和对系统内部的了解，列出系统中可能有错误或容易发生错误的特殊情况，再根据这些情况来设计用例，但是这种方法只能作为测试的补充不能单独用来设计用例。
测试方法的选择综合策略：☆☆☆
1、首先进行等价类划分
2、在任何情况下都必须使用边界值分析法
3、可以用错误推测法（就是随机测试法）追加一些测试用例
4、如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法。
5、对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果。
6、功能图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据。
7、对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。
8、对照程序逻辑检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
缺陷识别和缺陷跟踪 ☆☆☆
准确、有效的定义和描述软件缺陷，可以使软件缺陷得以快速修复，节约软件测试项目的成本和资源，保障产品质量。
软件缺陷的属性：
属性名称 描述
缺陷标识（ID） 是标记某个缺陷的一组符合。每个缺陷必须有一个唯一的标识。
缺陷类型（type） 是根据缺陷的自然属性划分的缺陷种类。
缺陷严重程度（Severity） 是指因缺陷引起的故障对软件产品的影响程度。
缺陷优先级（Priority） 是指缺陷必须被修复的紧急程度。
缺陷状态（Status） 是指缺陷通过一个跟踪修复过程的进展情况。
缺陷起源（Origin） 是指缺陷引起的故障或事件第一次被检测到的阶段。
缺陷原因（Source） 是指引起缺陷的起因。
缺陷根源（Root Cause） 是指发生错误的根本因素。
软件缺陷的类型：
类型 描述
功能（Functional）缺陷 影响了各种系统功能、逻辑的缺陷。
用户界面（UI）缺陷 影响了用户界面、人机交互性，包括屏幕格式、用户输入灵活性，结果输出格式等方面的缺陷。
文档（Document） 影响发布和维护，包括注释、用户手册、设计文档
软件包（Package） 由于软件配置库、变更管理或版本控制引起的错误
性能（Performance） 不满足系统可测量的属性值，如执行时间、事务处理速率等。
系统/模块接口（interface） 与其他组件、模块或设备驱动程序、调用函数、控制块或参数列表等不匹配、冲突。
缺陷严重等级：
| 缺陷严重等级 |
描 述 |
| 致命（Fatal） |
系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机，或者危及人身安全 |
| 严重（Critical） |
系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响 |
| 一般（Major） |
系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题 |
| 较小（Minor） |
是操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题 |
缺陷的优先级：衡量的是这个缺陷对测试工作的影响。
| 缺陷优先级 |
描 述 |
| 立即解决（P1级） |
缺陷导致系统几乎不能使用或测试不能继续，需立即修复 |
| 高优先级（P2级） |
缺陷严重，影响测试，需要有限考虑 |
| 正常排队（P3级） |
缺陷需要正常排队等待修复 |
| 低优先级（P4级） |
缺陷可以在开发人员有时间的时候被纠正 |
软件缺陷的严重程度和优先级没有必然关系，严重程度高的缺陷，不一定要优先修复。严重程度低的缺陷，优先级不一定就低。
缺陷状态：
软件缺陷生命周期（处理流程）：
发现缺陷
↓
提交缺陷
↓
确认缺陷
↓
分配缺陷
↓
修复缺陷
↓
验证缺陷
↓
关闭缺陷
缺陷报告的写作标准：
准确correct :每个组成部分描述准确，不引起误解
清晰 clear :每个组成部分描述清晰，易于理解
简介 concise :只包含必不可少的信息，不包括任何多余内容
完整 complete :包含复现该缺陷的完整步骤和其他本质信息
一致 consistent ：书写格式一致