哪些属于异常测试

异常测试核心是验证系统在非预期场景、非法输入、故障条件下的容错能力，简单说就是 “故意找问题、造麻烦”，看系统是否会崩溃、泄露数据或逻辑出错。结合常见测试场景，主要分为这几类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
一、输入类异常（最常用）
    非法格式：比如手机号输字母、日期输 “2025-13-01”、接口参数传非 JSON 格式。
    边界 / 极端值：价格输 0、负数或超大数（9999999）、文件上传选 10GB 超大文件。
    空值 / 缺失：登录时空用户名、新增药品漏填必填项、接口少传关键参数。
    恶意输入：SQL 注入语句、XSS 脚本、特殊字符（!@#$%^&*）。

二、业务逻辑类异常
    权限越界：普通用户想改管理员权限、无 Token 调用需登录的接口。
    状态冲突：修改已删除的药品、重复提交同一表单、审核中的医院直接发布内容。
    依赖异常：删除被药品关联的公司、修改药品所属医院为已注销医院。

三、环境与资源类异常
    网络问题：请求时断网、网络延迟高、服务器响应超时。
    依赖服务故障：Redis 缓存宕机、数据库连接失败、文件存储服务不可用。
    资源不足：服务器 CPU / 内存占满时，测试核心功能是否正常。

四、并发与负载类异常
    并发冲突：多用户同时改同一药品价格，看是否数据不一致。
    超出限制：超过接口限流阈值、同时上传多个大文件。
    缓存异常：缓存击穿、缓存雪崩（对应你项目中的缓存性能测试场景）。

五、兼容性 / 适配类异常
    浏览器 / 设备适配：旧版 IE 浏览器打开 Web 端、小屏手机访问系统。
    数据兼容：接口预期接收整数，实际传字符串；不同版本数据迁移后是否正常。
    简单总结：只要是 “不符合正常操作流程、超出预期范围” 的场景，都属于异常测试，核心是确保系统遇到问题时不崩溃、提示清晰、数据安全。

测试用例的编写要素

测试用例编写的核心是清晰、可复现、无歧义、全覆盖，无论功能测试、集成测试、自动化测试，都需包含以下核心要素

1
2
3
4
5
6
7
8
9
10
11
12
13
14
1. 用例编号：唯一标识，格式统一（如 “FT - 药品 - 001”“IT - 权限 - 002”，前缀区分测试类型：FT = 功能、IT = 集成），便于追溯和管理。
2. 测试模块 / 功能：明确用例归属（如 “药品管理 - 药品新增”“RBAC 权限 - 角色分配”“集成场景 - 药品 + 公司关联”）。
3. 测试标题：简洁概括核心场景（如 “新增药品 - 必填字段为空”“集成测试 - 普通用户无发布文章权限”），一眼能懂测试目的。
4. 前置条件：执行用例前必须满足的条件（如 “用户已登录且为管理员”“Redis 服务正常运行”“依赖的公司数据已创建”）。
5. 测试数据：明确所需具体数据（如 “用户名：test01，密码：123456”“药品 ID：1001，关联公司 ID：2001”“上传文件：2MB PDF”）。
6. 测试步骤：分步描述操作流程，每步只做一件事（如 “1. 进入药品编辑页；2. 输入价格为 - 10；3. 点击‘保存’按钮”），无歧义、可复现。
7. 预期结果：明确、可验证的结果（如 “系统提示‘价格不能为负数’”“接口返回 200 状态码，数据库价格更新为 25”“缓存与数据库数据一致”），不模糊。
8. 测试类型：标注场景类型（如 “功能测试”“异常测试”“集成测试”“性能测试”“兼容性测试”）。
9. 优先级：划分测试重点（高 / 中 / 低，如 “核心接口调用 - 高”“界面样式优化 - 低”），便于测试资源分配。
10. 严重程度：预判漏洞影响（致命 / 严重 / 一般 / 轻微，如 “登录功能失效 - 致命”“提示文案错别字 - 轻微”）。
11. 执行环境：明确测试环境（如 “Chrome 120+Windows 11”“测试服务器 + MySQL 8.0+Redis 6.2”）。
12. 依赖模块 / 组件：集成测试专属，明确联动模块（如 “药品模块 + Redis + 数据库”“前端 UI + 后端接口”）。
13. 备注：补充特殊说明（如 “需提前清空缓存”“该用例依赖用例 FT - 药品 - 001 执行成功”）。

postman 重点做哪些接口测试

Postman 重点聚焦接口 “功能有效性、数据合法性、安全可控性、基础性能” 四大核心维度，是接口测试的核心工具之一。

1
2
3
4
5
6
7
8
9
10
11
12
13
一、核心测试场景（必做重点）
1. 功能验证测试：最核心的基础测试，验证接口是否实现预期功能。包括正常请求（参数完整、格式正确）的响应结果、状态码是否符合预期，以及参数缺失、格式错误、业务逻辑冲突等异常场景的处理是否合理。

2. 参数全面测试：覆盖所有参数类型（路径参数、查询参数、请求体参数、请求头参数）。测试合法值、边界值（如最大长度、最小数值、临界值）、特殊字符（空格、符号、 emoji）、默认值的兼容性，确保参数处理无遗漏。

3. 认证与授权测试：保障接口访问安全。测试无 token/cookie 请求、过期 / 无效凭证请求、不同角色权限（管理员 / 普通用户 / 游客）请求，验证权限控制逻辑是否生效，避免越权访问。

4. 响应规范测试：检查响应数据的合规性。包括响应体格式（JSON/XML 等）是否规范、字段完整性、数据类型正确性（字符串 / 数字 / 布尔值是否匹配），以及响应头（Content-Type、缓存策略、过期时间）是否符合设计要求。

5. 接口依赖测试：针对有上下游依赖的接口（如先登录获取 token，再用 token 查数据）。通过 Postman 的 “环境变量 / 全局变量” 提取前一个接口的关键数据（如 token、订单 ID），传递给后续接口，验证流程衔接的完整性和数据一致性。

6. 基础性能与稳定性测试：通过 “集合运行”“并发请求” 功能，简单验证接口的响应速度、吞吐量。设置循环次数或持续运行时间，测试接口长时间运行是否无报错、无超时，识别明显的性能瓶颈（复杂性能测试需结合 Newman 或专业工具）。

测试流程

1
2
3
4
5
6
7
8
一、完整测试流程（按阶段推进）
1. 需求分析阶段：对接产品、开发，明确软件功能需求、非功能需求（性能、安全等），梳理核心业务流程，识别潜在风险点（如复杂交互、数据依赖）。
2. 测试计划阶段：确定测试范围、测试策略（黑盒 / 白盒、手动 / 自动化）、测试环境（硬件 / 软件 / 网络）、测试进度、人员分工和交付物（测试用例、测试报告）。
3. 测试用例设计阶段：基于需求文档，用等价类、边界值等方法设计用例，覆盖正常场景、异常场景和边界场景，确保用例可执行、可复现。
4. 测试执行阶段：搭建测试环境，按用例逐步执行，记录测试结果（通过 / 失败），发现缺陷后提交到缺陷管理工具（如 JIRA），跟踪缺陷修复进度。
5. 回归测试阶段：开发修复缺陷后，重新执行相关用例，验证缺陷是否解决，同时检查是否引入新缺陷（必要时执行全面回归）。
6. 测试总结阶段：整理测试数据（缺陷数量、通过率），分析缺陷原因，输出测试报告，判断产品是否满足上线标准。

测试的分类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
一、按测试阶段划分（从开发到上线的流程维度）
1. 单元测试：对软件最小功能单元（如函数、类、方法）测试，由开发者主导。聚焦代码逻辑正确性，比如验证 “用户密码加密函数” 是否能正确将明文转为加密串。
2. 集成测试：验证多个模块 / 单元间的接口交互，重点测数据传递和依赖关系。比如 “登录模块” 与 “用户信息模块” 集成后，测试登录成功能否正常获取用户昵称、头像。
3. 系统测试：对完整软件系统的全流程测试，覆盖功能、性能、兼容性等所有需求。比如电商 APP 从 “注册→搜索商品→下单→支付→物流查询” 的全流程验证。
4. 验收测试：用户 / 客户主导，验证软件是否满足实际业务使用需求。分 α 测试（内部员工测试）和 β 测试（外部用户公测），比如某社交 APP 上线前邀请 1000 名用户体验，收集使用反馈。

二、按测试方法划分（是否关注内部逻辑）
1. 黑盒测试：不关心软件内部代码结构，仅通过输入输出验证功能。比如测试计算器 “1+2” 是否输出 3，无需知道计算逻辑的代码实现。
2. 白盒测试：已知内部代码逻辑，针对性测试代码路径、分支。比如验证 “会员折扣计算代码”，覆盖 “普通会员”“VIP 会员”“满减叠加” 等所有分支。
3. 灰盒测试：兼顾功能与模块交互，不深究代码细节。比如接口测试，已知接口请求格式和返回规则，验证数据传输是否正常，无需关注接口内部代码。

三、按测试对象 / 目标划分（核心测试类型）
1. 功能测试：验证软件功能是否按需求实现，包括正常场景和异常场景。比如测试登录功能，输入正确账号密码登录成功、输入错误密码提示报错。
2.性能测试：评估软件运行效率和稳定性，包括响应时间、吞吐量、资源占用。比如测试电商 APP 高峰期（如双十一）的页面加载速度、并发下单能力。
3.安全性测试：防范安全风险，比如 SQL 注入、越权访问、敏感数据泄露。比如测试后台管理系统，普通用户能否通过 URL 直接访问管理员页面。
4.兼容性测试：验证软件在不同环境下的适配性。比如 APP 在不同手机型号、iOS/Android 系统版本，或网站在 Chrome/Firefox/Edge 浏览器上的运行情况。
5.UI/UX 测试：关注界面设计和用户体验。比如按钮位置是否合理、字体大小是否清晰、操作流程是否简洁（如购物车结算步骤是否过多）。

四、其他常用分类（按场景 / 方式补充）
1. 回归测试：开发修复缺陷后，重新测试相关功能，确保缺陷已解决且未引入新问题。比如修复 “下单后金额计算错误” 的 bug 后，重新测试下单流程及关联的支付、订单查询功能。
2. 冒烟测试：核心功能快速验证，判断软件是否具备进一步测试的条件。比如新开发的 APP，先测试 “能否打开、能否登录、能否浏览商品”，核心功能正常才进行全面测试。
3. 压力测试：极限场景下的性能测试，验证软件最大承载能力。比如测试服务器在 10 万用户同时登录时的稳定性，是否会崩溃。
4. 中断测试：模拟使用中被打断的场景，比如 APP 使用时来电、切后台，恢复后能否正常继续使用。

接口测试是什么

接口测试是验证系统组件间接口交互正确性的测试，聚焦 “请求→传输→响应” 全流程：

1
2
3
4
验证接口是否按需求接收请求参数、返回正确响应数据；
覆盖功能、数据、协议、认证、性能等维度；
无需关注系统内部实现，仅通过接口规范（如 API 文档）设计测试用例。

需求文档没有标明边界值，怎么确定边界值，确定边界值后怎么测

核心结论：需求文档未标明边界值时，通过 “业务逻辑推导 + 同类产品参考 + 技术常识预判” 确定边界，再按 “覆盖边界点 + 等价类结合” 的思路设计测试用例，确保无遗漏。

1
2


哪些属于边界测试

1
2


哪些属于边界测试

1
2


哪些属于边界测试

1
2


哪些属于边界测试

1
2