以近期测试的O2O微商城项目为例，另提一下51挖宝游戏微信小程序项目，简要分享以下3点测试经验。
首先是微信返回事件。当我们使用微信的导航栏的时候，IOS默认点击微信左上角的返回是回到上一个页面，另Android点击自带的返回键也是返回到上一个页面（新版本的微信已经做出改变，返回操作放在了页面下方进行类似浏览器的返回）。但是，有时候我们在微信网页里面点击导航栏的返回，并不一定是想要去返回上一个页面。或者说，直接返回到上一个页面在逻辑理解上是违背常规的。比如O2O微商城，当我们在订单结算页面点击提交订单之后，会跳转到成功提交订单的页面。此时如果我们点击返回，默认是返回到订单结算页面的，这在常规上是解释不通的。因为商品我已经结算过了而且已经成功提交。所以正常来说，应该是返回到订单结算的前一个页面。而进入点击结算页面是可以通过商品详情的立即购买或者购物车结算进入的。那么怎么进入提交的就应该返回到哪个页面。即最好的返回就是从购物车结算提交订单的，返回就是回到购物车。从商品详情立即购买提交订单的，返回就是回到商品详情。但是，基于目前web无法针对每个入口做监听，对每种返回做出处理，我们目前的处理方式是统一返回到首页。
然后说的是页面跳转。这里想讲的一点是规范或者说是需求的问题。因为有时候页面跳转过去另一个页面的需求是不明确的。从不同的理解，有时候都可以说得通。比如说51挖宝小游戏在锄地翻牌之后，点击结束游戏的页面跳转。你是直接跳到游戏首页让用户重新选择是否开始游戏呢？还是跳到我的奖品页面查看奖品呢？我的想法是前者，但是开发的做法可能是后者。当然，后面改为了前者啦，哈哈。虽然页面跳转只需要改一个url，挺简单的，但是我想说的是公司产品的需求不明确，会增加开发测试的成本。（这里纯粹是想吐槽一下😀）
最后说的是特殊值测试。理论说明，经常呢，一些bug的发生都是发生在特殊值的处理中。比如O2O微商城的购物车修改数量问题，我们是支持输入数量的。那对于输入值，我们就手痒会输入一些特殊值。比如，负数啦，小数啦，汉字啦，0啦，等等。而当我们输入小数之后，点击数量的加减事件是会报错的，报什么string类型不正确之类的错误。这就是对于特殊值没有处理到位。由于时间关系，web目前没有对此做出处理，而是去掉了输入数量的功能。再者提一下特殊值比如emoj表情，我们数据库不支持，目前也是没有做出处理的。还有提一下边界值，也是bug发生的重灾区。如上图所示，挖地的时候点击最后一块地（第16块地）无法挖地，后来演变成挖地之后能量没有减少，后台报数组越界的问题。这可能跟web处理的是16而后台处理的是15有关。所以说啊，有时候一不小心就埋坑~~~
