【 19个概念 】
安全测试
难易分类
简单概念
1 测试计划
概念解释：说明测试对象、目标、范围、数据、方法和通过标准的文档。
实例：公司针对订单系统形成一份《测试计划》，其中写明适用对象、执行内容、责任人员和结果证据。这份可以编号、查阅和归档的文件就是测试计划。
易混淆：把“测试计划”和“测试用例”混为一谈。测试计划的关键是“说明测试对象、目标、范围、数据、方法和通过标准的文档”；测试用例关注的是另一种对象、位置、作用或处理关系。
2 测试用例
概念解释：规定前置条件、步骤、预期结果、实际结果和证据的记录。
实例：公司针对订单系统形成一份《测试用例》，其中写明适用对象、执行内容、责任人员和结果证据。这份可以编号、查阅和归档的文件就是测试用例。
易混淆：把“测试用例”和“测试计划”混为一谈。测试用例的关键是“规定前置条件、步骤、预期结果、实际结果和证据的记录”；测试计划关注的是另一种对象、位置、作用或处理关系。
3 缺陷单
概念解释：记录问题、影响、等级、复现步骤、证据、责任和期限的文档。
实例：公司针对订单系统形成一份《缺陷单》，其中写明适用对象、执行内容、责任人员和结果证据。这份可以编号、查阅和归档的文件就是缺陷单。
易混淆：把“缺陷单”和“漏洞台账”混为一谈。缺陷单的关键是“记录问题、影响、等级、复现步骤、证据、责任和期限的文档”；漏洞台账关注的是另一种对象、位置、作用或处理关系。
难懂概念
4 安全测试
概念解释：验证安全功能、配置、权限、日志、恢复和异常处理是否有效。
主要对应的问题：要验证哪个对象、条件和预期结果，正常路径与异常路径是否都被覆盖，发现的问题是否真正修复？
特殊异常情况：常规测试全部通过，边界条件下控制措施立即失效
测试人员执行32个标准用例全部通过，随后使用一个过期令牌连续发送500次请求，并把订单编号换成其他部门的编号，系统仍返回完整数据。这个实例说明：安全测试需要覆盖正常、异常和边界条件，并保存可复现证据。
5 功能测试
概念解释：验证安全功能是否按照设计工作。
主要对应的问题：要验证哪个对象、条件和预期结果，正常路径与异常路径是否都被覆盖，发现的问题是否真正修复？
特殊异常情况：常规测试全部通过，边界条件下控制措施立即失效
测试人员执行32个标准用例全部通过，随后使用一个过期令牌连续发送500次请求，并把订单编号换成其他部门的编号，系统仍返回完整数据。这个实例说明：功能测试需要覆盖正常、异常和边界条件，并保存可复现证据。
6 权限测试
概念解释：验证角色只能访问授权资源。
主要对应的问题：谁在什么条件下可以访问什么对象、执行什么操作，权限何时复核、到期和回收？
特殊异常情况：人员已经离岗，隐藏权限和服务凭证仍然有效
2026年8月8日，公司完成岗位调整后回收了员工主账号，旧接口令牌、数据库账号和缓存会话仍可访问12万条订单。这个实例说明：权限测试必须覆盖人员、程序、设备、接口和有效期限，任何遗漏都会留下真实入口。
7 横向越权
概念解释：同级用户访问其他用户、部门或对象的数据。
主要对应的问题：在订单系统的实际工作中，怎样确认“横向越权”已经做到“同级用户访问其他用户、部门或对象的数据”，并能用配置、日志、文件或测试结果证明？
特殊异常情况：新增第三方接口后，横向越权遗漏3个关键环节
2026年10月9日，一家企业在订单系统中执行横向越权。常规抽查的20条记录均显示正常；当天新增第三方接口并处理7290条数据后，出现对象遗漏、责任不明或记录无法对应的情况。工作人员依据“同级用户访问其他用户、部门或对象的数据”重新核查，才找到未被原流程覆盖的环节。这个实例说明：横向越权需要在真实业务变化和边界条件下接受验证。
8 纵向越权
概念解释：低权限用户执行管理员或高权限操作。
主要对应的问题：在订单系统的实际工作中，怎样确认“纵向越权”已经做到“低权限用户执行管理员或高权限操作”，并能用配置、日志、文件或测试结果证明？
特殊异常情况：新增第三方接口后，纵向越权遗漏4个关键环节
2026年10月10日，一家企业在订单系统中执行纵向越权。常规抽查的20条记录均显示正常；当天新增第三方接口并处理7327条数据后，出现对象遗漏、责任不明或记录无法对应的情况。工作人员依据“低权限用户执行管理员或高权限操作”重新核查，才找到未被原流程覆盖的环节。这个实例说明：纵向越权需要在真实业务变化和边界条件下接受验证。
9 配置测试
概念解释：核验系统、数据库和产品配置是否符合基线。
主要对应的问题：要验证哪个对象、条件和预期结果，正常路径与异常路径是否都被覆盖，发现的问题是否真正修复？
特殊异常情况：常规测试全部通过，边界条件下控制措施立即失效
测试人员执行32个标准用例全部通过，随后使用一个过期令牌连续发送500次请求，并把订单编号换成其他部门的编号，系统仍返回完整数据。这个实例说明：配置测试需要覆盖正常、异常和边界条件，并保存可复现证据。
10 日志测试
概念解释：验证关键操作是否生成完整日志。
主要对应的问题：要验证哪个对象、条件和预期结果，正常路径与异常路径是否都被覆盖，发现的问题是否真正修复？
特殊异常情况：常规测试全部通过，边界条件下控制措施立即失效
测试人员执行32个标准用例全部通过，随后使用一个过期令牌连续发送500次请求，并把订单编号换成其他部门的编号，系统仍返回完整数据。这个实例说明：日志测试需要覆盖正常、异常和边界条件，并保存可复现证据。
11 恢复测试
概念解释：从备份恢复数据或系统，并验证完整性和可用性。
主要对应的问题：要验证哪个对象、条件和预期结果，正常路径与异常路径是否都被覆盖，发现的问题是否真正修复？
特殊异常情况：常规测试全部通过，边界条件下控制措施立即失效
测试人员执行32个标准用例全部通过，随后使用一个过期令牌连续发送500次请求，并把订单编号换成其他部门的编号，系统仍返回完整数据。这个实例说明：恢复测试需要覆盖正常、异常和边界条件，并保存可复现证据。
12 异常测试
概念解释：验证系统在无效令牌、错误输入或超频调用时保持受控。
主要对应的问题：要验证哪个对象、条件和预期结果，正常路径与异常路径是否都被覆盖，发现的问题是否真正修复？
特殊异常情况：常规测试全部通过，边界条件下控制措施立即失效
测试人员执行32个标准用例全部通过，随后使用一个过期令牌连续发送500次请求，并把订单编号换成其他部门的编号，系统仍返回完整数据。这个实例说明：异常测试需要覆盖正常、异常和边界条件，并保存可复现证据。
13 回归测试
概念解释：整改或变更后重新测试，确认问题修复且原功能正常。
主要对应的问题：要验证哪个对象、条件和预期结果，正常路径与异常路径是否都被覆盖，发现的问题是否真正修复？
特殊异常情况：常规测试全部通过，边界条件下控制措施立即失效
测试人员执行32个标准用例全部通过，随后使用一个过期令牌连续发送500次请求，并把订单编号换成其他部门的编号，系统仍返回完整数据。这个实例说明：回归测试需要覆盖正常、异常和边界条件，并保存可复现证据。
14 前置条件
概念解释：执行测试前必须具备的账号、数据、环境和配置状态。
主要对应的问题：在订单系统的实际工作中，怎样确认“前置条件”已经做到“执行测试前必须具备的账号、数据、环境和配置状态”，并能用配置、日志、文件或测试结果证明？
特殊异常情况：新增第三方接口后，前置条件遗漏5个关键环节
2026年10月18日，一家企业在订单系统中执行前置条件。常规抽查的20条记录均显示正常；当天新增第三方接口并处理7623条数据后，出现对象遗漏、责任不明或记录无法对应的情况。工作人员依据“执行测试前必须具备的账号、数据、环境和配置状态”重新核查，才找到未被原流程覆盖的环节。这个实例说明：前置条件需要在真实业务变化和边界条件下接受验证。
15 预期结果
概念解释：测试前明确的允许、拒绝、脱敏、告警或日志表现。
主要对应的问题：在订单系统的实际工作中，怎样确认“预期结果”已经做到“测试前明确的允许、拒绝、脱敏、告警或日志表现”，并能用配置、日志、文件或测试结果证明？
特殊异常情况：新增第三方接口后，预期结果遗漏6个关键环节
2026年10月19日，一家企业在订单系统中执行预期结果。常规抽查的20条记录均显示正常；当天新增第三方接口并处理7660条数据后，出现对象遗漏、责任不明或记录无法对应的情况。工作人员依据“测试前明确的允许、拒绝、脱敏、告警或日志表现”重新核查，才找到未被原流程覆盖的环节。这个实例说明：预期结果需要在真实业务变化和边界条件下接受验证。
16 风险测试
概念解释：验证风险是否存在、控制是否部署、控制是否有效及整改是否闭环。
主要对应的问题：什么因素可能造成损害，发生可能性和后果有多大，现有措施能否把风险控制到可接受范围？
特殊异常情况：单项风险很低，多项条件汇聚后形成重大影响
测试人员执行32个标准用例全部通过，随后使用一个过期令牌连续发送500次请求，并把订单编号换成其他部门的编号，系统仍返回完整数据。这个实例说明：风险测试需要覆盖正常、异常和边界条件，并保存可复现证据。
17 工具误报
概念解释：工具报告风险，但人工核查后确认不成立。
主要对应的问题：在订单系统的实际工作中，怎样确认“工具误报”已经做到“工具报告风险，但人工核查后确认不成立”，并能用配置、日志、文件或测试结果证明？
特殊异常情况：新增第三方接口后，工具误报遗漏2个关键环节
2026年10月22日，一家企业在订单系统中执行工具误报。常规抽查的20条记录均显示正常；当天新增第三方接口并处理7771条数据后，出现对象遗漏、责任不明或记录无法对应的情况。工作人员依据“工具报告风险，但人工核查后确认不成立”重新核查，才找到未被原流程覆盖的环节。这个实例说明：工具误报需要在真实业务变化和边界条件下接受验证。
18 工具漏报
概念解释：工具未发现实际存在的风险。
主要对应的问题：在订单系统的实际工作中，怎样确认“工具漏报”已经做到“工具未发现实际存在的风险”，并能用配置、日志、文件或测试结果证明？
特殊异常情况：新增第三方接口后，工具漏报遗漏3个关键环节
2026年10月23日，一家企业在订单系统中执行工具漏报。常规抽查的20条记录均显示正常；当天新增第三方接口并处理7808条数据后，出现对象遗漏、责任不明或记录无法对应的情况。工作人员依据“工具未发现实际存在的风险”重新核查，才找到未被原流程覆盖的环节。这个实例说明：工具漏报需要在真实业务变化和边界条件下接受验证。
19 人工复核
概念解释：结合业务、版本、配置、日志和样本确认工具结果。
主要对应的问题：在订单系统的实际工作中，怎样确认“人工复核”已经做到“结合业务、版本、配置、日志和样本确认工具结果”，并能用配置、日志、文件或测试结果证明？
特殊异常情况：新增第三方接口后，人工复核遗漏4个关键环节
2026年10月24日，一家企业在订单系统中执行人工复核。常规抽查的20条记录均显示正常；当天新增第三方接口并处理7845条数据后，出现对象遗漏、责任不明或记录无法对应的情况。工作人员依据“结合业务、版本、配置、日志和样本确认工具结果”重新核查，才找到未被原流程覆盖的环节。这个实例说明：人工复核需要在真实业务变化和边界条件下接受验证。