简介这是西南科技大学计算机学院的一份计算器黑盒测试实验报告面向软件测试初学者、计算机专业学生及需要完成类似实验报告的读者。报告以计算器程序为被测对象系统展示了黑盒测试中等价类划分与边界值分析两种核心方法涵盖加、减、乘、除四则运算的功能测试用例设计、执行过程、结果分析与界面截图。报告实测覆盖整数、小数、负数及无效输入等典型场景并针对除法除数为零等边界值问题进行了专门验证帮助读者直观理解测试用例设计背后的逻辑。资源为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 等价类划分与边界值分析除法、小数与溢出的用例骨架等价类划分把输入按是否产生同类行为分组。加法里 12 和 89 属于同一有效等价类各取一条即可除法里除数为零是无效等价类连续按两次运算符属于交互等价类。边界值分析在等价类的基础上把边界上点、内点、离点各取一条。计算器里最容易出边界用例的是除法和显示溢出下面是一组可以直接抄进报告的用例用例方向输入序列预期结果设计依据有效等价类8 ÷ 2 4正常除法无效等价类8 ÷ 0 错误提示除数为零边界上点8 ÷ 0.0001 80000除数接近零边界内点0 ÷ 8 0被除数为零溢出边界9999999999 1 科学计数法 1e10 或 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、等于显示 3TC-ADD-002初始状态按 0、点、1、加、0、点、2、等于显示 0.3误差允许 1e-10TC-SUB-001初始状态按 5、减、8、等于显示 -3TC-MUL-001初始状态按 2、乘、3、等于显示 6TC-DIV-001初始状态按 8、除、0、等于显示错误提示TC-CHN-001等号后按 2、加、3、等于、等于显示 8输入步骤必须写完整的按键顺序不能只写计算 12。原因很简单计算器是状态机同样的数字按不同顺序会得到不同结果比如 12 和先按 12 完全是两件事。预期结果要写完整包括错误提示这种非数字输出。实际结果和结论两列留空执行时逐条填不要在用例设计阶段就写死。3.3 用 pywinauto 把回归用例脚本化连接、按键与断言手工跑几十条用例没问题但实验报告通常要体现出可重复性。常见做法是用 pywinauto 把关键用例脚本化执行时一条命令跑完回归。先安装依赖pip install pywinauto。下面是针对 TC-ADD-001 的最小脚本import time from pywinauto import Application # 启动 Win10 计算器显式指定 uia 后端 app Application(backenduia).start(calc.exe) time.sleep(2) # 定位计算器主窗口 dlg app.window(class_nameCalcFrame) # 按 1 2 按钮按显示文本定位 dlg.child_window(title1, control_typeButton).click() dlg.child_window(title加, control_typeButton).click() dlg.child_window(title2, control_typeButton).click() dlg.child_window(title等于, control_typeButton).click() # 用 auto_id 读取结果框比按标题定位固定 result dlg.child_window(auto_idCalculatorResults).window_text() # 断言失败即回归失败 assert 3 in result, f预期结果包含 3实际结果为 {result} app.kill()参数说明backenduia 必须显式指定Win10 计算器在默认 backend 下部分控件识别不到title 绑定界面语言脚本换到英文系统要改成 Plus、Equalsauto_idCalculatorResults 是结果控件的固定标识所以取结果用 auto_id 而不是 titletime.sleep 是为了等窗口加载完跑大批用例时建议换成 wait(ready) 这类就绪等待。如果被测对象是网页版计算器思路一样Selenium 定位按键、点击、读值、断言只是定位器从 title 换成 xpath。4. 实验报告结构设计与 PDF 生成把测试证据链写成正式文档执行完用例报告本身决定了工作成果是否被认可。计算器黑盒测试实验报告不是流水账PDF 形式意味着结构、字体、截图都要经得住打印和批注。这一章讲报告骨架和导出命令。4.1 报告章节结构从实验目的到缺陷清单的六段式一份能直接交的报告常见做法是六段式结构实验目的一句话说清被测对象是什么、验证什么被测对象与测试环境对应基线记录测试依据与方法说明等价类、边界值、判定表分别覆盖了哪些输入域用例设计与执行统计用例表 通过/失败/阻塞统计缺陷清单结论。其中缺陷清单最容易被追问每条缺陷要有三样证据触发步骤截图、实际输出截图、输入序列文本。缺陷登记表模板缺陷编号关联用例缺陷描述严重级别状态DEF-001TC-DIV-001除零报错后直接输入数字错误状态未清空中已确认DEF-002TC-CHN-001连续等号行为与规格描述不符低待确认描述缺陷时不要写有点问题这种模糊表述要写复现步骤 实际行为 期望行为三段严重级别按影响范围分高、中、低三档。执行统计里要写清通过率并注明未通过用例都已进缺陷清单这样结论部分才能站得住。4.2 用 Pandoc 把 Markdown 导出成中文 PDF命令与字体参数报告写到 Markdown 里再导出 PDF 是最省事的链路。首选的命令是 Pandoc 加 XeLaTeX 引擎pandoc report.md -o 计算器黑盒测试实验报告.pdf \ --pdf-enginexelatex \ -V mainfontNoto Sans CJK SC \ -V geometry:margin2cm \ --toc --toc-depth2参数说明--pdf-enginexelatex 是中文 PDF 的关键默认的 pdflatex 对中文字体支持很差-V mainfont 指定中文字体Linux 上常用免费的 Noto Sans CJK SCWindows 上可以换成 SimSun 或 Microsoft YaHei-V geometry:margin2cm 控制页边距实验报告打印版一般用 2cm 到 2.5cm--toc 生成目录--toc-depth2 只收到二级标题目录不会太长。提示导出前先确认系统里有可用的中文字体运行 fc-list :langzh 查看已安装字体没有字体时 PDF 里中文会全部变成方块。如果机器上没有 TeX 发行版退路方案有两个一是 VSCode 装 Markdown PDF 插件直接导出二是把 Markdown 渲染成 HTML 后用浏览器打开走 web页面pdf打印即 CtrlP 另存为 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-001TC-SUB-001TC-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规格没有定义时记为观察项不判通过也不判失败。除零错误文案不同系统提示各不相同断言时匹配错误状态而不是具体文案字符串这样换系统跑回归不会因为文案差异误报失败。把这三条处理口径作为误差判定标准小节写进实验结论复查时直接指着这一节回应精度类质疑报告被追问的次数会明显减少。本文还有配套的精品资源点击获取