测试阶段分类

单元测试

程序最小模块完成后进行的测试

（可能是一个函数，也可能是一个类，也可能是一个界面）

集成测试

组装测试，在单元测试的基础上把多个模块组装到一起进行测试，重点关注模块和模块之间的接口

重点测试不同模块的接口部分

系统测试

把软件项目作为一个整体进行测试（软件测试、硬件测试），测试依据是需求说明书

（到了系统测试阶段，软件基本是完成的）

验收测试

站到最后用户的角度来测试

α （alpha）(内测版本)

β （betta） (公测版本)

γ （gamma） (接近于正式发布的版本)

是否查看源代码分类

黑盒：输入和输出

只测试功能，不关注功能的具体实现方式

白盒：代码内部实现逻辑

不但要关注功能，还要关注代码是如何实现的

灰盒：测试关注点（输入；输出；代码逻辑）

介于黑盒和白盒之间的一种测试

按是否运行分类

静态测试

不运行软件，静态观察软件是否符合预期；测试对象：文档；代码

动态测试

运行软件，在运行过程中测试；测试对象：运行中的程序

是否自动化

手工测试（功能测试）

通过测试工程师手工对软件进行测试

自动化测试

通过编程写代码,通过程序自动测试软件是否有bug

其他分类

冒烟测试

对软件最基本的流程和功能做一个粗略的测试，看最基本的流程是否能跑通

测试拿到研发的第一个版本，一般是先冒烟

回归测试

当修复一个bug后，把之前测试用例在新的代码下进行再次测试

随机测试

针对软件中的重要功能进行复试

探索性测试

一边了解和学习项目，一边测试项目

软件质量模型

功能性：检查业务功能是否满足需求

          功能的正确性

          功能的安全性

          功能的依从性

可靠性

        软件要有容错性

        出现错误后可以很快恢复

易用性：看得懂、会使用等

      软件界面是否流畅

      提示是否友好

     用户使用功能是否得到

效率：性能（响应时间、消耗资源（CPU内存）等）

       软件一定是要高效的

维护性：为后续功能的开发和维护提供便利

可移植性：软件需要在不同的软件环境和硬件环境下都能正常的工作

适应不同的系统         

软件开发模型        

瀑布模型

        需求分析：研发分析需求说明书；判断需求的可实现性

        概要设计：用到具体的技术点；大致模块划分

        详细设计：详细到可以为编码做支持；类和类关系，类的设计；函数设计；各个接口的细节；数据库的关系，字段关系 

        编码：依托于详细设计进行编码操作

        软件测试

        运行维护：上线后也是需要持续维护

瀑布模型特点

线性模型

每一步都是按顺序来执行

文档驱动

每一步都有文档产出

瀑布模型优缺点

优点 ：  

每个阶段很清晰

只需要关注后续阶段

缺点：

依赖于需求，不能适应需求的变化

风险到项目后期才体现，失去早期纠正的机会

典型应用场景：

需求清晰的大型项目，如银行、保险、建筑等。 

快速原型模型

一边确定需求一边实现

优点：避免瀑布模型的缺点可以适应早期的需求变化

缺点：适合小型项目

螺旋模型（了解）

优点：引入风险分析

缺点：风险分析需要专业的知识和人员

测试过程V模型

绘制：需求分析—概要设计—详细设计—编码—单元测试—集成测试—系统测试—验收测试

从研发的瀑布模型来的

优点：包含了底层和高层的测试过程；每个步骤都是文档驱动的，只需要关注当前阶段、文档驱动线性模型

缺点：和研发瀑布模型一样，不能适应需求的改变，灵活性比较低

测试W模型

绘制：

开发V：需求分析—概要设计—详细设计—编码—集成—实施—交付

测试V：验收测试设计—系统测试设计—集成测试设计—单元测试设计—单元测试—集成测试—系统测试—验收测试

优点：测试工作伴随整个研发周期，测试对象不只是代码，文档也需要测试；

            更早地介入研发工作。可以尽早发现问题及早处理。 

缺点：（技术和管理）对测试工程师要求比较高，实践起来难度比较大                       

测试用例

Test Case(测试用例)

作用：为特定的目的（检验开发的代码实现是否满足用户的需求）而设计的文档（测试输入、执行条件、预期结果），文档的形式可以是xmind、excel等

测试用例

基本要素包括：

用例编号、用例标题、测试项目、用例级别、预置条件、测试输入、执行步骤、预期结果 

（ID、模块、优先级、标题、前置条件、测试数据、执行步骤、预期结果）

测试用例设计

等价类划分法

概念：

通过科学的方法找到具有共同特性的测试输入的子集，能够从穷举测试中解放（大大减少测试用例的数量，从而提升测试效率）

分类：

有效等价类：满足需求的数据

无效等价类：不满足需求的数据

等价类划分方法操作步骤：

1、明确需求；2、确定有效和无效（规则（需求本身）、长度、类型、是否为空（必填项）、是否重复）等价类；3、编写测试用例

典型应用场景：

输入框

边界值划分法

作用：对等价类的补充，统计表明程序最容易出错的地方就是在边界附近

概念：基于边界值【有效等价类和无效等价类的分界点】设计测试用例的一种【黑盒】方法

边界值：

上点：处于外界上的点

离点：边界之内 离上点最近的点

内点：离边界最近的左右两点

（边界值 把两边的数都测一下）

开区间，闭区间

[开始值，结束值]——闭区间，包含开始值，包含结束值

（开始值，结束值）——开区间，不包含开始值，不包含结束值

对于闭区间，上点是有效数据，离点是无效数据；对于开区间，反之

不管开和闭区间，内点都是有效数据

使用边界值法步骤

1、明确需求

2、划分有效和无效等价类

3、划分边界值（上点、内点、离点）

4、编写测试用例

典型应用场景：

存在边界 > > = < < = 大于 小于 等于

判定表法：（测试用例没有缺失）

概念：有多个输入，有多个输出，输入和输出有组合和依赖的关系

判定表法

条件桩：列出所有输入条件，顺序无关

表示方式（字符：真/有效等价类/Y；假/无效等价类/N   ~   数字：真/有效等价类/1；假/无效等价类/0）

动作桩：列出所有的输出结果，顺序无关

条件项：把条件桩中所有能出现的组合都罗列出来（有效等价类和无效等价类）

动作项：根据不同条件项的组合产生的工作结果

判定表法步骤：

1、明确条件桩（找到所有的输入条件）

2、明确动作桩（找到所有的输出结果）

3、对条件桩进行全组合

4、明确每个组合对应的动作桩（基于每一种条件的组合情况，确定本组合的输出结果）

5、设计测试用例，每行数据对应一条测试用例

使用场景：

多条件组合条件

因果图

概念：用图解的方式表示输入的各组合关系，写出判定表，进而设计测试用例的一种【黑盒测试】方法

适用范围：适用于分析程序输入条件的各种组合情况，以及输入和输出之间的依赖关系

核心：

因：条件

果：结果

基本符号（掌握）：

恒等（-）：条件成立，结果成立

非（~） NOT：条件成立，结果不成立；条件不成立，结果成立

或（V） OR：只要有一个条件成立，结果就成立；所有条件都不成立时，结果才不成立

与/且  AND（^）：多个条件必须同时成立，结果成立；只要有一个不成立，结果就不成立

设计测试用例的步骤：

1、需求分析 

2、画出因果图

3、将因果图转换为判定表法

4、生成测试用例

正交表：（扩展（测试用例一定有缺失）

核心思想：用最小的测试用例获得最大的测试覆盖率

一种特制的表，一般正交表标记为Ln(m^k)

k代表因素（输入参数）

m叫水平（输入参数的取值）

n代表测试用例数

【n表行数 k表列数 m代表列的取值个数】

$L_9(3^4)$

9行4列 每列有3种取值个数

4因素 ，3水平

基于正交表设计测试用例

步骤：

1、需求分析

2、确定因素和水平（因素：控件名称；水平：每个控件对应的取值）

3、确定要使用的正交表

4、将正交表中的字母用文字代替

5、设计测试用例（一行就是一条测试用例）

【明确需求

绘制正交表：先确定列数；确定正交表每列的取值个数；根据因素和水平可以确定行数

根据正交表编写测试用例：正交表的一行代表一条测试用例（几行需要几行）】

基于allpairs设计测试用例

步骤：

1、需求分析

2、确定因素和水平（因素：控件名称；水平：每个控件对应的取值）

3、将确定的因素与水平复制到txt文件中

4、打开DOS窗口，进入allpairs 目录，运行命令：allpairs.exe text.txt > result.txt

5、根据生成的新文件编写测试用例（一行就是一条测试用例）

场景法（流程图发）

概念：场景法就是模拟用户操作软件时的场景，主要用于测试多个功能之间的组合使用情况

使用测试阶段

集成测试；系统测试；验收测试；

流程图常用符号： 

开始或结束：椭圆

方向或路径：箭头

处理或操作：长方形

判断：菱形

输入或输出：平行四边形

用流程图来描述用户的使用场景                        

用覆盖流程路径来设计测试用例

从流程图开始到结束，有几条路就是有几条路径

一个路径对应一个测试用例

使用步骤

明确需求

画出流程图

根据流程图编写测试用例：流程中有多少路径就对应多少条测试用例

错误推测法（了解）

凭测试工程师的直觉和经验来推测项目中可能出现bug的地方进行测试

使用场景：重要功能；使用同类型产品；任务急、时间紧、资源少

（时间紧张，突发事件）

测试用例设计方法总结

具有输入功能，但输入之间没有组合关系 =【等价类】

输入有边界 如长度、类型 =【边界值】

多输入、多输输入与输出之间存在组合关系、输入与输出之间存在依赖或制约关系 = 【判定表、因果图】

用最少的测试用例获得最大测试覆盖率时 = 【正交法】

多个功能的组合测试 = 【场景法、流程图】

最后推荐使用【错误推测法】来进一步补充测试用例