借着这次“小猪软件测试”项目的收尾我把整套测试过程重新过了一遍内容包括测试范围的梳理、一次典型的线上故障排查、自动化测试从零搭建、性能瓶颈定位以及兼容性测试的落地方式。“小猪”不是一个公开产品而是我们在内部反复用了四个月的项目代号它是一款社区生活类服务App涉及商品、订单、支付、库存、优惠券、配送这些电商核心链路。项目上线后的整体质量还算不错但过程中的坑一点都不少这篇文章就是把这些坑换成经验写出来。如果你是刚转行做测试的同学可以从头到尾读一遍如果你已经带项目了可以直接跳到第2节和第4节看环境治理和性能瓶颈定位的部分。我不保证所有方案都适合你的团队但至少能帮你少走几趟弯路。1. “小猪”项目的测试范围比想象中多出三个复杂点1.1 “小猪”到底测什么核心业务链路拆解“小猪”在项目内部一直是个代号它是一款社区生活类服务App核心场景是让用户在小程序里完成从浏览、下单到支付核销的整个闭环。技术侧并不复杂前端主要是小程序和H5后端是微服务架构服务之间通过HTTP和消息队列通信底层用MySQL、Redis和MongoDB。真正的复杂度不在某个单点技术上而在于业务链路太长登录之后要带出定位和门店信息门店信息决定商品库存和配送范围用户领券后下单下单时同时扣减库存、锁定优惠券、生成支付单支付回调回来再更新订单状态最后还要触发配送和核销消息。这条链路里任何一环出问题用户端看到的就是“下单失败”或者“支付成功但订单状态不对”。所以我在梳理测试范围时没有急着写用例而是先把这条主链路画出来把每两个系统之间的交互接口列成一张表再逐个标注异常情况。比如下单接口需要同时满足“商品上架”“门店营业”“库存充足”“优惠券可用”四个条件缺一个都要有明确的错误返回。测试范围不只是功能还包括接口契约、状态机、数据一致性、消息可靠性、权限控制。这些内容如果不在前期理清楚后面很容易漏测。1.2 订单状态机最容易漏测的一片区域“小猪”的订单状态设计是待支付、已支付、备货中、配送中、已完成、已取消、售后中。每个状态之间的合法转换都有触发条件比如“已取消”只能从“待支付”或“已支付”进入支付成功回调到达后才能从“待支付”变成“已支付”如果回调超时系统还要主动去支付渠道查单。测试时如果只覆盖正常路径会发现代码在demo环境跑得很顺畅一上线就出各种莫名问题。我的做法是把状态机做成矩阵横轴是当前状态纵轴是触发动作每个格子写预期结果。这个矩阵既是测试用例设计的基础也是开发自测时的检查单。实际执行过程中我特别关注两个边界一是“支付回调延迟很久才到达”此时订单可能已经被用户取消回调要能识别这笔订单已经不在合法状态不能把它重新拉回“已支付”二是“并发取消和支付同时发生”这看起来只会在竞态下出现但真实用户场景里确实会发生需要靠接口幂等和分布式锁去兜底。这类场景手工测很难稳定复现我会把它放到后面的接口自动化用例里用并发脚本去压。1.3 测试计划里的风险评估测试计划阶段我带着组员把需求按风险分了三个等级。高风险的模块是支付、库存、优惠券这三个模块任何一个出小问题都会直接造成资损所以回归策略是每条变更都必须跑完整用例。中风险的是订单状态流转、配送回调、售后流程这些模块逻辑复杂但不是每版都动按影响范围冒烟加主链路回归。低风险的是信息展示、搜索筛选这类纯查询功能做接口层验证加UI抽查就够。这个分级看起来简单但真正执行时很考验判断力。比如某个迭代只改了商品详情页的UI开发自测也说只是样式调整但我们通过接口变更记录发现详情页接口新增了一个“可售状态”字段如果后端没处理好下架商品仍返回可售可能把已经下架的商品重新暴露给用户。这种隐藏在UI改动背后的逻辑变更是测试计划阶段最常见的盲区。我的习惯是每次迭代不光看需求描述还要拉出后端接口的diff凡是接口字段、状态码、返回结构有变化都按高风险对待。2. 一次线上登录故障让我重新理解了测试环境隔离2.1 故障现象和初步排查上线后第三周运营反馈线上用户集中出现登录失败报错信息是“登录状态已过期”需要重新登录。诡异的是这个现象不是持续性的而是每天下午某个时段集中出现持续十几分钟后又恢复正常。一开始大家以为是正常的token过期但用户反馈量明显比平时高而且同一时段内大量用户同时掉线这不符合token自然过期的规律。我先从客户端日志入手发现用户请求的是普通的业务接口但服务端返回的都是401。接着看网关日志确认这些401请求都带着合法的token只是被网关判定为过期。再往后追发现鉴权服务在处理token时校验的是token里的“exp”字段和当前时间而Redis里缓存的token有效期配置值只有5分钟正常应该是30分钟。也就是说并不是用户token真的失效而是服务端判断token有效期的逻辑突然变短了。2.2 根因配置中心key被测试环境借用了继续查是什么改了token有效期配置。翻配置中心的变更记录发现当天下午有一位测试同学在环境配置里修改了这个key又设置成5分钟。他在测试环境验证“登录过期”场景时为了方便把token有效期调短然后忘记改回去了。如果只是测试环境变了线上不会受影响但问题是这个key所在的配置组被生产环境和测试环境共用配置中心虽然按环境做了分组但key的namespace没有严格隔离测试同学在操作时选择了错误的环境入口实际修改的是线上应用的配置。这个根因让我有点汗颜。我们平时很注意数据库隔离测试库和生产库是完全分开的连接串都做了区分但配置层面一直沿用着“复制一份再改”的方式没有真正区分环境。测试同学修改配置时选择框里显示的是“默认配置组”他以为自己在改测试环境实际改到了生产共用组。线上服务感知到配置变化后刷新了缓存token有效期从30分钟变成了5分钟所有已登录用户的token都提前失效表现就是集中掉线。2.3 隔离问题为什么这么隐蔽环境隔离的隐蔽性在于它不像数据库那样肉眼可见。数据库地址写错了应用起不来或者连不上很快能发现配置中心的key用错环境业务功能通常还是正常的只是某个参数被覆盖成非预期值而且这个非预期值可能在特定场景下才暴露。比如token有效期被改成5分钟如果当天没有集中登录压测可能只是用户觉得“怎么老是让我重新登录”还不至于成为故障。更麻烦的是这类问题往往不是第一责任人自己发现的。我们后来复盘发现测试同学修改的配置项有十几个只有token有效期这一个产生了线上影响其他几个参数因为在生产环境中没有对应调用链改完毫无感觉。所以排查环境隔离问题时不能只盯着“谁改了什么”还要看“改的这个参数会被哪些环境加载”“被哪些服务引用”。我给配置中心补了一张环境清单每个key都会标注它的生效范围和关联服务任何修改前必须先确认是否影响生产。2.4 后续的整改动作这次故障之后我们做了四个整改动作。第一配置中心按环境彻底拆分生产环境的namespace设置为只读权限除运维外其他账号一律不能改。第二凡是测试需要验证的“过期”“异常”类参数不允许直接改线上共用配置而是在应用层做本地配置文件覆盖或通过mock服务模拟。第三增加配置变更审计任何非生产环境配置变更都要记录操作人和变更内容每周由测试负责人复核。第四在测试计划中加入一项“环境隔离检查”每次发版前扫描配置、数据库连接串、缓存、消息队列是否指向正确环境。这个坑也让我重新理解了测试数据隔离。一直以为测试数据隔离就是测试库和生产库分开实际上还包括配置文件、Redis缓存、消息队列、第三方mock服务任何一个环节共用测试数据都可能串到生产。写进这块内容的初衷是希望后面做测试的同学不要只在用例设计上下功夫环境治理做得不好用例跑得再漂亮也不代表线上安全。3. 自动化测试从300条到3000条我踩过的三个坑3.1 定位策略前端一改版300条用例红了200条“小猪”的自动化测试最开始并不多只有300条接口用例和几十条UI冒烟用例。接口用例推进得很快但UI用例让我很痛苦前端同学只要调整页面结构哪怕只是改一个按钮的外层容器原来基于class定位的脚本就失效了。有一回前端统一改版第二天醒来发现300条用例红了200多条其中大部分并不是功能出问题而是定位器失效。后来我们把定位策略统一调整为基于data-testid属性前端在关键交互元素上增加稳定的测试标识测试脚本优先使用这个标识定位实在没有才回退到文本或xpath。同时引入页面对象模式把每个页面的元素定位和维护收拢到一个类里页面结构变化时只改一处不需要每个用例都动。这个投入在后续两个版本的迭代里价值很明显版本更新时UI回归用例的维护成本降了一大半。3.2 测试数据共享数据让断言变得不可控做接口自动化时初期喜欢复用已有数据比如直接查数据库里某个真实门店、真实商品来跑下单用例。问题在于测试执行有先后顺序一旦前面用例把商品库存扣完、把优惠券核销掉后面的用例再跑就会失败而且失败原因跟代码无关纯粹是数据被消费了。最典型的场景是一次夜跑测试任务执行到一半有几个用例连续报“库存不足”我看了半天代码最后才发现是前面一条用例把测试商品的库存减到0共享数据把整个执行过程变成了状态机。解决办法是做了一套简单的数据工厂每条用例执行前先通过接口或数据库脚本创建一个独立的测试门店、测试商品、测试账号用例跑完后统一清理。数据创建和清理都封装成公共方法用例里只关心业务断言。刚开始觉得多写了很多“无关代码”但半个月后执行稳定性从70%提到99%省下来的排查时间远超写数据工厂的时间。3.3 用例耦合A依赖B跑批时才暴露另一个坑是用例之间的隐性依赖。有段时间我们的用例总是单独跑能过全量跑就随机失败。排查后发现某条用例依赖前面用例创建的一条特定订单前面那条用例通过后订单留在库里供后面用例查询。一旦把后面用例单独抽取执行或者执行顺序被调度器打乱就会失败。我定的新规则是每条用例必须能独立运行不依赖其他用例的中间状态。长链路场景如果前置数据成本太高就通过接口直接造数据而不是依赖前面一段UI操作。比如要测“售后申请”前置条件是订单已完成那就直接调用内部接口把订单状态改到已完成而不是从下单开始一步步走这样既快又稳定。用例拆开、数据自理之后全量执行的随机失败问题基本消失。3.4 分层执行与CI集成自动化用例到3000条以后一次性全量执行需要1个多小时不适合每次提交都跑。我们把用例分成三层第一层是冒烟用例覆盖登录、主流程下单、支付回调等核心链路大概100条每次代码提交后自动跑15分钟内出结果第二层是核心业务用例覆盖订单、库存、优惠券、售后等所有重要分支每天凌晨定时跑第三层是全量用例每周跑一次做深度回归。CI平台用Jenkins失败任务会自动收集日志、截图和堆栈并推送到团队群。这个分层设计让自动化真正嵌入了研发流程。之前自动化只在发版前跑一次大家把它当成额外负担现在每次提交都有快速反馈开发自己会主动看冒烟结果。从300条到3000条最大的体会是自动化测试要形成“快速反馈循环”否则用例再多也只是定时给自己添堵。4. 性能测试压测报告里的TPS不是最重要的4.1 压测前的容量预估和场景配比“小猪”上线前有一个大促活动需要提前做容量评估。刚开始做性能测试时我们犯过一个常识性错误只盯着压测报告里的TPS看觉得TPS过万就是性能好。后来发现TPS只是一个汇总数字不能代表用户体验也不能直接指导扩缩容。真正要回答的问题是线上流量峰值是多少每个核心接口需要承受多大压力压测过程中哪个环节先扛不住。先做容量预估。从运营和产品拿到预测峰值是每秒8000个请求其中首页feed约占40%、商品详情约占25%、登录约占10%、下单约占10%、支付回调约占5%其余是其他接口。按这个比例配置混合场景压测模型而不是对所有接口都用最大压力。压测工具用的JMeter分布式节点施压机部署在测试环境的独立网段避免压测流量串到开发环境。4.2 瓶颈定位数据库连接池和Redis热点key第一次混合压测TPS跑到800左右就上不去了错误率开始上升。查看服务监控CPU和内存都很低数据库慢查询也不多让人摸不着头脑。后来打开数据库连接池监控发现连接池已经全部占满大量线程在等待获取连接。我们的连接池参数用的是服务框架默认值没有根据实例数和接口并发量调整。把连接池最大连接数从20调到100后TPS提升到1200。第二次瓶颈出现在商品详情接口。压测过程中发现Redis命中率骤降大量请求直接打到MySQLMySQL的慢查询日志里全是详情数据的查询。原因是压测脚本里的商品ID过于集中恰好是同一个爆款商品这个key在Redis里过期后并发请求同时穿透到数据库形成了热点key雪崩。解决方式是本地缓存加多级缓存兜底热点key在应用本地做短时间缓存并给商品详情接口增加限流和熔断策略。这次之后我学到一个规律压测不只是压软件也是在压架构设计的短板哪个环节薄弱压测会毫不留情地放大它。4.3 稳定性测试8小时压测逼出一个内存泄漏容量压测通过后我们安排了一次8小时的稳定性测试用中高水位持续跑混合场景。大概跑到第三小时监控面板上JVM堆内存曲线开始缓慢抬升GC频率也在增加从每10分钟一次Full GC慢慢变成每3分钟一次。我意识到大概率是内存泄漏而不是正常波动。通过线程转储和堆内存快照最终定位到问题出在一个缓存组件上某个查询结果被保存在一个静态集合里清理逻辑依赖定时任务而定时任务在业务高峰期被线程池拒绝导致老数据一直堆积最终撑满堆内存。修复后继续压测24小时堆内存曲线变得平稳。这个案例说明线上稳定性问题往往不是接口逻辑报错而是资源缓慢耗尽的慢性病单靠短时间压测根本发现不了。稳定性测试虽然耗时但在高并发项目里不能省。4.4 容量评估和上线建议压测结束后我根据单实例1核2G的实测数据做了容量计算单实例能稳定支撑约200 QPS的混合流量按峰值8000 QPS、预留30%冗余计算需要50台左右的实例。这个数字被运维拿去做了扩缩容基线同时我们给核心服务配置了基于QPS的HPA策略流量上来时自动扩容低谷时缩容。整理压测报告时我还加了一个“风险清单”模块把所有瓶颈点和对应的限流、熔断、降级策略列在一起方便后续排查。5. 兼容性测试设备覆盖矩阵比“测一堆手机”更靠谱5.1 覆盖矩阵怎么设计“小猪”的用户主要来自微信小程序和H5页面原本计划借一堆手机把市面上的机型都过一遍后来发现不现实光常见的设备型号就有上百种测试人力测不过来。后来我换了个思路不再追求设备数量而是建立覆盖矩阵从操作系统版本、屏幕分辨率、厂商系统、网络环境、运行环境五个维度选设备。操作系统版本维度覆盖iOS 12到当前版本Android覆盖8.0到当前版本屏幕分辨率覆盖小屏、标准屏、大屏和全面屏厂商系统覆盖几个主流厂商网络环境覆盖WiFi、4G/5G和弱网运行环境覆盖微信版本、H5浏览器内核。每个维度选1到3台代表设备组合出来的测试矩阵不到30台设备却基本覆盖了用户分布的Top 80%。矩阵设计好之后本地真机只保留最高频复用的几台其余情况用云真机平台执行一次性的大批量验证既不占空间又能快速覆盖不同机型。5.2 典型案例WebView白屏和iOS输入框遮挡矩阵执行到第二轮时Android 10某机型上活动页出现了白屏。本地真机和其他设备上没有复现刚开始很难定位。后来我用adb抓取设备日志发现WebView加载活动页时抛出了JavaScript异常页面渲染被中断。再对比其他机型的WebView版本确认是该机型内置WebView组件的兼容性问题。开发调整了初始化逻辑并加了异常捕获后问题修复。另一个问题是iOS低版本输入框被键盘遮挡。在小程序页面里输入手机号和验证码时键盘弹起后输入框被完全盖住用户看不见自己输入的内容。这个属于典型的布局适配问题排查时抓取了小程序的页面布局快照确认是键盘高度变化后页面没有正确滚动。这类问题在功能测试阶段很难遇到因为测试同学大多用最新设备但用户设备永远比测试设备“旧”所以矩阵里必须保留低版本操作系统的代表机型。5.3 日志抓取与缺陷记录要点兼容性测试最大的难点不是发现问题而是把问题描述清楚。一开始团队同学提的兼容性缺陷只有一句“XX机型上页面显示错乱”开发拿到后很难复现。后来我们统一了缺陷记录格式设备型号、系统版本、微信/浏览器版本、操作步骤、预期结果、实际结果、设备日志、截图或录屏缺一不可。凡是兼容性问题我会额外附上adb logcat或WebView console日志开发能直接定位是渲染问题、接口问题还是设备能力差异。录屏和抓包也很重要。有些兼容性问题只在特定网络环境下出现比如弱网下图片加载失败导致页面布局错乱抓包能看到静态资源和接口的加载失败记录。这些信息放进缺陷单能省掉开发一半的复现时间。6. 缺陷复盘和过程改进才是“小猪软件测试”最大的收获6.1 每周缺陷分析会“小猪”项目的缺陷率整体不高但上线后陆续收到一些用户反馈这促使我们开始做每周缺陷分析会。会议不追责只做数据统计和模式识别。按模块看订单和支付相关缺陷最多按原因看一半来自需求变更没有同步到测试用例四分之一来自环境问题剩下的是编码实现问题。这个统计结果直接改变了我们的测试节奏凡是涉及订单、支付的需求变更必须重新跑一遍完整回归不允许只测变更点。6.2 漏测复盘上线后收到的用户反馈里有一个案例印象很深用户在大促期间领了一张品类券下单时系统提示券不能用原因是券的使用门槛在商品维度做了限制但前端没有提示限制条件。这个功能在原需求文档里写了但测试用例只覆盖了“用户有券就能用”的正常场景没有覆盖“券存在使用门槛”的限制场景。漏测复盘得出的结论不是补一条用例而是要在用例设计阶段把需求里的每个“条件”都拆成独立用例并用判定表法覆盖条件组合不能只顺着正常路径走。6.3 用例评审和知识库后续我们引入了用例评审每周邀请开发和产品一起过测试用例。效果超出预期产品经常能指出测试同学因为太熟悉系统而忽略的边界条件开发也会主动提醒哪些接口有潜在并发风险。同时我把项目过程中踩过的坑整理成内部知识库包括环境隔离检查清单、自动化用例编写规范、性能瓶颈排查手册。团队里新来的同学照着手册能独立排查大部分问题不用每次都等我上手。项目后期做了一次质量复盘用数据看“小猪软件测试”上线首月的线上缺陷率从第一周的千分之二点三降到第四周的千分之零点六自动化用例的稳定执行率稳定在99%以上。数据不是我追求的唯一目标更重要的是团队对“测试到底在测什么”有了统一的认知测试不是找bug的体力活而是通过系统化的方法和持续的过程改进把质量风险控制在产品交付之前。如果非让我给后面接手类似项目的人留一句建议我会说测试计划阶段多花一天做环境治理和风险拆解后面能少踩好几个通宵排查的坑。 
长河君 · 2026/10/13 13:49:43 · 阅读 1.2k 软件测试实战指南：从小程序电商链路到自动化与性能优化
借着这次“小猪软件测试”项目的收尾我把整套测试过程重新过了一遍内容包括测试范围的梳理、一次典型的线上故障排查、自动化测试从零搭建、性能瓶颈定位以及兼容性测试的落地方式。“小猪”不是一个公开产品而是我们在内部反复用了四个月的项目代号它是一款社区生活类服务App涉及商品、订单、支付、库存、优惠券、配送这些电商核心链路。项目上线后的整体质量还算不错但过程中的坑一点都不少这篇文章就是把这些坑换成经验写出来。如果你是刚转行做测试的同学可以从头到尾读一遍如果你已经带项目了可以直接跳到第2节和第4节看环境治理和性能瓶颈定位的部分。我不保证所有方案都适合你的团队但至少能帮你少走几趟弯路。1. “小猪”项目的测试范围比想象中多出三个复杂点1.1 “小猪”到底测什么核心业务链路拆解“小猪”在项目内部一直是个代号它是一款社区生活类服务App核心场景是让用户在小程序里完成从浏览、下单到支付核销的整个闭环。技术侧并不复杂前端主要是小程序和H5后端是微服务架构服务之间通过HTTP和消息队列通信底层用MySQL、Redis和MongoDB。真正的复杂度不在某个单点技术上而在于业务链路太长登录之后要带出定位和门店信息门店信息决定商品库存和配送范围用户领券后下单下单时同时扣减库存、锁定优惠券、生成支付单支付回调回来再更新订单状态最后还要触发配送和核销消息。这条链路里任何一环出问题用户端看到的就是“下单失败”或者“支付成功但订单状态不对”。所以我在梳理测试范围时没有急着写用例而是先把这条主链路画出来把每两个系统之间的交互接口列成一张表再逐个标注异常情况。比如下单接口需要同时满足“商品上架”“门店营业”“库存充足”“优惠券可用”四个条件缺一个都要有明确的错误返回。测试范围不只是功能还包括接口契约、状态机、数据一致性、消息可靠性、权限控制。这些内容如果不在前期理清楚后面很容易漏测。1.2 订单状态机最容易漏测的一片区域“小猪”的订单状态设计是待支付、已支付、备货中、配送中、已完成、已取消、售后中。每个状态之间的合法转换都有触发条件比如“已取消”只能从“待支付”或“已支付”进入支付成功回调到达后才能从“待支付”变成“已支付”如果回调超时系统还要主动去支付渠道查单。测试时如果只覆盖正常路径会发现代码在demo环境跑得很顺畅一上线就出各种莫名问题。我的做法是把状态机做成矩阵横轴是当前状态纵轴是触发动作每个格子写预期结果。这个矩阵既是测试用例设计的基础也是开发自测时的检查单。实际执行过程中我特别关注两个边界一是“支付回调延迟很久才到达”此时订单可能已经被用户取消回调要能识别这笔订单已经不在合法状态不能把它重新拉回“已支付”二是“并发取消和支付同时发生”这看起来只会在竞态下出现但真实用户场景里确实会发生需要靠接口幂等和分布式锁去兜底。这类场景手工测很难稳定复现我会把它放到后面的接口自动化用例里用并发脚本去压。1.3 测试计划里的风险评估测试计划阶段我带着组员把需求按风险分了三个等级。高风险的模块是支付、库存、优惠券这三个模块任何一个出小问题都会直接造成资损所以回归策略是每条变更都必须跑完整用例。中风险的是订单状态流转、配送回调、售后流程这些模块逻辑复杂但不是每版都动按影响范围冒烟加主链路回归。低风险的是信息展示、搜索筛选这类纯查询功能做接口层验证加UI抽查就够。这个分级看起来简单但真正执行时很考验判断力。比如某个迭代只改了商品详情页的UI开发自测也说只是样式调整但我们通过接口变更记录发现详情页接口新增了一个“可售状态”字段如果后端没处理好下架商品仍返回可售可能把已经下架的商品重新暴露给用户。这种隐藏在UI改动背后的逻辑变更是测试计划阶段最常见的盲区。我的习惯是每次迭代不光看需求描述还要拉出后端接口的diff凡是接口字段、状态码、返回结构有变化都按高风险对待。2. 一次线上登录故障让我重新理解了测试环境隔离2.1 故障现象和初步排查上线后第三周运营反馈线上用户集中出现登录失败报错信息是“登录状态已过期”需要重新登录。诡异的是这个现象不是持续性的而是每天下午某个时段集中出现持续十几分钟后又恢复正常。一开始大家以为是正常的token过期但用户反馈量明显比平时高而且同一时段内大量用户同时掉线这不符合token自然过期的规律。我先从客户端日志入手发现用户请求的是普通的业务接口但服务端返回的都是401。接着看网关日志确认这些401请求都带着合法的token只是被网关判定为过期。再往后追发现鉴权服务在处理token时校验的是token里的“exp”字段和当前时间而Redis里缓存的token有效期配置值只有5分钟正常应该是30分钟。也就是说并不是用户token真的失效而是服务端判断token有效期的逻辑突然变短了。2.2 根因配置中心key被测试环境借用了继续查是什么改了token有效期配置。翻配置中心的变更记录发现当天下午有一位测试同学在环境配置里修改了这个key又设置成5分钟。他在测试环境验证“登录过期”场景时为了方便把token有效期调短然后忘记改回去了。如果只是测试环境变了线上不会受影响但问题是这个key所在的配置组被生产环境和测试环境共用配置中心虽然按环境做了分组但key的namespace没有严格隔离测试同学在操作时选择了错误的环境入口实际修改的是线上应用的配置。这个根因让我有点汗颜。我们平时很注意数据库隔离测试库和生产库是完全分开的连接串都做了区分但配置层面一直沿用着“复制一份再改”的方式没有真正区分环境。测试同学修改配置时选择框里显示的是“默认配置组”他以为自己在改测试环境实际改到了生产共用组。线上服务感知到配置变化后刷新了缓存token有效期从30分钟变成了5分钟所有已登录用户的token都提前失效表现就是集中掉线。2.3 隔离问题为什么这么隐蔽环境隔离的隐蔽性在于它不像数据库那样肉眼可见。数据库地址写错了应用起不来或者连不上很快能发现配置中心的key用错环境业务功能通常还是正常的只是某个参数被覆盖成非预期值而且这个非预期值可能在特定场景下才暴露。比如token有效期被改成5分钟如果当天没有集中登录压测可能只是用户觉得“怎么老是让我重新登录”还不至于成为故障。更麻烦的是这类问题往往不是第一责任人自己发现的。我们后来复盘发现测试同学修改的配置项有十几个只有token有效期这一个产生了线上影响其他几个参数因为在生产环境中没有对应调用链改完毫无感觉。所以排查环境隔离问题时不能只盯着“谁改了什么”还要看“改的这个参数会被哪些环境加载”“被哪些服务引用”。我给配置中心补了一张环境清单每个key都会标注它的生效范围和关联服务任何修改前必须先确认是否影响生产。2.4 后续的整改动作这次故障之后我们做了四个整改动作。第一配置中心按环境彻底拆分生产环境的namespace设置为只读权限除运维外其他账号一律不能改。第二凡是测试需要验证的“过期”“异常”类参数不允许直接改线上共用配置而是在应用层做本地配置文件覆盖或通过mock服务模拟。第三增加配置变更审计任何非生产环境配置变更都要记录操作人和变更内容每周由测试负责人复核。第四在测试计划中加入一项“环境隔离检查”每次发版前扫描配置、数据库连接串、缓存、消息队列是否指向正确环境。这个坑也让我重新理解了测试数据隔离。一直以为测试数据隔离就是测试库和生产库分开实际上还包括配置文件、Redis缓存、消息队列、第三方mock服务任何一个环节共用测试数据都可能串到生产。写进这块内容的初衷是希望后面做测试的同学不要只在用例设计上下功夫环境治理做得不好用例跑得再漂亮也不代表线上安全。3. 自动化测试从300条到3000条我踩过的三个坑3.1 定位策略前端一改版300条用例红了200条“小猪”的自动化测试最开始并不多只有300条接口用例和几十条UI冒烟用例。接口用例推进得很快但UI用例让我很痛苦前端同学只要调整页面结构哪怕只是改一个按钮的外层容器原来基于class定位的脚本就失效了。有一回前端统一改版第二天醒来发现300条用例红了200多条其中大部分并不是功能出问题而是定位器失效。后来我们把定位策略统一调整为基于data-testid属性前端在关键交互元素上增加稳定的测试标识测试脚本优先使用这个标识定位实在没有才回退到文本或xpath。同时引入页面对象模式把每个页面的元素定位和维护收拢到一个类里页面结构变化时只改一处不需要每个用例都动。这个投入在后续两个版本的迭代里价值很明显版本更新时UI回归用例的维护成本降了一大半。3.2 测试数据共享数据让断言变得不可控做接口自动化时初期喜欢复用已有数据比如直接查数据库里某个真实门店、真实商品来跑下单用例。问题在于测试执行有先后顺序一旦前面用例把商品库存扣完、把优惠券核销掉后面的用例再跑就会失败而且失败原因跟代码无关纯粹是数据被消费了。最典型的场景是一次夜跑测试任务执行到一半有几个用例连续报“库存不足”我看了半天代码最后才发现是前面一条用例把测试商品的库存减到0共享数据把整个执行过程变成了状态机。解决办法是做了一套简单的数据工厂每条用例执行前先通过接口或数据库脚本创建一个独立的测试门店、测试商品、测试账号用例跑完后统一清理。数据创建和清理都封装成公共方法用例里只关心业务断言。刚开始觉得多写了很多“无关代码”但半个月后执行稳定性从70%提到99%省下来的排查时间远超写数据工厂的时间。3.3 用例耦合A依赖B跑批时才暴露另一个坑是用例之间的隐性依赖。有段时间我们的用例总是单独跑能过全量跑就随机失败。排查后发现某条用例依赖前面用例创建的一条特定订单前面那条用例通过后订单留在库里供后面用例查询。一旦把后面用例单独抽取执行或者执行顺序被调度器打乱就会失败。我定的新规则是每条用例必须能独立运行不依赖其他用例的中间状态。长链路场景如果前置数据成本太高就通过接口直接造数据而不是依赖前面一段UI操作。比如要测“售后申请”前置条件是订单已完成那就直接调用内部接口把订单状态改到已完成而不是从下单开始一步步走这样既快又稳定。用例拆开、数据自理之后全量执行的随机失败问题基本消失。3.4 分层执行与CI集成自动化用例到3000条以后一次性全量执行需要1个多小时不适合每次提交都跑。我们把用例分成三层第一层是冒烟用例覆盖登录、主流程下单、支付回调等核心链路大概100条每次代码提交后自动跑15分钟内出结果第二层是核心业务用例覆盖订单、库存、优惠券、售后等所有重要分支每天凌晨定时跑第三层是全量用例每周跑一次做深度回归。CI平台用Jenkins失败任务会自动收集日志、截图和堆栈并推送到团队群。这个分层设计让自动化真正嵌入了研发流程。之前自动化只在发版前跑一次大家把它当成额外负担现在每次提交都有快速反馈开发自己会主动看冒烟结果。从300条到3000条最大的体会是自动化测试要形成“快速反馈循环”否则用例再多也只是定时给自己添堵。4. 性能测试压测报告里的TPS不是最重要的4.1 压测前的容量预估和场景配比“小猪”上线前有一个大促活动需要提前做容量评估。刚开始做性能测试时我们犯过一个常识性错误只盯着压测报告里的TPS看觉得TPS过万就是性能好。后来发现TPS只是一个汇总数字不能代表用户体验也不能直接指导扩缩容。真正要回答的问题是线上流量峰值是多少每个核心接口需要承受多大压力压测过程中哪个环节先扛不住。先做容量预估。从运营和产品拿到预测峰值是每秒8000个请求其中首页feed约占40%、商品详情约占25%、登录约占10%、下单约占10%、支付回调约占5%其余是其他接口。按这个比例配置混合场景压测模型而不是对所有接口都用最大压力。压测工具用的JMeter分布式节点施压机部署在测试环境的独立网段避免压测流量串到开发环境。4.2 瓶颈定位数据库连接池和Redis热点key第一次混合压测TPS跑到800左右就上不去了错误率开始上升。查看服务监控CPU和内存都很低数据库慢查询也不多让人摸不着头脑。后来打开数据库连接池监控发现连接池已经全部占满大量线程在等待获取连接。我们的连接池参数用的是服务框架默认值没有根据实例数和接口并发量调整。把连接池最大连接数从20调到100后TPS提升到1200。第二次瓶颈出现在商品详情接口。压测过程中发现Redis命中率骤降大量请求直接打到MySQLMySQL的慢查询日志里全是详情数据的查询。原因是压测脚本里的商品ID过于集中恰好是同一个爆款商品这个key在Redis里过期后并发请求同时穿透到数据库形成了热点key雪崩。解决方式是本地缓存加多级缓存兜底热点key在应用本地做短时间缓存并给商品详情接口增加限流和熔断策略。这次之后我学到一个规律压测不只是压软件也是在压架构设计的短板哪个环节薄弱压测会毫不留情地放大它。4.3 稳定性测试8小时压测逼出一个内存泄漏容量压测通过后我们安排了一次8小时的稳定性测试用中高水位持续跑混合场景。大概跑到第三小时监控面板上JVM堆内存曲线开始缓慢抬升GC频率也在增加从每10分钟一次Full GC慢慢变成每3分钟一次。我意识到大概率是内存泄漏而不是正常波动。通过线程转储和堆内存快照最终定位到问题出在一个缓存组件上某个查询结果被保存在一个静态集合里清理逻辑依赖定时任务而定时任务在业务高峰期被线程池拒绝导致老数据一直堆积最终撑满堆内存。修复后继续压测24小时堆内存曲线变得平稳。这个案例说明线上稳定性问题往往不是接口逻辑报错而是资源缓慢耗尽的慢性病单靠短时间压测根本发现不了。稳定性测试虽然耗时但在高并发项目里不能省。4.4 容量评估和上线建议压测结束后我根据单实例1核2G的实测数据做了容量计算单实例能稳定支撑约200 QPS的混合流量按峰值8000 QPS、预留30%冗余计算需要50台左右的实例。这个数字被运维拿去做了扩缩容基线同时我们给核心服务配置了基于QPS的HPA策略流量上来时自动扩容低谷时缩容。整理压测报告时我还加了一个“风险清单”模块把所有瓶颈点和对应的限流、熔断、降级策略列在一起方便后续排查。5. 兼容性测试设备覆盖矩阵比“测一堆手机”更靠谱5.1 覆盖矩阵怎么设计“小猪”的用户主要来自微信小程序和H5页面原本计划借一堆手机把市面上的机型都过一遍后来发现不现实光常见的设备型号就有上百种测试人力测不过来。后来我换了个思路不再追求设备数量而是建立覆盖矩阵从操作系统版本、屏幕分辨率、厂商系统、网络环境、运行环境五个维度选设备。操作系统版本维度覆盖iOS 12到当前版本Android覆盖8.0到当前版本屏幕分辨率覆盖小屏、标准屏、大屏和全面屏厂商系统覆盖几个主流厂商网络环境覆盖WiFi、4G/5G和弱网运行环境覆盖微信版本、H5浏览器内核。每个维度选1到3台代表设备组合出来的测试矩阵不到30台设备却基本覆盖了用户分布的Top 80%。矩阵设计好之后本地真机只保留最高频复用的几台其余情况用云真机平台执行一次性的大批量验证既不占空间又能快速覆盖不同机型。5.2 典型案例WebView白屏和iOS输入框遮挡矩阵执行到第二轮时Android 10某机型上活动页出现了白屏。本地真机和其他设备上没有复现刚开始很难定位。后来我用adb抓取设备日志发现WebView加载活动页时抛出了JavaScript异常页面渲染被中断。再对比其他机型的WebView版本确认是该机型内置WebView组件的兼容性问题。开发调整了初始化逻辑并加了异常捕获后问题修复。另一个问题是iOS低版本输入框被键盘遮挡。在小程序页面里输入手机号和验证码时键盘弹起后输入框被完全盖住用户看不见自己输入的内容。这个属于典型的布局适配问题排查时抓取了小程序的页面布局快照确认是键盘高度变化后页面没有正确滚动。这类问题在功能测试阶段很难遇到因为测试同学大多用最新设备但用户设备永远比测试设备“旧”所以矩阵里必须保留低版本操作系统的代表机型。5.3 日志抓取与缺陷记录要点兼容性测试最大的难点不是发现问题而是把问题描述清楚。一开始团队同学提的兼容性缺陷只有一句“XX机型上页面显示错乱”开发拿到后很难复现。后来我们统一了缺陷记录格式设备型号、系统版本、微信/浏览器版本、操作步骤、预期结果、实际结果、设备日志、截图或录屏缺一不可。凡是兼容性问题我会额外附上adb logcat或WebView console日志开发能直接定位是渲染问题、接口问题还是设备能力差异。录屏和抓包也很重要。有些兼容性问题只在特定网络环境下出现比如弱网下图片加载失败导致页面布局错乱抓包能看到静态资源和接口的加载失败记录。这些信息放进缺陷单能省掉开发一半的复现时间。6. 缺陷复盘和过程改进才是“小猪软件测试”最大的收获6.1 每周缺陷分析会“小猪”项目的缺陷率整体不高但上线后陆续收到一些用户反馈这促使我们开始做每周缺陷分析会。会议不追责只做数据统计和模式识别。按模块看订单和支付相关缺陷最多按原因看一半来自需求变更没有同步到测试用例四分之一来自环境问题剩下的是编码实现问题。这个统计结果直接改变了我们的测试节奏凡是涉及订单、支付的需求变更必须重新跑一遍完整回归不允许只测变更点。6.2 漏测复盘上线后收到的用户反馈里有一个案例印象很深用户在大促期间领了一张品类券下单时系统提示券不能用原因是券的使用门槛在商品维度做了限制但前端没有提示限制条件。这个功能在原需求文档里写了但测试用例只覆盖了“用户有券就能用”的正常场景没有覆盖“券存在使用门槛”的限制场景。漏测复盘得出的结论不是补一条用例而是要在用例设计阶段把需求里的每个“条件”都拆成独立用例并用判定表法覆盖条件组合不能只顺着正常路径走。6.3 用例评审和知识库后续我们引入了用例评审每周邀请开发和产品一起过测试用例。效果超出预期产品经常能指出测试同学因为太熟悉系统而忽略的边界条件开发也会主动提醒哪些接口有潜在并发风险。同时我把项目过程中踩过的坑整理成内部知识库包括环境隔离检查清单、自动化用例编写规范、性能瓶颈排查手册。团队里新来的同学照着手册能独立排查大部分问题不用每次都等我上手。项目后期做了一次质量复盘用数据看“小猪软件测试”上线首月的线上缺陷率从第一周的千分之二点三降到第四周的千分之零点六自动化用例的稳定执行率稳定在99%以上。数据不是我追求的唯一目标更重要的是团队对“测试到底在测什么”有了统一的认知测试不是找bug的体力活而是通过系统化的方法和持续的过程改进把质量风险控制在产品交付之前。如果非让我给后面接手类似项目的人留一句建议我会说测试计划阶段多花一天做环境治理和风险拆解后面能少踩好几个通宵排查的坑。