软件测试基础知识

⼀、测试介绍

什么是软件测试？

测试主流技能

⼆、测试常⽤分类

分类

阶段划分（阶段：软件产出过程顺序）

代码可⻅度

2.1 阶段划分

单元测试

说明：针对程序源代码进⾏测试（单元：最⼩独⽴功能代码段）

提示：

1 、国内单元测试⼀般开发⾃测

2 、单元测试可以解决 - 快速定位缺陷

3 、提⾼测试执⾏效率

集成测试

说明：针对单元与单元之间的接⼝进⾏测试

提示：⼜称接⼝测试。

系统测试

说明：针对系统整体功能 + 兼容 + ⽂档（说明、安装⽂档）

验收测试

内测：公司内部⼈员使⽤，发觉缺陷并修复。

公测：让⽤户帮忙测试

提示：验收测试 , ⼀般要根据项⽬类型决定是否使⽤。

2.2 代码可⻅度划分

代码可⻅度：代码可⻅的程度上划分

黑盒测试：看不见源代码，主要对程序概念进行测试-----系统测试

灰盒测试：看见部分源代码，主要对程序接口进行测试----集成测试

白盒测试：看见全部代码，主要对程序源代码进行测试-----单元测试

系统测试和⿊盒测试重点核⼼是功能测试

集成测试和灰盒测试⼜称接⼝测试

单元测试和⽩盒测试是对代码进⾏测试

⾃动化测试归属功能测试

性能测试、安全测试归属专项测试 s

三、模型

1.质量模型

2.测试模型

1. 质量模型能告诉我们，测试时应该考虑的⽅⾯

软件质量模型：1.功能性 2.兼容性 3.可靠性 4.可维护性 5.性能效率 6.易用性 7.信息安全 8.可移植性

四、测试流程

1.需求分析 2.计划编写 3.用例设计 4.用例执行 5.缺陷管理 6.测试报告

1.需求分析（评审）

前提：阅读 1 遍需求⽂档，记录不明确之处。

参与⼈员：前端、后端、测试、产品

⽬的：

1 、确保各部⻔需求理解⼀致

2 、各⻆⾊对需求进⾏查漏补缺

3 、了解软件有些功能

提示：需求分析阶段 -> 软件还未实现（刚⽴项）

2.测试计划

说明：指导测试执⾏的⽂档（重要）

测什么（⽬标、范围）

谁来测（⼈员进度及安排）

怎么测（测试⼯具、测试策略）

3.用例设计

说明：保证能准确验证软件测试点执⾏的⽂档。

1 、分析需求

2 、提取测试点

3 、设计⽤例覆盖测试点

4.用例执行

说明：实施测试

5.缺陷管理

提交---验证---关闭

6.测试报告

1、 bug 分析及统计

2 、测试中遇到的问题

3 、测试总结（本次测试中的优点和不⾜）

五、测试用例

作用： 1 、防⽌漏测    2 、衡量软件是否通过的标准

测试用例八大要素：

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

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

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

前置条件：要执行此条用例。有哪些前置操作

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

测试步骤：描述操作步骤

测试数据：操作的数据，没有的话可以为空

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

六、用例设计方法

1.等价类划分法 2.边界值分析法 3.判定表法 4.场景法 5.错误推测法

1.等价类划分法

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

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

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

c.步骤：1.明确需求  2.确定有效和无效等价类  3.提取数据表现测试用例

2.边界值法：

a.说明：使⽤边界值解决边界位数限制问题。

\

b.提示： 1、有关范围限制，最多7条⽤例（暂时未优化）

2 、边界值能解决位数限制问题，但是不能解决类型问题（要结合等价类）

c.步骤： 1 、明确需求    2 、确定有效和⽆效等价   3 、确定边界范围   4 、提取数据编写⽤例

d.优化：重点：开内闭外（开区间选包含的点，闭区选不包含的点）

开区间：不包含边界上的点（没有等号）。如： a<10

闭区间：包含边界上的点（有等号）。 如 :a<=10

在等价类的基础上针对有边界范围的测试数据输⼊的地⽅ ( 重点关注边界 )

常⻅词语描述 : ⼤⼩、尺⼨、重量、最⼤、最⼩、⾄多、⾄少等修饰词语

典型代表 : 有边界范围的输⼊框类测试

3.判定表法：

1 、明确需求

2 、画出判定表

1 ）、列出条件桩和动作桩

2 ）、填写条件项，对条件进⾏全组合

3 ）、根据条件项的组合确定动作项

4 ）、简化、合并相似规则 ( 有相同的动作 )

3 、根据规则编写测试⽤例

使用场景：有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖制约关系。适用于条件组合数量较少的情况下，比如4个以下

提示：

1 、多条件之间有依赖关系，使⽤判定表来进⾏测试覆盖。

2 、判定表⼀般适合 4 个以内条件依赖关系

3 、如果条件超过 4 个，就不适合覆盖所有条件，应采⽤（正交法）来解决。

4.场景法：

业务测试覆盖  

1 、覆盖业务测试 , 需要使⽤流程图法

2 、先测试业务，在测试单功能、单模块、单⻚⾯

流程图:业务⽤例是根据流程图来梳理的,需要先了解流程图

1 、线上⼯具： https://processon.com/diagraming/605880af07912927bd71c388

2 、离线⼯具： visio

3 、其他⼯具： Excel

5.错误推测法：

应⽤场景：当项⽬⽤例都执⾏完毕，且 BUG 修复完成，离上线还有⼀段时间，

在这段时间中可是使⽤错误推荐法复测主要业务或测试未覆盖的功能。

七。缺陷

1.缺陷概念

a.定义：软件中存在的各种问题，都为缺陷，简称bug

b.缺陷标准：

1 、少功能

2 、功能错误

3 、多功能

4 、缺少隐性功能

5 、易⽤性（软件测试⼈员专业⻆度）

c.缺陷产生的原因

1 、需求⽂档

2 、架构设计

3 、编码实现

4 、环境（硬件、软件）

d.缺陷的生命周期

1 、回归测试：

① 常规项⽬回归：项⽬本次发布新增 2 个模块，最基本要测新增模块功能及新增模块关联的旧模块。

② ⾮常规项⽬（银⾏、部队、航天）：新增功能，必须全部复测。

2 、回归 bug ：上⼀个版本发现的缺陷，开发修复完毕，在下个版本进⾏重新验证。

缺陷的核心要素：

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

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

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

4.缺陷的预期结果：希望得到的结果

5.缺陷的实际结果:实际得到的结果

6.缺陷的必要附件：图片，日志等信息

缺陷的提交要素：

缺陷的类型：

1 、功能错误

2 、 UI ⻚⾯错误

3 、兼容性

4 、数据（数据库）

5 、易⽤性

6 、建议

7 、架构缺陷

小结

设计⽤例 -> 执⾏⽤例（执⾏测试） -> 缺陷（提交、验证、关闭）

缺陷定义：任何问题（ Bug ）

缺陷标准：多功能、少功能、错误、缺少隐性功能、易⽤性

描述缺陷重点：缺陷标题、前置条件、复现步骤、预期结果、实际结果、附件备注

提交缺陷信息：指派⼈、缺陷等级、修复优先级、类型、状态（统计缺陷）

2.缺陷管理

缺陷跟踪流程：

缺陷提交要注意的事项：可重现/唯一性（一个缺陷上报一个问题）/规范性（符合公司或项目要求）

⾯试题：发现缺陷后，⾸先回怎么办？ -- 确定 Bug 可复现、确定是 Bug 。 提交时，要检查缺陷是否已存在。

缺陷管理工具：

1 、项⽬管理⼯具 - 管理缺陷 (禅道 https://demo.zentao.net/user-login.html 、JIRA 、 TFS)

2 、 Excel 管理缺陷

禅道特点：

八。HTML