软件测试基础知识理论+举例应用

1.1软件测试目的：以最少的人力、物力和时间找出软件中的各种缺陷和错误，保证各种错误和缺陷得以修复，避免软件发布后由于潜在的软件错误和缺陷造成的隐患所带来的商业风险。

                 同时利用测试过程中得到的测试结果和测试信息，作为后续项目开发和测试过程改进的重要输入，避免在将来的项目开发和测试中重复同样的错误；

                 采用更加高效的测试管理手段，提高软件测试的效率和软件产品的质量。

1.2测试和调试的区别：

    

	测试	调试
主体	测试人员	开发
目标	找Bug	将错误修改正确
方法	等价类、边界值....	程序和逻辑算法
思路	反向思维	正向思维

测试时从已知的条件开始，使用预先定义的过程，并且有预知的结果；调试是从未知的条件开始，结束的过程可能不可预计。

测试可以计划，可以预定测试用例和过程，工作进度可以度量；描述调试的过程或持续状态比较困难。

测试的对象包括软件开发过程中的文档、数据以及代码，而调试对象一般只是代码。

2.1软件工程包括两方面的内容：

     软件开发技术：软件开发方法学、软件工具和软件工程环境

     软件项目管理：软件质量、项目估算、进度控制、人员组织、配置管理、项目计划

2.2软件生命周期模型

1、瀑布模型（最早提出的软件开发的过程模型）

 存在的问题：

（1）强调时间顺序严格执行，前阶段不执行，后阶段不开始

1. 将测试放在了编码之后（没有体现出测试贯穿软件生命周期的原则，可避免需求的问题一直延续到代码完成才暴露或者才被发现）
2. 不适应用户需求变化

2、螺旋模型

引入风险分析

3、迭代模型

降低在一个增量上的开支风险

降低产品无法按照既定进度进入市场的风险

加快了整个开发工作的进度

迭代过程这种模式使适应需求的变化更加容易些

4、敏捷宣言

       

个体和互动	高于	流程和工具
工作的软件		详尽的文档
客户合作		合同谈判
响应变化		遵循计划

敏捷开发scrum

5、增量模型：把软件分割成独立模块，分批次的完成和交付

        缺点：打破原有的软件结构和框架，可能会带来一定的风险

增量模型一般会和迭代模型一起运用

1. 软件增加了新功能。
2. 优化了......功能
3. 修复了某些未知\已知bug

6、快速原型模式

   应用领域越来越多

   原型：就是一个模型，可以模拟操作、简单运行

典型应用和工具：Axure制作原型

3.1软件测试流程

     

获取测试需求

编写测试计划

制定测试方案

开发与设计测试用例

执行测试

提交缺陷报告

测试分析与评审

提交测试总结

准备下一版本测试

3.2软件测试过程模型

V模型

缺点与不足：V模型仅仅把测试过程作为在需求分析、系统分析以及编码之后的一个阶段，忽略了测试对需求分析、系统设计的验证；

            需求的满足情况一直到后期的验收测试才被验证；

没有体现出“尽早的和不断地进行软件测试”的原则。

W模型。由两个V模型组成，分别代表测试与开发的过程，明确表达了测试与开发的并行关系

优势：测试的活动与软件开发同步进行；

  测试对象不仅仅是程序，包括需求和设计；

  尽早发现软件缺陷可降低软件开发的成本；

    局限性：需求、设计、编码等活动被视为串行的，无法支持灵活的迭代

H模型

揭示了一个原理：软件测试是一个独立的流程；

软件测试要尽早准备、尽早执行；X模型X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，能帮助有经验的测试人员在测试计划之外发现更多的软件错误。

The.测试过程（工作独立性）

A：研发团队内部的测试岗位

B：企业内部的独立于研发部门的测试岗位

C：专门的测试外包公司的岗位

D：开发人员自己测试

测试独立性由高到低排序：C>B>A>D

3.3软件测试过程理念

尽早测试

全面测试

全过程测试

独立的、迭代的测试

4.1软件测试分类

 按照开发阶段划分：

（1）单元测试，单元测试又称弄快测试，是针对软件测试设计的最小单位--程序模块进行正确的检验的测试工作。需要从程序的内部结构出发设计测试用例。多个模块可以平行的独立进行单元测试。

一般要读程序和代码，大多数时候单元测试是由开发人员自己去完成（交叉）。（但是一般不认为是在做测试）测试人员为什么不做单元测试？（大家不懂代码和算法）

（2）集成测试

集成测试也叫组装测试。在单元测试基础上所有模块进行有序递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。

比较多的涉及到接口测试（接口测试工具和方法专门学习），企业非常需要接口测试工程师。它是一个持续不断的过程。

（3）确认测试（功能是否实现）

是在模拟的环境下，验证软件的所有功能和性能以及其他特性是否与用户的预期要求一致。通过了确认测试之后的软件，才具备进入系统测试阶段的资质

一般都是正向的测试。有些时候也把确认测试称为冒烟测试，一般不作为正式的测试环节。

（4）系统测试

在真实的系统运行的环境下，检查完整的程序能否与系统（包括硬件、外设、网络和系统软件、支持平台）

全面的：系统所有功能的测试：模拟所有的软件用户的操作；

全方位的：和硬件系统的联系、和系统软件的联系、和其他软件的关系

（5）验收测试

一般供求双方达成。一般由三种验收测试的主体：a测试：软件的开发商自己进行的交付前的测试；β测试：软件的需求方自己进行的测试；γ测试：第三方的软件测试

按照代码运行划分：（1）静态测试：指不实际运行被测对象，静态的检查程序代码（测试代码是否符合相应的标准和规范）、界面（测试软件的实际界面是否与需求中的说明相符）或文档（测试用户手册与需求说明是否真正符合用户的实际需求）中可能存在的问题；        （2）动态测试：指实际运行被测对象，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程

按照软件特性划分：

      0.）功能测试：是黑盒测试的一方面，它检查实际软件的功能是否符合用户需求。

.逻辑功能测试

.界面测试

.易用性测试

.安装/卸载测试

.兼容性测试

1. ）性能测试：功能的另一个指标，主要关注软件中的某一功能在特定的时间空间条件下，是否使用正常。软件的性能包括很多方面，主要是时间性能和空间性能。
2. ）安全性测试：验证安装在系统内的保护机制能否在实际应用中对系统进行保护，使之不被非法入侵，不受各种因素的干扰。

按照测试技术：

1. 黑盒测试。通过软件的外部表现来发现软件的缺陷和错误。黑盒测试法把测试对象看成一个黑盒子完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试，它只是检查程序是否按照需求规格说明书的规定正常实现。
2. 白盒测试。通过对程序内部结构的分析、检测来寻找问题。白盒测试可以把程序看成装在一个透明的盒子里，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。白盒测试又称为结构测试。
3. 灰盒测试。介于黑白盒测试之间的测试。灰盒测试关注于输出对于输入的正确关注内部表现，但是这种关注不像白盒测试

其他测试：

1. 冒烟测试：指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。也叫可测性测试。
2. 随机测试：指测试人员基于经验和直觉的测试，发现一些边缘性的错误。
3. 猴子测试：随便乱点，没有任何主观意识和想法参与进来，让一些意想不到的操作造成错误的结果。

4. 回归测试：指对软件的新版本测试时，重复执行之前某一个重要版本的所有测试用例

   目的：验证之前版本产生的所有缺陷已全部被修复；确认修复这些缺陷没有引发新的缺陷

按照测试运行主体划分：

1. 手工测试（功能测试）：（点点点）
2. 自动化测试。利用工具软件，或者编写代码的方法，测试被测的软件系统。（游戏外挂）

总结性

	单元测试	集成测试	确认测试	系统测试	验收测试
测试技术	黑盒 白盒	黑盒 白盒 灰盒	黑盒 白盒	黑盒 白盒	黑盒 白盒
代码运行	动态、静态	动态、静态	动态、静态	动态、静态	动态、静态
软件特性	功能 性能 安全	功能 性能 安全	功能 性能 安全	功能 性能 安全	功能 性能 安全
其他测试			冒烟测试	回归测试	随机测试 猴子测试
测试手段	手工 自动化

4.2软件测试原则

所有测试的标准都是建立在用户需求之上；

软件测试必须基于“质量第一”的思想去开开展各项工作，当时间的质量冲突时，时间要服从质量；

事先定义好产品的质量标准，只有有了质量标准，才能根据测试的结构，对产品的质量进行分析和评估；

软件项目一启动，软件测试也就是开始，而不是等出席写完，才开始测试；

穷举测试是不可能的；

第三方进行测试会更客观，更有效；

软件测试计划是做好软件测试工作的前提；

测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多的发现错误，提高程序的可靠性。

对发现错误较多的程序段，应进行更深入的测试。一般来说，一段程序中已发现的错误数越多，其中存在的错误概率也就越大。

重视文档，妥善保存一切测试过程文档（测试计划、测试用例、测试报告等）

应当把“尽早和不断测试”作为测试人员的座右铭

回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多错误出现的现象并不少见

测试应从“小规模”开始，逐步转向“大规模”

不可将测试用例置之度外，排除随意性

必须彻底检查每一个测试结果

一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系

对测试错误结果一定要有一个确认的过程

遇到的问题：1.测试时间不够的情况下（还有大量内容没有测试），软件能不能发布/上线？

1. 有的严重BUG没修复，但是赶着上线，能不能通融/放任？
2. 需求重要吗？错误的需求对测试有什么影响？
3. 你觉得软件测试在什么阶段介入比较好？为什么？
4. 软件发布了，但是有缺陷是测试人员的错吗？
5. 你写过测试计划吗？包含什么内容？测试计划可以被修改吗？
6. 设计和编写测试用例有什么区别？设计是一项脑力活动，编写是一项体力活动，将设计好的内容通过文字的形式表现出来。
7. 针对已经发现了缺陷得模块，如何进行深入测试？对发现缺陷模块使劲测，另外关联的模块也要进行测试。（缺陷有一种集群效应）
8. 软件项目不着急的时候，测试任务完成了，你会干什么？反复不断测试。
9. 软件项目上线了，还要进行测试吗？
10. 你觉得你有什么样的缺点？（不能说的：粗心、耐心不够、不善于与人沟通、语言表达能力不行）（斤斤计较，穷追不舍、轴）

5.1测试用例

简单的说，测试用例就是：

设计一个情况，软件程序在这种情况下，必须能够正常运行并且达到程序所设计的预期结果

如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那就表示程序软件人员已经测出软件有缺陷，这时就必须将这个问题标示出来并且通知软件开发人员。软件开发人员接获通过后，将这个问题修改完成于下一个测试版本内

软件测试工程师取得新的测试版本后，必须利用同一个用例来测试这个问题，确保该问题已修改完成

问题： 1.  什么是测试用例？

1. 如果软件按照测试用例运行达不到预期的结果，怎么办？
2. 开发人员说缺陷修复了，你认可吗？
3. 测试用例真的有必要耗费时间进行设计和编写吗？有用吗?
4. 时间不够用的情况下，还要进行详细的测试用例设计吗？尽可能多的进行测试，详细和效率找到平衡点
5. 测试用例需要经常更新吗？必须更新，尤其是发现过缺陷的测试用例。“杀虫剂效应”，一个发现过缺陷得测试用例就相当于杀虫剂。必须使用更强的“杀虫剂”——新的测试用例（与之前的用例中数据类型保持一致）进行重新测试。
6. 现在有一个文本框，有一个规则：XXXXX，请对这个规则进行输入内容的等价划分？尽可能详细的划分

测试用例模板

用例设计模板说明：

1. 标识符（用例编号）：一般编号规则：TestCase_项目名称_模块名称_功能名称_0001
2. 测试项。测试用例的测试目的。一般情况下，用一句话表明目的。例如：使用谷歌浏览器打开百度首页；在QQ登录界面输入正确的用户名密码能登录上。（表明你的测试模块、测试对象、方式、事件）（A：人名 B：人名 C：时间 D：地点 E：事件）
3. 依赖用例：一般功能流程上，下游的功能测试依赖于上游的功能测试的用例。例如：增加了一个数据的测试用例，将会被删除该数据的测试用例依赖。
4. 测试步骤。用最朴实的语言，写出来软件的操作步骤。要尽量详细。例如：在用户名文本框输入：XXX；在省份下拉列表选择：北京  城市下拉列表选择：北京
5. 测试数据：单独整合测试数据，必须和测试步骤中的数据保持一致。
6. 预期结果。准确、对象的准确性，内容的准确性。原则上每一个操作都要有一个结果。在重要的步骤之后，设定预期结果。例如：页面跳转到XXX；程序弹出对话框，提示：用户名或者密码错误，请重新输入！一般和测试目的密切相关。测试目的决定了测试步骤和预期结果。
7. 测试结果。要求在测试执行完成后添加。没有执行保持为空。测试结果只有两个：通过/失败；Pass/Failed。和预期结果一致即为通过；不一致即为失败。
8. 测试人。测试的执行人，可以和设计者相同，也可以不同。
9. 备注。为了测试用例正常执行而做的特殊准备。例如：专门制造网络不畅情况下，软件错误提示；

测试用例问题：

1. 用例按照测试分类：功能（Function）、界面（UI）、性能（Performance）、安全（Security）、接口（Interface）。
2. 测试项必须是确定的。测试项中可以不写目的产生结果，写了不算错。
3. 测试项一般只写一个测试目的，测试目的必须滴明确的，不能一次测试多个点。测试中一个反向的（无效等价类）测试数据，只能违反一个需求。例如非法的身份证号：130112198922301542。
4. 依赖用例。下游的用例依赖上游的用例（已经存在的测试用例），用例依赖可以跨越模块（A设计员可能依赖B设计员的测试用例）
5. 测试步骤。表明操作的对象和方式，数据。
6. 测试数据。没有数据空着不写；例如输入要求不为空，不输入就不写（需在测试项中标注某一个内容为空）。如果要对空格进行测试（ 数据 ）（建议不要把空格放在数据的最前面或者最后面）（123 456）
7. 测试结果。不执行就不填
8. 用例中不需要显示正向反向。
9. 等价类划分。不要出现重复的情况，也不要出现缺失的部分。

5.1.2用例设计和编写的作用：

有效性：测试用例是测试人员测试过程中的重要参考依据

可复用性：良好的测试用例具有重复使用的功能，使得测试过程事半功倍，提高测试效率

易组织性：即使是小的项目，也有可能会有几千甚至更多的测试用例，测试用例可能在数月甚至几年的测试过程中被创建和使用

可评估性：从测试的项目管理角度来说，测试用例的通过率是检验代码质量的保证

可管理性：测试用例也可以作为检验测试人员进度、工作量以及跟踪/管理测试人员工作效率的标准

5.2黑盒测试用例设计方法（等价类划分法，边界值法分析法，因果图法，错误推测法）

等价类划分法

原理：把程序的输入域划分若干部分，然后从每个部分中选取少数代表性数据作为测试用例

每一类的代表性数据在测试中的作用等价于这一类中的其他值，如果是某一类的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误，反之也成立。

等价类划分的原则：

1. 在输入条件规定了取值范围的个数的情况下，可以确定一个有效等价类和两个无效等价类

例如：一个文本框规定，输入字符个数为6~18位。

一个有效等价类：范围内个数

两个无效：小于6，大于18位

   2.在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个等价有效类和一个等价无效类

例如：请输入11位的手机号

11位就是有效

不是11位就是无效

    3.在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类

布尔量：表示“真”或者“假”

   4.在规定了输入数据的一组值（假定n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类

例如：登录中要输入用户名和密码

    5.在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类

例如：用户名要求6~18由字母数字下划线组成，字母区分大小写，以大写字母开头

    6.在确定已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步划分为更小的等价类

以百度注册页面为例：

用户名：设置后不可更改；中英文均可；最多14个英文或7个汉字。（用户名不可重复；不可为空；）

将等价类划分：

有效等价类	数据	无效等价类	数据
中文英文混合	杨kaikai	数字、特殊符号	123456
14英文/7个中文	yangkaikai	英文超过14/中文超过7	Accfbbjnnhumnnnn
不能为空	Y	为空
不能重复	杨凯	使用重复的数据进行测试	杨凯凯
7个中文	嘤嘤嘤

边界值分析法

边界值选择原则

边界值只是一个特定的数据。例如：文本框需要输入6~18位字符

边界值有：1）6个字符

  2）18个字符

次边界。边界附近的值，按照系统规定的单位或者计算方式，一个数据的差异。

例如：字符就是个，一个字符，没有半个字符的说法；人民币金额最小单位是0.01元，ATM机取款和存款，最小单位就是100元，只能是100元的整数倍

思考：1）6<=x<=18,请问测试中x的边界值要选取哪几个进行测试？5 7 17 19

      2）6<x<18,请问测试中x的边界值要选取哪几个进行测试？6  8 16 18

  3）文本框输入字符的个数要求是不大于150字，测试时候如何选择边界值？（0<=x<=150）空 1 149 151(空值就是最小的了，不能取负值）

 因果图法

一种适合于描述对于多种输入条件组合的测试方法；根据输入条件的组合、约束关系和输出结果的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法；适合于检查程序输入条件涉及的各种组合情况。

  1.原因和结果的关系

1. 恒等。原因A成立，结果B一定成立。
2. 非。原因A成立时，结果B一定不成立。
3. 或。原因ABC三者只要有一个成立，结果D成立。
4. 与。原因ABC三者都要成立，结果D成立。

        2.根据功能说明在因果图中加上约束条件，假如原因成立用1表示，不成立用0表示。（互斥、包含、唯一是对原因的约束，屏蔽是对结果的约束）

1. 互斥(Exclusive)。A+B+C≤1
2. 包含(Include)。3≥A+B+C≥1
3. 唯一(Only)。A+B+C==1
4. 要求(Request)。原因A成立要求B一定要先成立
5. 屏蔽(Mask)。结果之间会出现A结果出现B结果一定不出现。当你收到注册成功的提示就一定不会收到数据填写错误的提示。

   3因果图实例分析.

案例:自助售货机卖啤酒和橙汁，处理单价5角，投5角硬币，按下按钮处饮料；投币1元按下按钮，处饮料，找零5角

分析原因和结果：

画出原因和结果之间的关系（部分）

按照需求描述原因、结果间的约束

因果图使用中的局限性：当原因和结果很多的时候，之间的关系连线就会很多导致因果图的可读性变差。因此用局部的小功能（原因和结果不是很多的时候）分析。

列出所有的原因和结果的列表，设计初步的测试用例步骤

		Case1	Case2	Case3	Case4	Case5	Case6	Case7
投币	投5角	1	1				1
	投一元			1	1			1
按钮	选橙汁	1		1		1
	选啤酒		1		1
结果	出橙汁	1		1		1
	出啤酒		1		1
	找零五角			1	1

Case5是一种BUG.不能做测试设计。

因果图的优势在于能够发现设计中存在的不足。

经过分析发现：

1. 只选择饮料，没有投币的时候，软件没有任何结果；
2. 只投币，没有选择饮料的时候，软件也没有任何的结果；
3. 我们不能把软件的缺陷设计成测试用例

5.3判定表法

分析和表达多逻辑下执行不同操作的情况的分析

1. 应用场合：主要适用于多条件的内容组合和结果分析
2. 组成：由条件项、动作项、条件桩、动作桩四部分组成
3. 使用的条件：所有的条件桩在表中的位置和顺序互相不影响；所有的动作桩的顺序不会因为条件顺序的变化而产生不同。
4. 实现的步骤

1. ）识别出操作条件（原因）和对应的动作（结果）
2. ）分析条件的条件项（组合数量）：如果有n个条件，每个条件有成立和不成立两种情况，那么最后一共会有2……n个数量
3. ）简化和优化结果。排除一些不可能存在的情况

实例：需求：订购单的检查。

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

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

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

       1）分析条件和动作

条件1	条件2	条件3
金额>500	未过期	发出批准单，提货单
金额>500	过期	不发批准单，提货单
金额<=500	未过期	发出批准单，提货单
金额<=500	过期	发出批准单，提货单，通知单

         2）写入条件桩、动作桩、条件项、动作项：

        3）对判定表进行简化和优化（对其中不合理或者重复的进行取舍）

   不管金额的高低，只要未过期，就会发送批准单和提货单。（在测试时间不充足的情况下，可以二者中的一个情况进行测试,时间充足的情况下，每一个都要测试），所以优化之后，条件项就减少成为3个：

       4）将判定表中的每一列（条件项和对应的动作项）作为测试用例的数据和操作以及对应的预期结果。

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

1. 规则说明以判定表的形式给出，或很容易转换成判定表；
2. 条件的排列顺序不影响执行哪些操作；
3. 规则的排列顺序不影响执行哪些操作；
4. 当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则；
5. 如果某一规则要执行多个操作，这些操作的执行顺序无关紧要。

测试用例的设计方法：没有哪一种方法是单独使用。

1. 所有的软件，都是因为某种操作才会导致一定的结果。--考虑使用因果图
2. 所有的软件都有文本框。--考虑必须一定使用等价类、边界值。

判定表的实例题目难：该判定表为一个杂志的阅读指南判定，指导读者能够良性阅读。

读完表格后，请对表格内容进行优化，将重复的内容去掉。并且说明原因      

合并1、2、3、4位一项。在疲倦的情况下一律信息即可。

合并7、8为一项，在都不疲倦的情况下，不感兴趣就跳下一章

5.4场景法

重点

基本流（软件功能正确实现的流程）

备选流（基本功能流程之外的过程）

注意

1. 场景中必须有基本流
2. 场景中必须有内容从用例的开始到用例的结束

实例ATM机取款：

基本流：插卡-输入-密码-……出钞……取卡

包含了备选流的过程

备选流：

1. 卡片不是银行卡
2. 卡片不是银联的卡
3. 密码输入错误一次
4. 密码错误两次，第三次输入正确
5. 密码输入错误三次，冻结账号或者吞卡
6. 选择存款服务
7. 选择查询服务
8. 选择转账服务
9. 选择修改密码服务
10. 选择取款金额
11. 选择其他金额
12. 账户金额
13. ATM机没钱了
14. 账户取款金额达到取款机的当日金额上限

……

场景设计

场景1：基本流

场景2：基本流 备选流5

场景3：基本流 备选流1

场景4：基本流 备选流4

场景5：基本流 备选流2 备选流4

……

设计测试用例：

1. 每一个场景都是一个测试用例。

以场景5为例：设计步骤

假定ATM机只能识别银联卡（用一个万事达卡先进行插入）

1. 插卡（先用万事达卡）
2. 换卡（银联卡）再进行插卡
3. 输入密码（第一次输入错误）
4. 再次输入密码（第二次输入错误）
5. 第三次输入密码（输入正确）
6. 选择服务-取款
7. 选择取款金额-500
8. 等待出钞
9. 取卡

为用例的步骤设计数据

6.1正交试验法

1.日本人，统计学家提出

2.使用的工具：正交表。

3.统计和分析实验数据，从大量实验中找到合适的实验数据组合。（原本用于工业生产的数据组合与实验室的数据挑选）

4.”大量的实验中，挑选出来一部分具有代表性的点，进行实验，分析数据”

5.数学原理：《线性代数》、《概率论》、《数理统计》

6.核心概念：

1）影响实验结果的——实验因素（因子）、因素。

2）每一个因素的不同取值（情况）——水平

例如，字的显示效果——字体、字号、颜色都称为因素。

字体选择时，可以选择宋体、楷体、微软雅黑、隶书——称为水平（212个水平）

字号选择时，……称为水平（100个）

颜色选择时，……称为水平（256个）

测试字的显示效果将会有：212*100*256

3）正交表：每列中，同一个数字（水平），出现的次数相等；任意两列组成的数字对（水平对）出现的次数也是相等的。

7.实施步骤：1）分析所有对结果有影响的因素。从多个角度和方式进行分析（不要放过文本框、按钮等需求中提及或者没有提及）

2）分析每个因素的水平数量，充分利用等价类、边界值（需求中说明和未说明的都要分析）

3）选择正交表。只有特定的因素数和水平数的组合才有对应的正交表。所以在现实中用到的时候，找最贴近的正交表（正交表的因素数和水平数一般要大于实际的因素数和水平数。）

            ①正交表的数学关系。n 代表实验次数，m 代表水平数，k 因素的数量。这三个数字之间没有任何数学关系.

            ②仅适合用于每一个因素的水平数都相同的正交表。

8、小案例

完全排列组合：3*3*3=27

使用小工具完成正交实验的设计：（L9_3_4：三水平，四因素，9次实验）

每一列中，同一个数字出现的次数相等（3次）

任意两列中，同一个数字对出现的次数相等（1次）

6.2功能图法（状态迁徙图法）

1. 又叫做状态迁徙图
2. 适用场合：软件的状态会根据某些内容、条件、操作的变化而变化。
3. 目标：尽可能覆盖软件的状态、状态-条件的组合、状态变迁路径。
4. 步骤：①识别和列举所有的输入（操作）事件。以IPN（input）(N=1 2 3)②定义空闲状态（初始状态）。一般以软件刚启动时打开的界面状态为空闲状态。③为空闲状态加操作（只加一次）。④为第3）步所产生的新状态加操作（只加一次，并且曾经加过的操作，不再重复添加）。⑤循环为所有的新增状态加操作，直到没有新的状态产生为止。⑥组合任意的状态，以列表的形式展现，设计和编写测试用例。

     5.小案例（以QQ登录界面为例，说明功能的变迁）

（1）识别出可以进行的操作

IP1 输入账号

IP2 输入密码

IP3 点击登录

IP4点击关闭按钮

（2）定义QQ登录界面为空闲状态。

（3）给空闲状态加操作。第一轮分析后

产生了新的状态，对新的状态进行分析（第二轮）

得到一个新的状态。所以继续进行分析

虽然得到了一个全新的界面（状态），但是和空闲状态发生了“隔断”，因此将其视为空闲状态的结束，可以结束分析过程。

       （4）将状态变化过程列表化，准备设计测试用例。

状态名/序号	A	B	C	D
空闲	1	1	1	1
QQ号已输入		2		2
密码已输入			2
QQ号密码已输入				3
QQ主界面				4
退出	2	3	3

设计用例的时候：

①A列：从QQ的登录界面，直接点击关闭按钮，QQ登录退出

②D列：从QQ的登录界面，先输入QQ号（状态变成QQ号已输入）；再输入密码（状态变为QQ号密码已输入），点击登录，状态就会变成QQ主界面

③B列：（略）

6.3其他用例设计方法

1. 测试大纲法①特点：着眼于需求。进行详细的需求分析，将其转化为思维导图（树形结构）②无需用例设计。一般从根节点开始分析，到叶节点为止，这样的一条路径就是一条测试用例。③一般用于快速的测试和过程记录。用例一般进行候补。
2. 探索性测试法

①基于经验和直觉

②是计划内测试用例设计的补充。

③探索性测试执行前也需要设计测试用例

    3.猴子测试（随意测试）

没有测试用例（无意识的行为）

不能达到指定的覆盖率

想要重复测试，及其困难

6.4用例设计方法综合选择

①首先进行等价类划分

②在任何情况下都必须使用边界值分析法

③如果程序的功能说明中含输入条件的组合情况，则一开始就可以用因果图法和判定表驱动法

④对于参数配置类的软件，要用正交试验法选择较少的组合方式达到最佳效果

⑤状态迁徙图法也是很好的测试用例设计方法，我们可以通过不同时期条件的有效性设计不同的测试数据

⑥对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程

⑦可以用错误推测法追加一些测试用例

⑧对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例

首先明确用例设计方法：

1. 等价类划分法
2. 边界值法分析法
3. 因果图法
4. 判定表法
5. 场景法
6. 正交试验法
7. 状态迁徙图法（功能图法）

记住方法的名称很简单，但是如何使用是一个大问题；如何使用。用例设计方法的使用不是孤立无援的，而是存在于项目中！尤其是一个项目中。

以教育APP为例说明各种用例设计方法的应用。

（1）在启动页中。有如下需求：

①读取版本更新信息，匹配当前APP与线上需要更新的APP版本是否一致

②读取用户信息。未登录用户，则不用获取，已登录用户，验证是否登录过期

用例设计方法：采用场景法进行设计。

设计场景：

①APP的安装版本比最新版要低。启动就需要进行版本检测并进行提示

②APP安装版本与最新版一样，默认检测过程成功

③APP启动检测用户登录状态，如果登录过期或者为登录，启动完成后直接跳转登录界面

④APP启动检测用户登录状态，如果登录信息有效，启动完成后直接跳转首页界面

（2）在登录界面。看需求：

①手机号：暂时只支持大陆手机

②验证码：长度为6为位数字

③短信验证码文本内容：【正数】456712（正教验证码），30分钟内有效，为确保您账号安全，请务把验证码告诉他人。感谢您关注正教！

④登录按钮点击后，系统可能弹窗提示。

用例设计方法：采用等价类划分法和边界值分析法、因果图法。

等价类划分法：

①手机号的有效性。（手机号包含各种不合法字符）；

②验证码包含各种不符合需求的字符。

边界值分析法：

①手机号超过/不足长度限制；

②验证码超过/不足长度限制；

③验证码有效期为30分钟，所以超过30分钟后使用验证码就是边界值的使用。

④弹出提示1s消失，超过/不足的测试都是边界值的应用。

因果图法：

①提交数据时，APP网络中断，有网络异常的提示；

②提交数据时，服务端奔溃或者无法提供正常服务，有服务器报错提示或者等待提示；

③提交数据时，手机号不符合要求（不存在），有手机号错误的提示；

④提交数据时，验证码输入不是收到的验证码、超时，有验证码错误提示。

（3）课程内容页。需求如图示：

用例设计方法：场景法，等价类划分法、边界值分析法。

场景法：

①该课程今日有作业、有提问的内容展示；老师发布作业的时候，学生提问。

②该课程今日有作业、无提问的内容展示；老师发布作业的时候，学生不提问。

③该课程今日无作业、有提问的内容展示；老师不发布作业的时候，学生提问。

④该课程今日无作业、无提问的内容展示；老师不发布作业的时候，学生不提问。

等价类划分法、边界值分析法：

①日期的显示。有没有出现2017年2月有29天的现象？

②日期的显示。会不会出现2017年2月1日和2017年1月31日重复或者不相邻的现象？

总结：所有测试用例的设计方法，没有独立使用的。都是融合在一起使用的。往往在一个软件的界面中，都可以使用好几种测试用例的设计方法。