当然也可以做白名单,针对白名单改价验证
有支付自然就有退款,iap 可以接沙盒;不行就走报销;
买不是 m 的,哈哈哈哈- -好多问题啊
内测,众测
这难道没有通关上限的话还要无限测下去不成?
首先,这个系统的使用对象是谁,对于系统健壮的容忍度高不高;比如如果只是自己团队内部使用,一些交互或者校验可以不严格,但是既然有权限控制,那么基本的越权肯定是要处理的;
其次,如果是对外的,前端要做的拦截限制,接口也必然要做,不能只靠前端拦截,随便抓包就可以篡改,存在极大风险;
再者,对于异常,一定要进行封装再对外展示,甚至统一的内部错误的异常也好,否则你的一些报错信息会把代码细节暴露出去,导致安全问题;
概括下就是,通过现象,告知风险,不要仅仅用标准来强制要求,要让他们明白为什么要这么做,如果团队能够承担上述风险,我觉得那你也不用强求,否则你就列出风险及优化方案将问题上升处理;
生产 bug 倒也不是不能记
这个是真的
iap 支付主要烦在于对于票据的处理,你上面列的都是主动下单时候端上的表现,Charles 拦下修改下返回就行了。
没收到支付回调看下是没回调还是回调的环境不对,还是收到但是处理报错了;
有没有补偿查询,补偿查询多少次,对于补偿任务是否有监控;
俺不太懂,这玩意不就是 tearDown 要做的事情么
并没有。。。
再试一下
//fullexit