基本路径测试基本路径测试方法包括4个步骤：（1）画出程序的控制流图（2）计算程序的环形复杂度，导出程序基本路径集中的独立路径条数，这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界（3）导出基本路径集，确定程序的独立路径。（4）根据(3)中的独立路径，设计测试用例的输入数据和预期输出  

语句覆盖：设计若干测试用例，运行被测程序，使程序中每个可执行语句至少执行一次判定覆盖：设计若干测试用例，运行被测程序，使得程序中每个判断的真值结果和假值结果都至少出现一次。条件覆盖：设计若干测试用例，执行被测程序以后要使每个判断中每个条件的可能取值至少满足一次判定条件覆盖：设计足够的测试用例，使得判断条件中的所有条件可能至少执行一次取值，同时，所有判断的可能结果至少执行一次。条件组合覆盖：设计足够测试用例，使每个判断表达式中条件的可能组合都至少出现一次路径覆盖：设计所有的测试用例，来覆盖程序中的所有可能的执行路径

正交表：正交表行数计算：测试用例（行数）=条件因子数*（水平取值个数-1）+1正交表设计测试用例步骤：构造因子-状态表。首先要根据被测软件需求规格说明中某个具体的、相对独立的、基本的功能要求，分析找出影响其功能实现的相对独立的外部因素（变量），把他们当作因子，并确定每个因子有哪几个水平（即变量的取值有哪几种）。根据因素个数以及每个因素的水平数（状态数）选择一个合适的正交表。正交表可以访问以下链接获得：http://support.sas.com/techsup/technote/ts723_Designs.txt。将因子-状态表中的水平值映射到正交表中，把每一行的各因素水平的组合作为测试用例，构造测试用例集。根据经验补充在正交表中没有出现的组合设计测试用例。如何选择正交表:1、考虑因素（变量）的个数2、考虑因素水平（变量的取值）的个数3、考虑正交表的行数4、取行数最少的一个场景法：在需求规格说明书中，用例描述中的有基本路径和备选路径。场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有的基本流和备选流。基本流：用例无任何差错的情况下从用例开始到结束最简单的路径。备选流：出现故障或缺陷时流经的路径。场景法设计测试用例步骤：根据用例描述，分析程序的基本流和备选流。根据基本流和备选流生成不同的场景。为每一个场景生成相应的测试用例。

判定表判定表的组成：条件桩：列出问题的所有条件。动作桩：列出问题规定可能采取的动作。条件项：根据条件桩的条件列出所有可能的取值。针对取值，判断在所有可能情况下的真假值。动作项：列出在条件项的各种取值组合情况下应该采取的动作。规则：在判定表中，条件项和动作项构成的一列对应一条规则，每个规则规定了这一列条件组合下应该采取的动作。如果在两条或多条规则中采取的动作是一致的，并且规则中条件项之间存在着极为相似的关系，则可以进行规则的合并。利用判定表设计测试用例的步骤（1）根据输入条件定义条件桩，根据输出响应定义动作桩。（2）填入条件项。（3）填入动作项，得到初始判定表。（4）合并相似规则，简化判定表。（5）抽取判定表中每条规则作为测试用例优点：它能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题。缺点：不能表达重复执行的动作，例如循环结构

因果图因果图基本关系符号及约束：C表示原因，用E表示结果，原因和结果之间有恒等、与、或、非四种关系    恒等：如果原因出现，则结果产生，如果原因不出现，则结果不产生。   非：如果原因出现，则结果不产生，如果原因不出现，则结果产生。或：如果几个原因中有一个出现，则结果产生，如果几个原因都不出现，则结果不产生。   与：如果几个原因都出现，则结果产生，如果有一个原因都不出现，则结果不产生。原因和原因之间还可能存在着异、或、唯一、要求、强制这五种约束关系：异（E约束）所有原因中至多有一个原因出现，也可以一个原因都不出现。或（I约束）所有原因中至少有一个原因出现，多个原因可共存。唯一（O约束）所有原因中有且只有一个原因发生。要求（R约束）具有R约束的原因C1和C2，如果原因C1发生，则原因C2也发生。强制（M约束）具有M约束的原因C1和C2，如果原因C1发生，则原因C2不发生。因果图法设计测试用例的步骤分析被测对象需求规格说明，列出所有的原因、结果（原因即输入条件的等价类，结果是输出条件）。并为每个原因和结果编号，用编号代替对应的原因和结果，这样方便绘制因果图，通常习惯将原因画到因果图左边，结果画到因果图右边。分析原因之间、结果之间的约束关系，用因果图中对应的约束符号描述。分析原因与结果之间的关系，用因果图中原因和结果的关系符号描述。将因果图转换成判定表。     对判定表中的每一列设计一个测试用例。

边界值定义：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法，通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界原则：1. 如果输入条件规定了取值范围，选取范围边界、边界附近的值作为测试用例。2. 如果输入条件规定了值得个数，则用最大个数、最小个数、比最大个数多一个数、比最小个数小一个数作为测试用例。3. 如果输入或输出是—个有序集合， 如：线性表、顺序文件等；则选择该序列中的第—个及最后—个元素进行测试， 进—步考虑第二个元素和倒数第二个元素。边界值分类：普通边界值测试4n+1    －健壮性测试6n+1－最坏情况测试5^n－健壮最坏情况测试7^n等价类划分法与边界值分析法的区别等价类：将输入域划分为若干个等价类，在等价类中随机选取数据设计测试用例。边界值：作为对等价类划分法的补充，在等价类划分的基础上，选取的测试数据并非是随机的，而是有针对性地选取边界以及边界附近的值进行测试。边界值分析法设计的测试用例的代表性更广，发现错误的能力也更强

等价类定义：等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据，取得较好的测试结果分类：有效等价类和无效等价类等价类规则：1如果输入条件规定了取值范围，可定义一个有效等价类和两个无效等价类。2如果规定了输入数据的个数，则类似地可以划分出一个有效等价类和两个无效等价类。3如规定了输入数据的一组值，且程序对不同输入值做不同处理，则每个允许的输入值是一个有效等价类，并有一个无效等价类(所有不允许的输入值的集合)。4如果规定了输入数据必须遵循的规则，可确定一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则)。5在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类；6在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类。7在确知已划分的等价类中各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步的划分为更小的等价类。等价类划分步骤：（1）对每个输入或外部条件进行等价类划分，形成等价类表，为每一等价类规定一个唯一的编号； （2）设计一测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类，重复这一步骤，直到所有有效等价类均被测试用例所覆盖；（3）设计一新的测试用例，使其只覆盖一个无效等价类，重复这一步骤直到所有无效等价类均被覆盖；

软件测试基本流程（1）软件测试计划（2）软件测试分析（3）软件测试设计（4）软件测试实施（5）软件测试执行（6）评估出口准侧和报告（7）软件测试结束活动软件测试原则 1：测试可以证明缺陷存在，但不能证明缺陷不存在2：穷尽测试是不可能的  3：测试活动应尽早开始  4：缺陷的集群性  5：‘杀虫剂’悖论 6：测试依赖于测试内容  7：没有失效就是有用的系统是一种谬论

3根据测试实施策略分类：白盒 根据程序的内部逻辑来设计测试用例, 黑盒 根据程序的功能来设计测试用例,黑盒测试是根据软件的规格说明来设计测试用例。灰盒 基于程序运行的外部表现同时又结合程序内部逻辑结构来设计测试用例。一般认为集成测试阶段采用的测试策略近似于灰盒测试。4根据软件测试的执行方式：静态测试 不实际执行程序，而是利用人工手段及静态测试工具完成对程序的静态测试。主要目的是检查软件的表示与描述是否一致，没有冲突和歧义。包括代码检查、静态结构分析、代码质量度量。动态测试 则实际运行测试用例，以发现软件中的错误。 依据黑盒方法设计的测试是动态测试，白盒方法设计的测试则包括静态测试和动态测试两种类型 其他测试方法：回归测试  功能测试  性能测试  安全性测试  可靠性测试  兼容性测试可移植性测试  冒烟测试  随机测试  本地化测试  易用性测试  可维护性测试

软件测试对象：测试的对象不仅仅是程序，需求分析和设计也是测试的对象软件测试分类：软件测试阶段：测试需求的分析和确定、测试计划、测试设计（高级）、测试用例设计、测试工具、脚本的开发、测试执行（低级）、测试记录和缺陷跟踪、回归测试、测试的总结和报告1按开发阶段：单元测试 称模块测试，是指对软件中的最小可测试单元进行检查和验证。一般以白盒测试为主、结合黑盒测试的方法。允许多个测试单元的测试并行展开。单元测试的基本方法：人工静态分析、自动静态分析、自动动态测试，人工动态测试。集成测试 又叫做组装测试。是指根据实际情况对程序中已通过单元测试的单元采用适当的集成策略组装起来，检查各个单元之间的接口以及集成之后的功能是否正确；集成方法有自上而下测试法、自下而上测试法、三明治测试法。确认 目的检查已实现的软件系统是否满足需求规格说明书中规定的各种需求，以及软件     配置是否完全、正确。系统测试是将经过集成测试的软件，作为计算机系统的一个部分，与系统中其他部分结合起来，是对整个系统的测试，将硬件、软件、操作人员看作一个整体，在实际运行环境下对计算机系统进行的一系列严格有效地测试，以发现软件潜在的问题，保证系统的正常运行。验收  即按项目任务书或合同、供需双方约定的验收依据文档对整个系统进行测试与评审，     以决定是否接收软件系统。验收测试是检验软件产品质量的最后一个过程。验收测试通常更突出客户的主导作用，同时也需开发人员参与。分为Alpha测试和Beta测试。2按组织分类：α测试属于开发方进行的测试，指软件开发方组织公司内部人员模拟     各类用户对即将交付的软件产品(称为α版本)进行测试，以发现其中的错误并改正     α测试的关键在于尽可能逼真地模拟软件的实际运行环境，并尽最大努力涵盖所有     可能的用户操作方式β测试β测试( Beta Testing)是用户进行的测试，β测试的目的在于帮助开发方在正式发布软件产品前对其进行最后的改进。β测试一般在α测试之后进行，是由大量用户在实际操作环境下对软件的版本进行的测试。第三方测试  指由不同于开发方和用户方的组织进行的测试，通常模拟用户的真实操作环境，对软件进行确认测试。有利于客观、公正地测试和评价软件。

软件缺陷细化为如下5种规则：     1.软件未达到产品说明书标明的功能；     2.软件出现了产品说明书指明不会出现的错误；     3.软件实现了需求规格说明书中未提到的功能；     4.软件未达到产品说明书虽未指出但应达到的目标；     5.软件测试员认为软件难以理解、不易使用、运行速度缓慢等，即用户体验不佳。软件开发的主要阶段：按软件工程的观点，在在对软件系统的可行性进行论证之后，软件开发主要阶段如下：需求分析 软件设计 软件编码 软件测试 软件运行和维护软件测试目标：测试是为了发现程序中的错误而执行程序的过程。好的测试方案是尽可能发现迄今为止尚未发现的错误的测试方案成功的测试是发现了迄今为止尚未发现的错误的测试在进行测试时，往往在心理上会忽略软件中可能存在的缺陷，而把注意力集中在软件能否完成基本的、已知的功能上。1983年，在 Glenford. Myers观点的基础上，Bill Hetzel（比尔海泽尔）指出软件测试的目标不仅是尽可能多地发现软件中的错误，还要对软件质量进行度量和评估，以提高软件质量。这论断将对软件测试的认识提升到更高的层次1983年，IEEE对软件测试的定义则指出，软件测试的目标是为了检验软件系统是否满足用户的需求。软件测试定义：定义1：“软件测试是为了证明程序有错，通过运行程序发现其中存在的问题。定义 2：软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例（即输入数据及其预期的输出结果），并利用这些测试用例运行程序以及发现错误的过程，即执行测试步骤。 定义3：软件测试是验证软件产品是否满足用户显性或者隐性需求的活动。