很多人以为erp测试是什么测试，就是点点页面，录入几个单据看看能不能保存，第一次接手项目的时候，也是这么想的。拿到测试账号，顺着菜单一路点过去，新增采购单、保存、提交，页面没报错，就觉得这部分测完了。等到上线前一轮联调，才发现问题根本不在页面按钮上。
采购入库单审核之后，库存数量没自动更新，财务模块那边查不到这笔入库对应的暂估凭证。后台没抛错，界面显示审核成功，单看这一个功能，完全看不出异常。单独测采购、单独测库存、单独测总账，每个模块都能跑通，串在一起流转数据的时候，链路就断了。
erp测试不是单点功能测试。
它的核心是跟着真实业务场景走一遍完整流程，从单据创建、多级审批，到跨模块数据传递，再到最后的报表取值，每一步都要核对业务结果，而不是只看页面有没有弹窗报错。当时项目里配了一套模拟业务数据，模拟一家工厂从下达采购申请，下采购订单，货物到货入库，发票收到匹配，生成应付凭证，月末结转成本，最后查看库存台账和财务报表，整条链路反复跑。中间要模拟不同角色操作，采购员只能创建单据，仓库管理员只可以做入库，财务人员才能生成凭证，权限这块也要一并校验。
同一套流程，还要换不同的边界数据反复跑。比如订单数量填小数，零金额单据，跨月份入库，部分到货、部分退货，这些场景平时业务不是天天发生，但一旦上线遇到，系统处理逻辑不对，直接就会造成账实不符。做这部分的时候，经常一个场景测完，要同时核对三张表，库存明细表、应付明细账、成本核算表，三个表的数据必须互相匹配，差一个数字，都代表erp的业务逻辑存在漏洞。
之前犯过一个很大的疏漏，只测正常流程，漏掉反向业务。采购退货单做完，库存回退了，但是财务的应付金额没有同步冲减，报表上应付余额虚高。这条缺陷等到第二轮回归才抓到，开发调整脚本，重新跑完整套业务流程验证修复效果。回归测试也属于erp测试里固定的一环，代码改动之后，不光要验证修好的那一处，关联的上下游单据、报表都要重新核验，防止改动引出新问题。
压力层面的验证也包含在内，不过多数中小企业项目不会做重度性能测试，只模拟多用户同时操作，十来个账号同时保存单据、提交审批，观察系统会不会卡顿、单据会不会重复生成。并发场景下最容易出现重复建单，同一张入库记录在库存里出现两条，对账的时候根本理不清。
业务人员会参与进来一起做验收测试，他们更懂实际业务规则，能找出技术人员注意不到的逻辑问题。技术测试人员关注系统能不能执行操作，业务用户关心的是，系统算出来的数字，能不能和手工账对上，符不符合公司的管理制度。两边的测试视角合在一起，才算是完整的erp测试。
很多测试案例写的很长，一条案例包含一整条业务链，不是单条按钮动作。执行的时候，每一步都记录单据编号，方便后续追溯，一旦出现数据不一致，直接顺着单据回溯，定位是哪个节点的数据转换出错。
上线前那几天，加班重复跑场景，盯着屏幕上的报表数字。最后所有主流程、边界场景，还有修复后的缺陷全部验证通过，才可以交付上线。
上线第二天早上，打开系统，先抽查了三张昨天测试过的业务单据，核对库存和财务数据。