软件测试理论

一、软件测试分类

 1.按测试阶段划分

• 单元测试（模块测试）

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

单元定义：C中指一个函数，Java中指一个类，图形化的软件中指一个窗口/一个菜单。

• 集成测试（组装测试）

在单元测试的基础上，将所有程序模块进行有序的、递增的测试。重点测试不同模块的接口部分。

• 系统测试

将整个软件系统看作一个整体进行测试，测试依据是软件需求说明书。

• 验收测试

检验软件是否符合用户需求的测试。

（1）α测试

内测版本；软件开发者内部交流；bug较多，普通用户最好不要安装。

（2）β测试

公测版本，对所有用户开放。

（3）γ测试

接近与正式发布的版本。

2.按是否查看源代码

• 黑盒测试

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

• 白盒测试

盒子打开，研究里面的源代码和程序结构。

• 灰盒测试

介于黑盒测试与白盒测试之间的一种测试，多用于集成测试阶段，不仅关注输入输出的正确性，同时也关注程序内部的情况。

3.按是否运行

• 静态测试

不运行软件，静态观察软件是否符合预期。

• 动态测试

运行软件，在运行过程中测试。

4.按是否自动化

• 人工测试

测试人员手动进行测试。

• 自动化测试

利用代码或者工具帮助人工进行测试。

5.其他分类

• 冒烟测试

对系统进行最基本的功能测试，保证基本的功能和流程能走通。

• 回归测试

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

• 随机测试

对被测软件的一些重要功能进行复测，也包括测试当前的测试用例没有覆盖到的部分。

• 探索性测试

同时设计测试和执行测试。测试人员通过测试来不断学习被测系统。

二、软件质量模型

 功能性、可靠性、易用性、效率、维护性、可移植性。

三、软件开发模型

1.瀑布模型

• 需求分析：需求说明书；需求的可实现性。
• 概要设计：用到的技术点；大致模块划分。
• 详细设计：详细到可以为编码作支持；类和函数的设计；各个接口的细节；数据库表、字段的关系。
• 编码：依据详细设计进行编码操作。
• 软件测试
• 软件维护：上线后也是需要持续维护。

特点：线性模型（每一步都是按顺序来执行）；文档驱动（每一步都有文档产出）。

优点：每个阶段很清晰；当前阶段完成后，只需关注后续阶段。

缺点：依赖于需求，不适应需求的变化；风险到项目后期才体现，失去早期纠正的机会。

2.快速原型模型（了解）

一边确定需求，一边实现。

优点：克服瀑布模型的缺点，更好地满足用户需求并减少需求不明确带来的风险。

缺点：适合小型系统开发。

3.螺旋模型（了解）

优点：引入风险分析。

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

四、测试过程模型

1.v模型

是软件开发中瀑布模型的变种。

优点：包含了底层和高层的测试过程；每个步骤都是文档驱动的。

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

2.w模型

优点：测试伴随着整个开发周期，不仅要测代码，还要测文档；更早的介入测试，可以尽早发现并解决问题。

缺点：使用起来技术复杂度高。

五、测试用例

测试用例（Test Case）是为特定目的而设计的一组测试输入、执行条件和预期结果的文档。

测试用例八大要素：

1. 用例编号
2. 用例标题
3. 测试项目
4. 用例级别
5. 预置条件
6. 测试输入
7. 执行步骤
8. 预期结果

两个重要原则：1.能看懂；2.能执行。

如：

六、测试用例设计方法

1.等价类划分法

等价类：在所有测试的数据中，具有某种共同特征的数据子集。

等价类分为：

有效等价类：满足需求的。

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

案例：计算两个-99到99之间整数的和

 等价类操作步骤：

1. 明确需求
2. 确定有效等价类和无效等价类
3. 编写测试用例

案例1：QQ账号：6-10位自然数

案例2：某城市电话号码有三部分组成。分别是：

地区码：空白或三位数字。

前缀：非‘0’且非‘1’开头的三位数字。

后缀：四位数字。

正向用例：一条测试用例尽可能覆盖多种情况。

逆向用例：每一条无效数据，对应一条单独的测试用例。

2.边界值分析法

上点：边界上的点。

离点：离上点最近的点。

内点：范围内的点。

开区间[]、闭区间()

例如：对于闭区间，上点是有效数据，离点是无效数据。

对于开区间，上点是无效数据，离点是有效数据。

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

案例1：使用边界值的方法设计添加标题的测试用例（要求：标题长度>0且标题长度<=30）

注意：此案例并未涉及划分等价类。

使用边界值分析法设计测试用例的操作步骤：

1. 明确需求。
2. 确定有效和无效等价类。
3. 确定边界值。
4. 编写测试用例。

案例2：QQ账号：6---10位自然数

本案例需要同时考虑边界值和等价类，以选取的5个点为讨论依据。

本案例只有内点考虑了无效等价类，作为无效数据。

3.判定表法

有多个输入和多个输出，而且输入与输入之间有相互的组合关系，输入和输出之间有相互的依赖关系。

判定表通常由四个部分组成：

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

动作桩：列出所有输出，顺序无关。

条件项：列出条件桩中所有能出现的组合。

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

注：判定表中贯穿条件项和动作项的一行就是一条规则。

使用判定表步骤

1. 先明确需求
2. 画判定表
   1. 列出条件桩和动作桩。
   2. 列出条件项的不同组合。
   3. 根据条件项列出动作项。
3. 编写测试用例
   1. 判定表中的一条规则对应一条测试用例。

注意：

• 不能直接用判定表去执行测试。
• 通过判定表编写测试用例，用测试用例去执行测试操作。

案例1：

案例2：

4.因果图法

“因”——输入条件，“果”——输出结果

什么是因果图法：

用图解方法表示输入的各种组合关系，写出判定表，从而设计相应的测试用例。

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

因果图法中的基本符号：

 c表示原因，e表示结果。

因果图法的基本步骤：

1. 明确需求。
2. 画出因果图。
3. 将因果图转化为判定表。
4. 生成测试用例。

案例

5.正交表法

使用最小的测试过程集合获得最大的测试覆盖率。

适用范围：

当可能的输入数据或者输入数据的组合数量很大时，由于不可能为每个输入组合创建测试用例，可以采用这种方法。

特点：

均匀分散，齐整可比。

正交表的概念：

• 一种特制的表，一般的正交表标记为：$L_n(m^k)$
• n表示行数
• k表示表的列数
• m是列的取值个数

如：$L_9(3^4)$

行数：9，列数：4，列的取值个数：3，叫4因素3水平

使用正交排列法步骤

1. 明确需求
2. 画出正交表
   1. 确定列数（因素数）
   2. 确定正交表每列的取值个数（水平数）
   3. 根据因素数和水平数可以确定行数
3. 写出测试用例，正交表的一行代表一条测试用例。

案例1：字符属性设置

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

• 字体：仿宋、楷体、华文彩云。
• 字符样式：粗体、斜体、下划线。
• 颜色：红色、绿色、蓝色。
• 字号：20号、30号、40号。

• 列数/因素数：4（编号除外）
• 水平数：3（每个列的取值个数）
• 行数：9

 变式：

水平数取值：字体2，样式4，颜色3，字号4 

最大值为4，故应选样式或者字号作为基准。

本题选择样式作为基准：

案例2：用户筛选

假设有一个用户筛选功能，有三个输入分别是体型、年龄段、性别，体型有三个取值（胖、适中、瘦），年龄段有三个取值（老人、青年、儿童），性别有两个取值（男、女），请设计测试用例

判定表法与正交排列法案例：

判定表法：

条件桩：男，高，富

动作桩：高富帅，奋斗青年，屌丝青年，白富美，奋斗美女，屌丝美女

正交表法：

人物：刘备，关羽，张飞，赵云

地点：北京，上海，广州，深圳

动作：吃饭，睡觉，喝酒

正交表：3因素4水平

6.场景法

用流程图描述用户的使用场景，用覆盖流程路径来设计测试用例。

从流程图开始到结束，有几条路就是几个路径；一个路径对应一条测试用例。

使用意义

• 用户角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用。
• 测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试。

使用步骤

• 明确需求
• 画出流程图
• 根据流程图编写测试用例

案例1：乘坐地铁

7.错误推测法

• 凭测试工程师的直觉和经验来推测项目中可能出现bug地方,进行测试。
• 时间紧张,突发事件。

七、软件缺陷

缺陷定义：软件或程序中存在的各种问题。

缺陷判定标准

• 软件未达到需求规格说明书标明的功能。
• 软件出现了需求规格说明书指明不会出现错误的地方。
• 软件的功能超出了需求规格说明书指明的范围。
• 软件出现了需求规格说明书虽未指明，而应该达到的目标。
• 软件测试人员认为软件难以理解，不易使用，运行速度慢，或者最终用户体验不好。

缺陷产生的根源

• 需求变更
• 交流不充分
• 软件的复杂性
• 进度压力

缺陷信息

• 缺陷编号
• 缺陷状态
  • new新建
  • open打开（reopen关闭的缺陷，再次打开）
  • fixed修复
  • closed关闭
  • rejected拒绝
  • postpone拖延
• 缺陷标题
• 严重程度
  • 5-critical最高优先级
  • 4-veryhigh非常高优先级
  • 3-high高
  • 2-medium中
  • 1-low低
• 优先级
  • 5-urgent最高
  • 4-veryhigh非常高
  • 3-high高
  • 2-medium中
  • 1-low低
• 所属模块
• 缺陷的详细描述

缺陷报告注意事项

• 缺陷报告不能有缺陷。
• 简洁、准确、完整。
• 一个缺陷一个报告。
• 避免提交不确定的测试问题，缺陷一定是可重现的。
• 避免出现模糊的词汇。
• 不能有个人感情色彩。
• 复现bug过程一定要详细。

案例：两个整数相加

 

-9999和9999是上点，是无效的，只需结合有效等价类（整数）；

-9998和9998是离点，是有效的，只需结合有效等价类（整数）；

100是内点，既需要结合有效等价类（整数），又要结合无效等价类（小数/字母/中文/符号/空）。

测试用例：

 缺陷报告：

缺陷跟踪流程

new新建状态：新提交的缺陷为新建状态。

open打开状态：确认缺陷有效后为打开状态。

fixed修复状态：经开发人员修改后，缺陷变为已修复（待验证）状态。

closed关闭状态：测试人员对缺陷进行回归测试，验证问题是否修复。如果问题已经修复，则测试人员将该缺陷的状态设置为关闭状态（验证通过）。

reopen重新打开状态：如果已经关闭的问题再次出现，则测试人员将该缺陷的状态修改为重新打开。

缺陷分析需要注意的点

• 哪个模块问题最多
• 哪个测试工程师测试的缺陷最多
• 各类缺陷数量占比
• 开发是否可以及时修复缺陷
• 开发人员一次修复缺陷占比
• 软件是否可以正常发布