武汉金泉医疗科技软件测试面经：测试流程、用例设计与偶发 Bug 排查

《面试题目》

1. 自我介绍。
2. 软件测试的流程是什么？
3. 测试的目的是什么？
4. 设计测试用例有哪些方法？
5. 一个输入框只能输入 1-100 的整数，包含 1 和 100 这两个边界值，怎么设计测试用例？
6. 测试用例的八大要素是什么？
7. 一个搜索框输入关键词点击确定就跳转到搜索结果页面，怎么设计测试用例？
8. 黑盒测试和白盒测试的区别是什么？
9. Linux 下创建文件、删除文件、创建目录分别用什么命令？
10. 开发说这次软件改动比较小、不用测了，怎么办？
11. 项目里印象最深的 Bug，是怎么复现与排查的？
12. 实习过程中遇到的最大困难是怎么解决的？
13. 测试过程中遇到偶发的 Bug 怎么办？
14. 你的职业规划是什么？
15. 你最大的优点和缺点分别是什么？
16. 有了解过公司的产品和行业吗？
17. 你怎么看加班？
18. 反问环节（答：路径是测试员到测试经理，有带教，软硬件占比五五开）。

---

《参考解析》

测试流程与测试目的：先给骨架，再给判断

标准流程按「需求评审 → 测试计划 → 测试用例设计 → 用例评审 → 执行测试 → 缺陷提交与跟踪 → 回归测试 → 测试报告与上线放行」讲，但要补一句每个阶段的交付物：计划阶段出测试范围、人力与排期、环境需求；设计阶段出用例和测试数据；执行阶段出缺陷单和执行记录；报告阶段给的是「测得怎么样、还剩什么风险」而不是一张通过率的截图。面试官常追问的点是「测试什么时候介入」——正确答案是从需求评审就介入，需求阶段的歧义改一个字成本最低，等到提测再发现口径不对，返工的是整个迭代。

测试的目的不能只说「找出 Bug」。更完整的说法有两层：一是尽可能早地发现缺陷，因为缺陷发现得越晚修复成本越高，测试是把质量成本前移的手段；二是给发布提供依据——用可度量的覆盖度和缺陷收敛趋势，让团队知道当前版本能不能发。同时要主动说清测试的边界：测试能证明有缺陷，不能证明没有缺陷，所以质量不是测出来的，是设计与开发阶段做进去的，测试是最后一道验证。这一句话往往是区分「背过书」和「真想过」的地方。

用例设计题：区间输入框与搜索框，考的是分类的完整性

1-100 整数输入框这道题，答案的主体是等价类划分 + 边界值。有效等价类是 1 到 100 之间的整数；无效等价类要一条条摆开：小于 1（0、-1、-100）、大于 100（101、1000）、非整数（1.5、0.5）、非数字（字母、汉字、符号）、空值、纯空格、超长数字、科学计数法（1e2）、全角数字（１２３）、前导零（007）、前后带空格（50）。边界取 1、2、99、100，以及紧邻边界外的 0 和 101——边界取「上点、内点、离点」三组更规范。再往上叠一层非功能用例：粘贴超长文本、输入时按退格清空、输入后点提交与回车是否一致、并发快速点击提交、输入法中文状态下输入数字。面试里能把这层说出来，比只列 0 和 101 要扎实得多。

搜索框跳转搜索结果页，思路要从「输入」扩到「整条链路」。输入维度沿用上面那套（空、纯空格、超长、特殊字符、SQL 注入与 XSS 字符串、大小写、中英文混排）；交互维度要看点击确定与按回车结果是否一致、快速连点是否重复跳转、跳转后返回是否保留原关键词；结果页维度看无匹配时有没有友好的空态、结果分页与排序是否正确、关键词是否高亮、大结果量时的性能；异常维度看断网、接口超时、接口返回错误码时页面的兜底表现。用例写到这里，面试官通常会顺势问「你怎么保证覆盖率」——可以答按需求条目做「用例—需求」双向追溯，再加评审和冒烟集合兜底。

用例八大要素：口径不止一种，答清楚你用的是哪种

常见的两种口径都要知道。一种是面向执行的八项：用例编号、用例标题、所属模块或关联需求、前置条件、测试数据、操作步骤、预期结果、优先级。另一种是偏文档管理的：用例编号、测试项目、用例标题、重要级别、预置条件、测试输入、操作步骤、预期结果（有的公司把设计者和日期也算进去）。面试时不要硬背唯一答案，可以说「我们用的是前一种，另外还有把设计者、日期算进来的版本」，顺带说清每条的作用——编号是唯一标识便于追溯，前置条件和测试数据决定这条用例能不能被别人一次执行成功，预期结果是判定通过与否的唯一依据，优先级决定时间不够时先跑哪些。真被追问「用例标题和步骤有什么区别」，答标题是「测什么」（一句话说明验证点），步骤是「怎么测」，别把两者写成同一句话。

黑盒、白盒与 Linux：答概念要顺带答适用场景

黑盒测试不看内部实现，只从输入和输出验证行为是否符合需求，方法就是等价类、边界值、判定表、场景法、错误推测，面向的是功能测试、界面测试、接口测试；白盒测试要读代码结构，按语句覆盖、判定覆盖、条件覆盖、判定条件覆盖、条件组合覆盖、路径覆盖来设计，通常发生在单元测试阶段，由开发或测试开发来做。灰盒是知道部分内部结构（比如知道接口和数据表）之后设计用例，接口测试是最典型的灰盒场景。面试官问这题通常是想确认你会不会把两者对立起来——实际项目里是分层的：单元层面白盒、集成与系统层面黑盒，覆盖率工具（JaCoCo 之类）只是把白盒的覆盖情况量化出来。

Linux 那三条命令是入门题，答的时候顺手把常用变体一起给出更显熟练：创建文件用 touch a.txt，也可以 echo "内容" > a.txt 或 vim a.txt；创建目录用 mkdir dir，要多级目录加 -p（mkdir -p a/b/c）；删除文件用 rm a.txt，删除目录用 rm -r dir，空目录可以 rmdir dir。这里必须主动补一句 rm -rf 的风险——生产环境误删不可恢复，测试环境删数据前先确认路径、先备份或先 ls 确认。后面很可能被追问「查日志用什么」：tail -f、grep、less、find、ps -ef | grep、netstat -tunlp、df -h，测试岗问 Linux 基本都落在看日志和查进程上。

软性问题：真正被评估的是风险意识和协作方式

「开发说改动很小不用测了」是这组题里最值钱的一道，考的是你会不会用立场对抗代替风险判断。正确的拆法有三步：先要变更点——让开发说清改了哪个文件、哪个函数、影响哪条链路、有没有改公共逻辑；再做影响面分析——改动行数少不等于风险低，改一个判断条件可能影响全部下游，改一个常量可能只影响一个提示文案，判据是「被影响的业务路径有多宽、这段代码被多少场景复用、历史缺陷是否集中在这里」；最后一起定测试范围——可以按风险做最小回归集而不是全量回归，但必须留一条底线：核心链路冒烟必跑，同时用灰度发布、监控告警、可快速回滚来兜住残余风险。回答里出现「我会跟开发沟通并评估影响面，把结论和风险同步给负责人做决定」，比「他让不测我就不测」和「他说不用我也一定要全量测」都更职业。

「印象最深的 Bug 怎么复现排查」不要只讲结论，按「现象 → 复现 → 定位 → 修复验证」讲：现象要带环境、账号、数据、时间点；复现要能给出最小复现步骤和复现率；定位靠日志、抓包、数据库查询、二分法缩小范围、和开发对时间线；修复后用同一路径回归并补一条回归用例。没有日志的场合先提「加日志和埋点」，这个动作本身就是加分项。

「偶发 Bug 怎么办」的核心是「不放过，但也不能只靠反复点」。要做的是第一时间保留现场——截图、日志、请求返回、时间戳、请求 ID；提高日志级别或加埋点，把偶发变成可观测；写脚本或压测工具做大批量、并发、慢网络、切后台等异常场景放大复现概率；如果是并发或时序问题，去看共享状态、缓存、连接池、定时任务这些高嫌疑区。最后仍然要按影响面定处理优先级并记录在案，不能因为「偶发、不好复现」就默默关掉——很多线上事故就是从这个借口开始的。

HR 类的那几题同理：职业规划要落到「一两年内把业务和测试技术栈吃透、能独立负责模块的质量」，别答成「想转开发」；优点缺点要各配一个真实证据，缺点挑可改进的（比如对不熟悉的技术栈上手慢）并给出正在怎么改；了解公司和行业这题要在面试前真的去看公司官网和产品，医疗科技这条线要知道产品面向医院还是患者、有没有注册与合规要求、软硬件结合意味着测试要碰设备和联调；加班的问法本质是在确认预期是否一致，答「项目紧张时能配合，同时也关注长期效率和流程改进」即可，不要为了拿 Offer 说「无条件接受」。最后反问环节可以问清带教机制、团队软硬件测试的分工比例、版本节奏和上线流程——原帖的答复是路径为测试员到测试经理、有带教、软硬件五五开，这类回答已经说明了团队规模不大，入职后大概率要两头都碰。