线上出现bug

测试申请用户交付押金;

打开支付页面(用户登出或清除cookies)支付成功后,支付状态未改变的问题;

为了避免今后发生同样的问题,请各位今后在确认支付相关的功能点时注意下面的case:

1.发出支付申请后,用户退出登录然后成功支付,支付状态是否显示成功

2.发出支付申请后,用户清除cookie后成功支付,支付状态是否显示成功

重新整理了下关于支付的测试case,请各位在今后测试支付的时候严格执行这些测试用例并把结果记录到测试报告里,详细case如下所示:

正常case:

1.发出支付申请后,用户成功支付,支付状态是否显示成功

异常case:

1.发出支付申请后,用户退出登录然后成功支付,支付状态是否显示成功(APP为退出登录)

2.发出支付申请后,用户清除cookie后成功支付,支付状态是否显示成功

3.发出支付申请后,关闭浏览器后成功支付,支付状态是否显示成功(APP为关闭对应APP的进程)

4.发出支付申请后,中断支付或者支付失败后,打开支付宝后继续支付,成功支付,支付状态是否显示成功。

时间: 2024-10-05 11:22:45

线上出现bug的相关文章

关于线上的bug什么时候修复的思考

这里系统专门指的是那种用户量大的系统,比如有几百万或者上千万的注册会员.因为小系统因为用户量少,不存在这种思考,考虑有时候是多余的.另外还有内部系统,给自己公司内部人员使用的,即便是出现了问题,也不会造成很大的问题,内部协调一下即可. 而针对客户的系统,公司的收入和价值来源于给客户提供稳定的服务.这是关系到公司命脉的.如果系统不稳定,在客户心中造成的印象就会不好. 快速修复与稳定测试之间的权衡 如果线上系统出现了bug,用户反馈问题.作为开发人员,肯定要修复bug.是马修复代码后上传到生产环境,

线上应用bug跟踪查找-友盟统计

线上的应用只要用心点点都能发现些bug,连微信,QQ也不列外.但是bug中最严重的算是闪退了,这导致了用户直接不能使用我们的app. 我们公司是特别注重用户反馈和体验的,我们会定期打电话咨询用户的使用情况.我们也有自己的天使用户群,这些用户会跟我们及时的反馈应用的使用情况,bug情况,还有他们的需求. 用户不是技术人员他无法跟你清楚的描述怎么产生闪退的,于是我们需要一个bug统计的功能,我们公司采用友盟统计实现bug的记录.我们在iOS应用中植入友盟统计的功能,我也经常在查看友盟的错误统计和错误

Android线上bug热修复分析

针对app线上修复技术,目前有好几种解决方案,开源界往往一个方案会有好几种实现.重复的实现会有造轮子之嫌,但分析解决方案在技术上的探索和衍变,这轮子还是值得去推动的 关于Hot Fix技术 Hot Fix技术,简单来说就是针对线上已发布app出现了bug,在不推送新版本的情况下通过发布修复补丁进行修复.通常是刚上线的app,需要快速线上修复bug,类似的技术就叫做热修复或热补丁. 热修复技术能带来什么 让app具有了上线后被修复的可能性,增加事故风险可控性: 避免为修复bug而快速增发新版本,让

听说”双11”是这么解决线上bug的

--Android线上热修复的使用与原理 预备知识和开发环境 Android NDK编程 AndFix浅析 Android线上热修复的原理大同小异.这里仅仅针对眼下最火的框架AndFix进行解说.主要从AndFix的使用.原理以及优缺点三个方面进行阐述. 使用方式 介绍 AndFix是一个AndroidApp的在线热补丁框架. 使用此框架,我们可以在不反复发版的情况下,在线改动App中的Bug.AndFix就是 "AndroidHot-Fix"的缩写. 就眼下来说,AndFix支持An

快速定位iOS线上BUG在哪个控制器崩溃

快速定位iOS线上BUG在哪个控制器崩溃 快速定位iOS线上App崩溃在哪个控制器里面,需要和后台配合使用 下载本项目并添加手动添加到项目里 新建所有的页面都继承于YZViewController 在AppDelegate的didFinishLaunchingWithOptions方法里面写下如下代码: if ([[[NSUserDefaults standardUserDefaults] valueForKey:@"BUG"] isKindOfClass:[NSDictionary

【MySQL 线上 BUG 分析】之 多表同字段异常:Column ‘xxx’ in field list is ambiguous

一.生产出错! 今天早上11点左右,我在工作休息之余,撸了一下猫.突然,工作群响了,老大在里面说:APP出错了! 妈啊,这太吓人了,因为只是说了出错,但是没说错误的信息.所以我赶紧到APP上看看. 这果然是出错了,而且还是简单而粗暴的500,太吓人了. 二.本地赶紧调试起来! 既然线上出错了,我们又不能直接进行调试,那当然得马上在本地搞起来了! 1.代码是否有错? 立马启动本地的项目,访问对应的接口,看看是不是代码哪里出错了. 好了,本地的代码和 SQL 都是没错的! 2.SQL 是否有错? 那

数据库操作:编辑表向线上表更新

需求:表edit需要将数据更新到表release,里边会涉及增删改操作,如何做比较好??? 1.edit表是最新的数据,release表是线上表. 2.会有不同的容器调用release表,也就是需要解决容器之间的锁的问题,其他容器只有读操作,正在操控的容器有读写操作,因为更新操作无法做到原子,所以在操作之间可能会遇到其他容器查询为空或读了一半等出错的状态 a.   在另外一张表version里,打上到底使用哪张表.   即读取数据的时候是在两个表之间来回跳跃的 以下操作在我们做update的容器

轻松排查线上Node内存泄漏问题

I. 三种比较典型的内存泄漏 一. 闭包引用导致的泄漏 这段代码已经在很多讲解内存泄漏的地方引用了,非常经典,所以拿出来作为第一个例子,以下是泄漏代码: 'use strict'; const express = require('express'); const app = express(); //以下是产生泄漏的代码 let theThing = null; let replaceThing = function () { let leak = theThing; let unused =

性能测试之线上引流测试--让性能测试更真实更丰富

为什么要做引流测试 目前为止大部分的测试是在测试环境下,通过模拟用户的行为来对系统进行验证,包括功能以及性能.在这个过程中,你可能会遇到以下问题: 用户访问行为比较复杂,模拟很难和用户行为一致,模拟不够真实; 线下模拟场景有限,会出现业务覆盖不全的情况.引流测试就是为了解决以上问题,通过把线上的真实流量复制到线下环境,解决测试环境模拟不够真实,或覆盖不够全面的问题. 引流的做法 目前不少公司对引流测试进行了实践,主要有以下4种引流方式: 以上几种办法各有利弊,有的是需要自己开发相应的工具来支持.