简介图书管理系统测试报告 PDF 文档面向软件测试学习者、系统开发人员及高校相关专业学生可用于课程设计、毕业设计或项目验收时的测试文档参考。报告以图书管理系统为对象完整覆盖测试目的、项目背景、定义说明、运行环境、需求概述、测试方案、测试项目与测试准备等环节并重点介绍黑盒测试、白盒测试和灰盒测试方法分别对应图书信息管理、借阅管理、查询统计等模块的用例设计与条件约束文末还提供了测试评价的范围与准则。文档内含测试截图可以对照操作界面验证测试结论帮助读者掌握从测试计划设计、用例执行到结果评价的完整流程并迁移到其他管理信息系统中。资源为1个PDF文件总大小946KB已有1671人学习下载适用于软件测试实训和报告模板参考。1. 图书管理系统测试报告为什么值得写成一份“带截图”的文档在交付软件测试结果时真正能被开发人员、产品经理和客户同时快速接受的往往不是一张密密麻麻的缺陷清单而是一份能“看得见”的测试报告。图书管理系统这类业务逻辑清晰但分支繁多的项目尤其是 PHP、Java 或 .NET 等不同技术栈实现时登录、借阅、归还、检索、超期罚款等模块之间存在大量状态关联单靠文字描述缺陷复现步骤经常出现“开发说复现不了测试说就按你写的做的”这类扯皮。把关键操作路径和失败现场用测试截图固定下来嵌入 PDF 报告里本质上就是把“可复现性”变成可交付资产。这篇文章我会从测试报告的结构设计说起讲清楚测试用例怎么排布、接口和 UI 自动化如何产出可追踪的数据、截图怎么拍才不算白拍以及最后如何把散落的证据汇总成一份能直接发给任何人的 PDF。内容面向正在做测试报告整理、想提升报告说服力的 QA、开发兼测试以及刚接手图书管理系统这类业务系统的外包实施人员。2. 测试报告的核心结构与用例设计先把图书管理系统的测试范围定清楚2.1 图书管理系统测试范围与功能拆解一份合格的测试报告不是把测试结果按时间顺序贴出来而是要先告诉读者“我测了什么、没测什么、怎么判定通过”。以图书管理系统为对象常规模块拆分如下读者管理注册、登录、信息修改、注销、图书管理录入、编辑、下架、库存查询、借阅与归还借书、续借、归还、逾期计算、分类检索按书名、作者、ISBN、分类号、系统设置权限、参数配置。实际测试报告里我会先用一张功能矩阵表说明各模块覆盖情况模块用例总数已执行通过失败阻塞通过率读者管理3232292190.6%图书管理4141373190.2%借阅归还5553447283.0%分类检索2828262092.9%系统设置1515141093.3%这张表放在报告开头读者一眼就能知道整体风险集中在借阅归还模块。报告正文的每一章再对应展开对应模块的测试截图就放在该章节下面而不是把所有截图堆在附录里。这样做的检索价值在于当开发人员只看自己负责的模块时可以按图索骥直接翻到对应页。2.2 测试用例优先级与覆盖策略用最少的用例命中核心风险图书管理系统的业务核心是“借—还—查”闭环所以用例优先级不能按功能模块平均分配。我一般会按 P0/P1/P2 三层划分P0 是主干路径比如读者登录后成功借书、图书库存扣减、归还后库存恢复P1 是重要分支比如读者有逾期未还图书时是否还能继续借书、借书数量达到上限时的提示P2 是异常和边界比如 ISBN 输入 10 位和 13 位、借书日期跨月、库存为 0 时检索还显示在列表中。在设计用例时每个功能至少覆盖一条正向用例、一条反向用例和一条边界用例这样到测试报告汇总时通过率和缺陷分布才有分析意义。2.2.1 借阅归还模块的用例优先级示例以“归还图书”为例P0 用例是“正常归还库存增加”P1 用例是“归还超期图书计算并展示罚款金额”P2 用例是“重复归还同一本书弹出错误提示”。针对这三个优先级我在报告里会给出对应的用例表格每行包含用例编号、前置条件、操作步骤、预期结果、实际结果、截图名。截图文件名与用例编号一一对应比如TC-BORROW-001_正常归还.png。这样测试报告中的截图不是孤立的附件而是用例链条上的一部分。2.3 测试数据准备与状态清理图书管理系统的状态字段在馆、借出、预约中、逾期相互关联测试数据如果共用一份很容易出现一条用例的失败导致后面全部用例无法继续。我一般会用独立测试库并且在每个用例开始前用 SQL 重置业务状态而不是依赖界面操作。比如执行归还测试前需要保证该图书处于“借出”状态且读者没有未完成的借阅记录。在报告里我会在“测试环境与数据准备”一节写明数据库初始化脚本片段-- 重置图书状态为在馆清除借阅记录 UPDATE book SET status AVAILABLE WHERE book_id BK-1001; DELETE FROM borrow_record WHERE book_id BK-1001; DELETE FROM fine_record WHERE book_id BK-1001;这段 SQL 的作用是让每条用例都在同一起跑线上。如果不做状态重置第二次运行用例时可能因为库存已经被扣减而直接失败那么报告里记录的失败原因就不是真实的代码缺陷而是测试数据污染。所以测试报告里不仅要写“测试结果”还要写“测试数据是如何隔离的”这才叫一份让 5 年以上工程师也觉得有信息量的报告。3. 用接口测试和自动化测试生成可追踪的执据Postman、Newman 与 Allure 定制报告3.1 为什么接口层要跑一遍测试再截图很多人做图书管理系统测试时直接打开浏览器一点一点点击然后截图。这种做法对 UI 验证是必要的但缺陷是借阅、归还这类操作涉及库存扣减和状态变更如果只截 UI 结果无法证明后端接口返回了什么数据。所以我会先用 Postman 跑接口级测试把接口响应和断言结果作为证据再配合 UI 截图。这样测试报告里的每一张截图背后都对应一个明确的接口请求和响应开发和测试都能快速定位问题。3.2 用 Newman 命令行跑接口测试并输出 Allure 可读报告Postman 集合写好之后可以导出为 JSON接着用 Newman 在命令行批量执行。常见做法是newman run book-management.postman_collection.json \ -e book-management.postman_environment.json \ -d testdata/borrow-cases.csv \ --reporters cli,json,allure \ --reporter-allure-export ./allure-results这条命令的要点-e指定环境变量文件包含 baseUrl、token、readerId 等-d指定数据文件CSV 里每一行就是一组参数化的测试数据--reporters allure会让 Newman 把每次请求的请求体、响应体、断言结果都输出到allure-results目录。运行结束后再执行allure generate ./allure-results -o ./allure-report allure open ./allure-report就能打开本地报告。因为标题里提到“基于 psotman 定制化 allure 测试报告”这里展开说一点定制化Allure 默认展示的是整个集合的执行概况但测试报告需要按模块过滤可以在断言代码里用pm.info加上标签。比如在 Postman 的 Pre-request Script 或 Tests 里写pm.info.setName(借阅模块-正常借书); pm.info.addTag(BORROW);在 Tests 脚本里除了断言响应状态码为 200我还会断言返回的 JSON 里有bookId和dueDate并且dueDate晚于当前日期这样才算借书成功。如果没有这些断言接口返回 200 但业务逻辑错了Allure 报告里也会显示绿色通过测试报告就失去了信服力。3.2.1 Allure 定制报告里放什么粒度Allure 报告中的每个测试步骤对应一次接口请求而测试报告 PDF 中不可能贴全部请求。我一般只把 Allure 报告中标记为FAILED的用例和其响应截图截取出来嵌入 PDF。这样可以做到“截图带上下文”在 PDF 里放一张请求的 JSON 小图和一张响应报错的 JSON 小图再配一张 UI 上的报错提示截图三段拼成一个完整证据链。Allure 本身有allure attach的能力但在 Postman 环境下更简单的方式是把响应体保存成 JSON 文件后续用脚本插入报告newman run book-management.postman_collection.json -r json --reporter-json-export ./newman-output.json然后用一个小脚本过滤失败用例的响应体存成evidence/failed-{caseId}.json。这个动作是为了后面的 PDF 组装做准备而不是直接生成最终报告。3.3 用 Playwright 做 UI 自动化并接管截图接口测试证明后端逻辑没问题但页面交互、提示文案、表单校验这些必须靠 UI 自动化。Playwright 是当前比较顺手的选择因为它的page.screenshot()可以精准截取元素、全页面或视口并且可以指定fullPage: true。我常用的脚本片段from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessTrue, args[--window-size1280,800]) page browser.new_page() page.goto(http://localhost:8080/login) page.fill(input[nameusername], tester) page.fill(input[namepassword], Test123) page.click(button[typesubmit]) page.wait_for_load_state(networkidle) page.screenshot(pathevidence/TC-LOGIN-001_登录成功.png) browser.close()关键参数说明headlessTrue表示无头模式CI 里必须用但本地建议设成False能直观看到操作args[--window-size1280,800]是固定浏览器窗口大小不然截图尺寸不固定报告中排版会很乱wait_for_load_state(networkidle)是等所有网络请求结束再截图否则页面上可能还有 loading 状态。这一条代码解决的问题是同一个用例反复跑截图里的布局和字段位置不会变报告看起来专业。4. 测试截图的最佳实践时机、命名与嵌入 PDF 的完整流程4.1 截图时机选择不是每个用例都要截全屏测试报告需要的是“证据”不是“视频帧”。我在做图书管理系统测试时只会挑四类时机截图一是核心业务流程完成的那个页面比如借书成功的提示和库存变化二是断言失败时的实际结果页面这是开发排查缺陷最依赖的三是数据库或接口返回异常状态时需要把页面上对应展示的错误信息拍下来四是涉及金额计算如逾期罚款的页面需要把计算前和计算后都截。全链路截图只保留一条主干用例用于报告开头展示业务流程全景。对于如何让截图更有说服力我会对截图做两个处理第一在截图上用红色矩形框标出关键区域第二把截图上方自动加上测试用例编号和时间戳。Playwright 里实现标注需要配合图片处理我用 Python Pillow 写一个通用函数from PIL import Image, ImageDraw def mark_image(image_path, box, output_path, text): img Image.open(image_path) draw ImageDraw.Draw(img) draw.rectangle(box, outlinered, width3) draw.text((box[0], box[1]-20), text, fillred) img.save(output_path)这里box是(x1, y1, x2, y2)的四元组标注位置从哪里来可以自己根据页面元素坐标调试也可以简化让 Playwright 在截图时先用locator.bounding_box()获取元素位置然后把坐标传出来再调用mark_image。这样做的好处是报告阅读者不需要从整张截图里找文字提示直接顺着红框和编号就能定位问题。4.2 截图文件命名与目录规划截图存放目录需要和报告结构保持对应。我建议按模块分文件夹而不是全部平铺evidence/ ├── login/ │ ├── TC-LOGIN-001_正常登录.png │ └── TC-LOGIN-002_密码错误提示.png ├── borrow/ │ ├── TC-BORROW-001_借书成功.png │ └── TC-BORROW-002_库存不足.png └── return/ └── TC-RETURN-001_逾期罚款计算.png文件里包含用例编号和简短描述中间用下划线连接。这样用脚本生成 PDF 时可以直接根据文件名里的用例 ID 和对应测试结果打包。如果命名随意比如1.png、2.png那么后期写报告时还需要人工对照既慢又容易错。测试报告里的截图必须能追溯到具体用例这是做测试报告的基本功。4.3 把 Markdown 中间格式转成带截图的 PDF最常见做法是先写一份 Markdown 测试报告模板然后用 Pandoc 加 XeLaTeX 转 PDF。但图片插入需要路径正确截图文件名中有中文可能会报错我一般把图片重命名为纯英文和数字。先准备好报告正文report.md其中用引用截图。然后执行pandoc report.md \ --pdf-enginexelatex \ -V mainfontNoto Sans CJK SC \ -V geometry:margin2cm \ -o 图书管理系统测试报告_含测试截图.pdf-V mainfont指定中文字体不指定的话生成的 PDF 里中文部分会是空白。geometry控制页边距默认 LaTeX 页边距偏大截图缩小后可能看不清。如果要更细致的排版可以使用--from markdown --toc生成目录。但 Pandoc 方案的限制是图片宽度控制不灵活所以我更常用另一种方式用 Python 脚本直接拼接 PDF。4.3.1 用 ReportLab 直接生成测试报告 PDF当截图数量多且需要按测试结果动态排列时脚本生成比写死模板更实用。ReportLab 的SimpleDocTemplate搭配Table可以做出带有表头和截图单元格的页面。代码结构如下from reportlab.lib.pagesizes import A4 from reportlab.pdfgen import canvas c canvas.Canvas(book_test_report.pdf, pagesizeA4) width, height A4 # 写入标题 c.setFont(Helvetica-Bold, 18) c.drawString(50, height - 50, 图书管理系统测试报告) # 插入截图 c.drawImage(evidence/borrow/TC-BORROW-001_borrow_success.png, 80, height - 350, width200, height120) c.setFont(Helvetica, 10) c.drawString(80, height - 360, TC-BORROW-001 借书成功) c.showPage() c.save()drawImage的参数分别是图片路径、左下角 x/y、显示宽度和高度。需要提前计算图片的宽高比否则图片会变形。更省事的方式是先用 PIL 读取图片尺寸再计算绘制高度from PIL import Image img Image.open(evidence/borrow/TC-BORROW-001_borrow_success.png) ratio img.height / img.width draw_width 180 draw_height draw_width * ratio c.drawImage(path, 80, height - 200, widthdraw_width, heightdraw_height)这样每一张截图都能按照比例缩放。报告中还可以加一个封面试标题、日期、测试人员然后从第二页开始放正文。全部内容用这段脚本生成最终的 PDF 就实现了“含测试截图”这一要求。5. 测试报告可读性优化从“堆截图”到“问题定位型报告”5.1 给截图加上缺陷关联标记在最后一章我想说一个在真实项目中经常被忽略的点测试报告里的截图不是给测试自己看的而是给开发定位问题用的。一张截图要是没有对应缺陷编号开发接到报告后还要问“这个是哪个 bug”效率立刻下降。我建议在每张截图的下方标注与该截图相关的缺陷 ID 或风险等级。比如TC-RETURN-003的截图下写“关联缺陷 BUG-302逾期罚款金额显示为负数”。如果缺陷管理系统里的编号能够被 PDF 内的文本识别读者可以直接复制编号去查库。5.2 用 Allure 的缺陷聚合信息辅助报告排版前面提到的 Allure 报告虽然不直接作为最终交付物但它的统计信息非常好用。执行完allure generate后打开allure-report的/data/suites.json可以拿到每个套件的通过率、失败原因。把这些数据导入写 PDF 的脚本就能在报告开头自动生成一张缺陷分布饼图或柱状图。这里用 matplotlib 生成图表再嵌入 PDF 即可import matplotlib.pyplot as plt plt.figure(figsize(6, 4)) modules [借阅归还, 图书管理, 读者管理, 检索] failed [7, 3, 3, 2] plt.bar(modules, failed) plt.title(各模块失败用例数统计) plt.savefig(failed_modules.png)注意 Allure 默认不给出“按模块失败数”的细分需要自己在测试用例名称中加模块前缀然后脚本按前缀聚合。这一步做完测试报告不再是流水账而是有分析结论的文档。但不要写什么“综上所述”直接在报告里放图表和结论就行。5.3 截图清晰度与体积平衡测试报告 PDF 如果截图过多体积会膨胀到几十 MB发到群里或作为邮件附件都会被嫌弃。我一般会对截图为 PNG 格式先做一次压缩保留 80% 质量或者把 PNG 转成 JPEG黑白截图用 PNG彩色界面用 JPEG。ReportLab 的drawImage本身支持preserveAspectRatioTrue, maskauto来保持比例但体积控制还是要靠前置压缩。压缩的代码可以放在生成 PDF 之前批量处理find evidence -name *.png -exec convert {} -quality 80 {}.jpg \;最终 PDF 里的截图必须让读者在放大 150% 时依然能看清表单里的文字和报错信息否则截图就失去了存在的意义。这也是“含测试截图”的测试报告与普通文档之间的分水岭不是贴了图就叫含截图而是每一张图都要在需要放大查看细节时保持足够的分辨率同时整个文件体积又不至于大到无法传播。本文还有配套的精品资源点击获取 图书管理系统测试报告怎么写？带截图和自动化证据链
简介图书管理系统测试报告 PDF 文档面向软件测试学习者、系统开发人员及高校相关专业学生可用于课程设计、毕业设计或项目验收时的测试文档参考。报告以图书管理系统为对象完整覆盖测试目的、项目背景、定义说明、运行环境、需求概述、测试方案、测试项目与测试准备等环节并重点介绍黑盒测试、白盒测试和灰盒测试方法分别对应图书信息管理、借阅管理、查询统计等模块的用例设计与条件约束文末还提供了测试评价的范围与准则。文档内含测试截图可以对照操作界面验证测试结论帮助读者掌握从测试计划设计、用例执行到结果评价的完整流程并迁移到其他管理信息系统中。资源为1个PDF文件总大小946KB已有1671人学习下载适用于软件测试实训和报告模板参考。1. 图书管理系统测试报告为什么值得写成一份“带截图”的文档在交付软件测试结果时真正能被开发人员、产品经理和客户同时快速接受的往往不是一张密密麻麻的缺陷清单而是一份能“看得见”的测试报告。图书管理系统这类业务逻辑清晰但分支繁多的项目尤其是 PHP、Java 或 .NET 等不同技术栈实现时登录、借阅、归还、检索、超期罚款等模块之间存在大量状态关联单靠文字描述缺陷复现步骤经常出现“开发说复现不了测试说就按你写的做的”这类扯皮。把关键操作路径和失败现场用测试截图固定下来嵌入 PDF 报告里本质上就是把“可复现性”变成可交付资产。这篇文章我会从测试报告的结构设计说起讲清楚测试用例怎么排布、接口和 UI 自动化如何产出可追踪的数据、截图怎么拍才不算白拍以及最后如何把散落的证据汇总成一份能直接发给任何人的 PDF。内容面向正在做测试报告整理、想提升报告说服力的 QA、开发兼测试以及刚接手图书管理系统这类业务系统的外包实施人员。2. 测试报告的核心结构与用例设计先把图书管理系统的测试范围定清楚2.1 图书管理系统测试范围与功能拆解一份合格的测试报告不是把测试结果按时间顺序贴出来而是要先告诉读者“我测了什么、没测什么、怎么判定通过”。以图书管理系统为对象常规模块拆分如下读者管理注册、登录、信息修改、注销、图书管理录入、编辑、下架、库存查询、借阅与归还借书、续借、归还、逾期计算、分类检索按书名、作者、ISBN、分类号、系统设置权限、参数配置。实际测试报告里我会先用一张功能矩阵表说明各模块覆盖情况模块用例总数已执行通过失败阻塞通过率读者管理3232292190.6%图书管理4141373190.2%借阅归还5553447283.0%分类检索2828262092.9%系统设置1515141093.3%这张表放在报告开头读者一眼就能知道整体风险集中在借阅归还模块。报告正文的每一章再对应展开对应模块的测试截图就放在该章节下面而不是把所有截图堆在附录里。这样做的检索价值在于当开发人员只看自己负责的模块时可以按图索骥直接翻到对应页。2.2 测试用例优先级与覆盖策略用最少的用例命中核心风险图书管理系统的业务核心是“借—还—查”闭环所以用例优先级不能按功能模块平均分配。我一般会按 P0/P1/P2 三层划分P0 是主干路径比如读者登录后成功借书、图书库存扣减、归还后库存恢复P1 是重要分支比如读者有逾期未还图书时是否还能继续借书、借书数量达到上限时的提示P2 是异常和边界比如 ISBN 输入 10 位和 13 位、借书日期跨月、库存为 0 时检索还显示在列表中。在设计用例时每个功能至少覆盖一条正向用例、一条反向用例和一条边界用例这样到测试报告汇总时通过率和缺陷分布才有分析意义。2.2.1 借阅归还模块的用例优先级示例以“归还图书”为例P0 用例是“正常归还库存增加”P1 用例是“归还超期图书计算并展示罚款金额”P2 用例是“重复归还同一本书弹出错误提示”。针对这三个优先级我在报告里会给出对应的用例表格每行包含用例编号、前置条件、操作步骤、预期结果、实际结果、截图名。截图文件名与用例编号一一对应比如TC-BORROW-001_正常归还.png。这样测试报告中的截图不是孤立的附件而是用例链条上的一部分。2.3 测试数据准备与状态清理图书管理系统的状态字段在馆、借出、预约中、逾期相互关联测试数据如果共用一份很容易出现一条用例的失败导致后面全部用例无法继续。我一般会用独立测试库并且在每个用例开始前用 SQL 重置业务状态而不是依赖界面操作。比如执行归还测试前需要保证该图书处于“借出”状态且读者没有未完成的借阅记录。在报告里我会在“测试环境与数据准备”一节写明数据库初始化脚本片段-- 重置图书状态为在馆清除借阅记录 UPDATE book SET status AVAILABLE WHERE book_id BK-1001; DELETE FROM borrow_record WHERE book_id BK-1001; DELETE FROM fine_record WHERE book_id BK-1001;这段 SQL 的作用是让每条用例都在同一起跑线上。如果不做状态重置第二次运行用例时可能因为库存已经被扣减而直接失败那么报告里记录的失败原因就不是真实的代码缺陷而是测试数据污染。所以测试报告里不仅要写“测试结果”还要写“测试数据是如何隔离的”这才叫一份让 5 年以上工程师也觉得有信息量的报告。3. 用接口测试和自动化测试生成可追踪的执据Postman、Newman 与 Allure 定制报告3.1 为什么接口层要跑一遍测试再截图很多人做图书管理系统测试时直接打开浏览器一点一点点击然后截图。这种做法对 UI 验证是必要的但缺陷是借阅、归还这类操作涉及库存扣减和状态变更如果只截 UI 结果无法证明后端接口返回了什么数据。所以我会先用 Postman 跑接口级测试把接口响应和断言结果作为证据再配合 UI 截图。这样测试报告里的每一张截图背后都对应一个明确的接口请求和响应开发和测试都能快速定位问题。3.2 用 Newman 命令行跑接口测试并输出 Allure 可读报告Postman 集合写好之后可以导出为 JSON接着用 Newman 在命令行批量执行。常见做法是newman run book-management.postman_collection.json \ -e book-management.postman_environment.json \ -d testdata/borrow-cases.csv \ --reporters cli,json,allure \ --reporter-allure-export ./allure-results这条命令的要点-e指定环境变量文件包含 baseUrl、token、readerId 等-d指定数据文件CSV 里每一行就是一组参数化的测试数据--reporters allure会让 Newman 把每次请求的请求体、响应体、断言结果都输出到allure-results目录。运行结束后再执行allure generate ./allure-results -o ./allure-report allure open ./allure-report就能打开本地报告。因为标题里提到“基于 psotman 定制化 allure 测试报告”这里展开说一点定制化Allure 默认展示的是整个集合的执行概况但测试报告需要按模块过滤可以在断言代码里用pm.info加上标签。比如在 Postman 的 Pre-request Script 或 Tests 里写pm.info.setName(借阅模块-正常借书); pm.info.addTag(BORROW);在 Tests 脚本里除了断言响应状态码为 200我还会断言返回的 JSON 里有bookId和dueDate并且dueDate晚于当前日期这样才算借书成功。如果没有这些断言接口返回 200 但业务逻辑错了Allure 报告里也会显示绿色通过测试报告就失去了信服力。3.2.1 Allure 定制报告里放什么粒度Allure 报告中的每个测试步骤对应一次接口请求而测试报告 PDF 中不可能贴全部请求。我一般只把 Allure 报告中标记为FAILED的用例和其响应截图截取出来嵌入 PDF。这样可以做到“截图带上下文”在 PDF 里放一张请求的 JSON 小图和一张响应报错的 JSON 小图再配一张 UI 上的报错提示截图三段拼成一个完整证据链。Allure 本身有allure attach的能力但在 Postman 环境下更简单的方式是把响应体保存成 JSON 文件后续用脚本插入报告newman run book-management.postman_collection.json -r json --reporter-json-export ./newman-output.json然后用一个小脚本过滤失败用例的响应体存成evidence/failed-{caseId}.json。这个动作是为了后面的 PDF 组装做准备而不是直接生成最终报告。3.3 用 Playwright 做 UI 自动化并接管截图接口测试证明后端逻辑没问题但页面交互、提示文案、表单校验这些必须靠 UI 自动化。Playwright 是当前比较顺手的选择因为它的page.screenshot()可以精准截取元素、全页面或视口并且可以指定fullPage: true。我常用的脚本片段from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessTrue, args[--window-size1280,800]) page browser.new_page() page.goto(http://localhost:8080/login) page.fill(input[nameusername], tester) page.fill(input[namepassword], Test123) page.click(button[typesubmit]) page.wait_for_load_state(networkidle) page.screenshot(pathevidence/TC-LOGIN-001_登录成功.png) browser.close()关键参数说明headlessTrue表示无头模式CI 里必须用但本地建议设成False能直观看到操作args[--window-size1280,800]是固定浏览器窗口大小不然截图尺寸不固定报告中排版会很乱wait_for_load_state(networkidle)是等所有网络请求结束再截图否则页面上可能还有 loading 状态。这一条代码解决的问题是同一个用例反复跑截图里的布局和字段位置不会变报告看起来专业。4. 测试截图的最佳实践时机、命名与嵌入 PDF 的完整流程4.1 截图时机选择不是每个用例都要截全屏测试报告需要的是“证据”不是“视频帧”。我在做图书管理系统测试时只会挑四类时机截图一是核心业务流程完成的那个页面比如借书成功的提示和库存变化二是断言失败时的实际结果页面这是开发排查缺陷最依赖的三是数据库或接口返回异常状态时需要把页面上对应展示的错误信息拍下来四是涉及金额计算如逾期罚款的页面需要把计算前和计算后都截。全链路截图只保留一条主干用例用于报告开头展示业务流程全景。对于如何让截图更有说服力我会对截图做两个处理第一在截图上用红色矩形框标出关键区域第二把截图上方自动加上测试用例编号和时间戳。Playwright 里实现标注需要配合图片处理我用 Python Pillow 写一个通用函数from PIL import Image, ImageDraw def mark_image(image_path, box, output_path, text): img Image.open(image_path) draw ImageDraw.Draw(img) draw.rectangle(box, outlinered, width3) draw.text((box[0], box[1]-20), text, fillred) img.save(output_path)这里box是(x1, y1, x2, y2)的四元组标注位置从哪里来可以自己根据页面元素坐标调试也可以简化让 Playwright 在截图时先用locator.bounding_box()获取元素位置然后把坐标传出来再调用mark_image。这样做的好处是报告阅读者不需要从整张截图里找文字提示直接顺着红框和编号就能定位问题。4.2 截图文件命名与目录规划截图存放目录需要和报告结构保持对应。我建议按模块分文件夹而不是全部平铺evidence/ ├── login/ │ ├── TC-LOGIN-001_正常登录.png │ └── TC-LOGIN-002_密码错误提示.png ├── borrow/ │ ├── TC-BORROW-001_借书成功.png │ └── TC-BORROW-002_库存不足.png └── return/ └── TC-RETURN-001_逾期罚款计算.png文件里包含用例编号和简短描述中间用下划线连接。这样用脚本生成 PDF 时可以直接根据文件名里的用例 ID 和对应测试结果打包。如果命名随意比如1.png、2.png那么后期写报告时还需要人工对照既慢又容易错。测试报告里的截图必须能追溯到具体用例这是做测试报告的基本功。4.3 把 Markdown 中间格式转成带截图的 PDF最常见做法是先写一份 Markdown 测试报告模板然后用 Pandoc 加 XeLaTeX 转 PDF。但图片插入需要路径正确截图文件名中有中文可能会报错我一般把图片重命名为纯英文和数字。先准备好报告正文report.md其中用引用截图。然后执行pandoc report.md \ --pdf-enginexelatex \ -V mainfontNoto Sans CJK SC \ -V geometry:margin2cm \ -o 图书管理系统测试报告_含测试截图.pdf-V mainfont指定中文字体不指定的话生成的 PDF 里中文部分会是空白。geometry控制页边距默认 LaTeX 页边距偏大截图缩小后可能看不清。如果要更细致的排版可以使用--from markdown --toc生成目录。但 Pandoc 方案的限制是图片宽度控制不灵活所以我更常用另一种方式用 Python 脚本直接拼接 PDF。4.3.1 用 ReportLab 直接生成测试报告 PDF当截图数量多且需要按测试结果动态排列时脚本生成比写死模板更实用。ReportLab 的SimpleDocTemplate搭配Table可以做出带有表头和截图单元格的页面。代码结构如下from reportlab.lib.pagesizes import A4 from reportlab.pdfgen import canvas c canvas.Canvas(book_test_report.pdf, pagesizeA4) width, height A4 # 写入标题 c.setFont(Helvetica-Bold, 18) c.drawString(50, height - 50, 图书管理系统测试报告) # 插入截图 c.drawImage(evidence/borrow/TC-BORROW-001_borrow_success.png, 80, height - 350, width200, height120) c.setFont(Helvetica, 10) c.drawString(80, height - 360, TC-BORROW-001 借书成功) c.showPage() c.save()drawImage的参数分别是图片路径、左下角 x/y、显示宽度和高度。需要提前计算图片的宽高比否则图片会变形。更省事的方式是先用 PIL 读取图片尺寸再计算绘制高度from PIL import Image img Image.open(evidence/borrow/TC-BORROW-001_borrow_success.png) ratio img.height / img.width draw_width 180 draw_height draw_width * ratio c.drawImage(path, 80, height - 200, widthdraw_width, heightdraw_height)这样每一张截图都能按照比例缩放。报告中还可以加一个封面试标题、日期、测试人员然后从第二页开始放正文。全部内容用这段脚本生成最终的 PDF 就实现了“含测试截图”这一要求。5. 测试报告可读性优化从“堆截图”到“问题定位型报告”5.1 给截图加上缺陷关联标记在最后一章我想说一个在真实项目中经常被忽略的点测试报告里的截图不是给测试自己看的而是给开发定位问题用的。一张截图要是没有对应缺陷编号开发接到报告后还要问“这个是哪个 bug”效率立刻下降。我建议在每张截图的下方标注与该截图相关的缺陷 ID 或风险等级。比如TC-RETURN-003的截图下写“关联缺陷 BUG-302逾期罚款金额显示为负数”。如果缺陷管理系统里的编号能够被 PDF 内的文本识别读者可以直接复制编号去查库。5.2 用 Allure 的缺陷聚合信息辅助报告排版前面提到的 Allure 报告虽然不直接作为最终交付物但它的统计信息非常好用。执行完allure generate后打开allure-report的/data/suites.json可以拿到每个套件的通过率、失败原因。把这些数据导入写 PDF 的脚本就能在报告开头自动生成一张缺陷分布饼图或柱状图。这里用 matplotlib 生成图表再嵌入 PDF 即可import matplotlib.pyplot as plt plt.figure(figsize(6, 4)) modules [借阅归还, 图书管理, 读者管理, 检索] failed [7, 3, 3, 2] plt.bar(modules, failed) plt.title(各模块失败用例数统计) plt.savefig(failed_modules.png)注意 Allure 默认不给出“按模块失败数”的细分需要自己在测试用例名称中加模块前缀然后脚本按前缀聚合。这一步做完测试报告不再是流水账而是有分析结论的文档。但不要写什么“综上所述”直接在报告里放图表和结论就行。5.3 截图清晰度与体积平衡测试报告 PDF 如果截图过多体积会膨胀到几十 MB发到群里或作为邮件附件都会被嫌弃。我一般会对截图为 PNG 格式先做一次压缩保留 80% 质量或者把 PNG 转成 JPEG黑白截图用 PNG彩色界面用 JPEG。ReportLab 的drawImage本身支持preserveAspectRatioTrue, maskauto来保持比例但体积控制还是要靠前置压缩。压缩的代码可以放在生成 PDF 之前批量处理find evidence -name *.png -exec convert {} -quality 80 {}.jpg \;最终 PDF 里的截图必须让读者在放大 150% 时依然能看清表单里的文字和报错信息否则截图就失去了存在的意义。这也是“含测试截图”的测试报告与普通文档之间的分水岭不是贴了图就叫含截图而是每一张图都要在需要放大查看细节时保持足够的分辨率同时整个文件体积又不至于大到无法传播。本文还有配套的精品资源点击获取