测试理论
1、软件测试
在规定条件下对程序进行操作，以发现错误，对软件质量进行评估，包括对软件形成过程的文档、数据以及程序进行测试。
2、软件质量
软件特性的总和，软件满足规定或潜在用户需求的能力
3、软件测试与质量保证
软件测试只是质量保证工作中的一个环节，软件质量保证与软件测试是软件质量工程的两个不同层面的工作；
质量保证是指通过预防、检查与改进来保证软件质量，采用全面质量管理和过程改进的原理来开展质量保证工作，主要关注软件质量的检查与测试，主要着眼于软件开发活动的过程、步骤和产品。
软件测试是指通过执行软件来对过程中的产物（开发文档和程序）进行走查，发现问题，报告质量。
4、软件测试的目的
软件测试的目的是为了发现尽可能多的缺陷，不是为了说明软件中没有缺陷。
成功的参数在于发现了迄今尚未发现的缺陷，所以测试人员的职责是设计能有效地揭示潜伏在软件里的缺陷。
一个好的测试用例在于发现了至今未发现的错误；一个成功的测试是发现了至今未发现的错误的测试。
5、软件测试对象
程序、文档、数据
6、软件开发的瀑布模型
瀑布模型是一个特别经典，甚至有点老套的周期模型，一般情况下将其分为计划、需求分析、概要设计、详细设计、编码以及单元测试、测试、运行维护等几个阶段。瀑布模型的周期是环环相扣的。每个周期中交互点都是一个里程碑，上一个周期的结束需要输出本次活动的工作结果，本次的活动的工作结果将会作为下一个周期的输入。这样，当某一个阶段出现了不可控的问题的时候，就会导致返工，返回到上一个阶段，甚至会延迟下一个阶段。
7、软件开发的迭代模型
迭代模型，摒弃了传统的需求分析，设计，编码，测试的流程，而是将整个生命周期变成若干个冲刺阶段，每个阶段都是由以上若干或者全部传统的流程组成，在每一个阶段中，都会包含下面四个阶段：初始阶段，细化阶段，构建阶段，交付阶段。在初始阶段中，确认本次冲刺的范围、边界、系统选择的架构、计划、以及所需要的资源等信息。在细化阶段中，对问题进行建域，创建开发案例，创建模板以及准备工具等。在构建阶段的主要任务就是完成构建的开发并且进行测试，将完成的构建集成为产品，并且测试所有的功能。在交付阶段，主要是完成本次冲刺，将软件产品交付。
描述软件产品的不同阶段是按产品深度或细化的程度来划分。先将产品的整个框架都建起来，在系统的初期，已经具有用户所需求的全部功能。然后，随着时间推进，不断细化已有的功能或完善已有功能，这个过程好像是一个迭代的过程。最终的目标也是为了实现一个强大的、功能完善的、高质量的、稳定的产品。
8、软件开发的螺旋模型
螺旋模型，尤其重视风险分析阶段，特别适用于庞大并且复杂，非常高风险的项目。通常螺旋模型由四个阶段组成：制定计划、风险分析、实施工程和客户评估。螺旋模型中，发布的第一个模型甚至可能是没有任何产出的，可能仅仅是纸上谈兵的一个目标，但是随着一次次的交付，每一个版本都会朝着固定的目标迈进，最终得到一个更加完善的版本。
原型化模型第一步就是创建一个快速原型，能够满足项目相关人员和未来的用户可以与原型进行交互，再通过与相关人进行充分的讨论和分析，最终弄清楚当前系统的需求，进行充分的了解之后，在原型的基础上开发出用户满意的产品。在实际的项目过程中，借助于组织过程资产以及快速模型软件，一般在需求分析的时候，就可以建立一些简单的原型。原型化模型是极具意义的项目实践。
10、软件测试过程模型－V模型（RAD 快速应用开发模型）
V模型从整体上看起来，就是一个V字型的结构，由左右两边组成。左边的下划线分别代表了需求分析、概要设计、详细设计、编码。右边的上划线代表了单元测试、集成测试、系统测试与验收测试。看起来V模型就是一个对称的结构，它的重要意义在于，非常明确的表明了测试过程中存在的不同的级别，并且非常清晰的描述了这些测试阶段和开发阶段的对应关系。
是软件开发瀑布模型的变种，主要反映测试活动与分析和设计的关系；
局限性：把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现。
11、软件测试过程模型－W模型
在V模型的基础上，增加了开发阶段的同步测试，形成W模型；测试与开发同步进行，有利用尽早的发现问题。
局限性：仍把开发活动看成是从需求开始到编码结束的串行活动，只有上一阶段完成后，才可以开始下一阶段的活动，不能支持迭代，自发性以及变更调整。
12、软件测试过程模型－H模型
在H模型中，软件测试过程活动完全独立，贯穿于整个产品的周期，与其他流程并发地进行，某个测试点准备就绪时，就可以从测试准备阶段进行到测试执行阶段；软件测试可以进行尽早的进行；软件测试可以根据被测物的不同而分层次进行。
13、测试模型使用
在实际工作中应灵活地运用各种模型的优点
V模型：强调了在整个软件项目开发中需要经历的若干个测试级别，并与每一个开发级别对应；
忽略了测试的对象不应该仅仅包括程序，没有明确指出对需求、设计的测试。
W模型：补充了V模型中忽略的内容，强调了测试计划等工作的先行和对系统需求和系统设计的测试；与V模型相同，没有对软件测试的流程进行说明。
H模型：强调测试是独立的，只要测试准备完成，就可以执行测试。
14、测试分类
按开发过程分类：单元测试、集成测试、系统测试、确认测试、验收测试
按测试技术分类：白盒测试、灰盒测试、黑盒测试 、静态测试、动态测试
按实施组织分类：开发方测试（Alpha测试）、用户测试（Beta测试）、第三方测试
15、单元测试
定义：单元测试又称模块测试，是针对软件设计的最小单位程序模块进行正确性检查的测试工作。可从程序的内部结构出发设计测试用例，多个模块测试可以平行地独立进行测试。
目的：发现模块内部可能存在的各种差错。
内容：模块接口测试、模块局部数据结构测试、模块边界条件测试、模块中所有独立执行通路测试、模块中的各条错误处理通路测试
步骤：利用设计文档设计测试用例；创建被测模块的桩模块或驱动模块；利用被测试模块、驱动模块和桩模块来建立测试环境，进行测试。
16、集成测试
定义：集成测试又称组装测试或联合测试，在单元测试基础上，将所有模块按概要设计和详细设计进行组装，检查其接口是否存在问题,以及组装后的整体功能、性能表现。
目的：发现模块连接中的接口可能存在的各种差错。
内容：穿越模块之间的数据是否会丢失；一个模块组装后是否会对另一模块或其他模块存在影响；各个子功能组装在一起是否会达到预期的父功能；全局数据结构是否有问题；单个模块的错误累积起来是否会放大。
组装方式：一次性组装方式，非增殖式方式也叫整体拼装，对模块分别测试然后将所有模块组装；第二种增殖式组装方式，可以是自顶向下（按照系统层次结构图，以主程序模块为中心，自上而下按照深度优先或者广度优先策略，对各个模块一边组装一边进行测试）或自底向上（从系统层次结构图的最底层模块开始进行组装和集成测试的方式）。
完成标志：成功地执行了测试计划中规定的所有测试用例；修正了所发现的错误；测试结果通过专门小组的评审。
17、系统测试
系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。
18、确认测试
Validation，确认，更准确地应该是“有效性确认”。有效性确认要求更高，要能保证所生产的软件可追溯到用户需求的一系列活动。
确认过程提供证据表明软件是否满足系统需求（指分配给软件的系统需求），并解决了相应问题。
19、验收测试
Verification，验证，即检验，检验软件是否已正确地实现了产品规格说明书所定义的系统功能和特性。验证过程提供证据表明软件相关产品与所有生命周期活动的要求（如正确性、完整性、一致性和准确性等）相一致。
20、验收与确认的区别
验证是检验开发出来的软件产品和设计规格说明书的一致性，即是否满足软件厂商的生产要求。确认是检验产品功能的有效性，即是否满足用户的真正需求。
21、白盒测试
白盒测试也称结构测试或逻辑驱动测试。通过对程序内部结构的分析、检测来寻找问题，检查程序的结构及路径是否正确，检查程序的内部动作是否按照设计说明的规定正常进行。
白盒测试主要对程序模块进行以下检查：
（1）对程序模块的所有独立的执行路径至少要测试一次；
（2）对所有的逻辑判定，取真或假的两种情况至少要测试一次；
（3）对程序进行边界检查（常见的如数据越界检验）；
（4）检验内部数据结构的有效性。
在白盒测试用例设计中，主要使用两种方法：逻辑覆盖法和基本路径测试法。其中，逻辑覆盖法主要以程序内部的逻辑结构为基础的测试用例设计方法。
在逻辑覆盖法中，可以分为语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖和路径覆盖。
（1）语句覆盖：设计若干测试用例，运行被测程序，使程序中的可执行语句至少执行一次。
（2）判定覆盖：设计若干测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次，即判断真假值均曾被满足。
（3）条件覆盖：设计若干测试用例，执行被测程序以后要使每个判断中每个条件的可能取值至少满足一次。
（4）判定-条件覆盖：判定和条件覆盖设计方法的交集，即设计足够的测试用例，使得判断条件中的所有条件可能至少执行一次取值，同时，所有判断的可能结果至少执行一次。
（5）条件组合覆盖：设计足够的测试用例，使得判断中每个条件的所有可能至少出现一次，并且每个判断本身的判定结果也至少出现一次，与条件覆盖的差别是它不是简单地要求每个条件都出现“真”与“假”两种结果，而是要求让这些结果的所有可能组合都至少出现一次。
（6）路径覆盖：设计足够的测试用例来覆盖程序中的所有可能的执行路径。
22、黑盒测试
黑盒测试也称为功能测试或数据驱动测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。黑盒测试是以用户的角度，从输入数据与输出数据的对应关系出发进行测试的。很明显，如果外部特性本身设计有问题或规格说明的规定有误，用黑盒测试方法是发现不了的。
黑盒测试的主要目的是为了发现：模块中是否有功能遗漏或者逻辑错误；模块接口中是否存在问题；是否有数据结构错误或者外部信息访问错误；性能上是否满足要求。
黑盒测试用例设计方法：
（1）等价类划分法：把程序的输入域划分成若干部分，然后从每个部分中选取少数具有代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类的其他值。
在等价类划分法设计测试用例的过程中，需要使用两个过程：分类和抽象。第一个过程是分类，即将输入域按照具有相同特性或者类似功能进行分类；第二个过程是抽象，即在各个子类中抽象出相同特性并用实例来表征这个特性。
等价类是指某个输入域的子集合，在该子集合中，各个输入数据对于揭露程序中的错误都是等价的，它们具有等价特性，这样，对于表征该类的数据输入将能代表整个子集合的输入。因此，可以合理地假定：测试某等价类的代表值就是等效于对于这一类其他值的测试。
在进行等价类划分的过程中，不但要考虑有效等价类划分，同时需要考虑无效等价类划分。
有效等价类是指输入完全满足程序输入的规格说明，有效、有意义的输入数据所构成的集合。利用有效等价类可以检验程序是否满足规格说明所规定的功能和性能。
无效等价类和有效等价类是相反的，即不满足程序输入要求或者无效的输入数据构成的集合。使用无效等价类，可以鉴别程序异常情况的处理。在程序设计中，不但要保证所有有效的数据输入能产生正确的输出，同时需要保障在输入错误或者空输入的时候异常保护，这样的测试才能保证软件的可靠性。
（2）边界值分析法：边界值分析法是对等价类划分法的补充。边界值分析法是对输入的边界值进行测试，在测试过程中，可能会忽略边界值的条件，大量的错误发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部，因此，在测试用例设计中，需要对输入的条件进行分析并且汲取其中的边界值条件，通过对这些边界值的测试来查出更多的错误。通过选择等价类边界的测试用例。不仅重视输入条件边界，而且也必须考虑输出域边界。
（3）错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。
（4）因果图法： 一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种情况的组合。因果图法最终生成的是判定表。
（5）功能图法：一个程序的功能通常由静态说明和动态说明组成，动态说明描述了输入数据的次序或者转移的次序；静态说明描述了输入条件和输出条件之间的对应关系。对于比较复杂的程序，由于大量的组合情况的存在，仅仅使用静态说明来组织测试往往是不够的，必须还要动态说明来补充。功能图法就是因此而产生的一种测试用例设计方法。功能图法就是使用功能图形式化地表示程序的功能说明，并机械地生成功能图的测试用例。功能图模型由状态迁移图和逻辑功能模型组成。其中，状态迁移图用于表示输入数据序列以及相应的输出数据，由输入和当前的状态决定输出数据和后续状态；逻辑功能模型用于表示在状态输入条件和输出条件之间的对应关系。逻辑功能模型只适合于描述静态说明；输出数据仅仅由输入数据决定。测试用例由测试中经过的一系列的状态以及在每个状态中必须依靠输入、输出数据满足的一定条件组成。功能图法是一种黑盒和白盒混合用例设计方法，在功能图法中，要用到逻辑覆盖和路径测试的概念和方法，这是属于白盒测试用例设计中的内容。
测试用例设计练习：采用因果图方法设计测试用例
某个软件的规格说明中包含下面的要求：第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改。但如果第一列字符不正确，则给出信息L，如果第二列字符不是数据，则给出信息M。
输入条件：第一列字符：{A}，{B}，{其他}；
第二列字符：{数字}，{其他}
动作：修改文件，给出L，给出M。
|
条件 |
第一列 |
A |
B |
其他 |
A |
B |
其他 |
|
第二列 |
数字 |
数字 |
数字 |
其他 |
其他 |
其他 |
|
|
动作 |
修改文件 |
√ |
√ |
||||
|
给出L |
√ |
√ |
|||||
|
给出M |
√ |
√ |
√ |
||||
|
测试用例 |
A6 |
B2 |
M1 |
A! |
B% |
V+ |
23、灰盒测试
灰盒测试是介于白盒测试与黑盒测试之间的一种测试，灰盒测试多用于集成测试阶段，不仅关注输出、输入的正确性，同时也关注程序内部的情况。灰盒测试不像白盒那样详细、完整地关注程序内部的逻辑，但又比黑盒测试更关注程序的内部逻辑，常常是通过一些表征性的现象、事件、标志来判断内部的运行状态。
24、动态测试
通过运行被测程序，检查运行结果与期望的差异，并分析运行效率、正确性和健壮性等性能。这种方法由三部分组成：构造测试用例、执行程序、分析程序的输出结果。
25、静态测试
指不运行被测程序本身，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析、符号执行来找错。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套、不允许的递归、未使用过的变量、空指针的引用和可疑的计算等。静态测试结果可用于进一步的查错，并为测试用例选取提供指导。
26、开发方测试
也叫验收测试或Alpha测试’，在软件开发环境中，开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。
27、用户测试
也叫Beta测试，在用户的应用环境下，用户检测与核实软件实现是否符合自己预期的要求。把软件有计划地免费地分发到目标市场，让用户大量使用、评价检查软件。
28、Alpha测试和Beta测试的区别
Alpha测试是由用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟实际操作环境下进行的测试。开发者坐在用户旁边，这是在开发者受控的环境下进行的测试。由开发者随时记录下错误情况和使用中的问题。
Beta测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，这是在开发者无法控制的环境下进行的测试。由用户记录下遇到的所有问题，定期向开发者报告。beta测试是一模拟真实的使用环境从而发现缺陷的一种测试。
29、第三方测试
由第三方测试机构来进行的测试，也称独立测试。其目的是为了保证测试工作的客观性。
30、软件问题分类
软件错误、软件缺陷、软件故障、软件失效。
软件错误：在软件生存周期内的不希望或不可接受的人为错误。
软件缺陷：存在于软件（文件、程序、数据）之中的不希望或不可接受的偏差。
软件故障：软件运行过程中出现的一种不希望或不可接受的内部状态。
软件失效：软件运行时产生的一种不希望或不可接受的外部行为。
31、文档测试的范围
用户文档：用户手册、操作手册、维护修改建议
开发文档:需求说明书、概要设计、数据库设计、详细设计、可行性研究报告
管理文档:项目开发计划、测试计划、测试报告、开发进度月报、开发总结报告
32、冒烟测试
在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
33、回归测试
修改了旧代码后，重新进行测试以确认修改后没有引入新的错误或导致其他代码产生错误。
34、随机测试
是指测试中的所有输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。
