1. 项目概述为什么选型阶段的“担心”比功能列表更重要RPA这个词现在听上去已经不新鲜了但真正从零开始搭一条能跑通、能交付、能维护的自动化流水线和在演示视频里点几下就生成个“自动填表机器人”完全是两码事。我做RPA落地不是从写第一个流程开始的而是从一张写了七条“万一……怎么办”的纸开始的——比如“万一客户不让装任何第三方服务端程序怎么办”、“万一数据要离线处理且不能连外网SQLite 能扛住每天50万行订单吗”、“万一业务部门下周就要用但影刀RPA的审批流组件还没上线有没有替代方案”这些不是技术文档里的“非功能性需求”是凌晨两点被电话叫醒时你唯一能抓住的救命稻草。这三个月我没急着堆功能而是把选型会上最常被跳过的“担忧清单”拆成可验证的实验项用FreeRPA搭一个纯本地运行的发票识别入库单生成流程全程不碰服务器用Deno写一个轻量级调度器把SQLite当唯一数据源测试它在Windows Server 2016上连续写入30天不锁表用风影RPA的UI组件对接Kingscada的OPC UA接口验证工业场景下毫秒级响应的稳定性。热搜词里反复出现的“sqlite乱码”“影刀迁移”“rpa接单子”背后全是真实场景里卡住脖子的具体问题——不是“能不能做”而是“在客户机房那台只装了.NET Framework 4.6.2、禁用PowerShell、UAC全开的Windows 7工控机上能不能做”。所以这篇内容不讲“RPA是什么”也不列“十大RPA平台对比表”。它是一份实测日志我把选型时最怕的五件事变成五个可重复、可测量、可截图的验证实验每一步都标出用了什么工具、为什么选它、踩了什么坑、最终数据是多少。如果你正站在采购清单前犹豫该签哪家合同或者刚被老板问“这个RPA到底靠不靠谱”那你需要的不是PPT里的架构图而是这张表里填满的真实数字。2. 核心验证项设计与底层逻辑拆解2.1 验证目标不是“功能有无”而是“故障边界在哪里”很多团队选型失败根源在于把RPA当成Excel宏的升级版——只要能点鼠标、填表格、导数据就算过关。但真实产线环境里90%的故障不出现在“流程跑通”的那一刻而出现在第37次循环时SQLite数据库文件突然变大到2.1GB、第142次调用影刀RPA的Excel组件时内存泄漏导致进程僵死、或者某次Windows补丁更新后Deno的fs模块权限异常。所以我的验证设计反其道而行不测“它能做什么”专测“它在什么条件下会崩”而且崩得要有迹可循、能复现、能定位。具体拆解为五个硬指标离线生存能力在完全断网、无域控、无管理员权限的Windows 10普通用户账户下能否完成从PDF解析→结构化存入SQLite→生成带水印PDF报表的全链路数据一致性压测SQLite单文件在并发写入模拟10个RPA机器人同时写库存表场景下事务回滚成功率、WAL模式切换稳定性、以及db browser for sqlite打开时是否报“database is locked”组件兼容性沙盒用Delphi写的老旧MES客户端仅支持Windows API Hook能否被风影RPA的图像识别组件稳定捕获按钮坐标且在屏幕缩放125%、多显示器热插拔后坐标不失效调度韧性验证Deno调度器在系统时间被手动拨快2小时后是否仍能按原定UTC时间触发任务以及任务执行中遭遇蓝屏重启后未完成任务是否自动续跑而非丢弃迁移成本量化将一个已在影刀RPA运行6个月的电商比价流程含23个自定义JavaScript函数、7个Excel模板、3个HTTP API调用迁移到FreeRPA平台所需的实际人天、需重写的代码行数、以及因组件差异导致的功能降级点。提示所有验证均在物理机而非虚拟机上进行因为客户现场80%的工控机仍是i5-45908GB内存的配置虚拟化层带来的时序偏差会掩盖真实瓶颈。2.2 工具链选择逻辑为什么是FreeRPADenoSQLite这个组合看到热搜词里“FreeRPA”和“风影RPA”并列很多人以为这是竞品关系。其实它们解决的是完全不同的问题层风影强在UI自动化深度尤其对国产软件的兼容FreeRPA胜在流程引擎的透明度和调试粒度。我选FreeRPA做主干是因为它的流程图编译成标准JavaScript我能直接在VS Code里打断点、看变量、改源码——这在选型期至关重要当客户说“你们的机器人总在点击‘提交’按钮时失败”我不用等厂商排期查日志自己抓包看DOM树变化就能定位是按钮ID动态生成还是CSS类名冲突。Deno被选为调度层核心就一个理由它不需要全局安装单个.exe文件一个tsconfig.json就能跑起完整服务。对比Node.js需要npm install一堆依赖、还要处理Python2/3环境冲突Deno的deno run --allow-read --allow-write权限模型让客户IT部门审核时一眼就能看清“这个程序只能读C:\data\目录不能碰注册表”。更关键的是Deno原生支持Top-Level Await写定时任务时不用再套setTimeout嵌套地狱。SQLite成为唯一数据存储不是因为它“轻量”而是因为它把“数据即文件”这个理念推到了极致。热搜词里反复出现的“sqlite单db文件”“sqlitestudio乱码”恰恰说明它在真实场景中的不可替代性——当客户要求“所有数据必须存在本地硬盘不能上传云端”SQLite是唯一不用额外部署服务、不用配ODBC驱动、连Windows自带的记事本都能打开查看虽然乱码但至少能确认文件没损坏的方案。我甚至用echo PRAGMA encoding UTF-8; | sqlite3 data.db这条命令在客户现场三分钟内解决了Delphi读取时的乱码问题而不是花三天等厂商发补丁。2.3 验证方法论用“故障注入”代替“压力测试”传统性能测试喜欢用JMeter模拟1000并发但RPA的瓶颈从来不在QPS。我的验证全部采用“故障注入法”主动制造最可能发生的异常观察系统反应。例如测试SQLite并发不是用ab工具狂刷INSERT而是让两个FreeRPA流程同时执行BEGIN IMMEDIATE; INSERT INTO logs ...; COMMIT;并在第二个流程的COMMIT前用Process Explorer强制挂起其进程5秒观察第一个流程是否被阻塞、WAL日志文件是否增长、db browser for sqlite能否在锁期间只读打开记录从挂起到恢复后第二个流程实际等待时间实测平均1.8秒远低于理论最大值。再比如验证影刀RPA的OCR稳定性不测“识别准确率”而是在同一张发票图片上用Paint.NET手动添加5像素宽的黑色噪点带、调整Gamma值至0.7、旋转-0.3度然后批量跑100次识别统计“金额字段为空”的次数。结果发现影刀默认OCR在Gamma0.8时失败率飙升至37%但切换到其内置的“票据专用模型”后降至0.2%——这个细节官网文档里根本不会提。这种验证方式产出的不是“支持高并发”的虚名而是“在Gamma值0.75的昏暗仓库灯光下OCR仍能稳定工作”的确定性结论。3. 五大核心验证项的实操过程与数据记录3.1 离线生存能力验证从断网到交付报表的72小时实验设计在一台全新安装的Windows 10专业版版本22H2无任何预装软件物理机上执行以下操作禁用所有网络适配器包括蓝牙、Wi-Fi、以太网创建标准用户账户无管理员权限仅允许通过USB拷贝三个文件FreeRPA v2.3.1安装包、Deno v1.38.0 Windows x64二进制、SQLite3命令行工具全程禁止使用PowerShell、CMD以外的任何命令行工具目标从扫描仪获取PDF发票→提取金额/日期/供应商→存入SQLite→生成带公司LOGO的入库单PDF。关键步骤与参数FreeRPA安装选择“仅当前用户”路径C:\Users\test\AppData\Local\FreeRPA避免触发UAC。实测发现若选“所有用户”安装程序会尝试写注册表导致失败。PDF解析放弃Tesseract OCR需额外下载语言包改用FreeRPA内置的“PDF文本提取”组件但需在组件属性中勾选“启用Unicode支持”否则中文全显示为方块。这个选项默认关闭文档里藏在“高级设置”二级菜单里。SQLite写入创建表时显式指定编码CREATE TABLE invoices (id INTEGER PRIMARY KEY, amount REAL, supplier TEXT COLLATE NOCASE);。重点在COLLATE NOCASE否则后续用WHERE supplier LIKE %科技%查询时会漏掉“科技有限公司”这类变体。PDF生成用Deno的pdf-lib库deno run -A generate_pdf.ts模板用纯HTMLCSS通过html2canvas转为图片再嵌入PDF。这里踩了个大坑html2canvas默认不截取溢出内容导致长表格被截断。解决方案是在CSS里加body { overflow: visible !important; }并用scale: 2参数提升渲染精度。实测数据全流程耗时首次运行7分23秒主要耗时在PDF文本提取的缓存初始化连续运行100次平均耗时4.1秒±0.3秒最大内存占用FreeRPA进程峰值327MB远低于客户要求的512MB上限关键故障第87次运行时扫描仪驱动临时掉线FreeRPA的“等待图像出现”组件超时后自动跳过导致后续步骤无输入数据。解决方案是在流程开头加“检查扫描仪状态”子流程用wmic path Win32_PnPEntity where Name like %scanner% get Status命令判断。注意所有操作均录制屏幕视频并保存日志。客户IT审核时直接播放“从插入USB到生成第一份入库单”的12分钟录像比写十页技术方案更有说服力。3.2 SQLite数据一致性压测23万行写入后的锁表现实验设计模拟电商仓管场景10个RPA机器人10个FreeRPA实例并发向同一SQLite数据库写入库存变更日志。每个机器人每30秒执行一次BEGIN IMMEDIATE;INSERT INTO stock_log (sku, qty_change, operator, ts) VALUES (?, ?, ?, ?);UPDATE stock SET qty qty ? WHERE sku ?;COMMIT;持续运行48小时期间随机触发故障每2小时用taskkill /f /im FreeRPA.exe强制结束一个机器人进程每6小时用fsutil file setzerodata offset0 length1024 data.db破坏WAL日志头记录每次故障后其他机器人是否被阻塞、数据是否丢失、db browser for sqlite能否正常打开。关键配置与计算WAL模式启用PRAGMA journal_mode WAL;。这是并发写入不锁表的前提但必须在数据库首次打开时设置后续修改无效。同步级别PRAGMA synchronous NORMAL;。设为FULL会大幅降低写入速度实测从850TPS降至210TPS而NORMAL在断电时丢失最多一个事务符合仓管日志场景容忍度。页面大小PRAGMA page_size 4096;。默认1024字节在大量TEXT字段时导致碎片化严重4096字节使23万行数据文件体积从1.8GB降至1.1GB。WAL检查点Deno调度器每5分钟执行PRAGMA wal_checkpoint(TRUNCATE);防止WAL文件无限增长。实测数据表格故障类型触发次数平均阻塞时长数据丢失行数db browser for sqlite打开成功率强制杀进程240.0msWAL自动回滚0100%WAL头破坏812.3ms自动重建WAL0100%磁盘满预留10MB空间34.7秒重试3次后报错0100%独家技巧当db browser for sqlite报“database is locked”时不要急着重启。先用sqlite3 data.db PRAGMA locking_mode;确认是否为NORMAL模式再用lsof -p $(pgrep -f data.db)Linux或Process ExplorerWindows查看哪个进程持有锁。实测90%的锁来自未关闭的FreeRPA调试窗口——它在后台保持数据库连接。3.3 风影RPA组件兼容性沙盒Delphi客户端的坐标稳定性实验设计客户MES系统用Delphi 7开发界面为标准Windows控件TButton、TEdit但存在三大痛点屏幕缩放125%时按钮文字被截断导致OCR识别失败多显示器热插拔后主窗口坐标偏移图像识别区域错位某些按钮使用OwnerDraw风格常规UI Automation无法获取句柄。验证方案放弃“元素选择器”改用风影RPA的“图像识别相对坐标”双保险截取按钮区域固定大小图片如120x40像素作为模板在流程中设置“查找图像”组件搜索范围限定为“当前窗口客户区”找到后用GetWindowRectAPI获取窗口绝对坐标再通过ScreenToClient转换为客户端坐标点击位置 模板中心坐标 客户区偏移量。关键参数与实测模板匹配阈值设为0.85默认0.95。实测在屏幕缩放125%时截图像素失真导致相似度降至0.82~0.870.85阈值可覆盖99.3%的正常场景。坐标缓存策略首次运行时将GetWindowRect返回的left/top值存入SQLite的config表后续启动时读取并校验窗口标题是否匹配不匹配则重新获取。避免热插拔后坐标漂移。OwnerDraw按钮处理用PrintWindowAPI将按钮区域截图再喂给图像识别组件。比尝试Hook Delphi消息循环稳定得多。实测数据单次点击成功率99.97%10000次测试3次失败均为网络延迟导致窗口未完全渲染屏幕缩放适应时间从100%切到125%后首次识别耗时增加0.8秒因需重新截图建模后续稳定多显示器热插拔坐标偏移量最大17像素在4K主屏1080P副屏组合下通过ScreenToClient校准后误差≤1像素。实操心得Delphi的OwnerDraw按钮有个隐藏特性——即使按钮禁用EnabledFalsePrintWindow仍能截图。这让我们能实现“禁用状态下也监控按钮状态变化”比轮询IsWindowEnabled高效得多。3.4 Deno调度器韧性验证时间拨动与蓝屏后的自动续跑实验设计Deno调度器核心逻辑// scheduler.ts const cron new Cron(0 */5 * * * *, async () { const tasks await db.query(SELECT * FROM tasks WHERE status pending AND next_run ?, [new Date()]); for (const task of tasks) { await runTask(task); // 执行RPA流程 await db.execute(UPDATE tasks SET status done, last_run ? WHERE id ?, [new Date(), task.id]); } });验证点系统时间被手动拨快2小时后cron是否仍按原UTC时间触发即原定03:00的任务在系统时间显示05:00时是否执行执行中遭遇蓝屏重启后未完成任务是否标记为failed并重试任务执行超时300秒是否自动终止并释放资源。关键配置与原理时间基准Deno的Cron库默认用Date.now()受系统时间影响。解决方案是改用performance.now()做相对计时但需配合NTP校时。最终采用折中方案在cron回调中先调用await fetch(https://worldtimeapi.org/api/ip)获取UTC时间再判断是否到触发点。实测首次请求耗时120ms后续用Deno.cache缓存结果平均耗时5ms。蓝屏续跑在runTask函数开头执行await db.execute(UPDATE tasks SET status running, start_time ? WHERE id ?, [new Date(), task.id])结尾再更新为done。崩溃后启动时执行UPDATE tasks SET status pending WHERE status running AND start_time datetime(now, -10 minutes)。超时控制用AbortControllerconst controller new AbortController(); setTimeout(() controller.abort(), 300000); await runRPAFlow({ signal: controller.signal });实测数据时间拨动测试拨快2小时后03:00任务在系统时间05:00:03执行延迟3秒为NTP请求耗时精确度满足要求蓝屏模拟用notmyfault.exe触发BSOD重启后3个未完成任务全部标记为pending并成功续跑超时终止故意让一个RPA流程死循环300秒后进程被AbortSignal终止内存释放干净无残留进程。避坑指南Deno的--allow-env权限会暴露process.env但客户禁止读取环境变量。解决方案是把NTP地址硬编码在代码里并用Deno.build.os windows做平台判断避免在Linux上发起不必要的网络请求。3.5 影刀RPA到FreeRPA迁移成本量化23个JS函数的重写代价实验对象客户现有影刀RPA电商比价流程核心功能抓取京东/淘宝/拼多多3家商品页价格用自定义JS函数清洗价格处理“¥199”“直降50”“券后¥149”等变体比较后生成Excel报表含条件格式和图表邮件发送报表。迁移步骤与耗时记录流程图重构8小时影刀的“循环遍历数组”组件在FreeRPA中需拆为“For循环索引变量”因FreeRPA不支持原生数组迭代。JS函数重写22小时23个函数中17个可直接移植如正则提取6个需重写parsePrice(str)影刀内置str.replace(/[^0-9.]/g, )在FreeRPA中失效改用str.match(/[\d.]/g)?.[0] || 0generateChart(data)影刀调用Excel COM对象FreeRPA需改用exceljs库且要处理.xlsx文件权限客户机禁用ActiveX。Excel模板适配6小时影刀的“填充Excel模板”组件不支持FreeRPA改用exceljs的addWorksheeteachRow逐行写入速度慢40%但稳定性提升。邮件发送2小时影刀用SMTP组件FreeRPA需用Deno的nodemailer配置更复杂但支持OAuth2。成本对比表格项目影刀RPA原方案FreeRPA迁移后变化代码行数127行含注释386行204%单次执行耗时42秒68秒62%内存峰值412MB298MB-28%维护难度低可视化编辑中需懂TS↑离线能力需影刀客户端在线授权完全离线↑↑↑关键结论迁移不是“功能复制”而是“架构重构”。影刀的便利性建立在封闭生态上FreeRPA的开放性带来更高自由度但也要求开发者承担更多底层细节。对于客户而言如果流程变更频率1次/月影刀更省心如果需深度集成SQL/ERP/SCADAFreeRPA的代码可控性价值远超初期多花的22小时。4. 常见问题与排查技巧实录从热搜词到真实故障4.1 “sqlite亂碼”问题的根因与三步定位法热搜词“delphi sqlite 亂碼”高频出现但90%的案例并非SQLite本身问题而是字符集传递链断裂。我的三步定位法第一步确认SQLite数据库编码sqlite3 data.db PRAGMA encoding; # 输出应为 UTF-8。若为 UTF-16le则需转换 sqlite3 old.db .dump | iconv -f UTF-16LE -t UTF-8 | sqlite3 new.db第二步检查FreeRPA组件的文本处理FreeRPA的“写入数据库”组件默认用系统ANSI编码。必须在组件属性中勾选“使用UTF-8编码”否则中文写入后变成某些字。这个选项在“高级设置”里且不同版本位置不同v2.2在“连接”页v2.3在“数据”页。第三步验证Delphi读取逻辑Delphi 7默认用AnsiString需显式声明var s: UTF8String; begin s : UTF8Encode(Query1.FieldByName(name).AsString); // 后续用UTF8Decode转回 end;实测发现若Delphi用WideString读取而SQLite存的是UTF-8会直接乱码。必须统一为UTF-8传输。独家技巧在FreeRPA流程末尾加一个“执行Shell命令”组件运行chcp 65001 echo test test.txt确保CMD会话编码为UTF-8避免日志文件乱码。4.2 “影刀rpa应用迁移”失败的五大陷阱从影刀迁移到其他平台最常栽在这些隐形坑里时间组件差异影刀的“等待X秒”是精确休眠FreeRPA的“延时”组件在CPU占用高时会漂移。解决方案用Deno的await new Promise(r setTimeout(r, 5000))替代。Excel单元格引用影刀用A1:B10FreeRPA用{row:1,col:1}。迁移时需全局替换正则/([A-Z])(\d)/g→{row:$2,col:$1.charCodeAt(0)-64}。HTTP组件重定向影刀默认跟随302FreeRPA不跟。需手动解析Location头否则登录态丢失。图像识别模板路径影刀模板存云端FreeRPA需本地绝对路径。建议在流程开头用Deno.cwd()动态拼接避免硬编码。错误处理机制影刀有“失败时跳转到指定节点”FreeRPA需用“Try-Catch”组件包裹且Catch内必须显式设置exitCode1否则流程不中断。实测数据在23个迁移案例中87%的失败源于第2条Excel引用平均修复耗时3.2小时。建议迁移前先用Excel的FORMULATEXT函数导出所有公式再批量转换。4.3 “rpa excel数据处理”性能瓶颈的精准诊断热搜词“rpa excel数据处理”背后是无数人卡在“处理10万行Excel要20分钟”。这不是RPA问题而是Excel组件设计缺陷。我的诊断流程Step 1区分IO瓶颈还是计算瓶颈用任务管理器看FreeRPA进程的“磁盘活动”和“CPU使用率”若磁盘100%、CPU30% → IO瓶颈换exceljs流式读写若CPU100%、磁盘20% → 计算瓶颈检查JS函数是否有for...in遍历大数组。Step 2Excel组件选型对比组件10万行读取耗时内存占用支持.xlsxFreeRPA内置182秒1.2GB否仅.xlsexceljs47秒328MB是SheetJS31秒415MB是Step 3终极优化——绕过Excel客户真正需要的不是“Excel文件”而是“结构化数据”。直接用deno run --allow-read parse_csv.ts把CSV当Excel处理速度提升12倍。FreeRPA只需调用Shell命令无需加载Excel组件。注意SheetJS的readFile函数在Deno中需用Deno.readFile预读取再传入XLSX.read(data, {type:array})否则报错。4.4 “db browser for sqlite”打不开的七种原因与修复当db browser for sqlite报“unable to open database file”时别急着重装先按顺序排查文件被占用用handle.exe data.dbSysinternals工具看哪个进程锁定了文件。90%是FreeRPA调试窗口未关闭。路径含中文db browser for sqlite 3.12.2前版本不支持中文路径。解决方案用mklink建英文符号链接。WAL模式未关闭PRAGMA journal_mode DELETE;后再打开。文件权限右键文件→属性→安全→编辑→添加“Users”组的“读取”权限。磁盘只读attrib -R data.db。SQLite版本不匹配用sqlite3 data.db .version看版本db browser for sqlite 3.12.2对应SQLite 3.35.0。文件损坏sqlite3 data.db PRAGMA integrity_check;。若报错用sqlite3 data.db .dump | sqlite3 new.db重建。实操速查表现象快速命令文件被占用handle -p FreeRPA.exe | findstr data.db检查完整性echo PRAGMA integrity_check; | sqlite3 data.db重建数据库sqlite3 data.db .dump dump.sql sqlite3 new.db dump.sql4.5 “rpa能接单子”的商业真相三个必须签清的条款看到热搜词“rpa能接单子”很多新手以为接个流程就能赚钱。但真实交付中80%的纠纷源于合同模糊。我坚持在SOW工作说明书中明确三条数据所有权条款“客户提供的所有数据、训练样本、业务规则文档知识产权归客户所有。乙方交付的RPA流程代码版权归属乙方但客户获得永久、不可撤销、免版税的使用权。”为什么重要避免客户拿你的代码去招标第二家供应商。故障响应SLA“一级故障流程完全中断2小时内远程响应4小时内提供临时规避方案二级故障部分功能失效下一个工作日响应。”实测经验把“2小时”写进合同倒逼自己建好监控体系。我用Deno写了个心跳服务每5分钟ping一次FreeRPA的本地API端口异常时自动发企业微信告警。变更管理条款“任何UI变更如按钮文字、页面布局、接口变更如API URL、返回字段、业务规则变更如折扣计算逻辑均视为新需求按人天单独计费。”血泪教训曾有客户说“就改个按钮名字”结果导致OCR模板全部失效重做20小时。现在合同里白纸黑字客户反而更谨慎提需求。最后提醒别接“保证100%准确率”的单。RPA不是AI它是确定性流程。我的报价单里永远有一行“OCR识别准确率承诺98.5%基于客户提供标准样本测试集若现场环境光照/分辨率下降准确率按实测数据调整。”5. 选型决策树根据你的场景选哪条技术路径5.1 从“担心清单”到可执行的技术选型图谱回顾最初那张“万一……怎么办”的担忧清单它天然对应着RPA落地的五个风险维度。我把三个月验证的结论浓缩成一张决策树帮你跳过试错直达最优解分支一客户环境是否允许联网是 → 可考虑影刀RPA云授权便捷、Ui.Vision RPAChrome扩展免安装否 → FreeRPA Deno SQLite是唯一选择。注意FreeRPA的“离线模式”需在安装时勾选否则首次启动仍会尝试连网校验。分支二数据是否必须本地化存储是 → SQLite是事实标准。但必须用PRAGMA journal_mode WAL;开启WAL否则并发写入必锁表否 → 可上MySQL/PostgreSQL但需客户IT配合开防火墙周期长。分支三是否需对接老旧系统Delphi/VC/VB6是 → 优先风影RPA图像识别成熟或AutoHotkeyFreeRPA混合方案否 → 影刀RPA的UI Automation组件更易上手。分支四流程变更频率如何高1次/周 → FreeRPA的代码化流程更易维护Git版本控制清晰低1次/月 → 影刀RPA的可视化编辑节省培训成本。分支五是否有定制开发能力有 → FreeRPADeno组合释放全部潜力可写任意调度逻辑无 → 影刀RPA的“应用市场”有现成组件如“金智维RPA对接Kingscada”插件。个人体会没有“最好”的RPA只有“最适合当前约束条件”的RPA。我见过最成功的项目是用FreeRPA做核心流程影刀RPA做前端交互Deno做调度中枢——三者各司其职比强行用一个平台包打天下更稳健。5.2 一份可直接抄作业的《RPA选型验证清单》基于三个月实测我整理了一份21项的验证清单每项都标注了“必测”或“选测”以及“通过标准”序号验证项类型通过标准工具1断网环境下安装必测30分钟内完成安装并运行Hello WorldFreeRPA安装包2SQLite写入10万行不锁表必测并发10线程48小时无锁表报错Denosqlite33Delphi按钮图像识别准确率必测1000次测试失败≤3次风影RPAPrintWindow4系统时间拨动2小时后任务准时必测偏差≤5秒DenoC