软件测试实习避坑指南：黑盒白盒与SQL查证实战

简介一份软件测试实习总结报告约1400字主要面向软件测试实习生、应届生以及需要撰写实习总结或复盘测试工作的初级从业者。报告按理论掌握、系统操作、BUG流程、实践经验、学习目标与实习结论等模块展开理论部分解释了黑盒、白盒、灰盒测试及测试生命周期实操部分结合电力行业输电网、配电网、理论线损等场景记录了控制中心建单位、画接线图、用SQL查询排查问题等环节同时梳理了缺陷发现、报告、修复、验证、关闭的生命周期及团队角色分工。包体为单个doc文档大小仅13KB方便直接查看和编辑已有91人学习。对想快速了解软件测试岗位日常内容、梳理测试流程与BUG管理要点的读者来说这份总结能提供较真实、具体的写作参考和入门指导。1. 从理论笔记到电力业务系统实习生第一周的认知差第一周的前三天几乎全在看理论知识测试定义、黑盒白盒、测试流程看起来和学校课件没有区别。真正让人懵的是年后来上班的第一天主管说的不是“去测登录功能”而是“先去看控制中心”。控制中心里全是输电网、配电网、分压分区、理论线损这些名词每一个都要先查一遍再继续往下看。学校里的课程设计做的是物理删除系统里用户只能注销不能删除PPT里的接线图是画好的现场需要自己拖拽输电线路、跨接线和馈线。这些差距不是背基础知识能补上的而是要钻进系统里一个个点过、错过后才记得住。这是一篇真实的软件测试实习记录也把新人最容易踩的坑整理成可以对照的检查项适合正在软件测试实习或者准备软件测试实习生面试的人参考。2. 黑盒、白盒与灰盒测试方法选型在电网系统里的实际边界软件测试面试题里最常见的题目之一就是讲清楚黑盒、白盒、灰盒的区别。教材版本的答案很简单黑盒不关注内部实现白盒关注代码逻辑灰盒关注接口和数据结构。真实项目里测试方法的选择首先取决于你能看到什么其次才是被测对象适合什么。学校的课程设计建几个表、几个页面黑盒白盒随便用电力行业的系统涉及输电网、配电网、分压分区、理论线损等业务概念新人连系统里的名词都认不全更谈不上设计白盒用例。2.1 三种测试方法不是三选一而是三条互补的观察通道2.1.1 黑盒测试不打开代码先把功能边界摸清实习前两周的黑盒测试基本都是执行功能验证。比如在控制中心建一个单位设置角色、分配用户、配置数据权限然后观察单位是否出现在组织机构树里角色用户能否正常登录数据权限是否影响查询结果。这个过程中不打开任何代码只看输入和输出正好用来熟悉业务规则。黑盒测试的产出都在表面上但陷阱也在表面上。最初建单位时不知道数据权限是什么意思直接留空结果组织机构里建好的单位在电网树中显示不出来。后来才明白数据权限不是给单位填一个备注而是决定“谁能看到这条数据、在哪个维度汇总”的开关。这类问题在黑盒测试里很难靠“多点点”发现需要把系统里的业务对象关系摸清楚。2.1.2 白盒测试覆盖率和分支逻辑是后期专项教材里白盒测试讲的是语句覆盖、分支覆盖、路径覆盖这些在实习初期基本用不上。真实情况是实习生没有代码权限系统也不是开源的代码覆盖工具更不会在入职第一周就装到开发环境上。白盒测试更适合安排在熟悉系统之后的专项阶段比如针对电量计算模块配合开发同学提供的单元测试报告去看哪些分支没有被覆盖到。如果方向是测试开发白盒能力越早补越好。但就当前这份实习来说核心任务是把业务逻辑和数据状态搞清楚。等到能看懂表结构、知道每个元件属性里哪些是唯一标识之后再谈白盒执行才有效果。2.1.3 灰盒测试接口与数据库是实习生最合适的切入点灰盒测试在文档里解释得很抽象落到日常操作上就是“一边操作界面一边查数据库”。添加一个用户之后到用户表里看记录是否落库修改单位名称之后到组织机构表里看父级ID和排序字段是否正确。这种方式比纯黑盒多一层数据验证又比白盒少很多代码成本是实习生上手最快的测试方式。这里有个细节值得注意学校课程设计里的系统大多是物理删除删掉就没了真实系统的用户、元件、组织机构往往采用逻辑删除界面上的删除只是给数据打一个标记。灰盒测试的价值在于能直接看到这些标记字段的变化避免把“系统BUG”误判成缺陷。2.2 软件测试流程不只是顺序更是交付节奏软件测试基础知识里反复强调测试计划、测试设计、测试执行、测试报告的顺序实际上线项目里这些环节是交错的。三周的实习里主管不会等一份完整的测试计划写完才让接触系统而是让一边看控制中心的帮助文档一边顺手把系统里的功能点过一遍因为这个阶段的目标是熟悉系统而不是正式执行测试。阶段文档/产出物关键内容使用者测试计划测试计划文档测试范围、人员安排、环境、进度测试负责人测试设计测试用例文档前置条件、操作步骤、预期结果测试执行人员测试执行缺陷报告/执行记录复现步骤、实际结果、截图日志开发与测试测试报告测试报告用例执行率、缺陷统计、遗留风险项目经理、产品对应到这份实习里计划文档对应主管口头列出的学习安排先看控制中心、再画图、再学SQL用例文档对应把系统帮助文档导成Word按步骤对每个功能点过一遍缺陷报告对应后来误以为“同名元件是BUG”的那次查询经历。面试时能讲清楚“我在测试计划阶段负责整理哪些输入、在测试执行阶段遇到过什么误判”比完整背出软件测试流程更有说服力。3. 控制中心实操数据权限、拓扑图绘制与删不掉的测试数据3.1 为什么新人要从控制中心开始控制中心是电力营销与配网管理系统里最基础的操作入口。组织机构、配电网拓扑、台区档案、元件属性几乎都在这一层维护。先看控制中心相当于先掌握系统的主数据来源后面测业务模块时才知道界面上的数据是从哪里来的。这一段的实习方式是把系统里的帮助管理生成Word文档然后照着文档点一遍。看起来比视频教程慢实际效果却不错。视频教程是别人操作你看着自己点系统时脑子不会跟着走对着文档操作每一步都要自己判断按钮在哪、输入什么值。3.2 数据权限漏配为什么单位建好了却不显示最初建单位时没管数据权限这个字段结果组织机构里建好的单位在电网树那边根本不显示。第一反应是系统错了查了半天才发现问题出在自己身上。数据权限在教材里很少单独讲但在真实系统里它就是“你看得见哪些数据”的开关和角色权限完全是两回事。对比项物理删除逻辑删除删除行为数据直接从表中删除记录保留状态字段置为失效界面表现列表不再出现列表不再出现数据可查性无法查询数据库仍可查到适用场景测试数据、临时数据正式档案、操作历史记录数据权限和逻辑删除是同一类问题界面表现和数据状态并不完全一致。界面看不到不代表没有界面看得到也可能只是残留记录。测试这样的系统必须习惯把界面操作和数据状态放在一起看。3.3 拓扑图绘制从一拖就失控到双击左键停止画接线图、配线图、台区图是控制中心里最容易被低估的一类操作。从工具栏拖输电线路、跨接线、馈线时一开始总是拖起来就停不住元件被带得满画布乱跑鼠标也挪不开只能粗暴地关掉绘图窗口。后来才知道拖拽过程中双击左键就能停止。这类操作在测试用例里属于基本交互但是对电力行业系统的测试来说绘图是业务基础能力用例设计时不能只考虑“能不能画”还要考虑画错之后怎么撤销、误操作后系统是否保留中间状态。这类细节在软件测试项目实战的视频教程里很少看到只有自己操作过才能形成对交互边界的判断。3.4 用户只能注销不能删除逻辑删除在测试中的表现添加的角色用户只能注销不能彻底删除这是一个典型的设计约束。随手添加的一堆测试用户都删不掉每次查询看到一大堆乱命名的用户时都很无奈。这个约束不是BUG是系统为了保留审计痕迹而设计的逻辑删除策略。从测试角度看遇到这种设计应该在用例设计阶段就把“恢复”“注销”“重建”作为组合场景覆盖而不是等误操作之后才意识到。软件测试项目实战和学校作业的区别就在这里学校作业验证功能正确真实项目还要验证数据状态流转是否正确。4. BUG生命周期与缺陷判定那些像BUG又查不到依据的现象4.1 BUG状态流转不叫New和Closed也还是同一套逻辑软件测试八股文里把BUG生命周期背得滚瓜烂熟实际工作中各公司叫法不同但底层逻辑完全一致一个缺陷从提交开始会经历确认、修复、验证、关闭几个阶段每个阶段都有对应的角色动作。刚入职时最容易犯的错是只看界面表现就提交缺陷忽略了对数据状态的确认。BUG状态含义操作角色参考动作新建New缺陷已提交测试附复现步骤、截图、环境信息打开Open开发确认有效开发关联代码改动、标注修复版本修复Fixed已提交修复开发关联提交记录等待回归已验证Verified回归通过测试执行原步骤确认已修复关闭Closed确认无效或修复完成测试/负责人记录关闭原因拒绝Rejected非缺陷或设计如此开发测试复核后关闭实习中实际用到的不是背状态名而是理解每个状态切换前的确认动作。最常见的误操作是提交一个缺陷前没有先在数据库里确认数据状态结果问题不在系统逻辑而在测试环境数据本身。这套“先查数据再下结论”的思路放到银行软件测试等强合规领域也是基本功。4.2 两个一模一样命名的元件是BUG吗有一次恢复被删元件后又新建了同名元件系统里出现两条完全相同的记录。第一反应是系统出了BUG指导老师让用SQL查一下两者区别结果发现一条是逻辑删除前的旧档案恢复后与新建记录并存系统允许这种场景存在。这个案例给到的启发是判定BUG之前先做数据比对。先查两条记录是否在同一张表、主键是否相同、失效标记字段值是否不同。如果这些都正常那么“同名”只是业务约束问题不是数据缺陷。很多被当成“BUG”的现象查完数据库之后结果都是人为误操作或测试数据污染。4.3 描述一个可以复现的BUG至少要包含的信息很多实习生提交的BUG描述只有一句话比如“单位在电网树里不显示”。这种描述开发接过去没法处理。可以用下面的格式组织【前置条件】使用具有数据权限配置角色的账号登录控制中心 【操作步骤】 1. 进入组织机构选择根节点点击新增单位 2. 填写单位名称、编码不勾选数据权限 3. 保存后在左侧电网树刷新 【实际结果】新增单位不出现在电网树中 【期望结果】单位出现在电网树对应层级下 【环境信息】测试环境版本号以登录页为准 【严重程度】P2这套格式不是公司规定的模板但信息完整度是判断缺陷报告质量的底线。标题里写清楚模块和现象步骤里写清楚入口和输入值开发能快速复现测试后续做回归验证时也能按同一路径执行。写缺陷报告和写软件测试简历模板是同一个思路让看的人第一眼就抓到重点。5. PL/SQL实操用SQL把“看不懂的系统”变成可查证的数据5.1 学校学过的MySQL在PL/SQL面前不够用学校课程设计里用MySQL建表、写增删改查理论清楚实际项目却很少直接用。到了实习单位数据库操作基本都在PL/SQL工具里完成语法尚在其次问题是完全不知道字段在哪个表、哪些字段能过滤、哪些字段是冗余展示。主管指了一条路先看帮助文档里的系统管理说明把每个功能点对应的数据表找出来再对照表结构理解字段用途。这个过程比直接问人要慢但自己建立的表结构印象后续写SQL时都用得上。另外还要补一类知识拼音缩写字段名。比如正向有功示值字段往往是zxyg期初示值是zxygqc不熟悉电力业务的话这些字段看起来就像乱码。5.2 三条核心SQL定位、比对、验证5.2.1 按名称模糊查询定位元件在哪个表-- 查询名称中包含“电能表”的元件 SELECT t.id, t.device_name, t.valid_flag, t.create_time FROM sys_device_info t WHERE t.device_name LIKE %电能表% AND t.valid_flag 0 ORDER BY t.create_time;这条SQL是定位类查询的标准写法。LIKE %电能表%做模糊匹配不管“电能表”出现在名称开头还是结尾都能命中valid_flag 0是只过滤有效记录的常见写法不同系统里可能是delete_flag或is_deleted字段名需要先从表结构确认ORDER BY create_time保证同名记录按创建时间排序后续对比时更容易看出来哪条是先建的。5.2.2 按时间与状态比对区分两条相似记录-- 比对两个“台区A01”元件的差异 SELECT d.id, d.device_name, d.valid_flag, d.create_time, d.operator_code FROM sys_device_info d WHERE d.device_name 台区A01 ORDER BY d.create_time;前面提到的“同名元件”案例就是用这类查询查清的。如果两条记录的valid_flag不一样其中一条是逻辑删除后恢复的如果operator_code不一样说明是不同操作员分别建立的档案。对比查询的关键是逐列比对不要只看名称相同就下结论。比较的记录数量多时建议把结果导出成CSV用Excel筛选差异字段。5.2.3 用示值数据验证电量计算逻辑-- 计算用户本月电量正向有功示值 - 正向有功期初示值 SELECT t.user_id, t.data_month, t.zxyg_cur AS 当前正向有功示值, t.zxyg_first AS 期初正向有功示值, (t.zxyg_cur - t.zxyg_first) AS calc_elec FROM ele_energy_data t WHERE t.user_id 10023 AND t.data_month 202502;这里zxyg_cur和zxyg_first是模拟字段名真实项目里示值字段多数是拼音缩写。主管专门强调过表计换过之后期初示值要按新表底数计算不能直接用当前示值减上次示值否则电量相差巨大。这类验证必须在SQL里先做一轮再回到界面确认数值是否一致两条路径都通过才算验证完成。5.3 写SQL前先搞清楚唯一标识写SQL前先问三个问题这张表的唯一标识是什么逻辑删除字段是哪个时间字段是VARCHAR还是DATE。唯一标识决定你能不能在表里精确命中一条记录逻辑删除字段决定查询结果里会不会混入无效数据时间字段的类型决定能否直接比较大小。“不了解表结构就直接写SQL”是实习阶段最容易犯的错。常见的现象是拿着一个字段名在全库试试了半天发现根本不是这个表。先打开表结构的说明文档确认字段再动手写查询效率高很多。这个习惯坚持三周之后面对一个陌生功能点时第一反应会从“点哪里”变成“数据存在哪个表”这是测试思维开始成熟的表现。6. 从跟点系统到执行小型测试任务一个最小闭环与检查清单6.1 最小闭环用例 SQL抽查 记录复现步骤进入执行阶段之前可以先给自己搭一个最小闭环拿一份已有测试用例照着步骤在系统里操作一遍每完成一步记录实际结果遇到结果与预期不一致时不要立刻下“BUG”的结论先用一条SQL查对应数据表确认是数据状态问题还是界面展示问题最终把经过SQL验证的差异整理成可复现步骤再提交缺陷。参加过全国大学生软件测试大赛实战训练的人对这种节奏应该不会陌生。这个闭环能让系统操作从“比葫芦画瓢”变成“有依据的执行”。照用例走系统解决的是操作路径问题SQL抽查解决的是数据状态问题记录复现步骤解决的是缺陷可追溯问题。三轮走下来系统里大部分功能区块都能覆盖到。6.2 以追补电量审核为例写一个最小用例追补电量是对表计故障、接线错误期间的电量损失做补偿计算后的审核操作。最小用例可以按五步写前置准备一台存在故障记录的表计期初示值明确操作在追补电量功能中输入追补电量数值提交审核校验用SQL确认审核状态表和电量记录表的数据变化回归修改追补电量数值确认审核状态是否重新流转收尾记录本次追补在日志表中的操作人和时间把这一条用例完整执行下来比列十步“打开页面、点击按钮”的空泛用例更有价值。面试时被问到“独立执行过哪些软件测试任务”把这条用例从设计到SQL校验讲清楚效果远好于背软件测试面试宝典。简历上写“独立执行测试任务”时这条用例就是现成的证明材料。6.3 放在工位上的几条个人检查项实习第三周结束时把容易漏的地方固定成一张个人检查项贴在工位旁边操作带权限的系统前先确认登录账号的数据权限范围新增数据后立即执行一条查询SQL确认落库和唯一标识遇到界面不显示先查逻辑删除标记再决定是否上报缺陷提交缺陷时按前置条件、操作步骤、实际结果、期望结果四段填写每次点击前想清楚“这一步在数据库里会改变哪个字段”本文还有配套的精品资源点击获取