目录​​​​​​​

软件测试分类

1、阶段划分

2、是否查看源代码分类

3、是否运行分类

4、是否自动化

4、其他分类的测试

软件质量模型

软件开发过程模型（研发）

瀑布模型（最常见）

快速原型模型（了解）

螺旋模型（了解）

测试过程模型

测试V模型（小公司）

测试W模型（大公司）

测试用例

测试用例定义

测试用例八大要素

测试用例设计

软件缺陷

软件缺陷的定义

缺陷的标准

软件缺陷产生的原因

缺陷信息

软件测试分类

1、阶段划分

单元测试

程序的最小模块完成后，进行的测试，可能是一个函数，也可能是一个类、也可能是一个界面

集成测试

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

系统测试

把整个系统看成一个整体进行测试，测试的依据是需求说明书，到了系统测试阶段，软件基本是完成的

验收测试

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

α测试

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

β版本

公测版本，对所有用户开放的测试版本；专业爱好者的测试，将结果反馈给开发者，开发者再进针对性的修改

γ版本

指的是软件版本正式发行的候选版，该版本已经相当成熟了

2、是否查看源代码分类

黑盒测试

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

白盒测试

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

灰盒测试

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

3、是否运行分类

静态测试

不运行软件，静态的观察软件是否符合预期；较多是界面测试、

动态测试

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

4、是否自动化

手工测试

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

自动化测试

通过编程写代码，通过程序自动测试软件是否有问题

4、其他分类的测试

冒烟测试

对软件最基本的流程和功能进行一个粗略的测试，看最基本的流程是否能跑通；测试拿到研发的第一个版本，一般先冒烟

回归测试

当修复一个bug后，把之前测试用例在新的代码下进行再次测试（有可能改旧bug出现新bug）不是每一个bug都回归，由项目经理跟进进度确定是否回归

随机测试

对被测软件重要功能进行复测

探索性测试（实际工作上很少）

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

软件质量模型

ISO 9126定义的软件质量模型的六个特性

  • 功能性：功能的正确性、安全性、依从性（功能和功能之间关系是否正确）
  • 非功能性：
    • 可靠性：成熟、容错（具备处理错误能力）、易恢复（出现错误后会恢复）
    • 可移植性：适应性、Windows/Linux/macOS系统、安卓/苹果；适应不同的系统/浏览器/字符集
    • 维护性：稳定性、易改变性、易测试性（不可维护即不可用）
    • 效率：时间、资源利用、效率（支付界面）
    • 易用性：易理解性、易学性、易操作性、吸引性（研发和测试易争议；很难量化）

软件开发过程模型（研发）

瀑布模型（最常见）

基本步骤：

  1. 需求分析（研发拿到需求分析说明书，判断需求的可实现性）——> 分析报告
  2. 概要设计（用到具体的技术点，大致模块划分）——> 概要设计文档
  3. 详细设计（详细到可以为编码作支持，类和类关系，类的设计，函数设计，各个接口的细节，数据库表的关系、字段关系）——> 详细设计文档
  4. 编码（开始开发）——> 代码
  5. 软件测试 ——> 测试文档
  6. 软件维护（上线后也是持续维护）

优缺点

特点：线性模型、文档驱动（每个阶段都有个文档产出）

优点：各个阶段比较清晰、当前一段完成之后只需要关注后续阶段

缺点：依赖于需求，不适应需求的变化，风险往往延至后期才出现

快速原型模型（了解）

在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作（边做边完善需求、边修改）

优缺点

特点：快速得构建软件的原型、支持用户参与

优点：克服瀑布模型的缺点，更好的满足用户的需求并减少由于软件需求不明确带来的项目开发的损失

缺点：不适合大型系统的开发（适合开发小型的、灵活度高的系统）

螺旋模型（了解）

每设计一步则进行风险分析，及其复杂，成本及其高

优缺点

特点：引进了风险分析活动

优点：风险驱动的方法体系

缺点：需要相当丰富的风险评估经验和专门知识

测试过程模型

测试和研发密不可分的

测试V模型（小公司）

研发：                                                                 测试

需求分析                                                 验收测试

概要设计                                 系统测试

详细设计             集成测试

编码       单元测试

（#研发步骤由上往下，测试步骤由下往上）

优缺点

优点：测试V模型即包含了底层测试又包含了高层测试，每个步骤都是文档驱动的

缺点：当需求变更时将会导致阶段反复，返工量非常大，模型灵活度比较低

测试W模型（大公司）

优缺点

优点：

1）测试伴随整个软件的开发周期，并且测试的对象不仅仅是程序，需求和设计同样需要测试

2）更早的介入测试，可以发现开发初期的缺陷，那么可以用更加低的成本进行缺陷修复

缺点：使用起来技术复杂度高，对于需求和设计的测试要求高，实践起来困难

测试用例

测试用例定义

Test Case

为了特定的目的而设计的一组测试输入、执行条件和预期结果的文档

测试用例八大要素

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

测试用例设计

1、等价类划分

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

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

等价类划分后，有多少数据（类），就有多少测试用例（数据是什么，测试用例是什么）

等价类划分步骤：

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

2、边界值分析法

边界范围

确定边界情况（输入或输出等价类的边界）

选取正好等于、刚刚好大于或刚刚好小于边界的值作为测试用例

上点：边界上的点（正好等于）不管是开区间还是闭区间

离点：距离上点最近的点

内点：范围内的点

#4n+1；6n+1（n为变量值）

闭区间/开区间

#如果是开区间，那么离点就在域内，如果是闭区间，那么离点就在域外

#4n+1：

区间 上点 内点 离点

[20,30]闭区间 20和30 15 19和31（这里的离点无效数据）

[20,30)左闭右开 20和30 20 19和29

(20.30]左开右闭 20和30 20 21和31

(20,30)开区间 20和30 23 21和29（这里的离点是有效数据）

#对于闭区间，上点是有效数据，离点是无效数据

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

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

边界值分析步骤

  1. 明确需求
  2. 确定有效和无效等价类
  3. 确定边界值
  4. 编写测试用例（#4n+1：上点、离点、内点）

边界值例子

6到10位自然数：

1、需求：[6,10]，自然数

2、有效等价类：自然数、[6,10]

无效等价类：小于6、大于10、6-10位非自然数（含特殊字符、中文、字母）

3、边界值：5、6、8、10、11

4、编写测试用例：（按照边界值分类去书写，无效等价类辅助）

12345 无效数据

123456 有效数据

#因为这个例子上点6在范围内，在内点的时候就会对无效等价类的各种情况进行测试用例，所以不需要展开对上点6的测试用例编写（累赘）

  • 12345678        无效数据
  • 123456ab        无效数据
  • 呜呜呜12345   无效数据
  • 123456**         无效数据

1234567890有效数据

12345678901无效数据

3、判定表

#等价类划分和边界值分析法着重考虑的是单个输入条件，但是不考虑输入条件的各种组合、输入条件与输出条件之间的相互制约关系，因此采用判定表法（各种情况）

#判定表法表示的是多个输入，和多个输出，而且输入和输入之间有相互的组合关系、输入和输出之间有相互的依赖关系

判定表的四个组成部分

条件桩：列出了系统的所有输入，列出的输入次序无关紧要

动作桩：列出了系统可能采取的操作，这些操作的排列顺序没有约束

条件项：在不同的条件桩下，可能采取的真假值

动作项：列出在输入项的各种取值情况下应该采取的动作

判定表的设计步骤

  1. 明确需求
  2. 画出判定表：
  • 明确条件桩、动作桩
  • 填写条件项，对条件进行全组合
  • 明确每个条件组合对应的动作项
  1. 生成测试用例，判定表每条规定对应一条测试用例

判定表例子

1、若用户欠费或者关机，则不允许主被叫

2、订购单的检查

如果金额大于500，又未过期，则发出批准单和提货单

如果金额大于500，且过期了，则不发出批准单和提货单

如果金额小于500，则无论是否过期都发出批准单和提货单

在过期的情况下，无论金额大小还需要发出通知单

3、文件修改

如果想对文件进行修改，输入的第一列字符必须是A/B，第二列字符必须是一个数字，如果第一列字符不正确，则给出信息L，如果第二列字符不正确，则给出信息Ｍ

#不能用判定表去执行测试，判定表是中间过程，通过判定表写出测试用例，用测试用例去执行测试操作，因为写测试用例和执行测试用例的不一定是同一个人

#测试用例有两个很重要的原则：

  • 能看懂
  • 能执行

严格按照测试用例流程去执行，出现bug不能修改源代码（不能越俎代庖），只能提交bug给研发去修改

4、因果图

因：输入条件 C

果：输出结果 E

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

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

因果图步骤

  1. 明确需求
  2. 画出因果图
  3. 将因果图转换成判定表
  4. 根据判定表写测试用例

例子

文件修改

如果想对文件进行修改，输入的第一列字符必须是A/B，第二列字符必须是一个数字，如果第一列字符不正确，则给出信息L，如果第二列字符不正确，则给出信息Ｍ

5、正交表

使用范围：当可能的输入数据或者输出数据的组合量很大时，由于不可能为每个输入组合都创建测试用例时，可以采用这种方式

特点：均匀分布，齐整可比

概念

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

  • n表示行数
  • m是列的取值个数
  • k是表的列数
  • 如$L_9(3^4)$：9行4列，每列有3种取值个数

步骤

1、明确需求

2、画出正交表

  1. 确定需求中的因素数（所有的输入）与对应的水平数（输入的取值）
  2. 用需求中的文字代替正交表中的数字（123）
  3. 根据因素数与水平数选取正交表

3、写出测试用例

正交表有几行，就要写几个测试用例

案例

1、4因素3水平

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

什么是因素（Factor）：在一项试验中，凡欲考察的变量称为因素（变量）

什么是水平（位级）（Level）：在试验范围内，因素被考察的值称为水平（变量的取值）

#在这道题目中：4因素3水平

用正交表设计测试用例

2、不其次：以水平最高的为标准

3、不其次：以水平最高的为标准

4、

假设有一个用户筛选功能，有3个输入分别是体型、年龄段、性别

6、场景法

场景法是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试

场景法的意义

用户角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用

测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试

设计测试用例步骤

  1. 明确需求
  2. 画出流程图
  3. 编写测试用例（流程图有多少个结果，就有多少条路径，就有多少个测试用例）

ATM机取钱

7、错误推测法（了解即可）

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

基本思想

基本思想是列举出可能犯的错误或错误易发生的清单，然后根据清单编写测试用例

（较多的是凭借经验进行的）

使用场景

  • 项目紧、任务急、时间不够，不按照按部就班的测试，根据之前项目的经验，找到和之前出错的类似模块进行重点测试
  • 所有正常测试结束后，通过错误推断法再测试一些出过问题的模块

8、状态迁移法

图与树

图：使用线把点连接起来

树：没有闭环的图

状态迁移法

首先要找出被测对象的所有状态，然后再分析各个状态之间转换，据此编写测试用例

#状态迁移法不保证单个功能点的正确性，仅保证状态间的转换是否与需求描述的一致

适用场景

在业务流程中涉及到了复杂的业务场景（即业

务状态的迁移）而这些业务场景在需求说明书中往往不能够完全阐述清楚，容易出现纰漏（把全部的功能点全部串起来）

状态转移法的使用步骤

  1. 明确状态节点：分析被测对象的需求规格说明书，明确被测对象的状态节点数量
  2. 绘制状态迁移图：利用圆型表示状态节点，有向箭头表示状态间的迁移关系
  3. 绘制状态迁移树：根据状态迁移图的节点和箭头绘制状态迁移树（首先确定起始节点以及终止节点）
  4. 抽取测试路径设计测试用例：找到所有的叶子节点、一条路径就是根节点到叶子节点所走的路线、一条路径就是对应一条测试用例

案例分析-飞机售票系统

  1. 客户向航空公司打电话预定机票时，此时机票信息处于“预定”状态
  2. 顾客支付了机票费用后，机票信息变成“已支付”状态
  3. 旅行当天到达机场，拿到机票后，机票信息变成“已出票”状态
  4. 登机检票后，机票信息变成“已使用”状态
  5. 在检票之前任何时间都可以取消自己的订票信息，取消后，订票信息处于“已取消”状态
  • 绘制状态迁移图

  • 绘制状态转移树

  • 抽取测试路径
  1. 预定-->已支付-->已出票-->已使用
  2. 预定-->已支付-->已出票-->已取消
  3. 预定-->已取消
  4. 预定-->已支付-->已取消
  • 根据测试路径写测试用例

案例分析-订单状态

  1. 用户在网站完成下单后，订单状态为“等待付款”
  2. 用户完成付款后，订单状态变成“待发货”
  3. 管理员对订单进行确认并发货后，订单状态变成“待收货”
  4. 用户使用商品后，在系统中进行确认收货，订单状态变成“待评价”
  5. 用户使用商品后，对商品进行评价，评价提交后，订单状态变成“已完成”
  6. 商品发货前，用户可以对订单进行取消操作，取消后订单状态变成“已取消”
  7. 用户付款前，管理员可以认定订单无效，此时订单处于“已作废”状态
  • 绘制状态迁移图

  • 绘制状态转移树

  • 抽取测试路径

等待付款-->待发货-->待收货-->待评价-->已完成

等待付款-->待发货-->已取消

等待付款-->已取消

等待付款-->已作废

  • 根据测试路径写测试用例

软件缺陷

软件缺陷的定义

软件或程序中存在的各种问题和错误

软件缺陷的存在会导致软件产品在某种程度上不能满足用户的需求

缺陷的标准

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

软件缺陷产生的原因

软件缺陷的产生是不可避免的，造成软件缺陷产生的原因主要归纳如下：

  1. 需求解释、记录或者定义错误
  2. 设计文档说明存在错误或者拼写错误
  3. 编码说明、程序代码有误
  4. 硬件或者软件系统上存在错误

缺陷产生的根源：

  1. 需求的变更
  2. 交流不充分
  3. 软件的复杂性
  4. 进度压力

缺陷信息

包括以下16条信息：

缺陷的基本内容

缺陷标题、缺陷的预置条件、缺陷的重现步骤、缺陷的实际结果、缺陷的期望结果

缺陷的状态

  • new：新建状态
  • open：打开状态
  • reopen-关闭的缺陷重新打开
  • fixed：修复状态
  • closed：关闭状态
  • rejected：拒绝状态
  • postpone：拖延状态

缺陷的严重程度

缺陷的优先级

缺陷类型

  • 功能错误
  • 界面错误
  • 兼容性缺陷

缺陷报告模板

#每个公司都有一个模板，对于“缺陷严重程度”和“缺陷优先级”都有一定的规定，基本上包含以下内容：

报告模板

缺陷报告注意事项：

  • 尽量确保缺陷可以重现
  • 简洁、准确、完整
  • 一个缺陷一个报告

常见错误

  • 避免使用你、我等人称代词，可以直接使用动词或必要时使用“用户”代替
  • 避免使用情绪化的语言和强调符号
  • 避免使用诸如“似乎”“看起来可能”等含义模糊的词汇，而需要报告确定的缺陷结果
  • 避免提交不确定的测试问题，自己至少需要重现一次再提交；出现bug过程一定要详细

缺陷处理流程

“重新打开”这一步开始

  1. new新建状态：要提交一个缺陷，首先就是新建状态
  2. open打开状态：确认缺陷有效后，为打开状态
  3. fixed修复状态：由缺陷的处理人，把缺陷处理完成之后设置为修复状态
  4. closed关闭状态：验证缺陷确实修复成功后，一般由缺陷的发起人设置状态为关闭状态
  5. reopen重新打开状态：一个已经关闭的缺陷再次出现时，就要设置为出现打开状态

#实际情况可能有变化

缺陷跟踪

  • 新提交的缺陷为新建状态，确认有效后为打开状态，经过开发人员修改后，缺陷变为已修复（fixed）时就需要测试人员对缺陷进行回归测试，验证问题是否修复；
  • 如果问题已经修复，则测试人员将该缺陷的状态置为关闭状态（验证通过），同时添加回测说明“已解决”；
  • 如果已经关闭的问题再次出现，则测试人员将该缺陷的状态修改成重新打开；

缺陷统计

以下为例子：

1、按严重程度分布

2、按缺陷提交人分布

3、按缺陷类型分

#缺陷数据分析关注的问题

  • 正在测试的哪个模块的问题最多
  • 测试人员中谁报告的软件缺陷最多
  • 各类缺陷所占的数量百分比分别是多少
  • 开发人员能及时修复软件缺陷吗
  • 开发人员一次性正确修复缺陷的百分比是多少
  • 正在开发的软件能否在计划的时间内正常发布

测试报告

  • ✅找个word模板

使用centOS中禅道