1. 报告丑到没人看问题其实不在用例本身跑完一轮 pytest终端里一排绿点或者红点测试是真跑完了可当你把这堆输出丢给开发或者产品的时候对方的反应通常是「所以呢」。pytest 自带的输出是给写用例的人看的不是给读结论的人看的。这个矛盾在我做接口自动化的第三年变得特别尖锐用例数量从几十条涨到两千多条以后谁也没耐心去翻终端日志大家要的是「这轮迭代哪些模块挂了、挂在哪个接口、失败时的请求体和响应体长什么样」。allure 就是在这个节点被我引入进来的配合 pytest 使用以后报告从一堆文本变成了一份能点、能筛、能贴附件的东西。这篇就专门聊一件事在不同的操作系统上把 allure 装起来并把它的环境变量配到能用。Windows 和 Mac 两套流程我都会写全包括我自己在环境变量配置上踩过的坑。先把结论摆出来免得有人看到一半发现方向不对。allure 这套报告工具分两部分一部分是 Python 侧的allure-pytest插件负责在用例执行过程中往一个结果目录里写 JSON 和附件另一部分是 allure 命令行工具负责把这些中间产物渲染成一份静态 HTML 报告。Python 侧那个插件pip install就完事真正的麻烦全在命令行工具这一侧——因为它是 Java 写的运行时依赖 JDK所以整个链路变成了「JDK → 环境变量 → allure 命令行 → 环境变量 → pytest 插件」这么一条长长的依赖链。任何一环没接上你看到的报错都不会直白地告诉你「是环境变量没配」而是各种奇怪的command not found或者JAVA_HOME is not set。这也是为什么单独拿一篇出来讲环境不谈用例写法。适合谁看刚把 pytest 跑通、想给团队交一份像样报告的同学换了新电脑或者新公司机器、要从零搭一套自动化环境的同学以及已经在用 allure 但报告偶尔打不开、allure serve莫名其妙失败的同行。我会把版本选择的依据、路径该怎么规划、验证命令怎么写、报错怎么定位全部摊开讲。你不需要事先懂 Java但你需要知道为什么要装它这个我在第 2 章会解释清楚。2. 为什么非得塞一个 JDK 进来技术选型的取舍2.1 原生输出到底差在哪pytest 默认的终端输出和--junitxml生成的 XML 报告本质上是「执行流水」不是「分析视图」。你把 XML 拖进浏览器看到的是层层嵌套的标签用 IDE 打开看到的是属性列表。而实际工作中大家真正关心的信息是分层级的先看整体通过率再看失败集中在哪个功能模块再往下钻到具体用例的请求参数、响应断言、堆栈、截图或者日志附件。这三层结构XML 靠一堆testcase节点是表达不出来的它没有「模块层级」和「严重级别」的概念也没有统一的附件挂载机制。更现实的问题是协作。自动化报告要给的是非技术角色看的东西产品经理关心的是「这个功能验证过了吗」测试负责人关心的是「这次失败是环境抖动还是代码缺陷」。原生输出无法承载这些语义。我在早期试过一个折中方案自己写脚本把 XML 解析成 HTML做了两天就放弃了——因为要处理截图嵌入、日志折叠、失败重跑标记这些东西工作量远超预期而且每加一个新需求就要改一遍模板。allure 解决的正是这个问题。它的数据模型里有 suite套件、feature/story业务维度、severity严重级别、step步骤、attachment附件、environment环境信息这些概念pytest 侧只要加上装饰器报告就能自动按业务维度聚合。这不是单纯的「美化」而是把测试结果结构化让它成为一种可分析的数据资产。2.2 为什么它偏偏是 Java 写的这是很多人最不理解的环节我写 Python 测试凭什么要装 JDK答案很朴素——allure 命令行工具的原始实现是 Java 项目它通过读取结果目录里的 JSON 文件用模板引擎渲染出 HTML。你可以把allure这个命令理解成一个「本地的静态站点生成器」只不过它的输入格式是固定的。历史上还有个更老的依赖allure 的旧版本需要 Maven 参与构建所以早期教程里常见「先配 Maven 环境变量」这一步。现在从官网下载的allure-commandline是打包好的压缩包解压即用不再需要 Maven。如果你看到的教程让你装 Maven那多半是三年前的文章可以参考但不必照做。唯一硬性依赖就是 JDK而且只要java -version能跑通就行。注意allure 命令行较新的版本对 JDK 版本有要求JDK 8 在部分新版本上会出现兼容问题。稳妥的做法是装 JDK 11 或 JDK 17 这类长期支持版本不要死守 JDK 8。网上大量「JDK1.8 安装教程」是给老项目用的套用到 allure 上容易在渲染阶段报错。2.3 版本与环境清单我把自己线上和本地机器在用的组合整理成一张表这套组合稳定跑了很久没有出现过渲染失败或者中文乱码的问题组件推荐版本说明Python3.9 - 3.113.12 部分插件兼容性仍在补齐求稳可选 3.10pytest7.x8.x 与 allure-pytest 的兼容性已经没问题但旧项目慎升allure-pytest与 allure 命令行版本贴近插件版本落后太多时部分新特性标签不生效JDK11 或 17必须能全局执行java -versionallure-commandline2.24 及以上Windows 下走压缩包Mac 下走包管理器路径规划上有一条经验所有开发工具装到一个统一的根目录下路径里不要有空格和中文。Windows 上我习惯放在D:\devtools\下面比如D:\devtools\jdk-17、D:\devtools\allure-2.24.0。Mac 上如果用包管理器路径是自动处理的不用操心如果手动解压放到/opt/homebrew/opt/或者用户目录下的~/tools/都可以。这条听起来像废话但后面配置环境变量的时候路径里的空格会让一整行 PATH 解析错位排查起来很折磨人。3. JDK 的安装与环境变量配置这一步决定后面顺不顺3.1 Windows安装路径的选择与安装包类型Windows 上装 JDK 有两条路一是下.exe安装包二是下.zip免安装包。我推荐后者。原因很直接——.exe安装器会默认往C:\Program Files\Java\里塞而这个路径带空格后面配JAVA_HOME和 PATH 时容易出幺蛾子而且卸载重装的时候容易残留注册表项换个版本还要走一遍卸载流程。.zip包解压出来就是一个完整目录想换版本直接改环境变量指向新目录旧目录留着也不影响非常清爽。具体操作从 JDK 官方发行版页面下载 Windows x64 的 zip 包解压到D:\devtools\下重命名一下目录把版本号保留但去掉可能存在的空格。解压完检查目录结构确认里面直接就是bin、lib、conf、include这些子目录。如果解压后发现多套了一层同名目录比如D:\devtools\jdk-17\jdk-17\bin那就是解压时勾了「创建顶层文件夹」把里面那层挪出来就行。这一步有个细节值得强调目录层级里必须能直接看到bin文件夹。因为后面JAVA_HOME填的是bin的上一级而 PATH 里引用的是%JAVA_HOME%\bin。层级多一层少一层最终 PATH 指向的就是一个不存在的目录虽然不会报错但java命令就是找不到。3.2 Windows三个环境变量到底该怎么填打开系统环境变量的入口是「此电脑 → 属性 → 高级系统设置 → 环境变量」。这里有两个区域上面的「用户变量」和下面的「系统变量」。我的做法是统一在系统变量里配因为有些 CI 代理或者服务是以系统账户运行的用户变量它们读不到。如果你机器上还有别的账号在用也建议配系统级。需要配的值一共三个变量名值说明JAVA_HOMED:\devtools\jdk-17新建指向 JDK 根目录不带\binPATH追加%JAVA_HOME%\bin编辑已有的 PATH不要覆盖原有内容CLASSPATH.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar新版本可省略老库兼容时加上关于JAVA_HOME的值最常见的错误是填成了D:\devtools\jdk-17\bin。这样写的话PATH 里再加%JAVA_HOME%\bin最终就是D:\devtools\jdk-17\bin\bin命令当然找不到。判断方式很简单JAVA_HOME那一层目录里应该有bin、lib、conf三个子目录同时存在。关于 PATHWindows 的 PATH 是一个分号分隔的长字符串编辑的时候建议点「编辑文本」切到纯文本模式把所有条目行都看一遍确认没有和已有的 Java 条目冲突。有的机器之前装过 JDKPATH 里有一段硬编码的C:\Program Files\Common Files\Oracle\Java\javapath这段优先级经常比你的%JAVA_HOME%\bin还高导致你新配的版本根本不生效。遇到「明明改了环境变量java -version还是老版本」的问题第一个要查的就是这段。CLASSPATH现在其实可以完全不管。JDK 从 9 开始就不再需要预置dt.jar和tools.jar了很多新教程直接省略这一步。我保留它是因为手上有几个老项目还在跑加上也无害——注意开头的那个.不能丢它表示当前目录丢了以后执行自己编译的 class 文件会报找不到类。改完环境变量一定要新开一个终端窗口。已经开着的 CMD 或者 PowerShell 里环境变量还是旧的那份这个坑我吃过不止一次改完随手在当前窗口里敲java -version看到旧版本就以为配置失败其实是窗口没刷新。3.3 Mac包管理器与手动安装的取舍Mac 上装 JDK 有两种方式各有适用场景。用包管理器Homebrew装的好处是管理和升级方便一条命令搞定路径也自动处理好缺点是网络环境不好时下载容易中断或者卡在Updating Homebrew那一步很久不动。手动装则是从官网下载.tar.gz或者.dmg解压到指定目录再自己配 shell 的启动文件。我先说包管理器的流程这也是我更推荐的方式# 安装前先确认包管理器可用 brew --version # 安装 JDK 17也可以装 11 brew install openjdk17装完以后由于这类 JDK 是「keg-only」的不会自动链接到系统路径需要手动把它的bin目录加到 PATH或者在启动文件里写JAVA_HOME。打开你的 shell 配置文件如果用的是较新的 macOS默认 shell 是 zsh配置文件就是~/.zshrc如果是老版本或者手动切过 bash那就是~/.bash_profile。用编辑器打开加上两行export JAVA_HOME$(/usr/libexec/java_home -v 17) export PATH$JAVA_HOME/bin:$PATH这里的/usr/libexec/java_home是 macOS 自带的一个工具能按版本号帮你找到 JDK 的实际安装路径比写死路径稳得多。以后从 17 升到 21只要把版本号改掉就行不用去翻 JavaVirtualMachines 目录。如果你的机器上装了多个 JDK这个工具就更有价值了——java_home -V能列出全部已安装版本。手动安装的话.dmg双击装完默认落在/Library/Java/JavaVirtualMachines/下面.tar.gz解压后随意放只要保证JAVA_HOME指对就行。手动装的麻烦在于每次升级都要自己换路径而且卸载不干净的话会有多个版本并存java_home -V列出来一堆选错版本就白折腾。改完启动文件后同样要source ~/.zshrc或者新开一个终端窗口。Mac 上的终端复用比 Windows 更常见很多人开着一个窗口用一整天改完配置忘了 reload然后怀疑配置写错了。3.4 怎么验证 JDK 真的配好了验证只看两条命令输出对得上才算过关java -version javac -version第一条能打印出java version 17.x.x这类信息说明运行时环境通了第二条能打印编译器版本说明javac也在 PATH 里开发工具链完整。两条都通还要再看一眼JAVA_HOME# Windows CMD echo %JAVA_HOME% # macOS / Linux echo $JAVA_HOME输出应该是一个干净的目录路径不带bin不带引号不带多余的空格。提示如果java -version通但echo %JAVA_HOME%是空的说明你只把bin加进了 PATH没设JAVA_HOME。这种情况跑 pytest 可能没事但 allure 命令行渲染时会报JAVA_HOME is not set因为它内部是靠这个变量去定位 Java 运行时的。所以这四个值必须都对齐。4. allure 命令行的安装Windows 与 Mac 两种姿势4.1 Windows解压、定位、配 PATHWindows 侧的安装本质是一次解压加一次 PATH 追加。从 allure 官方发布页下载最新的allure-commandline-x.x.x.zip解压到D:\devtools\下目录名保持带版本号的原始格式方便以后多版本并存我发现新版本有问题时可以临时把 PATH 指回旧目录这是保留版本号的一个隐藏好处。解压完检查一下bin目录里有没有allure.bat和allure两个文件lib目录里应该有一堆 jar 包。接着新建一个系统变量ALLURE_HOME值填D:\devtools\allure-2.24.0然后在 PATH 里追加%ALLURE_HOME%\bin。关于要不要设ALLURE_HOME网上有争议因为 allure 命令行本身不读这个变量设它是为了给自己和团队一个统一的路径锚点——脚本里引用%ALLURE_HOME%\bin\allure比硬编码完整路径更好维护换机器时只需要改一个变量。验证方式是新开终端执行allure --version能打印出版本号就说明 PATH 生效了。如果提示「不是内部或外部命令」按这个顺序排查PATH 里那一行是不是少了分号%ALLURE_HOME%\bin里的文件到底叫什么终端是不是新开的以及有没有可能同时存在多个 PATH 条目互相覆盖。4.2 Mac包管理器安装与常见报错处理Mac 上就一条命令brew install allure装完自动就在 PATH 里了直接allure --version验证。整个过程比 Windows 简单一个量级但实际用下来最容易卡住的反而是这步因为包管理器本身的环境问题会在这里集中爆发。我遇到过的几类第一类是卡在更新索引阶段终端半天没输出看着像死了。这种情况多半是网络问题可以中断后重试或者把索引更新跳过去直接装。第二类是提示某个依赖的构建失败通常是本机缺少命令行开发工具执行xcode-select --install装上以后重试即可。第三类是提示权限拒绝某个目录不可写这时候要看清楚报错里的具体路径不要盲目加sudo——加了以后装的包归属会变成 root后续升级反而更麻烦。如果包管理器这条路实在走不通Mac 上也可以走压缩包手动装流程和 Windows 完全一样下载 tar 包、解压到~/tools/、在~/.zshrc里配置变量export ALLURE_HOME$HOME/tools/allure-2.24.0 export PATH$ALLURE_HOME/bin:$PATH然后source ~/.zshrc生效。手动装的好处是不受网络索引影响坏处是升级要自己动手而且要注意 mac 版压缩包的bin/allure脚本有没有执行权限没有的话补一句chmod x。4.3 两个平台的路径差异速查项目WindowsMac安装方式下载 zip 解压包管理器或手动解压安装位置D:\devtools\allure-x.x.x包管理器自动管理 /~/tools/环境变量文件系统环境变量面板~/.zshrc或~/.bash_profilePATH 引用语法%ALLURE_HOME%\bin$ALLURE_HOME/bin生效方式新开终端source或新开终端可执行文件名allure.batallure这张表看着简单但跨平台操作时最容易出错的就是「语法串台」——在 Mac 的配置文件里写%ALLURE_HOME%或者在 Windows 的 PATH 里写$ALLURE_HOME/bin都是不会报错但也不生效的静默失败。写配置文件的时候脑子里过一遍语法再落笔。5. pytest 与 allure 的对接从依赖到第一份报告5.1 Python 侧依赖与虚拟环境Python 侧的安装没有平台差异一条命令pip install allure-pytest强烈建议在虚拟环境里装不要用全局 Python。原因不只是「干净」更重要的是 pytest 生态里插件之间经常有版本冲突全局环境一旦装乱排查成本极高。用 venv 或者 conda 都行python -m venv .venv source .venv/bin/activate # macOS / Linux .venv\Scripts\activate # Windows pip install pytest allure-pytest装完确认版本pip show allure-pytestallure-pytest的版本和 allure 命令行的版本不需要严格一一对应但差距太大时会遇到「插件生成了某个字段命令行不认」的情况表现为报告里某些标签丢失或者渲染报错。我在项目里会把这两个版本号写进 README团队统一省得每个人环境不一样导致报告长得不一样。5.2 运行方式与参数选择pytest 侧生成结果的参数是--alluredirpytest --alluredir./allure-results这条命令执行完allure-results目录里会出现一堆.json和.txt文件这就是中间产物。这里有个很多人第一次用会困惑的点这些 JSON 不是给人看的也不是最终报告。最终报告要用命令行工具再渲染一次。渲染有两种模式用途不同# 模式一本地起一个临时服务浏览器自动打开 allure serve ./allure-results # 模式二生成一份静态 HTML 报告 allure generate ./allure-results -o ./allure-report --cleanallure serve适合调试阶段反复看它会启一个本地服务改完用例重跑一次刷新浏览器就能看到新结果不用手动清理目录。allure generate适合归档和分享生成的allure-report目录可以打包发给别人双击index.html就能看。注意--clean参数的作用是渲染前清空输出目录不加的话旧报告残留文件会和新报告混在一起出现「点进去还是上次的数据」这种诡异现象。注意直接双击allure-report/index.html用file://协议打开在部分浏览器上会因为跨域策略导致报告内容空白。稳妥的打开方式是执行allure open ./allure-report它会起本地服务来展示或者用python -m http.server在报告目录里起个静态服务。5.3 把报告从「能看」提升到「好用」装饰器是 allure 真正拉开差距的地方。最基础的几个用法import allure import pytest allure.feature(订单模块) allure.story(创建订单) allure.severity(allure.severity_level.CRITICAL) def test_create_order(): with allure.step(准备下单参数): payload {sku: A001, count: 2} with allure.step(调用创建订单接口): # 这里换成你的请求逻辑 resp {code: 0, order_id: 12345} with allure.step(校验返回结果): assert resp[code] 0 allure.attach(str(resp), 响应内容, allure.attachment_type.JSON)feature和story构成报告里的两级业务分组比按文件路径分组直观得多——尤其当你的用例目录结构是按技术维度api、ui、utils组织但报告需要按业务维度呈现的时候这两个装饰器就是桥梁。severity让报告能按严重级别筛选回归测试时先看 critical 的失败项效率提升很明显。step会把用例内部的关键动作展开成可折叠的步骤失败时能精确定位到哪一步。allure.attach挂载响应体、截图、SQL 语句这些附件出问题的时候不用再去翻日志文件。有一个细节值得说attach的第一个参数必须是字符串或者字节流。想把字典直接塞进去得先str()或者json.dumps()。我在项目里封装了一个辅助函数根据参数类型自动选 JSON 还是 TEXT 附件类型调用方就不用每次都记得转换了。5.4 测试环境信息的注入报告首页有一块「环境」区域默认是空的。想让它显示当前测试环境、Python 版本、被测服务地址这些信息可以在结果目录里放一个 properties 文件pytest 运行时不会自动生成需要你自己写import os def pytest_sessionstart(session): with open(allure-results/environment.properties, w, encodingutf-8) as f: f.write(fPython.Version{os.sys.version.split()[0]}\n) f.write(fTest.Env{os.getenv(TEST_ENV, staging)}\n) f.write(fBase.URL{os.getenv(BASE_URL, http://localhost:8000)}\n)配合conftest.py里的这个钩子每次跑测试都会刷新环境信息。这个小配置在排查「报告是不是上一次的」这类问题时特别有用因为环境信息会跟着变。6. 报错排查那些不会直说的错误信息6.1 Windows 侧的典型问题allure不是内部或外部命令。九成是 PATH 没生效。按这个顺序查先看ALLURE_HOME的值是不是指到了正确的目录再看 PATH 里那一行是不是%ALLURE_HOME%\bin少个\bin是最常见的笔误然后关掉终端重新开一个最后用where allure看看系统到底找到了哪几个路径下的同名命令如果找出来的是旧目录就把旧条目删掉。JAVA_HOME is not set。这个报错出现在执行allure generate或者allure serve的时候说明命令行工具找不到 Java。检查JAVA_HOME是否存在、是否指向 JDK 根目录、PATH 里有没有%JAVA_HOME%\bin。还有一种隐蔽情况JAVA_HOME的值末尾多了个反斜杠拼接后变成D:\devtools\jdk-17\\bin某些老版本的脚本处理不了这种双反斜杠改成干净的路径就好。报告中文乱码。这是控制台编码问题不是 allure 的问题。执行命令前先切一下代码页chcp 65001临时切到 UTF-8。想永久生效就改注册表或者系统区域设置里的「Beta: 使用 Unicode UTF-8 提供全球语言支持」但改这个要谨慎某些老软件会因此显示异常建议只在需要生成报告的那个终端里临时切。路径里有空格导致的奇怪失败。C:\Program Files\这种路径在 PATH 里如果不加引号会被当成两个条目解析。这也是我一开始就建议把 JDK 和 allure 装到D:\devtools\的原因从源头避免这类问题。6.2 Mac 侧的典型问题allure: command not found。先echo $PATH看输出里有没有你配的目录。如果没有说明配置文件没生效——检查是不是写到了~/.bash_profile但当前用的是 zsh或者忘了source。还有一种情况是写对了但顺序有问题$PATH被写在了自定义路径前面导致自定义路径优先级不够虽然一般不影响command not found但会有版本优先级问题。命令能跑但打开报告报权限错误。手动解压安装时bin/allure可能没有执行权限补一句chmod x ~/tools/allure-*/bin/allure即可。如果是allure serve起的服务端口被占用换端口就行不需要折腾环境。多个 JDK 版本打架。java -version和$JAVA_HOME指向的版本不一致这在 Mac 上很常见因为/usr/bin/java是个系统软链而JAVA_HOME是你自己配的。用/usr/libexec/java_home -V列出全部版本确认你配的那个版本号和实际执行的一致。不一致的话把 PATH 里$JAVA_HOME/bin的位置往前挪让它优先于系统软链。6.3 两个平台都会遇到的通用坑现象大概率原因处理方式报告内容为空用 file 协议直接打开了 HTML用allure open或起本地静态服务报告显示上次数据未加--clean或结果目录未清理渲染时加--clean或手动删结果目录标签不生效插件版本与命令行版本差距过大对齐两边版本或升级较旧的一侧步骤不展开未使用with allure.step上下文关键动作包进 step 上下文管理器附件看不到传的是字典等非字符串对象先str()或json.dumps()再传渲染很慢结果目录累积了历史 JSON每次跑测试前清空结果目录这里我想单独强调「结果目录不清空」这一条。它不会立刻出问题但跑上十几个迭代以后allure-results里会堆几千个 JSON 文件渲染时间从几秒变成几分钟而且历史失败记录会混进当前报告让人误判通过率。我的做法是在 pytest 的启动参数里固定加上清理逻辑或者在 CI 流水线里每次执行前rm -rf allure-results。6.4 我踩过的几个具体的坑第一个坑早期在 Windows 上装完 JDK 后立刻去跑 allure报JAVA_HOME is not set查了半天环境变量发现没错最后发现是终端窗口没重开。这件事教育我改完环境变量的第一件事永远是开新窗口。第二个坑Mac 上把JAVA_HOME写在了~/.bash_profile里但系统早就默认 zsh 了配置文件根本没被读取。表现是每次重开终端都要手动export一遍才行。改用~/.zshrc以后问题消失。判断当前 shell 用echo $SHELL。第三个坑包管理器装完的 JDK 因为 keg-only 没有自动进 PATH我一开始把bin目录硬编码进去了后来升级版本路径变了又得改一遍。换成/usr/libexec/java_home动态获取以后一次配置长期有效。第四个坑渲染报告时中文全部显示为方块。查下来是终端代码页的问题跟 allure 本身无关。加chcp 65001后正常。这个坑的特点是「看起来像工具问题实际是系统问题」容易被带偏去找 allure 的配置。7. 顺手把报告落到团队流程里环境配好只是起点真正让这套东西产生价值的是把它接进日常流程。我目前的落地方式是本地开发时用allure serve反复看提交代码后由流水线在测试阶段生成结果目录再由构建脚本统一渲染成静态报告并归档到构建产物里保留最近若干次的历史。这样出问题的时候可以直接对比上一轮的报告看失败项是新增的还是旧的。环境信息那块也别省。把当前分支、提交号、被测环境地址写进environment.properties报告就不再是孤立的执行记录而是能和代码版本对应的证据。我在一次线上问题复盘里就靠这个配置快速定位到了是哪次提交引入的回归比翻流水线日志快得多。分辨率上还有个建议如果团队里 Windows 和 Mac 混用把环境配置脚本化。Windows 侧写一个.bat或者 PowerShell 脚本把JAVA_HOME、ALLURE_HOME的设置和 PATH 追加动作都写进去新同事直接跑一遍Mac 侧则维护一份 dotfiles 里的配置片段。这样新机器搭建时间从半天压缩到十分钟而且不会因为某个人手滑填错路径导致报告格式不一致。最后再分享一个小技巧。allure generate出来的报告目录是纯静态的可以直接丢到任意静态托管服务上用固定的团队地址访问不用每次发压缩包。配合构建号做路径区分就变成了一套轻量的报告归档系统。我在两个项目上这么做以后产品同学会自己去翻报告看进度测试同学从「发报告」这件事里彻底解放了。至于用例怎么写才让报告更有信息量那是另一个话题核心思路是凡是你排查问题时想再看一眼的信息都挂成附件或步骤下次就不用再复现一遍了。