简介：这是西南科技大学计算机学院的一份计算器黑盒测试实验报告，面向软件测试初学者、计算机专业学生及需要完成类似实验报告的读者。报告以计算器程序为被测对象，系统展示了黑盒测试中等价类划分与边界值分析两种核心方法，涵盖加、减、乘、除四则运算的功能测试用例设计、执行过程、结果分析与界面截图。报告实测覆盖整数、小数、负数及无效输入等典型场景，并针对除法除数为零等边界值问题进行了专门验证，帮助读者直观理解测试用例设计背后的逻辑。资源为1个PDF文件，大小535KB，内容结构完整，从测试目的、测试步骤到结果分析一目了然。已有168人学习下载，适合用作用业参考、课程设计辅助或软件测试入门案例学习。
1. 计算器黑盒测试实验报告：先把被测对象和报告读者定清楚
拿到"计算器黑盒测试实验报告"这类任务时，最常见的做法是打开系统自带计算器按几个数、贴几张截图就交差，结果往往被批注成"用例没有设计依据""预期结果没有来源"。黑盒测试的核心是把计算器当作不透明盒子，只通过输入输出判断行为是否符合规格，所以报告的价值不在用例条数，而在三件事：输入域有没有被完整定义、预期结果能不能追溯、执行证据够不够支撑结论。读者通常是验收 QA、带实验课的老师、要接手计算器模块的嵌入式工程师，他们只关心一个问题——"你说它通过了，凭什么"。下文按方法选型、用例设计、执行、PDF 成稿、自查五步展开。
2. 黑盒测试方法选型：等价类划分、边界值分析与判定表在计算器上的落点
计算器功能简单，但状态不少，光靠"多按几次"堆用例，报告里讲不出依据。常见做法是把黑盒测试的三种方法分工：等价类划分负责把无限输入归成有限组，边界值分析负责把最容易出错的分界点单独拎出来，判定表负责处理连续按键这种组合条件。三个方法在计算器上各自管一段，下面按这个顺序落地。
2.1 功能拆解：先定义计算器的输入域与输出域
选方法之前，先把被测对象拆成输入域、显示域和状态域。标准型计算器的输入域包括数字 0-9、小数点、四则运算符、等号、清空（C/CE）、退格、正负号；显示域包括十进制结果、科学计数法结果、错误提示；状态域包括初始状态、输入过程状态、等号后的结果状态、出错状态。拆完列成一张表：
| 输入域 | 有效输入 | 无效输入 | 典型处理 |
|---|---|---|---|
| 数字 | 0-9 | 字母、控制字符 | 忽略或提示 |
| 小数点 | 每轮输入一个 | 重复小数点 | 忽略第二次 |
| 运算符 | + - × ÷ | 孤立运算符 | 等待操作数 |
| 正负号 | 数值输入过程中 | 等号后再按 | 切换符号 |
| 清空 | C / CE | 无 | C 清全部，CE 清当前输入 |
无效输入是黑盒测试的主战场。很多人只测"按了会不会报错"，正确的做法是测"按了之后系统处于什么状态"，并把状态变化写进预期结果。如果被测对象是科学型计算器，或者带角度输入的在线度分秒计算器，输入域还要追加度分秒格式校验：比如 45°30′00″ 的进制转换、以及三角函数对度分秒输入的解析结果，这些都要单独建等价类，不能和普通数字混在一起。
2.2 等价类划分与边界值分析：除法、小数与溢出的用例骨架
等价类划分把输入按"是否产生同类行为"分组。加法里 1+2 和 8+9 属于同一有效等价类，各取一条即可；除法里除数为零是无效等价类；连续按两次运算符属于交互等价类。边界值分析在等价类的基础上，把边界上点、内点、离点各取一条。计算器里最容易出边界用例的是除法和显示溢出，下面是一组可以直接抄进报告的用例：
| 用例方向 | 输入序列 | 预期结果 | 设计依据 |
|---|---|---|---|
| 有效等价类 | 8 ÷ 2 = | 4 | 正常除法 |
| 无效等价类 | 8 ÷ 0 = | 错误提示 | 除数为零 |
| 边界上点 | 8 ÷ 0.0001 = | 80000 | 除数接近零 |
| 边界内点 | 0 ÷ 8 = | 0 | 被除数为零 |
| 溢出边界 | 9999999999 + 1 = | 科学计数法 1e+10 或 Error | 显示位数上限 |
这里要特别说一个坑：边界不只是数字边界，还有显示边界。普通计算器显示位数有限，超过上限后进入科学计数法，不同实现的行为差异很大，所以预期结果列必须写"按被测对象的规格定义"，而不是按常识推断。浮点精度也属于边界范畴：0.1 + 0.2 在大多数实现里显示 0.30000000000000004。这条用例的关键不是判断对错，而是预先定义误差判定标准，比如"显示值与预期值误差不超过 1e-10 即判定通过"，否则执行时没法下结论。黑盒测试和白盒测试在这个场景的分工是：白盒看分支覆盖，黑盒看规格符合性，实验报告要求黑盒，就不要用代码覆盖率来凑数。
注意：预期结果列写的是"按规格定义的行为"，不是"我认为应该的行为"。规格缺失时，在报告"测试依据"一节注明该行为按同类产品默认行为处理。
2.3 判定表：处理连续按键与非法组合这类交互输入
等价类和边界值都处理单点输入，连续按键这种组合条件要用判定表。典型场景是：输入 2 按 +，还没按第二个数字就又按 ×，新运算符是替换旧的还是被忽略？再比如输入 2 + 3 = 之后再按 =，是重复上次运算还是无动作？这类交互行为必须写进报告，判定表给了出处：
| 规则 | 条件：已有待完成运算 | 条件：新运算符与旧相同 | 动作 |
|---|---|---|---|
| R1 | 否 | 不适用 | 记录运算符，进入等待操作数状态 |
| R2 | 是 | 是 | 忽略新运算符，状态不变 |
| R3 | 是 | 否 | 用新运算符替换旧运算符 |
判定表的价值在于：每条交互规则都有条件和动作的对应关系，写报告时能把"我为什么这么测"讲清楚。条件个数超过 5 个时全组合会爆炸，常见做法是先挑对行为有影响的条件，无关条件直接标"不适用"。判定表也可以转成可执行规则，下面是一段极简实现，用来在回归脚本里校验连续运算符行为：
# 判定表落地：连续运算符的解析规则 def resolve_operator(has_pending, old_op, new_op): if not has_pending: return new_op, "记录运算符" # 规则 R1 if new_op == old_op: return old_op, "忽略重复运算符" # 规则 R2 return new_op, "替换旧运算符" # 规则 R3 # 用例：2 + × 3，第二次按 × 时的行为 op, action = resolve_operator(True, "+", "×") print(action) # 期望输出"替换旧运算符"这段代码里 has_pending 表示是否已有待完成运算，old_op 是上一次按下的运算符，new_op 是刚按下的运算符。回归脚本里把按键事件映射到这三个入参，再断言 action 是否符合预期即可；重点不是实现本身，而是让判定表里的每条规则都有代码和用例双重覆盖。
3. 从用例设计到执行的完整闭环：基线确认、用例表格与脚本回归
方法定完，下一步是让用例真正跑起来。很多实验报告死在这一步：用例表设计得很漂亮，执行过程却只有模糊的"测试通过"四个字。要避免这个问题，需要把被测对象、用例字段、执行方式三件事一次性定清楚。
3.1 被测对象确认与基线记录：选 Win10 计算器还是自研实现
最常见的做法是选 Windows 10 自带的计算器，启动用 win10计算器快捷键：Win + R 打开运行窗口，输入 calc 回车。选它的理由很实际：系统自带、任何机器可复现、有稳定的 UI 自动化基础和现成截图手段。如果实验要求测嵌入式场景，常见替代是 Qt 计算器或开发板上的计算器模块，这时基线记录要额外写明固件版本和按键扫描方式。
基线记录是报告里第一块硬证据，至少包含六项：被测对象名称、版本号、操作系统版本、界面语言、运行模式（标准型/科学型）、测试日期。界面语言必须记录，因为自动化脚本里按钮是按显示文本定位的，中文系统写"加"，英文系统写"Plus"，语言不记录，结论就无法复现。
3.2 可抄作业的用例表格：字段、输入序列与预期结果
用例表格建议六列：用例编号、前置条件、输入步骤、预期结果、实际结果、结论。编号规则用 功能缩写-序号，比如 TC-ADD-001 表示加法第一条。下面是一个能直接用的模板：
| 用例编号 | 前置条件 | 输入步骤 | 预期结果 |
|---|---|---|---|
| TC-ADD-001 | 初始状态 | 按 1、加、2、等于 | 显示 3 |
| TC-ADD-002 | 初始状态 | 按 0、点、1、加、0、点、2、等于 | 显示 0.3，误差允许 1e-10 |
| TC-SUB-001 | 初始状态 | 按 5、减、8、等于 | 显示 -3 |
| TC-MUL-001 | 初始状态 | 按 2、乘、3、等于 | 显示 6 |
| TC-DIV-001 | 初始状态 | 按 8、除、0、等于 | 显示错误提示 |
| TC-CHN-001 | 等号后 | 按 2、加、3、等于、等于 | 显示 8 |
输入步骤必须写完整的按键顺序，不能只写"计算 1+2"。原因很简单：计算器是状态机，同样的数字按不同顺序会得到不同结果，比如 1+2= 和先按 12= 完全是两件事。预期结果要写完整，包括错误提示这种非数字输出。实际结果和结论两列留空，执行时逐条填，不要在用例设计阶段就写死。
3.3 用 pywinauto 把回归用例脚本化：连接、按键与断言
手工跑几十条用例没问题，但实验报告通常要体现出可重复性。常见做法是用 pywinauto 把关键用例脚本化，执行时一条命令跑完回归。先安装依赖：pip install pywinauto。下面是针对 TC-ADD-001 的最小脚本：
import time from pywinauto import Application # 启动 Win10 计算器，显式指定 uia 后端 app = Application(backend="uia").start("calc.exe") time.sleep(2) # 定位计算器主窗口 dlg = app.window(class_name="CalcFrame") # 按 1 + 2 =，按钮按显示文本定位 dlg.child_window(title="1", control_type="Button").click() dlg.child_window(title="加", control_type="Button").click() dlg.child_window(title="2", control_type="Button").click() dlg.child_window(title="等于", control_type="Button").click() # 用 auto_id 读取结果框，比按标题定位固定 result = dlg.child_window(auto_id="CalculatorResults").window_text() # 断言失败即回归失败 assert "3" in result, f"预期结果包含 3，实际结果为 {result}" app.kill()参数说明：backend="uia" 必须显式指定，Win10 计算器在默认 backend 下部分控件识别不到；title 绑定界面语言，脚本换到英文系统要改成 "Plus"、"Equals"；auto_id="CalculatorResults" 是结果控件的固定标识，所以取结果用 auto_id 而不是 title；time.sleep 是为了等窗口加载完，跑大批用例时建议换成 wait("ready") 这类就绪等待。如果被测对象是网页版计算器，思路一样：Selenium 定位按键、点击、读值、断言，只是定位器从 title 换成 xpath。
4. 实验报告结构设计与 PDF 生成：把测试证据链写成正式文档
执行完用例，报告本身决定了工作成果是否被认可。计算器黑盒测试实验报告不是流水账，PDF 形式意味着结构、字体、截图都要经得住打印和批注。这一章讲报告骨架和导出命令。
4.1 报告章节结构：从实验目的到缺陷清单的六段式
一份能直接交的报告，常见做法是六段式结构：实验目的（一句话说清被测对象是什么、验证什么）；被测对象与测试环境（对应基线记录）；测试依据与方法（说明等价类、边界值、判定表分别覆盖了哪些输入域）；用例设计与执行统计（用例表 + 通过/失败/阻塞统计）；缺陷清单；结论。其中缺陷清单最容易被追问，每条缺陷要有三样证据：触发步骤截图、实际输出截图、输入序列文本。缺陷登记表模板：
| 缺陷编号 | 关联用例 | 缺陷描述 | 严重级别 | 状态 |
|---|---|---|---|---|
| DEF-001 | TC-DIV-001 | 除零报错后直接输入数字，错误状态未清空 | 中 | 已确认 |
| DEF-002 | TC-CHN-001 | 连续等号行为与规格描述不符 | 低 | 待确认 |
描述缺陷时不要写"有点问题"这种模糊表述，要写"复现步骤 + 实际行为 + 期望行为"三段，严重级别按影响范围分高、中、低三档。执行统计里要写清通过率，并注明未通过用例都已进缺陷清单，这样结论部分才能站得住。
4.2 用 Pandoc 把 Markdown 导出成中文 PDF：命令与字体参数
报告写到 Markdown 里，再导出 PDF 是最省事的链路。首选的命令是 Pandoc 加 XeLaTeX 引擎：
pandoc report.md -o 计算器黑盒测试实验报告.pdf \ --pdf-engine=xelatex \ -V mainfont="Noto Sans CJK SC" \ -V geometry:margin=2cm \ --toc --toc-depth=2参数说明：--pdf-engine=xelatex 是中文 PDF 的关键，默认的 pdflatex 对中文字体支持很差；-V mainfont 指定中文字体，Linux 上常用免费的 Noto Sans CJK SC，Windows 上可以换成 "SimSun" 或 "Microsoft YaHei"；-V geometry:margin=2cm 控制页边距，实验报告打印版一般用 2cm 到 2.5cm；--toc 生成目录，--toc-depth=2 只收到二级标题，目录不会太长。
提示：导出前先确认系统里有可用的中文字体，运行 fc-list :lang=zh 查看已安装字体，没有字体时 PDF 里中文会全部变成方块。
如果机器上没有 TeX 发行版，退路方案有两个：一是 VSCode 装 Markdown PDF 插件直接导出；二是把 Markdown 渲染成 HTML 后，用浏览器打开走 web页面pdf打印，即 Ctrl+P 另存为 PDF。两条退路都不需要额外装引擎，但字体和页边距控制没有 Pandoc 那条命令精细。
4.3 截图命名、表格列数与结果措辞的排版约定
PDF 报告的排版问题集中在三处。截图命名直接绑用例编号：TC-DIV-001_input.png 和 TC-DIV-001_result.png，比"截图1"清晰得多，插进 Markdown 时用相对路径，例如：
相对路径的意思是图片和 report.md 在同一个目录树里，Pandoc 导出时会自动找；用绝对路径或者把图片放在系统临时目录，换机器导出就会断图。表格列数不要超过五列，超过就拆成子表，否则在 PDF 里会被截断。结果列统一用"通过/失败/阻塞"三态，不要写"可行""没问题"这类口语；通过率算成百分比后写进结论，并注明"未通过用例均已在缺陷清单 DEF-001 至 DEF-002 中登记"。
5. 交报告前的三个自查技巧：覆盖率矩阵、变异式校验与精度口径
报告写完到真正提交，中间应该有一轮自查。三个技巧成本很低，但能拦下大部分被批注的问题。
5.1 用"输入域 × 操作 × 状态"三维矩阵查漏测
把用例表压成一个矩阵，行是输入类型（正常整数、零、负数、小数、极大值），列是操作（加、减、乘、除），交叉点填用例编号：
| 输入类型 \ 操作 | 加 | 减 | 乘 | 除 |
|---|---|---|---|---|
| 正常整数 | TC-ADD-001 | TC-SUB-001 | TC-MUL-001 | 有 |
| 零 | 有 | 有 | 有 | TC-DIV-001 |
| 负数 | 有 | 有 | TC-MUL-001 | 有 |
| 小数 | TC-ADD-002 | 有 | 有 | 有 |
| 极大值 | 有 | 空 | 空 | 空 |
交叉点空缺的位置就是可能的漏测点，比如极大值的乘法和除法通常没设计用例。扫完输入域和操作域，再带着状态维查一遍：初始状态、输入过程中、等号之后、出错之后，四个状态下同一个按键行为可能不同，状态维没有覆盖到的用例要补。
5.2 变异式校验：故意改错预期结果，检验用例是否真的有效
抽查三条已经通过的用例，把预期结果改成错误值，重新执行。比如把 TC-ADD-001 的预期结果从 3 改成 4，如果脚本仍然通过，说明断言根本没有生效，要么是结果框读取失败，要么是参数定位到了错误的控件。这个方法对应变异测试的思路：通过注入错误来验证用例本身的有效性。执行前先想好结论，只有脚本真实报错，才说明这条用例有拦截能力；没报错的用例，要么修断言，要么从报告里删掉，不要留着充数。
5.3 浮点精度、负零与除零错误文案：实验结论里的口径处理
计算器报告里最常被批注的三个点，口径要先定好。浮点精度：0.1 + 0.2 显示 0.30000000000000004 时，报告里写"显示值与预期值误差小于 1e-10，判定通过"，并附上结果截图；除非被测对象规格明确要求精确十进制，否则不要把它登记成缺陷。负零：-1 × 0 有的实现显示 -0，规格没有定义时记为观察项，不判通过也不判失败。除零错误文案：不同系统提示各不相同，断言时匹配"错误状态"而不是具体文案字符串，这样换系统跑回归不会因为文案差异误报失败。把这三条处理口径作为"误差判定标准"小节写进实验结论，复查时直接指着这一节回应精度类质疑，报告被追问的次数会明显减少。
本文还有配套的精品资源，点击获取
