微信转账功能如何设计安全测试用例，并验证转账过程中密码不泄露？｜字节跳动测开面经解析

60 秒回答模板

我会先把微信转账抽象成支付类转账流程：选择收款人、输入金额、确认订单、输入支付密码、服务端校验、扣款入账、通知和账单。安全测试先做威胁建模，保护对象包括账户、余额、收款人、金额、支付密码、会话 token 和交易凭证。用例上要覆盖身份认证、收款人和金额不可篡改、越权转账、支付密码错误次数限制、会话过期、重复提交、弱网重试、回退重进、风控拦截和审计一致性。验证密码不泄露不能只看输入框是星号，要检查客户端日志、崩溃上报、剪贴板、截图、网络请求、服务端 access log、业务日志、数据库和消息队列中是否出现明文密码或可逆敏感值；在可控测试环境中可以用代理、日志扫描、测试桩和服务端审计 trace 验证。合格答案还要说明黑盒抓包无法完全证明服务端未记录密码，必须结合代码审查、日志脱敏规则和测试环境的端到端证据。

考点 资产和威胁

难度 真实面经题

回答目标 讲清设计、取舍和边界

深入解析

先做转账威胁建模

转账的核心资产是账户余额、收款人、金额、支付密码、会话凭证和交易记录。威胁包括冒用身份、篡改金额或收款人、绕过密码、重放请求、重复扣款、日志泄露和异常中断后状态不一致。

功能链路和安全链路一起测

正常转账要验证收款人确认、金额边界、密码校验、扣款入账和通知账单；安全测试要在每个阶段插入异常，例如改参数、过期会话、重复点击、断网重试、回退重进、密码错误和风控拦截。

密码保护不能只看 UI

输入框遮蔽只是最表层。还要验证密码不会进入剪贴板、截图、无障碍文本、客户端 debug 日志、崩溃日志、埋点、网络明文、服务端日志、数据库或消息队列。测试环境中应扫描关键字和字段，确认敏感字段被加密、token 化或脱敏。

传输和存储要有证据

网络层要验证 HTTPS、证书校验、请求不可被明文读取、敏感参数不在 URL 或日志里出现。服务端侧要检查 access log、应用日志、审计日志、错误栈和持久化字段，确保不记录明文密码。黑盒抓包只能证明链路外部不可见，不能替代服务端日志审计。

交易一致性和幂等要覆盖

支付类场景必须测重复提交、超时重试、客户端断线、服务端处理成功但客户端未收到、回调延迟和并发请求。断言是同一交易号只扣一次款，失败交易不扣款，状态机和账单一致，所有异常都有审计记录。

风险控制和审计闭环

还要验证密码错误次数限制、设备变更、异地登录、异常金额、频繁转账、黑名单和人工审核等风险控制是否触发。审计层要能追踪交易 id、用户、设备、风险决策和最终状态，同时不能泄露密码等敏感内容。

易错点

把安全测试写成普通转账功能测试，只覆盖输入金额和到账结果。
认为输入框显示星号就等于密码不泄露。
只做抓包，不检查客户端日志、服务端日志、崩溃上报和数据库。
忽略金额、收款人、订单号和签名字段的篡改测试。
没有覆盖重复点击、弱网重试和超时回调，可能导致重复扣款。
只强调加密，不说明证书校验、日志脱敏、审计和风控拦截证据。

面试官追问

只抓包没看到明文密码，能证明密码不泄露吗？

不能完全证明。抓包只能说明网络外部观察不到明文，仍需要检查客户端日志、崩溃上报、服务端日志、数据库、消息队列和代码脱敏规则。

支付密码输入框显示星号就安全吗？

不够。星号只是界面遮蔽，仍可能通过日志、剪贴板、截图、无障碍信息、埋点或请求参数泄露。测试要覆盖这些泄露面。

弱网重试下怎么防止重复转账？

客户端和服务端都应使用交易 id 或幂等键。测试重复点击、超时重试和回调延迟，断言只生成一笔有效扣款，重复请求返回同一结果或被安全拒绝。

如何测试金额或收款人被篡改？

在测试环境中拦截或构造请求，修改金额、收款人、订单号和签名字段，验证服务端以订单和签名为准进行校验，拒绝不一致请求并记录审计。

服务端日志需要保留什么、不能保留什么？

应保留交易 id、用户、设备、风险决策、状态流转和错误码，不能保留明文密码、完整 token、银行卡等敏感信息。必要敏感字段要脱敏或哈希化。