项目在上线之后又出现了Bug,这让很多测试人员和开发人员头痛.但很多时候线上Bug普遍地存在,不可避免. 任何项目都存在未发现 Bug  和 已发现 Bug  两种情况,不存在没有 Bug的情况. 即便是测试人员,在测试过程中也不可能发现所有Bug并覆盖 100% 的范围. 一个项目上线后也会出现Bug.那么遇到这种情况,测试人员该如何处理呢? 如果问题只在线上才出现,测试环境重现不了,那么可能是版本或环境配置的问题: 如果问题不仅线上能重现,测试环境也存在,那么很有可能是测试人员在测试过程中未

使用tcpcopy复制线上流量进行测试 online server 线上服务所在机器 10.136.11.4 部署tcpcopy sudo /usr/local/tcpcopy/sbin/tcpcopy -x ONLINE_PORT@ONLINE_SERVER_MAC_ADDR-10.136.11.5:TEST_PORT@TEST_SERVER_MAC_ADDR -s 10.136.11.3 -o eth4 -i eth4 -c 10.136.100.x -d -l ./tcpcopy.log

测试奇谭,BUG不见. 大家好,我是谭叔. 一提到线上问题,很多测试小白要么"原则性"恐惧,要么憨憨如也,不知如何下手. 本篇文章,我再细化下这道常见的面试题,跟大家捋捋发生线上问题,作为测试人,该有的思路. 首先,直接给出万金油三步公式: 第一步,初步排查,快速恢复业务: 第二步,查找问题根本原因,彻底解决: 第三步,团队分享,避免出现类似问题. 这三步中的措辞,十分重要.特别是第一点--初步排查,快速恢复业务. 出现问题,不要一来就盲目定位,本着不找到根本原因不罢休的思想去处理突发

事件回溯 1.7月26日上午11:34,告警邮件提示:tomcat内存使用率连续多次超过90%: 2.开发人员介入排查问题,11:40定位到存在oom问题,申请运维拉取线上tomcat 内存快照dump: 3.开发人员担心服务抗不过下午的业务高峰期,让运维在中午低估期间重启tomcat: 4.11:45,运维人员重启tomcat,内存使用回落. 事件分析 1.根据监控历史数据,发现7月10日后,内存逐步上升,且不能被full GC:怀疑和前一周版本有关,但检查前一周版本内容,不可能导致omm:

我们的线上erp系统一天使用人员反映部分数据死活保存不上而且页面操作很慢.开始以为操作数据量大的原因, 后来查看了我们线上的glowroot系统,发现slowtrace中有超长时间的访问,点开查看详情发现有语句产生了思索. 二话不说 登录生产环境数据库,查看引起状态 >show engine innodb status \G; 发现死锁关键词 随后分析之后的transaction 共有2个事务. 事务(1)产生了x排他所 事务(2)产生了s共享锁 我们都知道 共享锁和排它锁如果相遇是竞争的,是冲

线上iptables重启了下发现报错,排查了下 [root@xxxx ~]# /etc/init.d/iptables restart iptables: Setting chains to policy ACCEPT: filter nat [ OK ] iptables: Flushing firewall rules: [ OK ] iptables: Unloading modules: [ OK ] iptables: Applying firewall rules: iptables

前言 作为后端开发工程师,当收到线上服务器CPU负载过高告警时,你会这么做?重启服务,忽略告警?不过在我看来一个合格的工程师是一定要定位到具体问题所在的,从而 fix 它.下面记录一下线上服务器 CPU 负载过高排查过程,把排查流程理清楚,以后遇到问题将会迅速定位到问题所在,快速解决. 什么样的场景会导致线上CPU负载过高? 代码层面常见的场景有: 程序陷入死循环,不停地消耗CPU 线程死锁,线程相互等待,导致假死状态,不停地消耗CPU 程序死循环场景 这里使用 JAVA 简单模拟程序死循环带来

创建一个新的版本库: [root@centos03 svn]# pwd /home/svn [root@centos03 svn]# svnadmin create webtest [root@centos03 svn]# tree webtest/ webtest/ ├── conf │   ├── authz │   ├── passwd │   └── svnserve.conf ├── db │   ├── current │   ├── format │   ├── fsfs.conf

闲来无事,搭建一个负载均衡集群,至于负载均衡集群搭建过程,找时间写下.这次主要写集群之间的文件同步,以及线上测试环境的搭建. 笔者看过很多公司都没有线上测试环境,真是崩溃了,不造怎么确保线上线下环境一致的. 笔者此次使用三台服务器: 192.168.138.3   web服务器 192.168.138.4   web服务器 192.168.138.10  web服务器+线上测试环境+源站 其中3 4 服务器作为集群中的web服务器,对外开放,是负载均衡集群的部分. 其中10 服务器不对外开放,代

质量控制 大多数测试人员认为测试工作是发现bug,虽然这是测试的主要任务,但其实测试最重要的任务是质量控制,而发现bug和验证bug只是质量控制的一个重要环节而已. 我想很多测试人员都经历过这样的场景,就是测试环境全部都能测试通过,但正式上线之后就会有各种各样的bug,到底是哪里出了问题呢?   在测试工作中,常见的问题原因分为以下几类: ●不同版本的数据兼容 这是最常见的问题,一般新版本的迭代不仅仅是代码层面的,还有数据库的改动,而对于线上原有的数据来说改动了数据库有可能会受到影响. 举个例子

在测试账户系统过程中遇到了线上大面积用户登录态失效的严重问题,事后对于其原因及测试盲点做了一些总结记录以便以后查阅,总结分为以下7点,其中原理性的解释有些摘自网络. 1.账户系统token失效问题复盘2.Redis 经典流程3.Redis分片部署方式4.Redis扩容导致缓存数据失效5.Redis Sharding一致性hash算法6.缓存失效,缓存击穿,缓存穿透7.Redis缓存测试总结 账户系统token失效问题复盘现象:redis扩容后线上大量用户登录态失效,需要重新登录.由于登录态可以持

质量控制 大多数测试人员认为测试工作是发现bug,虽然这是测试的主要任务,但其实测试最重要的任务是质量控制,而发现bug和验证bug只是质量控制的一个重要环节而已. 我想很多测试人员都经历过这样的场景,就是测试环境全部都能测试通过,但正式上线之后就会有各种各样的bug,到底是哪里出了问题呢? 在测试工作中,常见的问题原因分为以下几类: 不同版本的数据兼容 这是最常见的问题,一般新版本的迭代不仅仅是代码层面的,还有数据库的改动,而对于线上原有的数据来说改动了数据库有可能会受到影响. 举个例子: 如

一.Fiddler在线调试功能和表白神器介绍 ​ 在以往的工作中,线上有bug,就需要把文件弄到本地来改,但经常会碰见本地环境又和线上不一样,导致调试困难,闭着眼睛改好之后传到线上去看对不对,不对的话又要改,循环往复,要多麻烦就有多麻烦啊. 今天给大家介绍一款前端神器,Fiddler ,它有个功能就是把线上文件映射到本地,通过拦截的方式,你在本地修改的内容实时的反映到线上,线上的环境,本地的文件,这非常方便我们调试,而且也不会给线上带来严重的错误,因为这些操作只对你本机有效果. 它还是对女神表白

- 假设我们要上线一个两年内不会宕机的先进架构.在上线前,免不了单元测试,功能测试,还有使用ab,webbench等等进行压力测试. 但这些步骤非生产环境下正式用户的行为.或许你会想到灰度上线,但毕竟可能会影响到部分用户,这怎么对得起我们两年内不宕机的承诺呢? 好在网易的 王斌 开发了tcpcopy, 可以导入线上流量进行功能和压力测试. tcpcopy介绍 tcpcopy是一种请求复制工具.可以将线上流量拷贝到测试机器,实时的模拟线上环境.在不影响线上用户的情况下,使用线上流量进行测试,以尽早

目录 [测试右移]介绍 ELK Stack 介绍 ELK 监控体系搭建 ES & Kibana 搭建 Nginx 日志自动采集 Nginx Agent 安装 Nginx 服务器 数据分析 Logstash 搭建 [测试右移]介绍 为什么要做测试右移? 测试环境不能完全模拟线上环境. 线上质量不仅取决于已发布代码,还取决于数据变更与配置变更. 线上测试可以获得更多质量数据,以辅助产品更新. 测试右移主要实践: 应用监控 综合监控质量监控(ContinuousQuality Monitoring)

前端开发时最不想做的就是在不同浏览器.平台和分辨率测试网页显示效果,通常这会浮现许多问题,尤其浏览器版本就可能让显示成效完全不同,也只好尽力维持让每一种设备都能正常浏览网页.修改到完全没有问题必须投入不少时间,安装多系统可以解决这个问题(土豪可以配置多台机器),但是非常的麻烦繁琐,特别是不同版本的ie浏览器 .微软作为ie和windows的开发当然也知道这个问题,所以也在做这方面的工作,推出了Browser screenshots只要输入网址就能建立在不同浏览器屏幕的截取画面; Browser

tcpcopy项目地址:https://github.com/session-replay-tools/tcpcopy 作者地址:http://blog.csdn.net/wangbin579 1:环境描述 架设三台服务器 10.53.132.52 10.53.132.55 10.53.132.101 101我们认为是线上服务器,52和55是测试环境.我们在101上运行tcpcopy把线上流量拷贝到55,在55上我们通过路由将应答转向52,在52上把应答丢弃. 分别在101和55上部署apach

转自:http://blog.csdn.net/kaosini/article/details/9176961 一.对Redis持久化的探讨与理解    redis是一个支持持久化的内存数据库,也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化.redis支持两种持久化方式,一种是 Snapshot(RDB)也是默认方式,另一种是Append only file(AOF)的方式.具体的理论说明请见这里.    我们应该明确持久化的数据有什么用,答案是用于重启后的数据恢复.Redis是

通常情况下布署的三套环境:测试.预发及线上环境.调试或者辅助验证测试时,切环境改变量甚是麻烦.这些变量包括但不限于:一些url信息,数据库信息,预置用户信息等. 切换环境方法一:使用变量文件,通过判断运行时输入的变量来返回不同的环境信息    名称解释:变量文件中包含了测试数据中的变量,变量文件可以动态地创建任意类型的变量     下面是导入Variables 视图,导入变量文件时使用args,传入变量${env},实际值为运行时上图指定的变量值:online 以下是env_chang.py的内

在咱们测试过程中,经常需要切换测试环境和线上环境.大致有如下几个方案. 一.服务器地址编译到app中 此种方式需要在代码里保存两套配置,一套指向线上,一套指向测试.通过编译参数分别生成测试包.线上包.记住此种方式一定要通过编译参数实现,防止将测试环境发到线上. 优点:简单暴力无需其它设置及设备支持 缺点:切换服务器需重新编译安装包. 二.app中留着修改服务器地址的隐藏功能 此种方式debug编译的情况下,预留一个可以修改服务器的入口,进入后可以随意切换服务器地址. 优点:代码中不会出现测试服务

Wechat开发笔记 线上环境搭建: 申请一个wechat公众平台. 手机个人微信可以用webwechat来测试. Website:https://web.weixin.qq.com/ 手机客户端扫一扫就可以登录. 在公众平台申请经过审核后,在左边菜单功能下高级功能,进入开发模式. 第一次进入开发者模式,需要填写接口的配置信息,url指向网络上的服务器中php文件. Token是 在服务器上要上传的php代码,示例代码可以从以上页面的接入指南中去下载. 打开Wx_sample.php文件. 对实