一，边界值

什么是边界值？

边界值是对于输入等价类和输出等价类而言，稍高于其边界值与稍低于边界值的一些特定情况。 大量错误发生在输入或输出范围的边界上，而不是在输入范围内部。

      边界值分析法是属于黑盒测试的一种常用方法。

二，因果图法

因果图法的定义:

因果图法是一种利于图解法分析输入的各种组合情况，从而设计测试用例的方法，他适合于检查程序输入条件的各种组合情况

-特点

        -考虑输入条件的互相制约以及组合关系

        -考虑输出条件对输入条件的依赖关系

因果图法产生的背景:

-等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输出条件的各种组合、输入条件之间的互相制约的关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。

    -如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

因果图核心:

-因果图法比较适合输入条件较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出。

        -因果图的“因”——输入条件

        -因果图的  "果”——输出结果

    -因果图法要注意考虑

        -所以输入/输出的条件的相互制约关系以及组合关系

        -输出结果对输入条件的依赖关系，也就是什么样的输入组合会产生怎样的输出结果，即“因果关系”

因果图中的基本符号:

-通常在因果中用Ci表示原因，用Ei表示结果，各结点表示状态，可取值“0”或“1”。“0”表示某状态不出现，“1”表示某种状态出现。

恒等

非（~）

或（v）

与（^)

因果图中的约束条件:

互斥

-E 表示abc三个原因不能同时成立

包含

-I 表示abc，中至少有一个条件成立

屏蔽（强制）

-M 表示结果a是1，则结果b强制为0

唯一

-O 表示ab条件中有且仅有一个成立

要求

-R 表示当a出现时b也必须出现

因果图法的极本步骤:

-利用因果导出测试用例需要经过以下几个步骤：

        -1，找出所有的原因，原因即输入条件或输入条件的等价类。

        -2，找出所有的结果，结果即输出条件。

        -3，明确所有输入条件之间的制约关系以及组合关系。

-哪些条件不能组合到一起，哪些条件可以组合到一起。

        -4，明确所有输出条件之间的制约关系以及组合关系。

-哪些输出结果不能同时输出，哪些输出结果可以同时输出

        -5找出什么样的输入条件组合会产生哪种输出结果

        -6把因果图转换成判定表/决策表

        -7为判定表/决策表的每一行表示的情况设计测试用例。

三，判定表法 

判定表的组成:

-条件桩：问题的所有条件

-条件桩：问题指的所有输出

-条件项：针对条件桩的取值

-动作项：条件项的 各种取值情况下的输出结果

判定表法流程:

-1,列出所有的条件桩和动作桩。

-2，填入条件项。

-3，填入动作项。得到初始判定表。

-4，简化判定表（合并相似规则（相同动作））

判定表法举例:

-怎样成为一个好学生？遵纪守法的前提下，学习成绩好就是好学生、品德高尚也是好学生；（违法乱纪一定是坏学生；成绩或品德任一项再加上遵纪守法就是好学生）

-合并使用“-”代表无关条件，选什么都不影响结果。

四，场景法

场景法中两个重要的概念:

-基本流

    -按照**正确的业务流程**来实现的一条操作路径（模拟正确的操作流程）

-备选六

    -导致程序出现**错误的操作流程**（模拟错误的操作流程）

-用例场景是用来描述流经用例路径的过程，这个过程从开始到结束遍历用例中所有基本流和备选流。

用例场景产生的背景:

>现在的软件几乎都是由事件触发来控制流程的，事件触发的情景便形成了场景。而同一事件不同的触发顺序和处理结果形成事件流。

>将这种在软件设计方面的思想引入到软件测试 中，生动的描绘出事件触发时的情景，有利于测试设计者测试用例，同时测试用例也更容易的得到理解和执行。

-在使用场景法设计测试用例时，需要覆盖系统用例中的主成功场景和扩展场景，并且需要适当补充各种正反面的测试用例和考虑出异常场景的情形。

场景法案例-TIM登录:

-使用场景法测试QQ登录功能。

    -输入正确的账号和密码后点击“登录”按钮，程序能正常登录

    -输入正确的账号，错误的密码点击“登录”按钮，程序应给出错误提示

    -输入正确的账号，不输入密码，点击“登录”按钮，程序应给出错误提示

    -不输入账号和密码，直接点击“登录”按钮，程序给出错误提示“请您输入账号登录”

    -输入错误的账号，正确的密码，点击“登录”按钮，程序应给出错误提示

    -（更多。。。）

-测试用例矩阵

五，流程分析法

流程分析法的步骤

- 第一步：详细了解需求；

- 第二步： 根据需求说明或界面原型，找出业务流程的各个页面以及各页面之间的流转关系；

- 第三步：画出业务流程（产品经理使用Axure软件制作）；

- 第四步：写用例，覆盖所有的路径分支。

使用ATM机取款

- 一、详细了解需求

- 二、找出业务流程的各个页面以及各页面之间的流转关系;

    - 1、用户向ATM取款机中插入银行卡……

    - 2、用户输入银行卡密码……

    - 3、用户输入取款金额……

    - 4、系统同步银行主机，点钞票，输出给用户并减去用户卡中相应数目的存款金额……

    - 5、用户取款，银行卡退卡……

    - 6、……

- 三、使用ATM机取款正常流程

- 第四步: 用例设计写用例，覆盖所有的路径分支。

    - 需求描述及流程图中，ATM取款机的提示信息对应于测试用例中的预期输出部分，用户的操作对应测试用例中的测试步骤部分。原则是一条有效路径使用一个测试用例覆盖。

- 依据业务流程图确定测试路径，即需要测试的业务流程。其主要包含三个方面：

    - a) 正常流程，取款成功（基本流程）：对应一次性取款成功；

    - b）异常流程，取款失败（分支流程）：对应取款失败，包括退卡、吞卡；

    - c）异常流程，取款成功（循环流程）：对应取款中间出现意外，比如密码输入错误，但是最终成功取钱的情况。

- 操作流程

流程分析法总结

流程分析法适用于有先后顺序的测试。常用于业务流程测试、安装流程测试等。

流程分析法重点在于测试流程。因此，一般每个流程用一个测试用例验证。

注意: 流程测试没有问题并不能说明系统功能没有问题，还需要针对每步功能进行测试。对于包含复杂流程的系统，只有功能点和处理流程都进行测试覆盖，才算是比较充分的测试。

六，错误推断法

错误推测法是指利用直觉和经验猜测出出错的可能类型，有针对性列举出程序中所有可能的错误和容易发生错误的情况，它是测试经验丰富的测试人员喜欢使用的一种测试用例设计方法。

基本思想

    基本思想是列举出可能犯的错误或错误易发生的清单，然后根据清单编写测试用例；这种方法很大程度上是凭经验进行的，即凭人们对过去所作测试结果的分析，对所揭示缺陷的规律性作直觉的推测来发现缺陷。

采用错误推测法，最重要的是要思考和分析测试对象的各个方面，多参考以前发现的Bug的相关数据、总结的经验，个人多考虑异常的情况、反面的情况、特殊的输入，以一个攻击者的态度对待程序，才能够设计出比较完善的测试用例

七，正交排列法

1992 年AT&T发表了一篇讲述在测试过程中使用正交表一个案例研究。

    它描述了对PC(IBM格式)和StarMail(基于局域网的电子邮件软件)做回归测试：

    最初制定的测试计划是用18周的的时间执行1500个测试用例。但是，开发推迟了，测试时间被压缩到仅仅8周时间。

    测试负责人采取另外一个测试方案和计划，即2个人8周的时间测试1000个测试用例，但是他不敢保证测试的质量，对这些用例检测缺陷的能力不放心。

    为了减轻这种不确定性的问题，他用正交表法重新设计了测试用例，此时测试用例只有422个。用这422个测试用例去测试发现了41个缺陷，开发人员修复缺陷，然后软件就发布了。

    在使用的两年时间内，凡被测试到的领域都没有再发现缺陷，因此在发现缺陷这方面，此测试计划是100%有效。

    据测试负责人估计，如果AT&T采用1000个测试用例的测试计划，可能仅仅只发现这些缺陷中的32个。

与最初的计划相比，用正交表设计测试用例执行工作量不到50%，但却多发现28%的缺陷，而且测试人员个人的效率也增加了。

正交排列法概述

- 正交排列法能够使用最小的测试过程集合获得最大的测试覆盖率。当可能的输入数据或者输入数据的组合数量很大时，由于不可能为每个输入组合都创建测试用例，可以采用这种方法。

案例：字符属性设置程序

- 窗体中有多个控件（字体、字符样式、颜色、字号），每个控件有多个取值

字体：仿宋、楷体、华文彩云

字符样式：粗体、斜体、下划线

颜色：红色、绿色、蓝色

字号：20号、30号、40号

在测试时，要考虑这些控件的组合情况，组合量非常大（有3^4 =81种组合情况）

由于组合量太大，不可能为每一种组合都创建测试用例。如何采用最少的测试用例集合获得最大的测试覆盖率——采用正交排列法

正交排列表的重要概念

正交试验设计【科普】

是研究多因素多水平的一种设计方法，它是根据正交性从全面试验中挑选出部分有代表性的点进行试验，这些有代表性的点具备了“均匀分散，齐整可比”的特点，正交试验设计是一种基于正交表的、高效率、快速、经济的试验设计方法。

正交表的概念

- 正交表：一种特制的表，一般的正交表记为：Ln（m^k）

        - n是表的行数，也就是需要测试组合的次数

        - K是表的列数，表示控件的个数（因素的个数，或因子个数）

        - m是每个控件包含的取值个数（各因素的水平数，即各因素的状态数）

    - 如： L9（3^4）

有4个控件

每个控件有3个取值

9为需要测试的组合个数

叫4因素3水平

正交排列法的使用步骤

    - 1、根据所测程序中控件的个数（因素）以及每个控件的取值个数（水平），选取一个合适的正交排列表

          - 2、把控件及其取值列举出来，并对其进行编号

          - 3、把控件及其取值映射到正交排列表中

        - 把正交排列表中的ABCD（因子）分别替换成4个控件

        - 把每列中的1,2,3（状态）分别换成这个控件的3个取值（水平），排列顺序要按            照表中给出的顺序

          - 4、根据映射好的正交排列表编写测试用例

案例：字符属性设置程序

- 窗体中有多个控件（字体、字符样式、颜色、字号），每个控件有多个取值

字体：仿宋、楷体、华文彩云

字符样式：粗体、斜体、下划线

颜色：红色、绿色、蓝色

字号：20号、30号、40号

- 由于组合量非常大（3^4=81种组合情况），因此考虑使用正交法，选择L9（3^4）正交排列表

步骤1

根据所测程序中控件的个数以及每个控件的取值个数，选取一个合适的正交排列表

- 4个控件（因素）：字体、字符样式、颜色、字号

- 每个控件有3个取值（水平）

- 选择L9（3^4）正交排列表

步骤2

把控件及其取值列举出来，并对取值进行编号

步骤3:

把控件及其取值映射到正交排列表中

- 1、把正交排列表中的A、B、C、D（因子）分别替换成4个控件

- 2、把每列中的1,2,3（状态）分别换成这个控件的3个取值，排列顺序要按照表中给出的顺序

步骤4:

根据映射好的正交排列表编写测试用例

- 正交表的每一行表示一种组合，对应编写一条测试用例

依次类推，把映射好的正交排列表中的每一行，转换成一条测试用例。

      这是进行测试的最少组合数量，但是，在测试中有72种（81-9）组合没有测试到。当然，如果时间允许，应该再补充一些用例。因为遗漏的组合越多，存在缺陷的可能性就越大。(时间问题！内测、公测)

正交表使用方法总结

    根据控件和取值数选择一个合适的正交表

    列举取值并编号,生成取值表

    把取值表与选择的正交表进行映射

案例：114系统查询企业单位

- 完全测试需设计用例数：2^5=32

- 有五个因素:

    - 音形码、拼音码、路名码、行业类别和特征码

    - 每个因素有两个水平5

    - 音形码：填、不填

    - 拼音码：填、不填

    - 路名码：填、不填

    - 行业类别：填、不填

    - 特征码：填、不填

  - 选择正交表

  - 表中的因素数＞＝ 5

  - 表中至少有五个因素的水平数＞＝ 2

  - 行数取最少的一个

  - 结果： L8（2^7）

  - 变量映射

  - 音形码：    1-填写  0-不填写

  - 拼音码：    1-填写  0-不填写

  - 路名码：    1-填写  0-不填写

  - 行业类别： 1-填写 0-不填写

- 特征码： 1-填写  0-不填写

- 把映射好的正交排列表中的每一行，转换成一条测试用例，写8条测试用例就可以了，正交排列表是经过严格的数学推理得来的，也就是说这8条用例是最优的。这是进行测试的最少组合数量，但是，在测试中有24种（32-8）组合没有测试到。当然，如果时间允许，应该再补充一些用例。因为遗漏的组合越多，存在缺陷的可能性就越大。

- 测试用例设计如下：

- 音形码填写、拼音码填写、路名码填写、行业类别填写、特征码填写

- 音形码填写、拼音码填写、路名码填写、行业类别不填、特征码不填

- 音形码填写、拼音码不填、路名码不填、行业类别填写、特征码填写

- 音形码填写、拼音码不填、路名码不填、行业类别不填、特征码不填

- 音形码不填、拼音码填写、路名码不填、行业类别填写、特征码不填

- 音形码不填、拼音码填写、路名码不填、行业类别不填、特征码填写

- 音形码不填、拼音码不填、路名码填写、行业类别填写、特征码不填

- 音形码不填、拼音码不填、路名码填写、行业类别不填、特征码填写

使用正交排列法的局限性

    - 目前常见的正交排列表只有前面附录文件中给出的几种

    - 即使是已有的正交排列表，基本都要求每个控件中取值的个数要相等，这在实际软件中很少遇到。

- 没有现成的正交排列表怎么办？

    - 通过正交排列法的学习，我们更多的应该学习到一种测试思想，也就是在从所有组合集合中选取测试数据时，应该均匀的选取其中的组合作为测试用例，而不要只在某个局部选取数据。

混合正交表

水平数不同

因素（变量）的水平数（变量的取值）不相同

例如

找不到现成的正交表，就只能使用工具来生成！

正交表生成工具all pairs

很多情况下无法找到合适的正交表，就要使用正交表生成工具

使用步骤:

制作取值表（只列出数据即可，不用编号）

复制取值表的数据，放到文本文档中保存（注意不要更改任何格式，例如文件叫Test2.txt ）

把文本文档放在allpairs文件夹中

win+r后输入cmd进入控制台

使用控制台代码进入allpairs文件夹（cd 目录名字）

在控制台中输入allpairs.exe Test2.txt>chenggong.txt  （ chenggong是自己起的名字，用来存放生成的组合用例，可以自动生成，不必提前建好）

1.制作取值表 

2.复制取值表的数据，放到文本文档中保存

3.把文本文档放在allpairs文件夹中

4.win+r后输入cmd进入控制台

5.使用控制台代码进入allpairs文件夹（cd 目录名字）

6.在控制台中输入allpairs.exe Test2.txt>chenggong.txt

最终得出测试用例

八，测试用例方法总结

通常，在确定测试方法时，应遵循以下原则：

- 根据程序的重要性和一旦发生故障将造成的损失来确定测试等级和测试重点。

- 认真选择测试策略，以便能尽可能少的使用测试用例，发现尽可能多的程序错误。因为一次完整的软件测试过后，如果程序中遗留的错误过多并且严重，则表明该次测试是不足的，而测试不足则意味着让用户承担隐藏错误带来的危险，但测试过度又会带来资源的浪费。因此测试需要找到一个平衡点。

测试方法的选择

通常在确定测试方法时，有以下几条参考原则：

- （1）拿到一个测试任务时，先关注它的主要功能和业务流程、业务逻辑是否正确实现，考虑使用场景法。

- （2）需要输入数据的地方，考虑采用等价类划分法，包括输入条件和输出条件的等价划分，将无限测试变成有限测试。

- （3）在任何情况下都必须采用边界值分析法。这种方法设计出的测试用例发现程序错误的能力最强。

- （4）如果程序的功能说明中含有输入条件的组合情况，则一开始就应考虑选用因果图和判定表法。

- （5）对于参数配置类的软件，需要考虑参数之间的组合情况，考虑使用正交排列法选择较少的组合方式（最少的测试用例获得最大的的测试覆盖率）。

- （6）对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，则应当再补充更多的测试用例。

- （7）采用错误推断法再追加测试用例——依靠测试工程师的经验和智慧。

测试用例的力度

测试用例可以写的很简单，也可以写的很复杂。

- 最简单的测试用例是测试的纲要，仅仅指出要测试的内容。

    - 测试用例写的过于简单，则可能失去了测试用例的意义。过于简单的测试用例设计其实并没有进行“设计”，只是需要把测试的功能模块记录下来而已，它的作用仅仅是在测试过程中作为一个简单的测试计划，提醒测试人员测试的主要功能包括哪些而已。

- 最复杂的测试用例则会指定输入的每项数据，期待的结果即检验方法，具体到界面元素的操作步骤，指定测试的方法和工具等。

    - 测试用例写得过于复杂或详细，会带来两个问题：一个是效率问题，另一个是维护成本问题。另外，测试用例设计的过于详细，留给测试执行人员的思考空间就比较少，容易限制测试人员的思维。

> 大多数的测试团队编写的测试用例的力度介于两者之间

测试用例的本质

测试用例的设计本质应该是在设计的过程中理解需求，检验需求，并把对软件系统的测试方法的思路记录下来，以便指导将来的测试。

- 基于需求的测试用例设计

    - 基于需求的用例场景来设计测试用例是最直接有效的方法，因为它直接覆盖了需求，而需求是软件的根本，验证对需求的覆盖是软件测试的根本目的。

    - 要把测试用例当成活的文档，因为需求是活的，善变的。因此在设计测试用例方面应该要把敏捷方法的“及时响应变更比遵循计划更有价值”这一原则体现出来。

> 不要认为测试用例设计是一个阶段，测试用例的设计也需要迭代，在软件开发的不同阶段都要回来重新评审和完善测试用例。

测试用例评审

同行评审

- 测试用例的检查方式有很多，同行评审是其中最敏捷的一种。

- “个体和交互比过程和工具更有价值”，这强调了测试用例设计者之间的思想碰撞，通过探讨、协作来完成测试用例的设计。

用户评审

- “顾客的协作比合同谈判更有价值”。

>  如果测试是对产品的批判，则顾客应该指最终用户或顾客代表（在内部可以是市场调查人员或相关领域专家）；

>如果测试被定义为对开发提供帮助和支持，那么顾客就是程序员。