ecshop测试用例
ECShop的测试测试用例，说白了就是用例拿把尺子去量一个老裁缝的手艺。这系统年岁不小，测试代码里沉淀着十年前的用例江湖规矩，测它不能光靠自动化脚本那套冷冰冰的测试流程。我得先看一眼后台的用例订单列表，鼠标点开那个“发货”按钮，测试页面刷新得比想象中快——0.8秒，用例这数字在本地环境算及格。测试可一旦加上真实数据库里那两万条历史订单，用例速度立刻掉到三秒开外。测试
真实场景比测试环境脏得多。用例我见过最典型的测试坑是商品规格组合：一件T恤有颜色、尺码、用例袖长三个属性，测试测试用例里写了十八种组合，全过。结果上线第二天，用户选了“红色-XXL-七分袖”，库存扣减直接跳过了“七分袖”那行记录。为什么？因为ECShop的属性表用逗号分隔存值，代码里用的是in_array判断，而实际数据里“七分袖”和“七分袖 ”（末尾带空格）被当成两个值。这种问题，你翻遍官方文档也找不到，只有拿真实用户数据去怼接口才能暴露。
支付回调是另一座雷区。ECShop老版本对支付宝返回的签名校验有缓存机制，同一笔订单号如果回调两次，第二次会被直接丢弃——这在正常流程里没问题，但用户点“返回商家”和服务器异步通知几乎同时到达时，订单状态就可能卡在“已付款未发货”。我写用例时特意模拟了并发请求，用JMeter开了五十个线程同时打回调地址，果不其然，有七笔订单的状态对不上账。
你得学会跟这个老系统妥协。比如它的模板引擎，Smarty的变量解析在PHP7.4下偶尔会抛异常，但报错信息里连个行号都不给。我后来学乖了，测试用例里专门加了一条“修改模板变量名后清空缓存”，这招能避开八成假故障。还有它的数据库表结构，ecs_order_info里有个order_sn字段，长度只有20位，可第三方物流单号现在普遍是22位——你填进去，MySQL直接静默截断，后期对账时才发现单号对不上。这种坑，写用例时就得把边界值设成21位、22位、带字母的混合串。
最磨人的是权限控制。ECShop的后台管理员分级别，但“订单导出”功能居然没做行级权限——一个普通客服能导出全站用户的手机号和收货地址。我测试时用了个低权限账号，点击导出，Excel文件哗啦一下生成，里面躺着三万条真实客户信息。这问题在需求文档里根本没提，因为没人想过一个老系统会犯这种低级错误。后来我每次迭代都单独跑一遍“越权访问”用例，用不同角色去点每个菜单，哪怕页面显示404也得确认是权限拦截而不是路由错误。
回归测试不能靠点鼠标硬扛。我写了个Python脚本，每天凌晨跑一遍核心流程：注册、加购、下单、支付、发货、确认收货。脚本会截图关键步骤，再把日志里的异常关键字筛出来。但脚本覆盖不了全部——比如优惠券叠加规则里有个“满100减20再送10元无门槛券”，这个逻辑藏在旧代码的某个if分支里，没有独立函数，想单元测试都没法下手。我只能手动构造五十组价格数据，用二分法找到那个临界点——原来满100减20的优惠码，在订单总额恰好等于100.00元时，因为浮点误差，被判断成99.99元，优惠不生效。
最后说个玄学。ECShop在PHP5.6下运行了八年没出过大事，一升级到PHP7.4，session机制突然失效，用户登录状态撑不过十分钟。查了两天，发现是旧代码用了session_register()这个PHP5.4就废弃的函数。这提醒我，测试用例不能只盯着功能逻辑，还得把运行环境的版本变更当成一个独立测试项——每次升级环境，先跑一遍登录、购物车、订单状态这三个最基础的操作，比跑一百条复杂用例都管用。