先测正常功能
先确认安全功能按设计工作。
师傅
“我们先用客服账号登录。”
小白
“手机号显示成部分隐藏。”
师傅
“页面正常，再看看报表和接口。”
小白
“如果三个地方都按规则显示，功能测试才比较完整。”
【 第 5 步 】
软件测试室
师傅：“新功能已经开发完成，但开发人员说‘页面能打开’并不能证明安全要求已经实现。今天进入数据安全软件测试。我们要分别做功能测试、权限测试、配置测试、日志测试、恢复测试、异常测试和回归测试，确认安全功能正常、无权限操作会被拒绝、配置符合基线、关键动作能够留下日志、备份真的能恢复。
每一项检查都要写成可重复的测试用例，包括编号、测试项、前置条件、操作步骤、预期结果、实际结果和证据。测试发现的问题还要形成缺陷记录，而不是口头告诉开发人员改一下。”
01 · 现场对话
软件测试室的知识任务
再测不应该成功的操作
权限测试不能只看管理员。
小白
“现在用普通客服尝试导出全部会员资料。”
师傅
“预期结果是什么？”
小白
“系统拒绝，或者要求进入审批。”
师傅
“还要确认有没有留下日志。”
测试写成可重复步骤
不能只写“测试通过”。
小白
“这条记录怎么写？”
师傅
“先写前置条件。”
小白
“客服账号已启用，没有导出审批。”
师傅
“然后写步骤、预期结果、实际结果和证据。”
小白
“这样其他人也能按同样方法复测。”
发现问题形成缺陷
测试失败要进入跟踪。
小白
“接口返回了完整手机号，但页面已经脱敏。”
师傅
“登记缺陷。”
小白
“写清问题位置、复现步骤和证据。”
师傅
“整改完成以后再做回归测试，确认修改没有破坏其他功能。”
02 · 小白做现场笔记
重要概念及注释
数据安全软件测试
- 正式含义
- 验证安全需求是否正确实现、配置是否符合基线、安全控制是否真正有效，以及异常情况下系统是否保持受控。
教材将功能、权限、配置、日志、恢复、异常和回归列为基础测试类型。
安全测试不是证明系统“能用”，而是证明系统“按安全规则运行”。
测试计划
- 正式含义
- 在执行测试前，对测试对象、范围、方法、数据、标准和风险进行统一安排。
- 基本内容
- 测试对象 测试目标 测试范围 测试数据 测试方法 通过标准 业务影响 测试窗口 备份与回退
测试之前先说清测什么、怎么测、怎样算通过。
测试用例
- 正式含义
- 把具体安全检查写成能够重复执行的标准步骤。
- 基本结构
- 编号 测试项 前置条件 操作步骤 预期结果 实际结果 证据教材也将这些内容列为测试用例的基本要素。
一条好用例，别人拿过去也能重新测试出同样的结果。
权限测试
- 正式含义
- 验证不同角色只能访问被授权的数据和功能。
- 面包厂示例
- 普通客服 → 查询本人负责订单 → 允许 普通客服 → 导出全部会员数据 → 拒绝
权限测试既要试“允许什么”，也要试“禁止什么”。
配置测试
- 正式含义
- 核对系统的实际配置是否符合批准的安全基线。
- 检查示例
- 默认账号是否关闭 不必要端口是否关闭 日志是否开启 远程访问是否限制来源 备份是否启用
设计写在纸上，配置测试负责看真实系统是不是照着做了。
日志测试
- 正式含义
- 验证关键操作是否产生完整、可查询和可追溯的日志记录。
- 典型测试动作
- 登录 查询 导出 修改 删除 授权测试以后检查：账号 时间 对象 来源 结果
做一次关键操作，再去日志里看看能不能完整找到它。
回归测试
- 正式含义
- 系统修复问题或修改配置以后，重新验证原问题和相关功能，确认整改有效且没有造成新的问题。
- 工作路线
- 发现缺陷 ↓ 整改 ↓ 重新执行原用例 ↓ 检查关联功能
修好了还要重新测，不能只听一句“已经改完”。
缺陷记录
- 正式含义
- 记录测试发现问题的位置、现象、影响、证据和整改状态。
- 基础内容
- 问题是什么 在哪里出现 怎样复现 预期是什么 实际是什么 有什么证据 由谁整改 什么时候复测
问题要写到别人能够重新找到，而不是只写一句“系统有问题”。
03 · 经验和难点
小结
这一站，小白通过功能、权限、日志、异常和回归等测试，验证了安全需求是否真正进入系统，并学会把检查过程写成可重复的测试用例。最值得记住的经验是：安全测试既要验证“应该成功的”，也要验证“不应该成功的”。初学者最容易遇到的难点，是只检查页面结果，遗漏接口、日志、配置和恢复路径。