正向的话，可以在测试环境对截图进行人工打标，生产就可以比对；
反向的话，就是把可以预见的错误情况进行维护，判断不出现比如白页，loading，特殊的图片之类的。

当然也可以做白名单，针对白名单改价验证

有支付自然就有退款，iap 可以接沙盒；不行就走报销；

买不是 m 的，哈哈哈哈- -好多问题啊

内测，众测

这难道没有通关上限的话还要无限测下去不成？

首先，这个系统的使用对象是谁，对于系统健壮的容忍度高不高；比如如果只是自己团队内部使用，一些交互或者校验可以不严格，但是既然有权限控制，那么基本的越权肯定是要处理的；
其次，如果是对外的，前端要做的拦截限制，接口也必然要做，不能只靠前端拦截，随便抓包就可以篡改，存在极大风险；
再者，对于异常，一定要进行封装再对外展示，甚至统一的内部错误的异常也好，否则你的一些报错信息会把代码细节暴露出去，导致安全问题；
概括下就是，通过现象，告知风险，不要仅仅用标准来强制要求，要让他们明白为什么要这么做，如果团队能够承担上述风险，我觉得那你也不用强求，否则你就列出风险及优化方案将问题上升处理；

挺好的，加油，也可以参考下https://metersphere.io/docs/v2.x/user_manual/test_track/test_case/#41-x-pack

生产 bug 倒也不是不能记

这个是真的

iap 支付主要烦在于对于票据的处理，你上面列的都是主动下单时候端上的表现，Charles 拦下修改下返回就行了。

没收到支付回调看下是没回调还是回调的环境不对，还是收到但是处理报错了；
有没有补偿查询，补偿查询多少次，对于补偿任务是否有监控；

俺不太懂，这玩意不就是 tearDown 要做的事情么

并没有。。。

再试一下
//fullexit