PG官网

  有个客户之前找我们做个系统，做了两个月，功能都做完了。他说赶紧上线吧，别测了，用户等着用呢。我说至少得测一周，他说不用那么麻烦，先上线再说，有问题再改。

  结果上线第三天就出问题了。一个数据统计功能算出来的数不对，财务那边对了半天账才发现。然后又发现一个审批流程，走到第三步会卡住，提交不了。前后折腾了快两周才把主要问题修完，用户意见很大。这个客户后来跟我说，早知道就好好测一下了。

为什么测试省不了

  很多老板觉得，功能做出来不就完事了吗，测什么试。你自己想想，你做个网站、做个小程序，是不是每个按钮都点过、每个流程都走过一遍？

  开发人员写代码的时候，他是站在自己的角度写的。他觉得这个功能应该这么用，但用户不一定这么用。用户可能点错按钮、可能填错数据、可能网络不好的时候提交了一半又取消了。这些情况开发的时候不一定想得到。

  你不测直接上线，这些问题就全暴露在用户面前了。用户不会觉得是 bug，他只会觉得你这个软件不好用。第一次体验不好，他下次就不想用了。

  还有更麻烦的。有些 bug 不是表面能看出来的，是数据层面的。比如你存进去的数据格式不对，当时用着没问题，过了几个月要统计的时候才发现数据全乱了。这种问题上线后再改，代价就太大了，因为数据已经脏了，你得人工一条一条去修。

哪些 bug 是上线后修不起的

  不是所有 bug 都很严重。有些就是界面不对齐、某个按钮颜色不好看，这种上线后慢慢改也行。但有几类 bug，上线后你真的修不起。

• 第一类是数据相关的。比如订单金额算错了、库存数量不对、用户数据丢失。这种问题一旦发生，直接影响钱和用户，你必须马上修，而且还要善后，给用户补偿、给客户道歉。

• 第二类是权限相关的。比如普通用户能看到管理员的数据、员工能修改别人的信息。这种问题是安全问题，发现晚了可能出大事。

• 第三类是核心流程走不通。比如用户付了款但订单没生成、审批走到一半卡住了、登录不上系统。这种问题直接让业务停摆，你必须立刻解决。

  这些问题你在测试阶段发现，改起来就是开发人员半小时的事。等上线了再发现，可能就是停服、回滚、人工处理数据，再加上用户投诉和赔偿，成本完全不是一个量级。

怎么用最少的测试成本避免最大的损失

  不是说测试要做得面面俱到，所有功能所有情况都测一遍，那样时间太长成本太高。

  聪明的做法是分优先级。先测核心流程，就是用户最常用、最关键的那几步。比如商城的核心流程就是逛商品、加购物车、下单、付款。这几步一定要测通，不能出问题。

  然后测异常情况。用户填错数据怎么办、网络断了怎么办、同时两个人操作同一条数据怎么办。这些情况你不测，上线后肯定有人会遇到。

  最后才测那些边缘功能和界面细节。比如某个页面的动画好不好看、某个按钮的位置对不对，这些可以后面慢慢优化。

  还有一个办法，就是灰度发布。先给一部分用户用，收集反馈，没问题了再全量上线。这样就算有问题，影响的也是一小部分人，你有足够的时间去修。测试这个事，你花一周时间测，可能帮你省后面一个月的返工和修复。这笔账怎么算都划算。