1. 项目背景与测试范围1.1 语伴聊天系统是做什么的语伴聊天系统本质上是一个面向语言学习者的实时交流平台。用户通过匹配语伴、发起文字或语音会话、在对话中完成语言练习。它解决的核心问题很简单语言学习不能只靠背单词和刷语法题必须有真实语境下的交流对象但线下找语伴受地域、时间、语言水平匹配等因素限制线上系统把这件事搬到了互联网上。我拿到的测试任务是这套系统的完整质量验证。测试对象包括Android端、iOS端、Web端三个客户端服务端部署在CentOS 7.6服务器上数据库使用MySQL 8.0缓存层使用Redis 6.2即时通讯模块基于WebSocket实现语音通话走的是WebRTC方案。测试周期共两周我带着一个测试组一共投入了3名测试工程师的人力。整个测试工作覆盖了功能测试、接口自动化测试、性能压测、兼容性测试、稳定性测试和安全测试六个维度最终产出的报告除了给研发团队看还要作为项目上线评审的准入依据。这套系统虽然业务逻辑不算复杂但涉及实时通信和多端同步测试的深度和广度都比普通业务系统要求更高。1.2 测试目标与准入准出标准测试目标不是泛泛的“保证系统质量”而是拆成了几个可量化的指标。功能测试方面核心功能用例通过率必须达到100%非核心功能用例通过率不低于95%。性能方面系统需支持3000并发用户在线核心接口的响应时间在压测环境下P95小于800毫秒。稳定性方面系统需在持续混合负载下稳定运行24小时不允许出现内存泄漏导致的OOM宕机。准入标准也很明确开发提测前必须完成单元测试且覆盖率不低于60%冒烟测试通过率100%才能进入正式测试阶段。准出标准则是所有阻断级Bug清零遗留问题必须有明确的版本修复计划性能和安全指标全部达标。这里有一个我做测试这些年反复强调的点测试报告不是测试结束才写的而是从测试计划制定那一刻就开始积累。我在整个测试过程中坚持每天输出测试日报包括用例执行进度、Bug分布情况、阻塞风险和明日计划。这样到最终输出完整测试报告的时候所有数据和结论都是有据可查的而不是靠回忆去补。2. 测试环境与工具选型2.1 硬件环境与部署架构测试环境搭得好不好直接决定测试结果有没有参考价值。我在搭建环境时坚持一个原则测试环境尽可能接近生产环境。很多团队拿低配机器跑性能测试测出来的数据夸夸其谈一上线就被打回原形这种情况我见过太多次了。本次测试环境的服务端采用的是与生产一致的配置应用服务器是4台8核16G的云主机部署了Nginx做负载均衡后端服务采用微服务架构拆分了用户服务、匹配服务、聊天服务、通知服务四个模块数据库为一主两从。压测机单独使用了2台4核8G的机器部署JMeter避免压测工具本身成为瓶颈影响测试结果。客户端测试机覆盖了Android 10/11/12/13共4个系统版本共使用8台不同品牌和配置的Android机型覆盖高中低三个档位。iOS端使用了iPhone 11、iPhone 12、iPhone 13和iPhone 14四款设备系统版本从iOS 14到iOS 16。Web端覆盖了Chrome、Edge、Firefox、Safari四个主流浏览器的最新两个大版本。这里有个经验要补充iOS设备数量有限时至少保证覆盖当前最新版本和用户量最大的前两个版本历史版本如果有条件就做兼容没条件就通过线上版本分布数据来取舍。Android端则是机型碎片化严重优先选择市场占有率高的热门机型。2.2 测试工具链与数据准备接口自动化测试我选了Python Pytest Requests这套组合搭配Allure生成测试报告。这套方案的优势是生态成熟、上手快、报告展示效果好团队内部都有使用经验不需要额外培训成本。性能测试工具选择了JMeter配合ServerAgent监控服务器资源用Grafana Prometheus监控应用层指标。数据库压测这块用到了BenchmarksQL针对MySQL做基准测试主要看数据库在标准负载下的TPS和QPS表现为后续业务压测结果提供参照基线。这很有价值——如果压测发现性能瓶颈先对比基准数据能快速判断是SQL问题还是应用逻辑问题而不是两眼一抹黑到处排查。测试数据准备是很多团队忽略的环节。我提前准备了10000个模拟用户账号其中2000个用户带有完整的语伴匹配偏好设置。准备了5000条匹配记录和30000条聊天消息用于功能测试和接口测试的查询场景。性能测试的数据量则是按生产预估数据量的1.5倍准备的这样测出来的索引优化效果才真实可信。我坚持要求开发人员提供生产数据库的脱敏数据导入到测试环境而不是测试自己编造数据。原因很简单生产数据有真实的数据分布特征比如消息长度分布、用户活跃度分布、好友关系密度等这些特征直接影响了SQL查询计划的效率自己造数据往往过于均匀测不出真实场景下的性能问题。3. 功能测试设计思路与执行策略3.1 测试用例设计与模块覆盖语伴聊天系统的功能测试我按照用户操作路径把整个系统拆成了五大模块注册登录模块、语伴匹配模块、聊天会话模块、语音通话模块和个人中心模块。注册登录模块覆盖了手机号验证码登录、微信授权登录、账号密码登录三种方式。语伴匹配模块是系统的核心亮点需要重点验证匹配算法的准确性和匹配效率测试用例覆盖了按语言、按学习目标、按兴趣爱好、按水平等级四类筛选条件组合。聊天会话模块是整个测试的重头戏覆盖了文字消息、图片消息、语音消息、表情消息的收发消息的已读未读状态聊天记录的本地缓存与云端同步消息撤回、消息删除、会话置顶等交互功能。语音通话模块测试了1对1语音通话的拨打、接听、拒绝、占线、超时无人接听五种状态流转通话过程中的网络切换处理。整个功能测试我采用了等价类划分、边界值分析、场景法、错误推断法四种用例设计方法结合使用。比如手机号校验我用等价类划分法确定了有效手机号和无效手机号两类然后用边界值分析法补充了11位手机号上限和10位手机号下限的用例。每个功能点至少有一条正向用例和一条反向用例核心功能点每条用例都关联了需求编号确保需求可追溯。3.2 核心功能模块的测试深度语伴匹配这个模块我第一次测试时就发现了算法层面的隐患。连续点击“换一批”10次以上推荐列表开始出现重复用户有些用户甚至在连续5次换一批中反复出现。原因是匹配服务的推荐列表没有做去重处理每次请求只是从候选池里随机抽取候选池较小的用户画像场景下重复率急剧上升。我和开发沟通后了解到推荐逻辑是根据用户设置的语言偏好和兴趣标签从用户池里做SQL查询然后通过随机函数打乱结果取前20条返回。当筛选条件组合较少时候选池可能只有几十人随机函数并不能保证多次抽样结果不重复。最终的修复方案是在匹配服务里增加一个基于Hash的去重集合每次请求过滤掉已推荐过的用户ID如果候选池耗尽则重置去重集合。聊天模块的测试里我特别关注了弱网环境下的消息状态同步。用Charles模拟3G网络、高延迟、丢包三种弱网场景分别在发送文字和图片消息时观察客户端行为。发现的问题是弱网下发送图片消息消息卡片一直显示“发送中”但实际上服务器已经成功收到并存储了图片。客户端重试机制触发了重复发送导致服务端出现两条相同的图片消息。这是一个典型的幂等性问题后来开发在消息发送接口增加了消息ID幂等校验才从根本上解决。语音通话的测试我使用了Appium模拟了更复杂的中断场景通话中插入系统电话、闹钟提醒、低电量弹窗验证应用是否能正确处理音频焦点被抢占的情况。Android端在插入来电时通话会直接断开且不会自动重连而iOS端则是通话保持但对方听不到声音。这两个问题都属于系统级音频焦点处理的Bug分别在不同平台上有不同表现修复时也需要分开处理。3.3 功能测试执行过程与Bug统计功能测试共执行了两轮。第一轮发现的Bug数量明显较多共记录了76个问题其中严重级别的问题有9个。这9个严重问题主要集中在语音通话无声、消息乱序、登录状态失效三个模块分布在Android端的有7个iOS端有2个。第二轮回归测试时第一轮的问题已修复78个剩余6个延期问题均有明确的版本计划同时新增了5个回归相关的问题。Bug的分布有一个值得关注的规律越是用户操作路径长的场景Bug密度越高。比如从“注册登录—完善资料—设置偏好—进入匹配—发起聊天—接收回复”这个完整流程中发现的问题占了总数的28%。原因是这些长链路场景涉及的模块多接口调用链条长任何一层的异常处理不到位都会暴露问题。我习惯在Bug统计时区分“功能缺陷”和“体验缺陷”。功能缺陷是用户无法完成核心操作链路的问题体验缺陷是操作可以完成但交互反馈不够友好的问题。这次测试中功能缺陷有61个体验缺陷有15个。体验缺陷虽然不影响功能可用性但直接影响用户留存比如匹配成功后没有明显动画反馈、聊天消息删除后没有撤销入口这些问题都进入了需求的优化池。4. 接口自动化与性能压测实录4.1 接口自动化测试的实现与执行语伴聊天系统的后端接口有47个按优先级我从中筛选出32个核心接口做了自动化覆盖覆盖率达到68%重点集中在用户、匹配、消息、关系链四类核心接口。自动化用例共编写了186条包含正向用例102条、异常用例84条。异常用例的设计并不是简单传一个错误参数我会根据接口的业务规则、权限控制、参数边界、依赖关系四个维度来设计。以发送消息接口为例正向用例覆盖了文本、图片、语音三种消息类型正常发送和接收的完整流程。异常用例覆盖了消息内容为空的请求、接收方不存在的请求、发送方未登录的请求、消息长度超过限制的请求、发送频率过高的请求这五类典型场景。每一个异常用例都需要断言两个层面接口返回的状态码是否正确、错误信息是否符合约定的错误码规范。自动化测试框架我采用了分层设计思想数据驱动层用YAML文件维护测试数据接口封装层封装了请求方法、登录鉴权、签名算法用例执行层用Pytest管理用例和fixture报告展示层用Allure生成包含请求、响应、断言的完整报告。这样的框架结构维护成本低新增接口用例只需要在数据文件里加几行配置不需要改任何代码。本轮自动化测试共发现了5个接口相关的Bug其中3个是参数校验不严格导致的例如用户昵称接口未校验特殊字符长度导致提交包含emoji的超长昵称时数据库存储异常。另外2个是异常场景下接口返回的HTTP状态码不符合规范比如未登录访问匹配接口应当返回401实际返回了403。这种问题在手工测试中很容易漏掉自动化脚本用统一断言一查一个准。4.2 性能测试场景设计与压测执行性能测试的场景设计我摒弃了单一接口压测的做法而是按用户真实操作占比设计了混合场景。根据产品数据统计语伴匹配系统的高频操作分布为登录请求占比10%、匹配推荐请求占比30%、消息发送请求占比25%、消息拉取请求占比20%、会话列表请求占比10%、其他操作占比5%。混合压测场景按这个比例分配请求权重才能真实反映生产环境的负载模型。压测过程分了三步走。第一步是基准测试单接口单线程跑确定每个接口的基准响应时间。第二步是负载测试逐步增加并发用户数从500、1000、2000到3000观察各接口响应时间和系统资源使用率的变化趋势。第三步是稳定性测试用2000并发持续跑24小时观察内存、线程、连接池等指标是否有泄漏趋势。真实的压测数据在这里记录一下系统在1000并发时匹配列表接口的P95响应时间是320毫秒升到2000并发时P95到了580毫秒到3000并发时P95变成了760毫秒依然在800毫秒的目标线以内。消息发送接口的性能表现稍差一些3000并发下P95达到了920毫秒超过了目标线成为整个系统中最先出现性能瓶颈的接口。压测过程中有个细节特别值得记录消息发送接口在压测进行约30分钟时出现了一次明显的TPS跌落。从监控数据看Redis的CPU使用率从45%瞬间跳到了80%以上。日志排查后发现是消息未读数量的缓存Key设置了统一的过期时间大量Key在同一时刻过期引发了缓存雪崩。这个问题的修复方式是给缓存Key设置随机过期时间并且在数据库查询层加了本地缓存兜底。4.3 性能瓶颈分析与优化建议基于BenchmarksQL的MySQL基准测试结果在本机测试环境下MySQL能够稳定支撑的TPS约为4200QPS约为23000。但在业务压测中消息发送接口涉及对消息表的插入、对会话表的更新、对未读数的Redis更新三个操作事务链条长3000并发时数据库服务器的CPU使用率已达到75%是主要的资源消耗点。分析慢查询日志发现消息表的查询出现了全表扫描的情况。查看执行计划后定位到原因会话列表查询时使用了user_id和session_id两个条件做排序但索引只建立在session_id上。优化方案是创建了一个联合索引(user_id, update_time)把会话列表的查询从全表扫描优化为索引覆盖扫描查询耗时从850毫秒降到了120毫秒效果非常明显。WebRTC语音通话属于实时通信不能简单用JMeter做常规压测我在测试中采用了Kite工具模拟WebRTC呼叫。在100路并发通话的负载下观察了音视频传输的延迟、抖动和丢包率三个核心指标测试结果为平均延迟420毫秒、抖动50毫秒、丢包率2.8%整体处于可接受范围。但如果并发通话数继续翻倍就建议引入SFU类型的媒体服务器来分担压力而不是继续使用P2P直连架构。5. 兼容性与安全测试专项5.1 多端兼容性矩阵测试兼容性测试在移动应用领域的重要性怎么强调都不过分。我在执行兼容性测试时建立了一个多维矩阵从操作系统版本、屏幕分辨率、网络环境、系统语言四个维度做交叉验证。Android端的重点在于屏幕适配和系统权限差异iOS端的重点在于系统版本间的API差异和权限弹窗逻辑差异。Android端共执行了218条兼容性用例发现的主要问题集中在Android 10及以下的系统上语音消息播放时没有正确请求录音权限导致播放失败部分国产ROM在后台运行时限制了WebSocket连接导致消息推送延迟严重这个问题需要推进ROM厂商的白名单申请或者改用厂商推送通道做消息推送兜底。iOS端共执行了176条兼容性用例发现的问题相对较少。一个值得注意的问题是在iOS 16系统上首次启动应用时连续弹出通知权限和麦克风权限两个系统弹窗如果用户在第一个弹窗未处理时就操作页面会导致应用出现短暂的无响应。这个问题最终通过在启动流程中增加权限引导页统一管理权限请求时机来解决。模拟器上的测试真的不能完全替代真机测试。语音通话的音频路由策略、消息推送到达率的统计、相机和相册的调起速度这些场景在模拟器上的表现和真机差异很大。我在测试中固定使用4台真机作为主测机模拟器只用来覆盖系统版本兼容性和屏幕尺寸适配的场景。5.2 专项安全测试要点安全测试我重点关注了五个维度越权访问、数据加密、传输安全、输入注入、敏感信息泄露。越权访问测试中发现了一个比较典型的水平越权问题——通过修改聊天会话ID参数一个用户竟然能读取到不属于自己的聊天记录。原因是服务端查询聊天记录时只校验了会话ID是否存在没有校验当前用户是否是这个会话的成员。垂直越权这块问题不大因为系统的角色模型相对简单只有普通用户和管理员两个角色。但管理员接口的身份验证强度不够后台管理系统仅使用了JWT作为鉴权凭证没有启用IP白名单。我建议增加了管理员操作的双因素认证并对后台管理接口全部接入独立的认证网关。数据加密检查的结论是用户的聊天消息在传输层使用了TLS加密数据库存储时采用了AES-256进行字段级加密密码使用了BCrypt加盐散列存储整体的加密策略符合合规要求。但Web端的用户会话Token在本地存储中是以明文形式保存在localStorage里的存在被XSS窃取的风险建议改为HttpOnly Cookie方式保存会话凭证。输入注入专项测试中我分别对登录接口、搜索接口、消息接口的输入参数做了SQL注入和XSS注入测试。使用sqlmap自动扫描和手工构造恶意Payload两种方式结合幸运的是没有发现SQL注入的问题。XSS测试发现消息内容和用户昵称字段没有完全过滤HTML标签存储型XSS有触发风险开发在服务端统一增加了输出编码和富文本白名单过滤后复测结果通过了验证。6. 测试总结与经验沉淀6.1 测试结论与上线评估整个测试周期跨了两周时间功能测试共发现81个Bug其中严重级别9个、一般级别46个、轻微级别26个。迭代完成后已修复72个剩余9个问题中4个是低概率偶现问题、3个是优化型需求、2个是第三方SDK的兼容问题均有明确的后续版本计划。性能测试各项核心指标基本达标匹配推荐接口的P95响应时间从压测初期的760毫秒优化到了500毫秒以内消息发送接口经过索引优化后响应时间也回落到760毫秒左右。从上线评估的角度我的结论是当前版本满足上线条件但建议WebRTC语音通话模块采取灰度发布策略先开放10%的流量观察线上通话质量数据再逐步放开。同时消息发送接口在3000并发下仍存在性能隐患建议在上线后持续监控线上P95指标若出现劣化趋势立即启动对该接口的进一步拆分和异步化改造。测试报告中的数据整理有一个原则我一直坚持不对测试结果做任何粉饰也不为了呈现好看的数据去调整压测参数。测试报告的价值在于客观反映系统的真实质量状况如果数据不好看恰恰说明系统还没达到上线标准这时候通过调整参数让数据变好看是在坑害项目而不是帮助项目。6.2 测试工作的几点实际体会这次语伴聊天系统的测试做下来我感触最深的还是沟通成本问题。测试团队和开发团队之间如果各说各话测试报告写得再漂亮也没有价值。我在项目推进过程中坚持每天花15分钟和开发负责人同步测试进展遇到阻塞性问题第一时间拉会沟通Bug单的描述也严格要求包含操作步骤、预期结果、实际结果、优先级、日志信息、截图或录屏七个要素确保开发拿到Bug单就能复现不需要再来回追问。测试工具链的投入是值得的。接口自动化用例的执行时间从手工回归的两天压缩到了25分钟而且每次执行结果都会自动推送到项目群里任何一次回归造成的接口异常都能在最快时间内被发现。性能测试的监控体系搭建起来之后不只服务这次压测后续每次发版都可以快速跑一轮基准对比判断新代码是否引入了性能退化。最后说一句掏心窝的话测试这份工作最有成就感的时刻不是提交一份满是绿色通过图标的报告而是通过测试发现那些用户会真实踩到的坑并且推动团队把这些坑填平。语伴聊天系统从测试启动到最终验收整个质量提升的过程有数据可查、有结论可依这才是测试报告应该有的样子。