新浪测试开发一面：压测工具、回归范围与登录用例设计

《面试题目》

1. 请做一下自我介绍。
2. 压测工具的开发上，除了利用 AI 工具，你主要独立完成了哪些部分？
3. 具体介绍一下系统优化的思路。
4. 时间确实不足以完成全量测试，那我们如何确定它可以回归的范围？
5. 测试用例的设计思路是什么？
6. 如何定义是否为有效 bug？
7. 针对登录接口如何设计测试用例？
8. 能否来提前实习？
9. 手撕代码：统计 records 的状态码、时间和数量。

《参考解析》

全量测不完时，回归范围怎么划

核心思路是从「按用例全集回归」切换到「按风险选回归」，用三个输入来决定范围：一是本次变更的影响面——改了哪个模块、被哪些上游依赖调用、是否动到公共组件、配置或数据结构；二是业务价值——下单、支付、登录这类核心链路无论改没改都要跑，边缘功能可以靠冒烟覆盖；三是历史缺陷分布，最近出过问题的模块和接口优先级更高。

落到执行上就是分层：核心用例集（P0，每次必跑，规模控制在能在发布窗口内跑完的量）＋ 变更相关用例（按影响面分析挑出来的）＋ 自动化冒烟（接口级、可秒级跑完）。同时用代码覆盖率或调用链数据反查「改了但没被测到」的部分，宁可少跑几条也要保证改动点被覆盖。最后一定要把「本次没测什么、依据是什么」写进测试报告，让风险显式化，而不是靠一句「时间不够」。

如何定义是否为有效 bug

有效 bug 至少要同时满足四条：① 可复现——能给出稳定的复现步骤、环境和数据，偶现问题也要说明复现概率和已定位的触发条件；② 与预期不符——预期结果的来源必须是需求文档、接口契约、设计稿或业界通用的隐性约定，不能是测试个人的偏好；③ 影响可描述——能说清影响范围、用户可见后果和严重程度，而不是「看着不对」；④ 不重复、非环境问题——先检索缺陷库，并排除测试环境自身的问题（配置、脏数据、依赖服务未就绪）。

容易被追问的边界是「需求没写清楚怎么办」：这种应该先按「与产品确认后形成结论」处理，把结论回写到需求或缺陷里，再判定有效性；不能因为文档没写就直接关掉，也不能凭个人理解开单。另外「开发说这是设计如此」时，判定权在产品，不在测试或开发任何一方。

登录接口的测试用例设计

按维度铺开：功能正例（正确账号密码 + 正确验证码登录成功、返回 token 与会话信息、跳转正确）；参数校验（账号/密码为空、超长、含空格与特殊字符、大小写、Unicode、密码前后端加密方式是否一致）；账号安全策略（连续错误 N 次锁定、锁定后解锁路径、错误提示不泄露「账号是否存在」、验证码错误与过期、图形/短信验证码刷新与重放）；协议与安全（HTTPS、密码不落日志、越权用他人 token、SQL 注入与 XSS 载荷、暴力破解频率限制、CSRF）；会话（token 有效期与续期、退出后 token 失效、多端登录策略、并发登录、篡改 token 与签名校验）；性能与并发（同一账号高并发登录、压测下的响应时间与错误率、Redis/DB 连接是否被打满）；兼容与异常（弱网、重复提交、服务端依赖不可用时的降级与提示）。

组织答案时最好先给一句方法：等价类划分 + 边界值 + 场景法，再按「功能、安全、性能、兼容」四类列出代表用例，说明哪些是必测的高优先级项。

手撕：统计 records 的状态码、时间和数量

这题的本质是「一次遍历做分组聚合」，考察能不能写出健壮的边界处理。基本解法是遍历 records，用一个 HashMap<Integer, Stat> 以状态码为 key 累加：count++、sumTime += time，同时维护 min/max，需要的话再按状态码记录耗时列表算分位数。

写的时候主动交代几个细节，比直接给出代码加分更多：① 时间字段的单位和类型（毫秒还是微秒、long 防溢出，累加用 long 而不是 int）；② 空集合、null 元素、状态码为 null 或负数时怎么处理；③ 是否需要按状态码排序输出，那就用 TreeMap；④ 空间只允许 O(状态码种类数)，不要把所有 record 都留下来；⑤ 如果 records 是并发产生的，改用 ConcurrentHashMap + LongAdder，或者先分片统计再合并（merge 的写法天然适合做这件事）；⑥ 如果要按时间窗口（比如每分钟 P99），就换成时间桶 + 分位数结构，而不是全量排序。