本文针对的是创业公司的测试、验收工作，顾省略测试用例编写等步骤（实际工作中，如果是产品经理兼顾测试的，也不会时间去写测试用例的）。产品经理需要兼顾测试工作或验收产品，这是很平常的事，但又有多少人可以正确打开”测试”这份工作呢?
一轮奋战之后，新版本终于上线了，正当嗨森之时，却收到了BOSS或者其他渠道的反馈，出现了xxxx的bug，瞬间整个人都要崩溃了。相信很多人都有遇到过这种神乎其神的情况，明明是测试过的，为什么就是会出现问题了。如果公司是有专门的测试人员，这时候一般是测试人员遭殃，如果是产品自己兼顾测试的，那就是产品遭殃了。
这种情况并不是在测试的过程中漏掉了，而是自己的测试方式不对！
那打开测试的正确方式应该是怎样的呢？皓皓把自己多年的坑一一告诉大家。
一、 产品的上线流程
完成测试版之前的需求评审之类，皓皓就不多啰嗦了，今天主要讲的出了测试版到上线这个流程。正常情况，都会现有专门的测试部门去测试，当产品达到了一定的条件，就会提交给产品去验收，验收没有问题之后，就可以上线了。
“勿忘初心，方得始终！”这句话从另一个角度的理解就是：做什么事情需要确定目标，不要让自己迷失了，最后毫无收获。因很多创业公司是没有专门的测试部门，所以产品经理也会义不容辞（其实是迫不得已）把测试工作给接下来。到了这个时候，产品经理就一定得明白，自己到底是做测试阶段的工作，还是在做验收的，请不要搞混了，否则就要承担后果了。皓皓的心血叮嘱：请不要偷懒，把测试和验收工作一起做了！
三、 测试阶段：重功能
清楚目标，那就要开展工作了。在测试阶段的工作中心是注重功能的实现，功能可以简单概括为三个方面：UI、具体功能、逻辑。这三个方面可以使用以下方法来进行测试。
1）UI——界面显示是否美观
UI，通常容易出现问题地方就是“撑爆了”。撑爆了是在展示内容超过一定限制时，会出现奇怪的现象，比如一个名字展示框，在展示5个字以内时，显示都是美美的，一旦超过了5个字，就出现莫名奇妙的换行或者其他影响美观的现象。所以在测试的时候，应该时时刻刻都在注意UI的显示，而测试UI是不用专门走一遍，通常是测试具体功能的时候辅助性的看一下就行了，这是个很简单的工作。
2）具体功能——反向测试法
具体功能，比如一个输入框，点击需要弹出数字键盘，而且是只能输入数字，不带小数点喔，这个就是具体的功能。一般情况下，开发小伙伴们在开发的时候，已经按照正常的情况做了一次单元测试，所以测试时就得按照非一般的做法来进行全方位测试。在这里，皓皓常用的是反向测试法。
举个例子：
目标：测试收款输入框的功能是否通过了？
测试：检查点击时是否弹出数字键盘？是否可以输入小数？小数有没有限制位数？是否可以输入负数？是否可以输入超过10位的数字？
这样一轮下来，通常会收货颇丰：比如不可输入超过2位的小数，应限制不允许输入0时收款成功。或许会有人说，正常的人都会在收款的时候输入负数或者是输入小数的时候输入超过2位的反人类行为呀，但是测试就得反人类！
3）逻辑—— 一个一个对着测
在逻辑测试这个层面上，皓皓采用的是最笨的方法，一个一个对着测。比如有ABCD四个角色，每个角色的权限都不一样，皓皓就是弄了4个角色的账号，一个一个对着，虽然方法笨，但还是挺有用的。但为了更专业点，皓皓以后还是得学习一些更优的方法才行。
四、 验收阶段：业务、场景的构建
很多时候，在上线后反馈回来的bug，就是在验收的时候没有做好导致。验收阶段，很多测试的方法都是排不上用场的，考究的是业务和场景构建。业务和场景的构建一定要有一连串的动作，不可像测试那样，对单个模块进行验收，否则很多问题都是会被忽略掉，最后被boss发现，于是中枪，卒~ 为了辅助大家的理解，皓皓还是通过一个例子来阐述。
目标：验收淘宝的付款模块
业务、场景构建：
业务——付款》选择付款方式》支付密码校对》付款。
场景——用户下单成功了，需要向卖家付款，这里会有多个场景出现。
场景A：用户刚下单成，紧接着向卖家付款。该场景下，用户有可能发生的情况是：
1）付款》（刚好余额够）》输入支付密码（刚好支付密码对了）》付款成功。
2）付款》（余额不够）》切换到银行卡（已经绑定了银行卡）》输入支付密码（刚好支付密码对了）》付款成功。
3）付款》（余额不够）》切换到银行卡（未绑定银行卡）…………
如此类推~
场景B：用户以前下单成功的，现在要向卖家付款。该场景下，需要考虑到用户会点击商品、订单详情来查看的环节。
五、 小结
产品上线前的测试、验收都是一个重大的工程，需要谨慎对待。为把产品做得更好，需要明确每个阶段的目标，然后针对不同的目标采取不同的措施。
