★ FEATURED ARTICLE 1. 为什么高权限Agent的验收不能一把梭做过测试的人都有一个共识功能测试好写权限测试难缠。尤其是当被测对象是一个拥有高权限的Agent——它能读文件、发请求、调接口、执行命令——验收这件事就从点按钮看结果变成了拆炸弹。我参与过几次这类高权限Agent的验收工作最开始也走过弯路。那时候的思路很朴素给它一个任务看它能不能完成能完成就算通过。结果呢上线之后问题一个接一个有的Agent在测试环境跑得好好的到了生产环境因为网络策略不同直接卡死有的Agent拿着测试用的临时凭据去访问了不该访问的资源还有的Agent在遇到异常时不会停一直重试直到把下游服务打挂。这些问题的根子不在功能本身而在于验收时没有把授权、网络、凭据、停止条件这四个维度拆开来看。它们混在一起的时候你看到的是Agent能干活拆开之后你才能看到Agent在什么条件下能干活、在什么条件下会出事。这篇内容就是把我踩过的坑和后来总结出来的验收方法整理出来。适合正在做Agent类产品验收的测试同学、负责Agent上线的开发同学以及需要评估Agent风险的安全同学。不管你是刚接触这类项目还是已经做过几轮验收应该都能从中找到一些可以直接用的思路。核心就一句话高权限Agent的验收不是测它能不能完成任务而是测它在各种边界条件下会不会失控。而要做到这一点必须先把四个维度拆开逐个击破最后再组合验证。2. 授权维度Agent到底能碰什么不能碰什么2.1 授权边界的定义为什么总是模糊的授权这件事说起来简单——给Agent划定一个它能操作的范围。但实际操作中这个范围往往定义得非常模糊。我见过最常见的情况是开发同学在配置Agent权限时直接给了一个够用就好的权限集。什么叫够用就好就是Agent能跑通主流程就行。至于这个权限集里有没有多余的权限、有没有越界的可能没人深究。测试同学拿到手也不知道该测什么边界因为边界本身就没定义清楚。这里的问题在于授权边界的定义不应该由开发同学单独完成而应该是开发、测试、安全三方一起对齐的结果。开发知道Agent需要什么权限才能工作测试知道怎么验证权限是否被正确使用安全知道哪些权限组合会带来风险。三方对齐之后才能产出一份可测试的授权边界清单。具体怎么做我通常建议用一个简单的表格来梳理操作类型所需权限是否必须风险等级验证方式读取配置文件文件读权限是低正常读取成功越界读取失败写入日志文件写权限是低正常写入成功越界写入失败调用内部API接口调用权限是中授权接口调用成功未授权接口返回拒绝访问数据库数据库读权限视场景高授权表可读未授权表返回空或报错执行系统命令命令执行权限否极高默认应拒绝除非明确授权这张表的价值在于它把Agent能做什么变成了Agent在什么条件下能做什么每一个操作都有对应的权限要求和验证方式。测试同学拿着这张表就知道该测哪些正向场景、哪些反向场景。2.2 最小权限原则在Agent场景下的落地难点最小权限原则大家都听过——只给必要的权限不多给。但在Agent场景下这个原则的落地有几个难点。第一个难点是Agent的行为具有不确定性。传统的软件程序代码写死了它要做什么权限需求是确定的。但Agent不一样它可能会根据任务动态决定调用哪些工具、访问哪些资源。你今天给它一个读文件的权限它可能明天就尝试去读一个你没想到的文件。这种不确定性让最小权限的最小很难界定。第二个难点是权限的继承和传递。Agent调用的工具可能还有自己的权限体系Agent的权限和工具的权限叠加在一起实际能做的事情可能比预期多。比如Agent本身只有读权限但它调用的某个工具内部有写权限那Agent通过这个工具就间接获得了写能力。针对这两个难点我的经验是对Agent的行为做枚举和分类。不要试图穷举所有可能的操作而是把Agent的行为分成几大类读、写、执行、网络请求等每一类设定一个权限上限。Agent可以在上限内自由行动但不能突破上限。对工具链做权限穿透测试。不要只测Agent本身的权限还要测Agent通过工具间接获得的权限。具体做法是构造一个场景让Agent调用某个工具去执行一个它本身没有权限的操作看系统是否会正确拦截。注意权限穿透测试是最容易被忽略的环节。很多团队只测了Agent的直接权限没测间接权限结果上线后出现了Agent本身没权限但通过工具绕过了限制的问题。2.3 授权验收的实操清单基于上面的分析我整理了一份授权维度的验收清单可以直接拿去用正向验证Agent在授权范围内的操作是否全部成功。逐条对照授权边界清单确保没有遗漏。反向验证Agent在授权范围外的操作是否全部被拒绝。重点测那些看起来像在范围内但实际越界的操作比如路径穿越、参数注入等。权限穿透验证Agent通过工具链间接执行的操作是否受到同等限制。权限变更验证当权限配置发生变化时Agent的行为是否随之改变。比如撤销某个权限后Agent是否立即无法执行对应操作。并发场景验证多个Agent同时运行时权限是否互相隔离是否存在一个Agent的权限被另一个Agent借用的情况。这五项做完授权维度的验收基本就覆盖了。但要注意授权验收不是一次性的每次Agent的能力升级或权限配置调整后都需要重新跑一遍。3. 网络维度Agent的通信边界在哪里3.1 网络策略的差异为什么总在验收时暴露网络问题有一个特点它在测试环境往往不出现一到生产环境就爆发。原因很简单——测试环境的网络策略通常比生产环境宽松。我遇到过好几次这样的情况Agent在测试环境能正常调用某个外部服务验收通过。上线后生产环境的网络策略不允许访问那个服务Agent直接超时。更麻烦的是Agent没有正确处理超时一直重试把上游服务拖垮了。这个问题的根源在于验收时没有把网络策略当作一个独立的测试维度。大家默认网络是通的但实际上网络通不通、能通到哪里、通了之后能做什么都是需要验证的。网络维度的验收核心要回答三个问题Agent能访问哪些网络资源白名单Agent不能访问哪些网络资源黑名单当网络访问失败时Agent的行为是什么降级策略3.2 白名单、黑名单与DNS解析的验收要点白名单和黑名单是网络策略的基础。验收时不能只看配置文件里写了什么要实际验证Agent的行为是否符合预期。白名单验收构造Agent访问白名单内资源的场景确认访问成功。同时要注意白名单的粒度是否足够细。比如白名单里写的是某个域名但Agent是否能访问该域名下的所有路径是否支持通配符这些细节都要验证。黑名单验收构造Agent访问黑名单内资源的场景确认访问被拒绝。这里有一个容易忽略的点黑名单的优先级是否高于白名单如果某个资源同时在白名单和黑名单里Agent的行为是什么这个边界情况必须测。DNS解析验收Agent在解析域名时是否使用了预期的DNS服务器是否存在DNS劫持或缓存污染的风险验收时可以通过构造不同的DNS响应来测试Agent的行为。比如让DNS返回一个错误的IP看Agent是否会连接到错误的地址。下面是一个网络验收的检查表验收项验证方法预期结果备注白名单内资源访问构造访问请求成功注意路径和参数黑名单内资源访问构造访问请求拒绝确认拒绝方式超时/报错白名单黑名单重叠构造重叠资源按优先级处理明确优先级规则DNS解析正确性模拟DNS响应使用预期IP注意缓存影响网络超时处理模拟超时按降级策略执行确认不无限重试网络断开处理断开网络按降级策略执行确认不崩溃3.3 网络异常时Agent的降级行为怎么测网络异常是常态不是异常。Agent在网络不通时的行为往往比网络通的时候更能反映它的健壮性。我通常会用以下几种方式模拟网络异常完全断网直接断开Agent所在环境的网络观察Agent的行为。它是否会立即报错是否会重试重试几次重试间隔是多少高延迟通过网络工具注入延迟观察Agent是否设置了合理的超时时间。超时时间太短会导致正常请求被误判为失败太长会导致Agent长时间挂起。丢包模拟一定比例的丢包观察Agent是否能正确处理部分失败的情况。DNS故障让DNS解析失败观察Agent是否有备用解析方案或降级策略。这里有一个实操心得测试网络异常时一定要同时监控Agent的资源消耗。我见过一个Agent在网络不通时疯狂重试CPU直接跑满把整个环境都拖慢了。这种问题在功能测试中根本发现不了只有专门测网络异常才会暴露。提示网络异常的降级策略应该在Agent的设计文档中明确写出来验收时逐条对照。如果设计文档里没写那本身就是个问题应该先补文档再验收。4. 凭据维度Agent拿什么身份干活4.1 凭据的生命周期管理为什么容易失控凭据是Agent访问外部资源的钥匙。这把钥匙怎么发、怎么用、怎么回收每一个环节都可能出问题。我见过最离谱的情况是Agent的凭据被硬编码在配置文件里而且这个配置文件被提交到了代码仓库。任何能访问仓库的人都能拿到凭据相当于Agent的身份被公开了。凭据管理容易失控主要有几个原因凭据的创建和分发没有统一流程。开发同学为了方便直接手动创建凭据手动配置到Agent里。没有审批没有记录没有回收。凭据的权限过大。为了避免麻烦直接给了一个万能凭据什么都能访问。一旦泄露影响范围极大。凭据的轮换没有自动化。凭据长期不换或者换了之后没有同步更新到Agent导致Agent突然无法工作。4.2 凭据泄露、过期、权限过大三种场景的验收方法凭据维度的验收核心是模拟三种异常场景看Agent和系统如何应对。场景一凭据泄露。模拟凭据被未授权的第三方获取看系统是否能检测到异常使用。比如同一个凭据在短时间内从不同地理位置发起请求系统是否有告警凭据泄露后是否有快速吊销的机制场景二凭据过期。模拟凭据过期看Agent是否能正确处理。它是直接报错还是有自动续期机制续期失败时是否有降级方案这里要注意凭据过期的时间点最好在验收时人为调整不要等自然过期。场景三凭据权限过大。模拟Agent使用一个权限过大的凭据看它是否会执行超出预期的操作。比如给Agent一个只读凭据但它尝试执行写操作系统是否拒绝如果拒绝拒绝的方式是什么下面是一个凭据验收的对照表场景模拟方法预期行为实际行为是否通过凭据泄露异地使用同一凭据告警并阻断凭据过期调整过期时间自动续期或降级凭据权限过大使用高权限凭据执行低权限操作按最小权限执行凭据轮换触发轮换流程Agent无感知切换凭据吊销吊销凭据Agent立即停止工作4.3 凭据轮换与Agent无感切换的验证凭据轮换是一个容易被忽略的验收点。很多团队在验收时只关注凭据能不能用不关注凭据换了之后Agent还能不能用。我建议在验收时专门安排一轮凭据轮换测试让Agent正常运行确认它能正常访问资源。触发凭据轮换流程生成新凭据并配置到Agent。观察Agent是否能在不重启、不中断的情况下切换到新凭据。确认旧凭据被正确吊销无法再使用。确认新凭据的权限与旧凭据一致没有多也没有少。这个过程中最容易出问题的是第3步。有些Agent在凭据更新后需要重启才能生效但设计文档里没写验收时也没测上线后轮换凭据导致Agent中断服务。注意凭据轮换的验收一定要在类生产环境下做。测试环境的凭据管理流程往往和生产不一样在测试环境通过不代表在生产环境也能通过。5. 停止条件Agent什么时候必须停下来5.1 没有停止条件的Agent有多危险一个没有停止条件的Agent就像一个没有刹车的车。平时开得再稳一旦遇到紧急情况就是灾难。我听过一个真实的案例细节做了模糊处理某个Agent在执行任务时遇到了一个它无法处理的错误但它没有停止而是不断重试。每次重试都会产生新的请求这些请求又触发了更多的错误形成了雪崩效应。最后不仅Agent本身挂了还拖垮了下游的好几个服务。这个案例的核心问题就是Agent没有定义明确的停止条件。它不知道什么情况下应该放弃什么情况下应该继续。它只会一直试直到把资源耗尽。停止条件应该包括但不限于以下几种重试次数上限同一个操作重试超过N次后停止并报错。执行时间上限Agent执行任务的总时间超过阈值后强制停止。资源消耗上限Agent消耗的CPU、内存、网络带宽超过阈值后强制停止。错误率上限Agent执行的操作中错误比例超过阈值后停止。外部信号收到停止信号后Agent应该在合理时间内停止。5.2 超时、重试、熔断三种停止机制的验收差异超时、重试、熔断是三种常见的停止机制但它们的验收方法不一样。超时验收重点是验证超时时间是否合理。太短会导致正常操作被误杀太长会导致Agent长时间挂起。验收时可以通过注入延迟来测试观察Agent是否在预期时间内超时。同时要验证超时后的行为——是直接报错还是走降级逻辑。重试验收重点是验证重试策略是否符合预期。重试次数、重试间隔、重试条件每一项都要验证。特别要注意的是重试是否会导致重复操作。比如Agent重试一个写操作是否会导致数据被写两次这个在验收时必须覆盖。熔断验收重点是验证熔断的触发条件和恢复条件。当错误率达到阈值时熔断是否及时触发熔断后Agent是否停止了对下游的请求熔断恢复后Agent是否能正常恢复工作这些都需要构造场景来验证。下面是一个停止条件验收的对照表停止机制验收重点模拟方法预期行为超时超时时间合理性注入延迟在阈值内超时并降级重试重试策略正确性模拟失败按策略重试不重复操作熔断触发和恢复条件模拟高错误率及时熔断恢复后正常工作资源限制资源阈值有效性模拟高消耗达到阈值后停止外部停止停止信号响应速度发送停止信号在合理时间内停止5.3 停止后的状态清理与恢复验证Agent停止之后事情还没完。停止后的状态清理和恢复同样是验收的重点。我见过一些Agent停止之后留下了大量的临时文件、未关闭的连接、未释放的锁。这些残留状态在下次启动时会导致各种奇怪的问题。比如临时文件占满了磁盘未关闭的连接耗尽了连接池未释放的锁导致其他Agent无法工作。验收时需要检查以下几个方面临时资源是否被清理Agent停止后它创建的临时文件、临时目录是否被删除。连接是否被关闭Agent打开的网络连接、数据库连接是否被正确关闭。锁是否被释放Agent持有的锁是否被释放其他Agent是否能正常获取。状态是否可恢复Agent重新启动后是否能从上次停止的状态恢复还是需要从头开始。日志是否完整Agent停止时是否记录了足够的日志便于事后分析。提示停止后的状态清理最好在验收时专门安排一轮测试。让Agent执行一个会产生大量临时资源的任务然后中途停止检查资源是否被正确清理。这个测试往往能发现一些隐藏的资源泄漏问题。6. 四个维度组合验证从单点通过到整体可信6.1 为什么要做组合场景而不是单维度验收单维度验收通过不代表组合场景也能通过。四个维度之间是相互影响的单独测每个维度都正常组合在一起可能就出问题。举个例子授权维度测了Agent不能访问未授权的资源网络维度测了Agent不能访问黑名单地址凭据维度测了Agent使用最小权限凭据。单独看都没问题。但组合起来如果Agent用一个低权限凭据去访问一个白名单内的资源但该资源需要更高权限Agent会怎么处理是报错还是尝试用其他方式绕过这就是组合场景要验证的。组合验证的核心思路是构造那些需要同时考虑多个维度的场景观察Agent的行为是否符合预期。这些场景往往是最接近真实使用情况的也是最容易暴露问题的。6.2 典型组合场景的构造方法我通常会构造以下几类组合场景场景一低权限凭据 白名单资源 超时停止。Agent使用一个只有部分权限的凭据去访问一个白名单内的资源。该资源的部分操作需要更高权限。观察Agent是否能正确识别权限不足并在超时后停止而不是无限重试。场景二高权限凭据 黑名单资源 熔断。Agent使用一个高权限凭据尝试访问一个黑名单内的资源。观察Agent是否被正确拦截拦截后是否触发熔断熔断后是否停止对下游的请求。场景三凭据过期 网络延迟 重试。Agent的凭据在任务执行过程中过期同时网络出现延迟。观察Agent是否能正确处理凭据过期是否会在重试时使用新凭据重试次数是否在限制内。场景四授权变更 网络中断 停止信号。在Agent执行任务过程中动态撤销某个权限同时断开网络然后发送停止信号。观察Agent是否能按优先级处理这些事件是否能在合理时间内停止。这些场景的构造需要一定的环境支持比如能够动态调整权限、模拟网络异常、发送停止信号。如果测试环境不支持可以考虑在类生产环境中进行但要注意风险控制。6.3 组合验收的通过标准怎么定组合验收的通过标准不能简单地用成功或失败来判断。因为组合场景下Agent的行为可能是多种多样的关键是要符合预期。我通常会用以下几个标准来判断行为可预测Agent在组合场景下的行为是否与设计文档中描述的一致。如果设计文档没写那本身就是一个需要补充的点。边界可控制Agent在组合场景下是否会在某个边界上失控。比如无限重试、资源耗尽、权限穿透等。状态可恢复组合场景结束后Agent是否能恢复到正常状态是否需要人工干预。日志可追溯组合场景下Agent是否记录了足够的日志便于事后分析问题原因。如果这四个标准都满足那组合验收就算通过。如果有任何一个不满足就需要定位问题并修复然后重新验收。7. 验收之后把一次性测试变成持续保障验收通过不是终点而是起点。高权限Agent上线之后环境会变、权限会变、网络会变、凭据会变。今天验收通过不代表明天还能正常工作。我的经验是把验收时的检查项转化为持续监控的指标。比如授权维度监控Agent的实际操作是否超出授权边界如果有立即告警。网络维度监控Agent的网络请求是否命中黑名单是否有异常的外联行为。凭据维度监控凭据的使用情况是否有异常使用、是否接近过期。停止条件监控Agent的重试次数、执行时间、资源消耗是否接近阈值。这些监控指标不需要一开始就全部上线可以优先覆盖风险最高的维度。比如凭据泄露的风险最高那就先上凭据监控。等运行稳定了再逐步补充其他维度。另外每次Agent的能力升级或配置变更后都应该重新跑一遍核心验收项。不需要全量跑但授权、凭据、停止条件这三个维度的核心场景必须覆盖。网络维度如果变更不涉及网络策略可以适当简化。我个人在实际操作中的体会是高权限Agent的验收最怕的不是测出问题而是没测出问题。测出问题说明验收有效没测出问题反而要警惕——是不是验收的覆盖面不够是不是有些边界没考虑到。保持这种警惕才能让Agent真正可控。
阅读完成 · 觉得有帮助？
