测试基本理论-CSDN博客

本文链接：https://blog.csdn.net/weixin_51008312/article/details/148308019

1.软件测试流程

需求分析：测试团队分析需求与功能点，明确测试范围与优先级，输出测试需求清单。

测试计划：明确测试范围，人员，资源，时间节点，风险等。

测试设计：编写测试用例，准备测试数据，搭建测试环境。

测试执行：执行测试用例，记录测试结果，提交bug。

缺陷跟踪：跟踪缺陷修复情况，回归测试已修复缺陷。

测试总结与报告：汇总测试数据，评估质量，编写测试报告。

2.测试类型

测试类型可以从功能性测试和非功能性测试划分：

功能性测试：单元测试，集成测试，系统测试，验收测试，回归测试，冒烟测试。

- - 单元测试：针对最小的代码单元测试，可以是某个函数或某个方法。
  - 集成测试：多个模块组合后交互的接口测试。
  - 系统测试：整个系统的全规格测试。
  - 验收测试：用户或产品经理对产品是否符合规格做的最后的测试。
  - 回归测试：对已修复的缺陷进行测试。
  - 冒烟测试：快速测试系统的核心功能。

非功能测试可分为性能测试，压力测试，兼容性测试，可用性测试，安全性测试等等。

- - 性能测试：测试系统的响应时间，并发能力，吞吐量等。
  - 压力测试：在高负载的情况下运行系统，测试系统的稳定性和恢复性。
  - 兼容测试：测试系统在不同部署环境下是否正常运行。
  - 可用性测试：测试系统是否人机交互友好，是否易于使用。
  - 安全测试：测试系统是否存在安全漏洞。

同时也可以按照执行方式划分：

- - 功能测试：测试人员手动执行测试用例。
  - 自动化测试：通过编写脚本，测试UI,接口等。
  - 静态测试：不运行程序，通过代码审查，文档审查等方式测试。
  - 动态测试：运行程序测试。

3.测试用例设计方法

黑盒测试：

1.等价类划分

将所有输入分为有效等价类和无效等价类。

比如18~100岁，他的有效等价类就是18~100的数值，无效等价类就是小于18，大于100。

2.边界值分析

将边界附近容易出错的边界值重点测试，分别是边界上，边界外，边界内。

比如18~100岁，就是17，18，19，99，100，101。

3.判定表法

逻辑条件复杂时，列出所有条件组合以及对应动作。

比如查询条件，分为地区，时间，排序，以及搜索内容，就需要列一个2^4=16的16行5列的判定表。是否选择地区，是否选择时间，是否排序，是否输入内容，这四者的所有组合，并给出他们的预期结果。

4.状态迁徙法

当系统在不同的状态中切换，需要测试他的状态扭转是否正确。

比如下单业务会生成一个订单，点击下单后订单状态为创建未支付，支付后就是支付完成待发货，发货后就是待收货，收货后就是待签收，签收后就是待评价，依次评估状态是否扭转成功。

5.因果图法

同样面对复制判断条件时，可以列出所有因，以及对应的果，根据他们之间的规则设计测试用例。

比如登录校验功能，因就可以由用户名已输入，密码已输入，验证码正确，果就可以是允许登录，用户名或密码为空，验证码错误。通过与或非这些逻辑运算对因进行组合，再对应出果。

6.错误推测法

基于经验推测可能发生的错误。

比如一个搜索框，可以是乱码，表情，空白，超长数据，0，null等

7.场景法

模拟用户操作系统的一系列功能步骤。也可以是业务流。

比如某个电商系统，就是注册-登录-加购-下单-支付-签收-评价。

白盒测试：

语句覆盖：所有语句都至少执行一次。

判定覆盖：所有if/else/while/for等判定分支都至少执行一次。

条件覆盖：每个判断条件（原子条件）的True和False都取过。

路径覆盖：所有可能的执行路径都执行一次。

判定-条件覆盖：每个判定条件都去一次True和False，每个原子条件都取一次True和False。

条件组合覆盖：判定条件中的原子判定之间的组合全部枚举一次。

4.测试用例

标准结构就是：用例编号，用例名称，用例优先级，前置条件，测试步骤，输入数据，预期结果，实际结果，测试时间，测试人员。

1.用例编号：用于标注该用例唯一ID。

2.用例名称：用简单的语言描述用例的目的。

3.优先级：执行测试用例的优先级。

4.前置条件：执行该用例前需要达到的条件。

5.输入数据：测试用到的数据。

6.测试步骤：测试该用例应该执行的步骤。

7.预期结果：测试的正确结果。

8.实际结果：测试用例执行后实际的结果。

9.测试时间：记录测试的时间。

10.测试人员：记录执行该测试用例的人员。

5. 缺陷生命周期

1.新建：测试人员发现bug，在缺陷管理工具新建缺陷。

2.已分配：测试人员将缺陷指定给开发人员修复。一般由测试主管或者项目负责人指派。

3.打开：开发人员打开缺陷，并着手解决。

4.已修复：开发人员修复缺陷后，通知测试人员已修复。

5.待回归：测试人员等待回归测试，判定是否已修复。

6.已验证：验证成功已修复则标记为已修复。

7.关闭：缺陷流程正式结束。

8.拒绝：开发人员拒绝缺陷，一般是无法复现，不是缺陷等。

9.延期：因为开发进度紧急，或者该缺陷优先级低，亦或者缺陷有待进一步讨论解决，无法在当前版本更新。

10.重复：缺陷提交重复。

11.重新打开：缺陷修复后验证不通过，重新打开。

6. Bug等级与优先级

缺陷等级一般为：

1.致命：影响系统无法正常运行，系统启动报错，直接崩溃。

2.高：核心功能受到影响，比如手机验证码始终收不到，A 用户可以看到 B用户的信息等。

3.中：一般功能问题，不影响主流程，但是用户体验不好，比如搜索结果不准确，文本框长度校验不严格等。

4.低：轻微功能偏差，某些界面问题，排版错误，文本提示语错误，时间格式不统一。

5.建议：非缺陷，属于产品优化建议，比如 UI 不统一，交互不符合人机工学等。

优先级一般为：

1.最高：影响系统运行，应立即修复。

2.高：影响核心功能执行，尽快修复。

3.中：影响非核心功能运行，可适当延后。

4.低：可以延后处理的缺陷，一般在没有其他任务时修复。

7. 七大测试原则

1.无法穷尽测试：不可能测试所有可能发生的结果。

2.认为没有缺陷是一种谬误：即使系统没有任何异常错误，但是业务不满足用户需求，也是没有意义的。

3.测试依赖上下文：不同系统软件侧重点不同，金融侧重安全，游戏侧重用户体验。

4.缺陷聚集效应：缺陷一般呈现聚集出现，多数缺陷出现在少数地方。

5.尽早测试：测试应尽早介入开发流程，比如需求阶段的文档审查，越早发现缺陷，修复成本越低。

6.杀虫剂悖论：某一套测试用例在反复执行后发现缺陷越来越少，应该及时更新测试用例。

7.测试应该指出缺陷存在，而不是证明无缺陷：测试的目的是发现缺陷，而非证明系统无缺陷。

8. 测试模型理论

1.V 模型

V 模型强调测试先于编码开始，测试与开发并行。

需求分析->系统设计->详细设计->编码实现

验收测试->系统测试->集成测试->单元测试

2.W 模型

3.H 模型

H 模型将测试独立出来为一个过程，设定了测试准入点，当达到准入点条件后才可进行测试，同时测试对象抽象为一整个产品包，不局限于需求分析到实施的过程。

4.敏捷测试模型

将测试过程嵌入到敏捷迭代开发中，除了必要测试文件，其他文件都可以随着迭代开发不断更迭，拥抱变更。

5.测试金字塔

测试越靠近底层，执行越快，越稳定，应覆盖越多。

UI 测试为顶层应该避免过多 UI 自动化，功能测试为中间，单元测试为底层，最快速也最稳定。

9. 质量度量与覆盖率

常见的质量度量有：

缺陷密度：每千行代码中发现的缺陷数量，比如100w行代码有100个缺陷，缺陷密度就是10。

缺陷发现率：每周或每日发现的缺陷数，比如每日平均发现10个缺陷。

缺陷修复率：已修复数量/总缺陷数量。修复8个剩两就是80%。

回归缺陷率：修稿引入的bug的比率，比如修复了10个但是引入了两，就是20%。

测试用例通过率：测试用例通过的数量/总测试用例数量。

覆盖率：基于白盒测试的测试用例方法，编写了多少用例，和可以产生的用例数作比。比如条件覆盖率，一共有10个原子条件，应该是2^10个用例，但是只执行了一半，那就是50%。

10.面试常见问题

测试用例设计方法有哪些？分别适用哪些场景？

边界值（数值范围），等价类（字段输入），因果图（复制业务逻辑），判定表（复杂规则），状态迁徙（流程状态切换），场景（用户业务流程），错误推测（没有详细需求文档）。

如何衡量一个产品的测试质量？

回归缺陷率，缺陷密度，缺陷发现率，缺陷修复率，测试用例通过率，覆盖率等。

遇到 Bug 不复现怎么办？

复现环境确认，复现步骤确认，日志/抓包分析，记录图片或视频，和开发沟通确认。

怎么理解测试与开发的关系？

协作，互补，共同提升产品质量，开发从技术角度保障产品，测试从用户角度测试产品。

你是如何评估一个功能是否测试充分的？

覆盖率，缺陷率，测试用例是否全面，测试用例执行结果分析等。

如果开发不重视 Bug 怎么办？

及时沟通消除和开发之间的沟通障碍，避免错误理解，同时再次确定 Bug 级别和优先级从对系统危害角度分析，结合从用户角度分析 Bug 的危害，如果仍不重视，可以反馈给测试组长或产品经理，测试应该与开发保持良好沟通，消除偏见以及沟通障碍，沟通大于硬刚。

你是如何做回归测试策略的？

以及优先级以及缺陷等级，先回归优先级高和缺陷等级高的，测试用例的选择，着重评估易出现缺陷的用例，利用自动化测试回归，以及按照版本更新，除了全量回归还可以选择性着重回归版本迭代内容。

如何设计测试计划和测试方案？

测试计划包含了测试目标，测试范围，测试资源，测试人员，各测试时间点，风险以及应对。所以需要分析需求，明确测试的最终目标以及范围，避免过度或过少测试，再然后要明确测试所需资源，这些属于测试前置条件，没有安排到位无法开展工作，同时要分派好测试人员任务，再然后需要明确测试的各个时间点，每个时间点里程碑需要达到的目标，最后就是测试中可能出现的风险，需要评估可能出现的风险并给出解决方案。

测试方案则是具体的解决方法，不同阶段，不同模块，不同功能，采用何种测试方法和工具，同时要提供设计测试用例的思路与应该采用的方法，确定 Bug 管理流程，以及明确测试通过标准。

给你一个电子秤怎么设计用例？

1. 功能性测试

基本称重功能：

用例：放置标准砝码（如1kg），验证显示值是否为1kg±误差范围。

用例：称重超出量程（如最大10kg，放11kg），验证是否提示"超载"或显示错误。

单位切换：

用例：切换单位（kg/g/lb），验证显示值是否正确转换。

清零/去皮功能：

用例：放置容器后按"去皮"，再放物品，验证显示是否为净重。

稳定性测试：

用例：多次称量同一物品，结果是否一致。

边界值测试：

用例：称重接近量程极限（如9.99kg/10kg）。

2. 非功能性测试

环境适应性：

用例：在不同温度/湿度下称重，结果是否稳定。

电源测试：

用例：电池低电量时是否提示，称重是否准确。

耐久性测试：

用例：连续称重100次，检查按键/传感器是否正常。

3. 异常场景

干扰测试：

用例：称重时轻拍桌面，显示值是否快速恢复稳定。

非法输入：

用例：放置非均匀物体（如半悬空），是否提示错误。

如何定位 Bug？

1. 重现Bug

确定Bug的可重现性

记录重现步骤和环境条件

尝试在不同环境下重现

2. 日志分析

检查应用日志、系统日志和错误日志

查找错误堆栈跟踪

分析时间戳和事件序列

3. 代码审查

检查相关代码段

使用版本控制查看最近变更

分析可能受影响的依赖关系

4. 调试工具

使用调试器逐步执行代码

设置断点检查变量状态

使用性能分析工具

5. 缩小范围

使用二分法隔离问题区域

构建最小可重现示例

排除外部因素干扰

给你一个接口你会如何编写测试用例？

1. 基础测试用例

**测试用例ID**: API_001
**描述**: 验证接口基本功能
**请求方法**: GET/POST/PUT/DELETE
**URL**: /api/resource
**请求头**: Content-Type: application/json
**请求体**: { "key": "value" }
**预期响应状态码**: 200
**预期响应体**: { "status": "success", "data": {...} }

2. 参数验证测试

必填参数缺失测试

参数类型错误测试

参数边界值测试

参数组合测试

3. 错误处理测试

无效认证测试

权限不足测试

资源不存在测试

服务器错误测试

4. 性能测试

响应时间测试