职业认证在线考试防作弊测试实战：从身份验证到纵深防御

在线考试系统这几年在职业认证领域用得越来越普遍大大小小的资格证考试、企业内部晋升考核、继续教育结业测评都开始从线下考场搬到线上。系统本身不稀奇真正让技术团队和主办方头疼的是防作弊。线下考试有监考老师盯着线上考试隔着屏幕怎么保证坐在电脑前答题的人确实是考生本人怎么防止他一边考试一边查资料、问别人这才是在线考试系统能不能被信任的核心问题。我这次接到的项目就是针对一套用于职业认证场景的在线考试系统做防作弊专项测试。系统本身是现成的功能很完整有摄像头监控、屏幕录制、切屏检测、异常行为告警这一整套东西但到底能不能防得住真实作弊哪些环节会被绕过哪些功能会误伤正常考生这些都不能拍脑袋必须用测试数据说话。这篇文章就把整个防作弊测试的过程、方法、踩过的坑完整记录下来给正在做同类系统测试的朋友一个参考。1. 测试目标与防作弊体系拆解1.1 职业认证场景对防作弊的特殊要求职业认证考试和普通的学校在线考试有个很大的区别证书的含金量直接决定了防作弊的强度。学校里的期末考作弊被抓可能就是挂科补考但职业认证考试通过之后是要拿证执业上岗的一旦混过去一个不合格的人后续的责任风险会落到认证机构头上。所以这类考试在防作弊设计上通常比一般在线考试严格得多而且考生群体非常复杂从二十出头刚毕业的年轻人到四五十岁的老技术员都有意味着防作弊功能不能设计得太极端否则会把大量正常考生误杀在登录环节。另一个特点是考试的严肃性。线下考试有监考老师、有考场纪律、有身份证核验线上考试要把这些环节全部数字化。我在测试之前先梳理了这套系统的防作弊能力矩阵发现它基本分成四层登录身份核验层人脸识别、身份证OCR比对、活体检测考试过程监控层摄像头实时画面、屏幕录制、切屏检测行为分析层答题速度异常、鼠标轨迹异常、离开页面频率数据防作弊层试题乱序、选项乱序、防复制粘贴、IP异常检测测试不能一上来就到处乱点而是要先明确这套系统声称具备哪些能力再逐项设计攻击和绕过实验。我拿到的这个系统功能上声称支持上述全部四层能力但声称归声称实际效果如何需要逐项验证。1.2 防作弊测试的核心目标与通过标准防作弊测试的目标不是“把系统打挂”而是回答几个具体问题这个系统能否有效识别出不同类型的作弊行为误报率有多高被绕过之后有没有兜底方案整个测试我给定了三条核心通过标准标准一针对每种已声明支持的作弊方式模拟攻击后告警触发率应达到100%不能存在“无声通过”的情况。标准二正常考生在合规操作下误报率不能超过理论允许值。职业认证场景下正常的低头思考、揉眼睛、短暂离开视线等动作不能被判定为作弊。标准三系统在识别到可疑行为后必须留下可审计的证据记录包括截图、时间轴、操作日志方便后续人工复核。后面所有的测试用例设计、执行、问题跟踪都是围绕这三条标准展开。有一点要先说明防作弊测试和普通功能测试最大的不同在于它的对抗性测试人员要站在作弊者的角度思考想办法钻空子。这个思维方式不转变过来测出来的结果基本都是“系统表现良好”这种没有价值的结论。2. 测试环境搭建与攻击工具准备2.1 构造多设备多浏览器测试矩阵在线考试系统的防作弊功能高度依赖浏览器环境和设备能力同一个切屏检测在Chrome上能触发在Firefox上可能就失效了人脸识别在Windows自带摄像头上工作正常换到虚拟摄像头环境里可能直接被骗过去。所以测试环境不能只拿一台电脑一个浏览器跑一遍就行必须构造一个覆盖常见场景的设备矩阵。我搭建的测试环境包括三类设备常规Windows笔记本两套分别装Chrome 120和Edge 119测试主流浏览器场景macOS设备一套Safari 17测试苹果系生态老旧Windows 7台式机一套预装Chrome 109模拟考生用旧电脑的极端情况网络环境上我准备了正常家庭宽带、企业办公网络、手机热点三种接入方式。为什么这么安排因为职业认证考试很多考生是在单位或者网吧参加的这些网络环境的IP特征和普通家庭宽带差异很大如果系统有IP异常检测我必须知道它到底以什么为基准判断“正常”。测试工具方面用到了这么几个Selenium WebDriver用来做浏览器自动化操作模拟各种异常行为虚拟摄像头软件测试人脸识别活体检测的可靠性Fiddler抓取考试过程中的网络请求分析接口层的防作弊逻辑多开浏览器环境和隐身窗口测试同设备多账号登录的拦截能力2.2 关键测试工具的原理解读这里单独说一下Selenium和虚拟摄像头这两个工具因为在防作弊测试里它们的使用方式跟普通自动化测试完全不同。用Selenium做防作弊测试不只是让它自动点按钮填答案而是要利用它构造“非人类操作”的特征。正常考生答题时鼠标轨迹是曲线停留时间是随机的键盘输入是有节奏的。Selenium的操作则非常机械坐标跳变快输入速度快且均匀。如果系统的行为分析模块足够聪明它其实应该能识别出这种异常特征。所以在测试用例里我设计了“Selenium极速答题”这个场景专门测试系统能不能区分“像机器的正常考生”和“像机器的作弊工具”。虚拟摄像头则是测试活体检测的利器。现在很多在线考试系统宣称用活体检测防止照片冒充但不同厂商的实现方式差异很大。有的会要求考生眨眼、张嘴、转头有的只是简单判断画面里有没有人脸。我准备了三类攻击素材来测试静态照片考生照片直接打印出来对着摄像头屏幕播放视频用另一块屏幕播放一段预先录好的点头眨眼视频动态虚拟摄像头输出用软件实时把人脸照片和视频流混合后输出这三类素材基本覆盖了低中高三个攻击等级。测试的时候心里要有个预期如果系统连静态照片都防不住那这个活体检测基本就是摆设项目直接不通过后续的复杂攻击也不用再测了。3. 核心防作弊场景用例设计与执行3.1 登录环节身份核验与活体检测攻击测试登录环节是整个防作弊体系的第一道门也是最关键的一道门。如果这里的身份核验被绕过后面所有监控手段都白搭因为系统根本不知道坐在屏幕前的人到底是谁。我设计的第一组用例是静态照片攻击。把一张清晰的考生正面照打印出来正对摄像头同时用软件给照片加了一点抖动效果模拟人在轻微移动的假象。然后启动人脸识别登录流程。系统要求考生完成眨眼、张嘴、左右转头三个动作静态照片无法完成这些动作所以最终被成功拦截提示“活体检测未通过”。这一关通过说明这个系统没有停留在最原始的人脸比对层面。第二组用例升级为视频回放攻击。用手机录制一段真人在做眨眼、张嘴、转头动作的视频然后对准摄像头播放。这个攻击方式比照片复杂得多因为它提供了完整的动态行为序列。结果系统短暂卡顿了几秒最终依然判定失败。我看了后台日志发现它应该是对画面做了深度特征分析能够识别屏幕反射的摩尔纹和视频播放的帧率特征而真人现场的视频流不存在这些特征。这说明系统用的是有深度的活体检测而不是简单判断“画面里有没有人在动”。第三组测试针对戴口罩和光线不足两个场景。因为职业认证考试的考生分布在全国各地有些地方室内光线很差有些考生出于习惯会戴口罩。我模拟了口罩遮挡下半张脸的情况人脸识别直接失败无法进入考试。又模拟了光线昏暗环境下的人脸识别同样失败率很高。这两组用例暴露了一个问题系统的防作弊能力强但对变化环境的适应性不够。后来对比了一下资料发现主流的活体检测方案在口罩场景下普遍需要配合“局部特征比对”或者“佩戴口罩检测后放行”的策略这应该是产品后续优化的方向。3.2 考试中切屏检测与页面焦点监控测试切屏检测是几乎所有的在线考试系统都会声明支持的功能但实现方式上有本质差别。低端方案是监听浏览器的visibilitychange事件和window.blur事件只要浏览器页面失去焦点就记录一次切屏。高端方案会结合操作系统级别的焦点监听和摄像头画面联动判断考生究竟是切出去了还是只是弹出了系统对话框。我对这套系统的切屏检测做了四组测试。第一组是传统的AltTab切换窗口。这是我用Selenium模拟的在考试进行中切到另一个浏览器窗口去查询资料再切回来。系统在切出后约3秒弹出了全屏警示遮罩提示“检测到切屏行为本次行为将被记录”。后台日志还能看到具体的时间点和切屏时长。这个功能表现是合格的。第二组是WinD快速回到桌面再点回考试页面。这组操作触发的判定结果和AltTab一样被记录为切屏。这符合预期因为考试期间回到桌面本身就不合理。第三组是点击系统弹窗。考试中途Windows弹出一个系统更新提示框考生点了“稍后提醒”这个操作导致考试页面短暂失焦。系统把这个也判成了切屏然后考试平台弹出了警告提示。这一条是误报的重灾区很多正常考生因为系统弹窗被误判后面会专门展开分析。第四组是双屏扩展场景。现在用双屏的考生不少一块屏幕答题另一块屏幕开着资料。我把浏览器窗口拖动到跨越两个屏幕的位置然后鼠标在副屏区域点击。系统没有触发切屏告警因为浏览器窗口始终处于焦点状态。这算不上系统的漏洞但值得在防作弊策略说明中提醒主办方注意。3.3 答题过程异常行为分析测试异常行为分析是防作弊体系里最依赖算法的一层也是测试结果最难用“对错”来衡量的部分。我设计了几类典型的作弊行为特征和正常行为特征进行对比测试。第一类是极速交卷。用Selenium脚本控制答题页面每道题只停留2秒就切到下一题整套30道题在大概70秒内全部答完提交。系统在提交后直接触发了“答题速度异常”告警把该场考试标记为人工复核对象。这个结果符合预期因为正常考生不可能用这个速度完成30道题哪怕全部蒙答案也需要阅读题面的时间。第二类是“先查后答”的典型模式。切换出去3分钟查资料回到考试页面后短时间内连续作答10道题。系统没有实时弹窗但后台日志记录了切屏行为并在试卷提交后生成了“高风险”标记需要人工审核。这里要说一下很多考生以为切屏回来没弹窗就没事实际上系统已经把整个过程记录下来了只是不在当时声张。第三类是正常考生的行为模拟。按正常速度答题中间偶尔停下来思考抬头看摄像头方向偶尔用手指敲桌子。整个考试结束后系统没有给出任何异常标记误报率降到了比较理想的水平。第四类比较刁钻模拟“屏幕边缘外置设备”方式。我在屏幕边缘摆放了一个手机摄像头画面刚好可以拍到它人正常答题但眼睛会偶尔瞟向手机。后端行为分析模块无法识别这个行为因为画面分析逻辑大概率聚焦在“人脸是否在画面中”和“是否有第二张人脸入镜”不会对眼球的移动轨迹做判断。这意味着防作弊系统并非无懈可击需要结合现场管理和策略安排来做补充。3.4 数据层防作弊试卷随机性与接口安全测试很多在线考试系统的防作弊方案重点关注页面交互层的功能却忽略了一个更基本的层面——数据接口本身是否安全。如果试题接口能被遍历选项排列固定不变那么考生只需写一个脚本在开考后把所有试题和答案一次性拉取出来配合外部搜索引擎就能轻松作弊。这类攻击完全不需要绕过人脸识别也不需要切屏但它对考试公平性的破坏是致命的。我针对试题接口做了一轮专门的测试使用Fiddler抓取考试开始前的请求查看试题是否在进入考试页面的瞬间全部下发到浏览器端测试试题接口在未登录状态下是否可以直接访问测试同一账号多次调用接口是否能够获取不同题目分析试题和选项的排列规律验证是否为随机打乱实测下来这套系统在数据层的表现相当不错。试题虽然一次性下发到浏览器端但接口做了签名校验直接改参数请求会返回401。同一个考生账号在不同考试场次拿到的题目顺序是不同的同一道题的ABCD选项排列也是乱序的。进一步验证了单个考生在左右相邻座位使用相同卷面但答案选项顺序不同的场景确实会被打散。唯一有个小问题接口返回的数据包没有加密抓包工具能看到明文数据。这意味着懂技术的人可以通过在控制台执行脚本读取页面内存里的题目数据绕开界面直接调接口解析。这不算在线考试系统的核心漏洞因为考试服务端肯定不希望考生逆向你的前端代码但加密传输仍是值得后续加强的方向。3.5 罚时策略与告警策略测试防作弊不只是“识别”还要有策略。识别到作弊行为之后怎么处置不同处置策略对考试公平性的影响差异很大。这套系统的策略分为三层实时弹窗警告、后台标记异常、强制交卷。我针对每层策略设计了验证用例。弹窗警告策略的触发条件是单次切屏超过3秒或者累计切屏达到3次。我用自动化脚本模拟了“切屏2秒后马上回来”的操作系统没有弹窗但后台记录了行为。又模拟了“切屏4秒后回来”系统弹出了警告浮层提示行为已被记录。这说明系统的触发逻辑里既有时间阈值也有次数阈值不是一有切屏就反应过激。强制交卷策略的触发条件是考试期间累计切屏超过8次或者被判定为“严重作弊行为”比如识别到画面中出现第二张人脸。这个策略我认为设计得比较合理给了考生一定的容错空间同时对严重行为零容忍。在测试时我故意在摄像头前放了一张室友的照片让画面里出现第二个人脸。系统在约5秒后识别到并弹出了“请确保考试环境内无其他人员”的警告但没有立即强制交卷。后台标记为“疑似作弊需人工审核”。这个处置思路是对的——单人考试场景突然出现第二张人脸确实有可能是路过或者环境干扰直接强制交卷容易误杀先标记再人工复核更稳妥。4. 问题分析与排查技巧实录4.1 人脸识别误杀率过高的定位与调优整个测试过程中我最头疼的问题不是作弊行为识别不出来而是正常考生被误杀。人脸识别模块在光线不足的时候识别率骤降我拿到的测试账号有一半在傍晚室内光线下无法通过人脸验证。一开始我怀疑是摄像头分辨率的问题后来用工具抓取识别过程的日志发现系统对人脸图像的亮度值有一个硬性阈值低于这个阈值直接判定“图像质量不合格”根本不会进入人脸比对环节。这个设计本身没有错低质量图像确实不适合做人脸比对。但在实际考试场景里要求每个考生都坐在光线明亮的环境里是不现实的。而且职业认证考试的考生里有很多是晚上下班后在家考试顶灯一开人脸背光的情况非常普遍。定位到原因后我和开发团队确认了调整方向降低亮度阈值加入“亮度不足时提示考生调整光线”的引导文案同时增加一个“仍然继续尝试”的按钮让考生多试几次。调整之后误杀率明显下降。这里想多说一句测试时拿到的“误杀率”和真实考试中的“误杀率”可能差异很大。因为测试环境是我们可控的光线不好我可以开灯但真实考生就未必会主动调整。所以在设计这类用例时一定要把“环境不太理想”当作默认场景而不是异常场景。4.2 切屏检测的系统弹窗误报问题切屏误报是这次测试里暴露得最明显的问题。Windows系统更新通知、杀毒软件弹窗、输入法候选框弹出、甚至QQ消息通知任何让浏览器窗口短暂失去焦点的操作都会被在线考试系统记录为切屏。测试期间我模拟了一个很常见的场景考试进行到一半Windows安全中心弹出了一个病毒库更新提醒。考生下意识点了“确定”然后考试页面就被记录了一次切屏。这种误报如果频繁出现会严重影响考生的心态——考到一半看到“你已切出考试页面”的红色警告就算没作弊心里也发慌。针对这个问题后续的测试方案里我特别增加了一个“系统级弹窗”的用例组目的是整理出一份常见系统弹窗清单反馈给产品团队。技术上的解决方案是把焦点丢失事件和键盘鼠标事件结合判断如果焦点丢失后用户在短时间内返回且没有键盘和鼠标在另一个窗口内操作的记录就不触发切屏告警。但从实际项目推进来看这个优化需要改动切屏检测的核心逻辑周期比较长短期内的应急方案是在考试客户端内加入“专注模式”屏蔽系统通知和弹窗。4.3 浏览器崩溃后恢复考试的超时问题在线考试系统的稳定性问题在防作弊测试中同样不能忽视。我测试时模拟了浏览器崩溃和电脑蓝屏两个极端场景。正常做法是考生重新打开浏览器、重新登录系统、恢复未完成的考试。但这个系统在恢复流程上卡了一个bug——重新登录后无法恢复到崩溃前正在作答的那道题而是回到了考试首页。如果考试中断时间超过了系统设置的“超时自动交卷”阈值考生基本上就失去了继续考试的资格。这个问题在防作弊测试里很容易被忽略因为它不属于“作弊识别”的范畴。但它对考试公平性的影响非常大一个没有作弊的正常考生仅仅因为电脑死机就丢掉了考试资格这比作弊识别失效还严重。测试中我踩了这个坑后专门写了一个“故障恢复”用例集覆盖浏览器崩溃、电脑重启、断网重连、断电重启四个场景验证试卷进度是否保留、答题时间如何计算、恢复流程是否顺畅。现在很多在线考试系统采购方在技术验收时已经把这类故障恢复测试作为必检项我建议做同类项目的朋友一定要把它纳入计划。4.4 多账号同设备与IP异常检测多账号同设备在真实考试中通常意味着“一个人帮另一个人考”是典型的代考作弊场景。我测试了同一台电脑先后登录两个不同考生账号参加两场考试系统没有给出任何拦截或告警。这其实是个隐患但也比较难防——因为同一台电脑完全有可能是两个考生轮流使用同一台设备必须在不同的时间段完成各自的考试这种场景本身是合理的。系统的处理方式是在考试须知里明确声明“同一设备短时间内不得登录多个账号”如果两台考试间隔非常短就触发人工复核。IP异常检测的情况也类似。我在测试中发现如果考生的IP在一天内跨越了多个城市系统会给他打上“异地登录”的标签。但实际场景中考生的网络会经过运营商的中继节点有时会出现IP归属地偏离的情况。我遇到过一个人使用手机热点考试IP归属地在另一个城市直接被系统判为异地。这类误报对正常考生影响很大处理方式只能是人工复核时核对设备登录记录确认是本人操作后予以放行。5. 防作弊测试的几个核心观察整个测试做下来我有一个很直观的感受在线考试系统的防作弊能力从来不是靠某一个单点功能成就的而是靠多层策略叠加形成纵深防御体系。单看人脸识别它能防住照片但防不住双胞胎单看切屏检测它能防住AltTab但防不住手机。但只要这些功能组合在一起再加上人工复核环节作弊的成本就会被拉得很高。绝大多数非专业作弊者调用照片和切屏操作在登录环节就会暴露。愿意花大力气用专业手段作弊的人是极少数纵深防御体系应对这种情况基本够用。从测试设计的角度来说防作弊测试和普通功能测试最大的区别在于你要站在作弊者的角度去思考问题而不是站在“验证功能正常”的角度。普通功能测试是“我点切屏它有没有记录”防作弊测试是“我用什么方式切屏它记录不到”。这两种思维方式看起来差不多实际执行起来的深度完全不同。建议做防作弊测试的同学在用例设计阶段直接列一张作弊方式清单从低级到高级逐项排然后针对每一个方式设计对应的测试数据和操作步骤测试的完整性会好很多。在职业认证这个特定的考试场景里还有一点必须纳入测试范围——考试的公证性和追溯性。作弊行为被识别后试卷必须能被标记、冻结、送入人工复核流程异常行为记录必须保留完整的截图和时间线方便后续查阅。这些功能不直接产生“拦截”效果但它是整个防作弊体系的最后一道保险也是认证机构背书时的底气所在。测试这类功能时需要验证证据记录的完整性确认是否包含操作时间、行为类型、页面截图三个必要元素同时确认主办方后台可以按场次批量筛选。我测试的这套系统证据链记录基本完整后台还能回放考生在考试过程中的所有切屏记录这一点值得点赞。最后分享一个实操层面的小建议做防作弊测试千万别只依赖自动化工具。有些行为是用代码模拟不出来的比如摄像头画面中出现的自然光线变化又比如考生因为紧张频繁抬头张望这些和环境高度耦合的真实场景只有人工手动测试才能覆盖到。自动化工具适合用来做高重复度的回归验证测试的深度还是要靠人去设计、去感知、去判断。在线考试系统的防作弊测试是个典型的“对抗性”测试测试人员越懂作弊手法就越能帮系统补上真正的漏洞。