软件测试基础

测试分类

按测试阶段分类：

单元测试：针对源代码进行测试

集成（接口）测试：针对模块之间访问地址进行测试

系统测试：对整个系统进行测试（包括功能、兼容、文档等）

验收测试：主要分为内侧、公测，使用不同人群发觉项目缺陷

按代码可见度分类：

黑盒测试：源代码不可见，UI可见（系统）

灰盒测试：部分源代码可见，UI不可见（集成）

白盒测试：源代码全部可见，UI不可见（单元）

质量模型（衡量一个软件优秀的维度）：

功能性：功能数量、功能正确实现、错误处理

性能：服务器每秒处理请求数、服务器硬件配置是否满足

兼容性：浏览器、操作系统、手机

易用性：简介、友好、流畅、美观

可靠性：无响应、卡顿、死机

安全：传输加密、存储加密

可移植性：数据迁移

可维护性

测试流程：

需求评审：确保各部门需求理解一致

计划编写：测什么、谁来测、怎么测

用例设计：验证项目是否符合需求的操作文档

用例执行：项目模块开发完成开始执行用例文档进行测试

缺陷管理：对缺陷进行管理的过程（修复好）

测试报告：实施测试结果文档

---

测试用例：

为测试项目而设计的执行文档

测试用例作用：防止漏测、实施测试的标准

用例设计编写格式：

用例编号：项目_模块_编号

用例标题：预期结果（测试点）

项目/模块：所属项目或模块

优先级：表示用例的重要程度或影响力P0~P4（P0最高）

前置条件：执行此条用例，需要哪些前值操作

测试步骤：描述操作步骤

测试数据：操作的数据（没有可以为空）

预期结果：预期达到的结果

等价类划分（穷举场景设计测试点（用例））

在所有测试数据中，具有某种共同特征的数据集合进行划分

场景：针对有大量数据测试输入，但是没法穷举测试

输入框

下拉列表

单选复选框

分类：

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

无效等价来：不满足需求的数据集合

步骤：

明确需求（长度、类型、规则）、确定有效和无效等价类、提取数据编写测试用例

边界值（限定边界规则）

边界范围节点：选取正好等于、刚好大于、刚好小于边界的值作为测试数据（最多7条 优化5条）

上点：边界上的点（正好等于）（必选）

离点：距离上点最近的点（刚好大于、刚好小于 一个上点有两个离点（开内闭外））

内点：范围内的点（区间范围内的数据）（必选）

步骤：

明确需求、确定有效和无效等价类（类型）、确定边界范围值、提取数据编写测试用例

判定表（多条件依赖关系）

以表格形式表达多条件逻辑关系

组成：

条件桩：列出问题中的所有条件，列出条件的次序无关紧要

动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束

条件项：列出条件对应的取值，所有可能情况下的真假值

动作项：列出条件项的各种取值情况下对应的动作结果

规则：判定表中贯穿条件项和动作项的一列就是一条规则，假设有n个条件，全组合有2的n次方规则

步骤：

明确需求、画出判定表、根据规则编写测试用例

使用场景：

有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖

判定表一般适用于条件组合数量较少的情况（比如4个条件以下）

场景法（流程图法）（项目业务流程）

流程图：使用标准图形和箭头来表达程序或业务的走向

能够看懂流程图，设计业务用例

当需求文档信息不全，能够根据需求，梳理出流程

冒烟测试用例：整个基础的业务流程（需要能够跑通）

错误推荐法

通过经验推测系统可能出现的问题

思想：

根据经验列举出可能出现问题的清单，根据清单分析问题可能原因，推测发现缺陷

场景：

时间紧任务量大时，根据之前项目类似经验找出易出错的模块重点测试

时间宽裕，通过该发放列出之前出现问题较多的模块，再次测试

---

缺陷（用例执行不通过）

定义：软件在使用过程中存在的任何问题都叫软件的缺陷，简称bug

判定标准：

少功能：软件未实现需求中明确要求的功能

功能错误：软件出现了需求中指明不应该出现的错误

多功能：软件超出了需求中明确要求的功能

隐形功能错误：软件未实现需求中未明确指明但应该实现的要求

不易使用：软件难以理解，不易使用，运行缓慢，用户体验不好

产生原因：

需求阶段：需求描述不易理解，有歧义、错误等

设计阶段：设计文档存在错误或缺陷

编码阶段：代码出现错误

运行阶段：软硬件系统本身故障导致

核心内容：

标题：描述缺陷的核心问题

预置条件：缺陷产生的前提

复现步骤：复现缺陷的过程

预期结果：希望得到的结果

实际结果：实际得到的结果

必要附件：图片、日志等信息

提交要素：

缺陷报告编号：缺陷的唯一标识

严重程度：严重、一般、微小、建议

缺陷优先级：

bug类型：代码错误、兼容性错误、设计缺陷等

缺陷状态：新建、打开、关闭、延期

缺陷类型：功能错误、UI错误、兼容性、数据、易用性、架构

缺陷流程

提交缺陷注意事项：

可复现：缺陷可以复现

唯一性：一个缺陷上报一个问题

规范性：符合公司或项目要求

缺陷编写规范：

准确：描述的信息是正确的

具体：有细节且是真是特定的

简洁易懂：描述简单容易理解

次序清晰：描述缺陷过程有条件，有先后顺序

---