上线遇到的bug

1、项目在测试环境里运行得很好,切换到生产环境后,突然来个页面一打开几秒钟后就直接就崩溃了,而且还是在chrome下直接崩溃,一看任务管理器CPU内存一下冲高,16G的内存也扛不住,我去!哪里出了问题?最后断点+单步检查发现接口数据翻了十几倍,又因为这个数据在页面会循环生成dom元素,不分页的情况下直接挂了。一开始没用fiddler查看接口数据,导致花了些时间才找到问题根源。看来以后要对异常情况多做预防,不能偷懒呀!

时间: 2024-10-05 05:11:50

上线遇到的bug的相关文章

测试指南(适用于Feature/promotion/bug)

1.提前了解需求,在需求的业务基础和开发的架构基础上分析测试关键点,给出测试策略,甚至需要准备测试数据: 2.分析需求时不要受开发影响,要有自己的分析和判断,包括测试范围,测试时间: 3.在开始测试之前,根据之前的分析准备 qa checklist for every feature/promotion/bug fix,如果时间允许可以写scenario/checklist,甚至test case; 4.在开发提测后,先把整个业务最关键的逻辑测试一遍,然后报第一轮bug,目的有两个,一是发现关键

ios开发不能不知的动态修复bug补丁第三方库JSPatch 使用学习:JSPatch导入、和使用、.js文件传输加解密

JSPatch ios开发面临审核周期长,修复bug延迟等让人无奈的问题,所以,热修复的产生成为必然. ios上线APP产生bug,需要及时修复,如何修复: 我整理了jspatch的使用说明,并建立一个简单demo供他人使用和学习,此博客不做详细介绍,具体如何使用附上代码地址: 代码下载地址: https://github.com/niexiaobo/JSPatchUse ##### demo.js里添加代码:1.重写crashBtnClick方法 2.跳转新建的JPTableViewContr

普及一下中小企业项目上线的一般流程

在公司从事运维工作期间,发现了一些更新上线项目发布的问题: 1,程序中写有大量的接口调用使用的是ip地址. 2,程序中的垃圾代码很多,用我的话说程序不干净,很明显是因为交接造成的. 3,生产环境更新的备份文件压缩文件到处乱放 tomcat等的日志有分割但是没有定期清理,高达上G.配置文件  写的一沓混乱. 4,运维人员离职居然没有交接文档,更没有生产环境的维护文档. 更甚的是我这个倒霉蛋居然来了都没人给个口头交接,只是口头仅此而已,没有. 5,更新上线没有提前通知规定,没正式流程 都要过年了居然

app开发外包注意事项,2017最新资讯

我们见过很多创业者,栽在这app外包上.很多创业者对于app外包这件事情不是特别重视,以为将事情交给app外包公司就完事了,实际上不是的.无论是从选择app外包公司还是签订合同.售后维护等各方面都有许多地方需要注意的.下面51开发app官网(外包潜规则揭秘网)将创业者在 app开发外包上容易犯的错误一一列举出来. ◆ 以为开发一个app软件和简单,自己需求不明确就开始让app外包公司开发了,若你找的app外包公司是不负责任的,那么你悲剧就开始了 ◆ 在需求没有明确之前急着要报价.这是一个常见的错

菜鸟学习 - Unity中的热更新 - Lua和C#通信

孙广东 2015-4-6 热更新我是个菜鸟,感谢网上的各位的奉献,这次又当一回搬运工. 准备: 1.了解Lua的语法 推荐书籍<Lua程序设计 第二版> 2.使用ULua插件进行通信 尽量早上真机.因为Bug问题特别多. 大杂烩: 更新LUa其实也是更新资源. Lua被看作一个资源么.Lua代码都是运行时才编译的,不运行的时候就如同一张图片.一段音频一样,都是文件资源:所以更新逻辑只需要更新脚本,不需要再编译,因而Lua能轻松实现"热更新".运行效率由于使用反射,所以成为它

Android混淆总结篇(二)

Ⅰ.前言 上篇文章总结混淆相关的知识点,基本的技术点都有罗列到.如果项目开发比较紧张,可以考虑套用混淆配置的模板,复制粘贴的基础上再修修补补. 上篇文章说到和朋友讨论的问题,前几天也基本探究完了,那么也得理理思路~总结总结,期望有更多的问题出现~才可以去探讨. Ⅱ.异常收集 这篇文章主要的技术点是异常收集,项目上线前除了混淆.打包.加固.签名和发布等,还有一项是无可避免的,就是对线上的应用进行各种统计,对应用进行各种统计包括异常的收集统计.应用的渠道下载率.活跃量.留存率和页面访问路径统计等等,

李洪强iOS面试一般性问题

iOS面试一般性问题,学会这些拿offer几率提升90%! 面试题中有一些一般性的问题,通常是会问到的.面试iOS应聘者时,切入点很重要,不同的切入点会导致不同的结果,没有找到合适的切入点也无法对应聘者有一个全面的了解.所以下面的面试问题更多的是提供方向,没有固定的答案,而且可以根据应聘者的回应引出更多有意思深层次的讨论. 注意:以下问题的参考答案均为笔者所答,不代表正确,问题答案因人而异,请根据自己的实际情况回答,若认为不合理,请在评论中指出.下面所有的参考答案,都是笔者站在面试官的角度来分析

微服务与Java EE

本文来源于我在InfoQ中文站翻译的文章,原文地址是:http://www.infoq.com/cn/news/2016/01/microservices-and-java-ee 时至今日,基于微服务的架构已经随处可见了.我们见识到了Netflix与Amazon等创新者是如何通过微服务来取得业务上的成功.不过,对于那些使用Java EE服务器,编写传统系统的开发者来说应该何去何从呢?我们一直所做的都是错误的么?我们该如何让技术设计能够适应于未来? 单体架构 首先,我们来看一下这些传统系统,或者说

持续集成之“自动化部署”

在前文<依赖管理>中,我们讨论了如何在代码变得庞大,组件增多的情况下,做好外部库和内部组件依赖管理,从而提高构建效率.可以应用的实践包括:一次生成,多次复用:建立统一制品库,外部依赖库可以使用像Maven或Ivy这样的工具进行统一管理:对架构进行调整,使一个大的代码库分成多个组件:每个组件有自己的持续集成体系:对多个组件做持续集成.然而,解决一个问题后,总会有另一个问题等在那里,需要你来解决.这次Joe的团队遇到了部署问题. 星期一早上,Alice一进办公室,就看到一脸倦意的Joe坐在椅子上,