因果图测试用例

软件测试基本概念

软件测试的定义：

1.软件测试是为了发现错误而执行程序的过程。

2.软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例，并利用这些测试用例运行程序以及发现错误的过程，即执行测试步骤

其实这两种定义是一致的，前面一种定义，强调了软件测试的目的，后面一种定义强调了软件测试的方法和过程。通过这两个定义，我们知道了，软件测试就是通过设计测试方法和用例，对软件进行流程抽样得到软件正确性，可靠性的过程。

软件测试在软件生命周期中横跨两个阶段：

第一个阶段：单元阶段，即在每个模块编写出以后所做的必要测试。

第二个阶段：综合测试阶段，即爱完成单元测试后进行的测试，如集成测试，系统测试，验收测试。

测试用例：所谓测试用例是为特定的目的而设计的一组测试输入，执行条件和预期的结果；测试用例是执行测试的最小实体，一个好的测试用例在于发现了还未曾发现的错误，一次成功的测试则是发现了错误的测试。

测试步骤：测试步骤详细规定了如何设置，执行，评估特定的测试用例。

我们都不可能对程序进行完全测试。原因有三点：

1.可能的输入范围太大，根本无法穷举测试。

2.程序中可能的运行路径太多，根本无法穷尽测试。

3.用户界面问题太复杂，不可能进行完全测试。

既然不可能进行完全测试，那么我们也就无法验证一个程序的正确性，那测试的目的到底是什么呢？

测试的目的是发现错误。测试是程序的执行过程，目的在于发现错误，并且是尽可能地发现更是多错误，发现的错误越严重越好。

根据以上软件测试的目的，总结出软件测试的原则是：

1.尽早地和及时地测试，发现的越晚，修复的代价越高

2.测试用例应当由测试数据和与之对应的预期结果两部分组成

3.在程序提交测试后，应但有专门的测试人员进行测试，避免有程序设计者自行检查程序

4.测试用例应包括合理的输入条件和不合理的输入条件

5.严格执行测试计划，排除测试的随意性

6.充分注意测试当中的群里现象

7.应对每一个测试结果做全面的检查

8.保存测试计划，测试用例，出错统计和最终分析报告，为维护工作提供充分的资料。

测试停止的依据标准

1.第一类标准:测试超过了预定时间，则停止测试。

2.第二类标准：执行了所有的测试用例，但并没有发现故障，则停止测试。

3.第三类标准：使用特定的测试用例设计方案作为判断测试停止的基础。

4.第四类标准：正面指出停止测试的具体要求，即停止测试的标准可定义为查出某一预订

数目的故障。

5.第五类标准：根据单位时间内查出故障的数量决定是否停止测试。

软件测试的分类：

1.按照是否需要执行程序，软件测试可划分为静态测试和动态测试。

2.按照软件测试用例的设计方法，软件测试可以分为白盒测试和黑盒测试

3.按照软件测试的策略和过程，软件测试可分为单元测试，集成测试，系统测试，验收测

试和确认测试。

一、现在有一个小程序，能够求出3个在-10000到+10000间整数中的最大者

1．数值等价类

对每个文本框而言，输入值的限制是在-10000到+10000之间，因此，我们可以划分一个有效等价类和两个无效等价类

<-10000

-10000到+10000

>+10000

测试用例略。。。。

2．数据类型等价类

由于在文本框中只能输入整数，因此可以确定：

有效等价类：数字

无效等价类：字母，小数点，控制字符，功能键

测试用例略。。。。

3.其它：除了上面列出的测试用例以外，为了使程序的性能更稳定，良好，还要设计下的用例：

因果图法

因果图中使用的是简单的逻辑符号，以直线连接左右节点，左结点表示输入状态或称原因，右结点表示输出状态或称结果：

下面是考虑输入和输出的状态：

恒等：若原因出现，则结果出现，若原因不出现，结果也不出现

非：若原因出现，则结果不出现，若原因不出现，则结果出现

或：若几个原因中1个出现，则结果出现，若几个原因都不出现，则结果不出现

与：若几个原因都出现，结果才出现，若有1个原因不出现，则结果不出现。

输入与输入之间的依赖关系：

E约束：a和b中至多有一个可能为1，即a和b 不能同时为1。

I约束：a、b和c中至少有一个必须为1，即a、b和c 不能同时为0。

O约束：a和b必须有一个，且仅有一个为1。

R约束：a是1，b必须是1，即不可能a是1时b是0。

输出条件的约束类型只有M约束：若结果a是1，则结果b 强制为0。

因果图设计步骤如下：

1．分析程序规格说明书中，哪些是原因，哪些是结果，并给每个原因和结果赋予一个标识符。原因常常是输入条件或是输入条件的等价类，而结果是输出条件。

2．分析程序规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的关系，根据这些关系，画出因果图

3．由于语法和环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现，为表明这些特殊情况，在因果图上用一些记号表明约束或限制条件。

4．把因果图转换成判定表。

5．把判定表的每一列拿出来作为依据，设计测试用例。

判定表decision table

判定表：是分析和表达多逻辑条件下执行不同操作的情况下的工具。

由于它能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。

1．判定表组成：

判定表通常由4个部分组成，

条件桩condition stub：列出了问题的所有条件，通常认为列出的条件的次序无关紧要。

动作桩action stub：列出了问题规定可能采取的操作，这些操作的排列顺序没有约束

条件项condition entry：列出针对它所列条件的取值，再所有可能情况的真假值。

动作项action entry：列出在条件项的各种取值情况下应该采取的动作。

2．规则及规则合并

规则：任何一个条件组合的特定取值及其相应要执行的操作，在判定表中贯穿条件项和动作项的一列就是一条规则。显然，判定表中列出多少组条件取值，也就有多少规则，即条件项和动作项有多少列。

化简：就是规则合并，有两条或多条规则具有相同的动作，并且其条件项之间存在着极为相似的关系。

3．建立判定表

判定表的建立应该依据软件规格说明，步骤如下：

1．确定规则的个数，假如有N个条件，每个条件有两个取值（0，1），故又2n 种规则。

2．列出所有的条件桩和动作桩

3．填入条件项

4．填入动作项，制定初始判定表

5．简化：合并相似规则或者相同动作。

适合使用判定表设计测试用例的条件：

1．规格说明以判定表的形式给出，或很容易转换成判定表

2．条件的排列顺序不影响执行那些操作

3．规则的排列顺序不影响执行那些操作

4．当某一规则的条件已经满足，并确定要执行的操作后，不比检验别的规则

5．如果某一规则要执行多个操作，这些操作的执行顺序无关紧要。

练习：

1．订购单的检查。

如果金额超过500元，又未过期，则发出批准单和提货单；

如果金额超过500元，但过期了，则不发批准单；

如果金额低于500元，则不论是否过期都发出批准单和提货单，在过期的情况下还需要发出通知单。

简化：比如〉500未过期和〈=500未过期。这两个条件项导致的结果是一样的，并

这里再引入一个概念--规则，以上判定表里，右部的每一列（条件项和对应的动作项）

因果图测试用例：

1.有一个处理单价为1元5角钱的盒装饮料的自动售货机软件。

若投入1元5角硬币，按下可乐，雪碧，红茶按钮，相应的饮料就送出来。若投入2元硬币，在送出饮料的同时退还5角硬币

分析：这一段说明，我们可以列出原因和结果

原因：

1.投入1元5角

2.投入2元硬币

3.按可乐按钮

4.按雪碧按钮

5.按红茶按钮

中间状态

11．已投币

12．已按钮

结果：

21.退还5角硬币

22.送出可乐饮料

23.送出雪碧饮料

24.送出红茶饮料

因果图略。。。。。。

易用性：

易用性包含易见性，易学习性、易用性。即软件产品被理解，学习，使用和吸引用户的能力。

易见是指单单凭观察，用户就应知道程序的状态。

易学是指不通过帮助文件或简单的帮助文件，用户就能对一个陌生的软件产品有清晰的认识。

易用是指用户不翻阅手册就能使用该软件。

效率性是指用户熟悉软件功能或界面后，完成任务的速度。

出错率是指在使用软件过程中，用户出现了多少错误，这些错误有多严重，从错误中是否容易恢复等。