Android App压力测试-Monkey(真机)

昨天一个朋友说自己工作了好几年,但是依然只是会一些功能测试(手工),问有没有什么工具。其实工具永远都是辅助,首先要确定你要往哪个方向发展,然后由这个方向自会引申出很多工具,你再去专研工具,边专研边对这块方向深入,到时候,你就是前辈了,一通百通。

好了,下面来点干货,前两年在新浪博客里写过Monkey在模拟器上如何执行,今天从头到尾讲下在真机上如何运行。我的目的就是,你看了我的东西,是真的能够学会我所说的,不仅仅是知识的硬塞入。

首先,Monkey主要用于移动端的压力测试,在adb shell中,生成用户或系统的伪随机事件。做压力测试的目的就是提高产品的稳定性及留存率。

 什么时候用Monkey测试比较合适?

1)测试节点最好安排在功能系统测试通过,路径上没有问题的时候

2)测试时间最好安排在下班后的夜间进行,不占用上班时间,节约时间成本

Monkey测试涉及的核心:

1)ADB:Android Debug Bridge,安卓调试桥

2)MonkeyScript:一组可被Monkey识别的命令集合,可以完成重复固定的操作
当当当,下面进入正题

一、搭建Monkey的环境

1、下载安装sdk环境,不需要下载开发的api部分。

下载传送门:http://pan.baidu.com/s/1o80il2U

下载之后解压。

2、配置环境变量

在path变量值里加入Android-sdk中platform-tools和tools的目录路径,记得分号隔开。

3、验证是否配置成功

打开cmd命令行窗口,输入adb,出现下面的内容即为环境配置成功

monkey01

二、连接设备

1、首先通过USB线连上手机和电脑,确保手机的调试模式打开

2、cmd命令行窗口输入,adb devices,查看已连接的设备,如下图所示

注:可能是驱动的原因,有时候需要先打开手机助手(豌豆荚),连上手机。与adb.exe冲突,结束adb.exe进程。

monkey02其中,98AFBNM24J7R为已连接设备的名字。

3、指定设备安装测试包

adb -s 98AFBNM24J7R install ***.apk(写清楚apk的完整路径)

如图所示

monkey03

:有的人会出现以下问题:

monkey04这个是为什么呢,看看你连接的手机,因为安装的时候手机要允许。

三、执行Monkey

1、查看该包的packagename

aapt dump badging ***.apk(写清楚apk的完整路径),如图所示

 http://blog.jianjiexuan.com/tools/android-sdk/82.html

monkey05

2、最简单的monkey执行语句

adb -s 98AFBNM24J7R shell monkey -p <packagename>(即上一步查询的东西) -v 1000

这时的执行结果在命令行端显示

monkey06

具体想扩展的直接百度就可以,我这里只给大家一个准确简单的完整流程。

3、存储结果在手机端

进入该设备的shell界面

adb -s 98AFBNM24J7R shell

monkey08

执行:

 monkey -p <packagename>(即上一步查询的东西) -v 1000 > /mnt/sdcard/monkey.txt

加强综合版:有了这个基本可以说自己会monkey了(如果你看到这,可以加我微信了:jianjiexuan520

monkey -p ***** –ignore-crashes –ignore-timeouts –ignore-security-exceptions –monitor-native-crashes –pct-touch 50 –pct-motion 10 –pct-nav 10 –pct-majornav 10 –pct-appswitch 10 –pct-anyevent 10 –pct-syskeys 0 -v -v -v -s 123 –throttle 300 360000 2>/sdcard/yymonkey.log &

fuck,明明打的两个杠杠,显示出来的都是一个,为了避免误导大家,我顺便截个图,你们自己记得修改

命令说明:(具体详细解释可以看另一篇文章)

-p 包名:运行该程序

–ignore-crashes:当应用程序崩溃或发生任何失控异常时,Monkey将继续向系统发送事件,直到计数完成。

–ignore-timeouts :当应用程序发生任何超时错误,Monkey将继续向系统发送事件,直到计数完成。

–ignore-security-exceptions:当应用程序发生许可错误(如启动一个需要某些许可的Activity)时,Monkey将继续向系统发送事件,直到计数完成。

–monitor-native-crashes:监视并报告Android系统中本地代码的崩溃事件。

–pct-anyevent 10等:设定启动activity的百分比为10%(调整其它类型事件的百分比。它包罗了所有其它类型的事件,如:按键、其它不常用的设备按钮、等等。)

-v -v –v:提供更加详细的信息。一个V为较少信息;二个为较详细信息;三个提示很详细信息。

-s 123:伪随机数生成器的seed值。如果用相同的seed值再次运行Monkey,它将生成相同的事件序列。(再次测试需要输入不同的数字,不然结果是一样的)

–throttle 300:在事件之间插入固定延迟。通过这个选项可以减缓Monkey的执行速度,如这里输入300就是为300ms,一般情况下是设置1000,为了发现更多的问题,我们加大了压力

360000:事件数设定为360000,大概可以保证晚上安心下班,明早看结果了。

0>(自定义路径):输入所有LOG记录

1>(自定义路径):输出所有LOG记录

2>(自定义路径) :输出错误LOG记录

:可以拔掉数据线再换个手机了~

四、结果分析

1、调取手机端执行结果到电脑上

adb pull 文件名 (写清楚文件在手机端的完整路径)  要储存在pc端的路径

例:

adb pull /sdcard/monkey.txt d:/  (注意这边的斜杠,反斜杠是不行,Unix使用/作为路径分隔符)

monkey07

2、查看结果

开发人员结合monkey打印的日志和系统打印的日志,结合测试中出现的问题。

  • CRASH:即崩溃,应用程序在使用过程中,非正常退出。(Exception)
  • ANR:Application Not Responding,等待时间过长,程序无响应
  • oom:out of memory 超出内存(一般来说是图片过大或内存泄漏引起的,大部分情况是图片问题)

一个完整的基本流程已经结束了,如果还想深入的小伙伴可以继续研究,可参看其他文档。

 

小企业如何最大限度提高测试质量?

众所周知,小企业肯定人数不会多,很多能精简则精简。甚至很多小企业都没有测试人员,当我们有幸加入到一个不是很大的企业的测试部门,如何能更好的进行测试呢?

现在敏捷开发被炒的很热,其实,我觉得现在还没有一个完全正确的工作流程能去阐述清楚敏捷开发,基本都是每家小企业拿着个文档不全的理去美化自己是敏捷开发,1000个企业就有1000个敏捷开发流程。敏捷开发里是弱化了文档的重要性,更着重讯息的及时沟通,需求变更也平常。所以,敏捷开发里的每一环的人员自身能力都要很靠谱。而对于测试人员的挑战与压力无非是巨大的。因为没有统一的文档,我们要时时刻刻关注所有聊天群组、站立会议、邮件等探讨出的新需求,漏掉哪一个,就彻底漏掉了,没有根源可寻。但是一出现问题,你没有测到,某某这时就会站出来说,我明明在之前说过,说没说过没人知道,因为你不是对着测试说的,我们已经尽力去搜寻散落的需求,但是这种遗漏还是会存在,发生这种情况总会比较尴尬。

  但是如何能避免呢?

你需要一个记事本,新版本的所有需求,反正你知道的,无论何种途径,立马同步更新到你的记事本里,开发过程中的新增需求、修改的需求,删减的需求,都及时同步,这样就会最大化保证需求的同步,好记性不如烂笔头,这样在最后验收的时候才能确保万无一失。记事本可以考虑印象笔记、onenote,都还不错。

需求已经尽量得到了同步,接下来如何去进行高质量、高效的测试呢?

从高效的角度来说,敏捷开发完全可以摒弃测试用例。那种详细的、繁杂的描述也是就是耗费时间,没等你写完,就已经到了开测的时间。这时候的测试用例基本成了鸡肋,用也用不上。而且慢慢看测试用例的时间已经够我测完一个需求点了。但是我们又不能什么都不写,那我们和那些不懂测试,拿到手就开始随便点点点的人又有何不同?不写测试用例是节约了时间,但是如何保证质量呢?其实我们可以根据现有的需求列出checklist,这样即节约了时间成本,又给我们真正测试时提供了测试思维的提醒,不至于漏测一些常规路径,从而可以保证质量。

也许其他人会有更好的想法,我目前是这样安排的:


解释:

1、需求编号:有些录入到禅道或者excel中的需求是有编号的,为了方便我们查看,可以写出编号;有些是临时加的,我们可以直接写出需求点;另外如果有删减的,可以直接添加删除线。

2、checklist:即是需要测试的检查点,对应的A、B、C其实是测试人员。checklist由C写出后,给与A一些参考,A可继续完善补充checklist再给B参考,B测试过程中也可继续完善和补充checklist,这样最终返回到C手中的checklist已经丰富了好多。

3、系统测试:系统测试其实是很重要的一个缓解,需要测试好几轮,确保bug收敛到最低,然后交给B去交叉。

4、交叉测试:交给B交叉是为了发散出更多的路径,毕竟每个人看东西的角度都是不一样的,这样能更大限度的去保证质量。

5、验收测试:从写checklist到现在,C其实一直没有参与到测试,而这时,bug基本已经没有,C根据补充完善后的checklist进行最后的验收。

6、常规测试:这是我自己分化的功能模块,每个测试人员都有自己负责的模块功能。这样没有新增需求的模块、线上的应用、反馈的问题,都能对应到具体模块负责人,比如首页就是A一直负责的,所以最终新增需求都测试结束后,首页整个模块都需要A最后再去验收。

7、α测试:除去参与此需求从产生到结束的人员,找一些公司其他人员,充当用户,给与15分钟的快速体验,测试只需在一旁记录下体验期间提的所有建议就可以。这些建议也许不是bug,仅仅是操作上的不爽,这些也应该记录,之后汇总、讨论,哪些是必要解决,哪些是可以延期处理的,哪些是可以忽略的。

8、β测试:不一定每次的版本都需要执行,可以在重大需求,或者发布有风险的前提下实行。增加一些灰度测试,取一些真实用户去体验,及时收集用户的反馈,并可根据第三方查看日志,是否有崩溃等问题出现。

 

表格解释完了之后,明眼人都能看出,这样一层层测试下来,质量绝对是有保障的,而且能利用的资源基本都被高效利用了,已经实现了利益的最大化。针对于小型企业、测试部门人数不足的情况,我目前只能想到这样去安排工作,如果我之后发现有更好的工作方式,会及时更新的。

希望对你有作用。

如何更好的测试移动端app总结

测试移动端与测试web或者其他还是有些许差异的,为了方便大家能够快速的掌握测试移动端app的要点,下面根据自己的切身经验进行了一些总结。希望能够对大家有所帮助。

测试前的思考

我们这个产品主要是做什么的?市场上有那些同类型的产品?我们的产品所具有的优势?

测试前的准备

1、使用同类型的产品,在接触到自己产品之前,就已经对大致的主体功能有测试方向。

2、熟悉我们产品的需求设计文档,模糊的地方积极和pm交流。

3、写测试用例,资源不够的话可以不写,但是需要有checklist。

功能测试注意点

1、基本功能,主要指app是否完成了设计的所有功能。

分清模块,写一份checklist,避免漏测。

详细包括:

1)安装/卸载时,系统正常安装/卸载成功(注意覆盖安装);

2)安装成功后,系统图标显示正确;

3)根据checklist进行需求点的覆盖测试;

4)对于中途中的一些返回或退出,应有相应的提示信息;

5)显示的数据与接口返回的数据一致(抓包查看,如fiddler、charles)

6)信息上传到数据库,上传的数据保持正确

 

2、系统交互:系统正在使用一些功能时,外界给与的干扰是否会影响当前功能。

1)电话短信干扰;

2)低电量提醒;

3)push提醒;

4)usb数据线插拔提醒;

5)充电提醒;

6)音乐播放器干扰等。

 

3、兼容性:android碎片化是个难题,bug也多,ios相对bug少。

需要针对不同系统及不同机型进行覆盖测试。Android可以选取一些代表性的机型。

 

性能测试注意点

1、稳定性:利用monkey在下班后进行一些伪随机用户事件的执行,会发现一些ANR及CRASH的问题。

2、app运行的内存消耗和cpu消耗。

3、app后台长时间运行的耗流量,耗电量。

2、3点等可以用Emmagee或GT进行Android端的测试,iOS端可以直接利用xcode自带的插件进行分析

4、不同网络下的响应速度测试(可以利用charles工具实现)。

5、服务端的压力测试(可以使用jmeter),高用户的并发都要要考虑的问题。

 

易用性测试注意点

1、路径短,用户操作简单

2、界面是否吸引人、容易理解。

3、界面整洁、简单,色调统一。

4、无错别字,字体格式统一。

5、点击范围确定,利于用户操作等。

这部分测试很多,可以参照易用性-界面测试规范,如果认为有不合理的地方通常会提交需求bug-设计问题。

 

自动化测试注意点

如果不是敏捷开发,可以执行自动化测试(robotium,monkeyrunner,androidjunit),这样在回归的时候会节约很多资源。但是面对经常变更UI的敏捷开发,自动化测试的维护成本就较高,这时候并不合适加入自动化测试。但可以加入monkey自动化随机测试,还可以对接口进行自动化测试。

另外,敏捷开发中,一定要有持续集成的环境,这样可以节省很多时间。

 

其他测试注意点

1、网络切换下的app运行情况及功能正常(wifi/4G/3G/2G)。

2、网络信号强、弱甚至无网络情况下的app运行情况。

 

暂时就总结这么多了,以我目前的眼界也只能囊括这么多,如果以后发现了更多的注意点,会逐步更新的。

JMeter之获取某页面所有链接并再次请求

  今天主要讲下JMeter逻辑控制器和正则的联合使用,以jmeter获取某页面所有的链接,然后通过这些链接再次发出请求为列。

  首先我们知道,凡是输入一个地址,点击回车,通过F12查看,请求并不止一个,而如果放入jmeter中,如果不加其他设置,那我们测试的结果与实际是不符的。所以我们一般会在高级设置中勾选“从HTML文件获取所有内含的资源”,如图下所示:

当然还是眼见为实,举例,我们只是请求https://www.taobao.com,做基础的请求操作,点击运行,结果只有一条,而如果我勾选,则下方还会获取其他请求,如图所示:

但是,这些还不够!

下面我们一起来实战下,获取一个网页所有的链接并进行再次请求。

1、首先,你要打开jmeter,创建一个线程组,添加一个http请求,我们还是以淘宝为例,输入服务器名称:www.taobao.com,协议输入https,方法为GET请求。

2、在1的http请求下加上后置处理器-正则表达式提取器,关于正则的具体用法可以百度或者谷歌,我这边就直接给结果了,概念性的东西可能以后会单独出篇文章讲解。如图所示:

3、线程组下添加一个逻辑控制器-ForEach控制器(ForEach控制器会循环遍历一系列相关变量),关于逻辑控制器,到时候我会单独开篇文章去讲解,这边主要是实现目的。

 

4、在ForEach控制器下添加一个http请求,填写路径,路径为foreach中填写的输出变量名称,如图所示,注意jmeter元件作用域与执行关系,这个可以看文章:http://blog.jianjiexuan.com/tools/jmeter/213.html

如图所示:

5、添加监听器-察看结果树,保存计划,点击运行,就可以查看淘宝里所有链接的二次请求了。大功告成!

对Web应用进行静态性能的评估

概念:开发Web应用时,基于一系列Web应用页面性能优化的最佳实践对Web应用的页面进行静态分析,被给出评估结果的性能分析方法。即通过分析页面的代码来评估页面的情况

工具:YSlow(雅虎)、PageSpeed(谷歌)

 

以chrom为列

1、打开chrom浏览器

2、打开扩展程序

3、在扩展程序中进行搜索这两款软件,或下载插件导入

4、chrom-工具-打开yslow,点击runtest按钮,就会进行网页的静态性能分析,并给出分数和级别

以Firefox为列

1、打开Firefox浏览器

2、打开扩展程序

3、在扩展程序中进行搜索yslow,或下载插件导入

4、在扩展程序中进行搜索firebug,或下载插件导入

5​、F12-打开firebug-切换到yslow,点击runtest按钮,就会进行网页的静态性能分析,并给出分数和级别

分数和级别的解释

ABCDEF A为最好,依次分数降低 评估标准有23条,解释如下:

1)尽量减少http的请求  Make fewer HTTP requests

2)页面有没有CDN,内容分发网络  Use a Content Delivery Network(CDN)

3)避免空的src和href这样的编码,渲染的时候会有影响  Avoid empty src or href

4)为文件头指定过期标签  Add Expires headers

5)有没有使用gzip对内容进行压缩  Compress components with gzip

6)将css样式表尽量放在页面代码的顶部 Put CSS at top

7)将JS脚本放在底部,这样用户在访问的时候能够尽早的呈现内容 Put JavaScript at bottom

8)使用CSS样式表的时候尽量避免CSS表达式的使用   Avoid CSS expressions

9)使用JS和CSS样式表的时候尽量使用外部文件,这样可以进行缓存  Make JavaScript and CSS external

10)减少DNS的查找次数  Reduce DNS lookups

11)精简JS和CSS样式表  Minify JavaScript and CSS

12)避免URL的跳转  Avoid URL redirects

13)删除重复的JS和CSS脚本  Remove duplicate JavaScript and CSS

14)配置Etags,使用此技术可以提升性能  Configure entity tags(ETags)

15)使AJAX可以缓存,加快响应  Make AJAX cacheable

16)使用GET完成AJAX请求  Use GET for AJAX requests

17)减少DOM元素的数量  Reduce the number of DOM elements

18)避免404错误  Avoid HTTP 404(NOT Found)error

19)减少cookie大小  Reduce cookie size

20)使用没有cookie的域 Use cookie-free domains

21)避免滤镜的使用(低版本IE中会导致大的性能问题)  Avoid AIphaImageLoader filter

22)HTML里面不要使用缩放图片的方式来处理我们的图片  Do not scale images in HTML

23)小图标尽量使它的文件大小变小,而且文件是可以缓存的 Make favicon small and cacheable

PageSpeed与YSlow的功能差不多,通过这样的静态分析,我们可以知道web应用的基本性能情况。Goodbye~~

iOS抓包工具—Charles简介及安装

Charles是一个HTTP代理服务器、HTTP监视器、反转代理服务器。它可以查看所有连接互联网的HTTP通信。这些包括request, response现HTTP headers (包含cookies与caching信息)。移动端的话,这款工具更加适用于苹果设备,安卓的话有点反应缓慢。

一、下载安装Charles

1、下载地址:

https://www.charlesproxy.com/

2、安装Charles

下载完成后直接进行安装即可,如果不注册每次只能使用30分钟,关于如何注册破解,可以网上下载jar包替换。

 

二、使用Charles

1、打开charles

2、录制pc端

默认打开就开始录制了,直接将Proxy-Windows Proxy勾选,此时在pc端任意链接互联网的http通信都能抓包。

3、录制移动端

本篇文章即主要针对如何对iOS移动设备进行抓包

1)查看本机的IP,win+R,输入cmd,命令输入ipconfig即可查看

或打开Charles的Help-Local IP Address

2)查看Charles的HTTP Proxy的Port,在Proxy-proxy setting中,如下图所示

3)手机端连接无线网(与pc连接同一网段),在无线网详情中选择HTTP代理-手动模式,如下图所示

输入服务器ip,即你步骤1当中查询的本机ip;

输入端口,即你步骤2中查询的端口号;

填写完成之后点击返回即可

4)确保Charles录制按钮已经打开,即红色圆点的按钮

5)在手机端进行操作,charles即可进行抓包

 

最基本抓包功能就这样了,还是很简单的,关于其他的分析以及扩展使用,可以在其他文章中查看。

关于软件上线后出现重大bug是谁的责任?

之所以写这篇文章,主要是大部分测试还是处于弱势地位,线上一旦出问题,大部分人想到的是:你这个没测?基于这点,这篇文章也许可以给你一个明确的答案,这到底是谁的责任。

一、先解决问题

线上爆发重大bug,这时候不是追究责任的时候,而是动员所有可调用的资源,尽快解决这一问题,将损失降到最低。而一般公司在这之前就应该制定好出现重大问题的补救流程和方案以及对应的人员分配。

二、定义bug的性质

解决问题后,定义线上发生的问题的性质,是第三方引起的,不可抗拒的问题,还是自身疏忽导致的错误?且爆发的问题的严重程度,关于bug严重程度的区分,可以参看我的另一篇文章。(传送门:http://blog.jianjiexuan.com/testdocument/42.html

三、分析产生bug的根源

1、需求未涉及,或需求当初定义的不够详细造成。

 这个一般由需求、设计、测试都承担责任,需求的责任最重。之所以说设计和测试也有连带责任,是因为需求评审的时候也参与进去了,而需求都是通过大家一致确认可行通过才执行的。当然,有些公司对于需求评审也不是很重视,也没有专门写需求文档的人,甚至一些小公司直接都是口头表达,这样的需求连记录都没有,实在没办法追责。不过,一般这样的公司也不会追责,如果追责的话,建议设计(产品)、测试一句:你可以刷新简历了。

2、设计过程、开发过程未实现造成。

 这种问题是需求检查到了有未完成的需求,但是设计和开发并没有进行弥补。则为设计与开发的责任,而设计的责任最大。

3、测试过程中的疏漏造成。

 测试过程中的疏漏有2种情况,一种是测试用例没有覆盖,一种是测试用例覆盖了没有执行。第一种参与过测试用例评审的都有责任,但是设计测试用例的人承担最大责任。第二种则完全是测试责任。当然,很多公司根本就不具备评审测试用例或者有专门写测试用例的人,本来管理流程就乱,一人做多种职位的事情,这时候如果硬要追责,建议测试一句:你可以刷新简历了。

4、交付部署中出现问题造成。

 比如版本错误、发布错误、部署错误,一般在设计(产品)、配置、测试经理共同承担责任。

5、私自改动代码造成。

 只能开发哥哥完全承担了。

四、分析总结

 对于这次的事件进行分析与总结,确定是谁的问题后,应该吸取教训,并给出措施,给下次的版本一个参考。

 

其实这套方案肯定是基于自身的流程和管理都非常明确的公司执行。并不适合小团队去执行,小团队建议还是大家一起承担,否则,只会让员工提前离开。如果你不是领导者,愿你不需要看到这篇文章。

 

JMeter元件作用域与执行顺序

在复杂的脚本中,会涉及到jmeter的多个元件,而元件之间的作用域和执行顺序这时候就很重要了,放错位置不仅会造成数据获取不正确,严重还会无法执行,下面即为大家介绍一下元件作用域与执行顺序。

1、元件的作用域

  • 配置元件(config elements):会影响其作用范围内的所有元件(同级别或父级起作用)
  • 前置处理程序(Per-processors):在起作用范围内的每一个sample元件之前执行
  • 定时器(timers):对其作用范围内的每一个sampler有效(同级别或父级起作用)
  • 后置处理程序(Post-processors):在其作用范围内的每一个sampler元件之后执行(同级别或父级起作用)
  • 断言(Assertions):对其所用范围内的每一个sampler元件执行后的结果执行校验
  • 监听器(Listerners):收集其作用范围的每一个samoler元件的信息并出现(同级别或父级起作用)
  • sampler元件不和其他元件相互作用,因此不存在作用域的问题

2、元件的执行顺序

  • 配置元件
  • 前置处理器
  • 定时器(首次也是定时器先执行再执行sampler)
  • Sampler
  • 后置处理器(只在有结果可用情况下执行)
  • 断言(只在有结果可用情况下执行)
  • 监听器(只在有结果可用情况下执行)

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

备注:如果两个相同配置元件作用于同一个采样器,那么这两个配置元件会进行合并,完全一样的取排序靠近的配置元件(如父子级关系)

例1:zuoyongyu1则执行结果是:one显示网页b的地址加上了a的参数(HTTP默认请求都有网页,必须取其一,那么取就近的地址,参数不受影响)。

例2:

zuoyongyu2

后置处理器debug,作用域里按照顺序执行,无就近原则。

3、元件的部分概念

  • 断言:可以用来判断请求响应的结果是否如用户所期望的。它可以用来隔离问题域,即在确保功能正确的前提下执行压力测试。
  • 前置处理器及后置处理器:负责在生成请求之前完成工作。前置处理器常常用来修改请求的设置。
  • 后置处理器:负责在生成请求之后完成工作。后置处理器常常用来处理响应的数据,我们主要在动态关联中用到后置处理器的正则表达式提取器

JMeter录制手机端操作

这只算一个小技能,并没有什么难度,大家可以体验一下:

1、首先打开jmeter,在测试计划下,右击添加“线程组”

2、在工作台下,右击添加“非测试元件—HTTP代理服务器”

1)输入端口号,可以自定义,如9887

2)输入HTTPS Domains(域名):输入自己主机的ip,查询:cmd输入ipconfig即可查看,如:192.168.1.1

3)目标控制器,选择上面的线程组

4)HTTP sampler settings中的Type选择“HttpClient4”

5)配置完手机端(下面的第3步),点击【启动】

shouji1

ps:关于HTTP代理服务器的一些扩展

如图所示,分组选择每个类型的含义:(颜色标出的是比较常用的方式)

shouji2

  • 不对样本分组(Do not group samplers):所有请求全部罗列
  • 在组间添加分隔(Add separators between groups):加入一个虚拟的以分割线命名的动作,运行同“不对样本分组”,无实际意义
  • 每个组放入一个新的控制器(Put each group in a new controller):执行时按控制器给输出结果
  • 只存储每个组的第一个样本(Store 1st sampler of each group only):对于一次url请求,实际很多次http请求的情况,这个选项很好用,因为我们常常是不关心后面的那些请求的。(当选择这个进行录制后,获取的http请求,可以选中图下模式)

shouji3

 

 

3、配置手机端

1)打开设置-无线网-详情,选择HTTP代理—手动

2)输入服务器ip:即为你上面填写在jmeter中的ip,即主机ip

3)输入端口:即为上面自定义的端口,9887

4、操作手机,按着需要录制的东西操作

5、录制完成后,点击HTTP代理服务器的停止按钮,然后删除掉不必要的请求,添加监听器,即可按着刚刚的操作运行查看结果。(有问题可调试解决)

备注:

工作台默认不保存在脚本里,如果需要保存,需要勾选图下内容:(一般情况下我们不需要保存工作台下面的内容)

shouji4

高级软件测试工程师需具备的能力

enlightened每个测试在工作一段时间后,都会迷茫,其实不仅仅是测试,很多工种都会这样,不知道下一步往哪个方向发展,觉得自己在虚度岁月,没有任何进步,开始慢慢的适应了现在的一成不变,这是很危险的,你能看到这篇文章,说明你想改变,恭喜你,你会有收获的。 测试或其他技术工种的发展方向大致是相同的:1、继续专研技术,成为中级测试、高级测试、测试专家等;2、管理方向,这就不仅仅是测试技术了,你得懂得很多团队的东西,最好能有几个证书;3、转相关行业,比如产品、开发什么的。大部分人会选择第一点,而第一点又能细分很多种,白盒的、性能的、数据库的,而我主要讲的是综合的,慢慢的提升以下能力,不管你去互联网哪家公司,你都能如鱼得水。

一、品德心态好

  为什么把这个放在第一位呢?很多人不在乎,认为有技术就行,其实这个不管在测试还是其他方面都很重要,你平易近人,凡事有理有据,不歇斯底里,大家就都愿意和你共事,这样的你也会在这样的工作氛围内更加得心应手,而且测试是需要吵架的,如何把握这个吵架的分寸就很重要,不影响彼此的关系还能把工作做好。

1、首先,我们自己要语气平缓,有些人真的是天生语气就很冲(我身边有这样的人,基本没朋友),如果你是,一定要尽力去更改。虽然也许你本意只是阐述一个bug,但是别人听起来就是责怪,所以这是很头疼的。我之前也有,我明明是在讲bug,开发说你别这么激动,感觉我要吵架,其实真没有(宝宝好委屈(┬_┬)),因为不仅仅一个人这样说,我知道这肯定是我的问题,我肯定是要改的,所以就经常听些舒缓的音乐,看些心理或者周易之类的书,说话的时候每次注意点,形成习惯后,就会彻底改变。

2、讲问题要有理有据,对事不对人,测试很多时候对需求的理解和开发或者产需求的人有偏差,还有描述问题的时候和开发理解的有偏差,这时候难免会起争执。首先,有争执是好事,证明你有自己的想法,你去思考了,你在乎这个需求了,而争执的目的我们要清楚,就是希望产品更好,千万不要带着个人色彩,这样以后的工作大家都会尴尬。但是有争执不能歇斯底里,我们要讲事实摆道理,最重要的一点,一定要倾听别人的想法,坚持己见固然不错,前提是你真的是对的。如果别人说的有道理,你也可以称赞认同,记住,我们争执的目的。

3、对于同是测试的同事,要互相帮助,不要吝啬自己所会的,因为你一直在前进就不怕别人赶超,你帮助别人的同时,也能巩固自己的知识。我经常遇到这样的测试,自己偷偷的学习些技术,为什么说偷偷的呢,因为别的测试走过去的时候,她会迅速关掉正在看的东西(技术类的),首先你学习是好事,但是被看到又怎么了,别人有心也去学,这不是激励你么,再说别人真有心去学,肯定也能搜到,如果无心,看到就看到呗,反正不思进取。还有很多时候新手问问题,很多人会说,就这样啊,点一下写几个东西就好了,很简单的。拜托,你不想说就直说,想说就说清楚。如果你有这些问题,你一定要更改,你的突出不是阻止别人前进,而是加快自己前进的步伐,而且,好的心态,对你整个人生都是有帮助的。相信我。

二、业务熟悉

  作为一个合格的测试,不管你要测什么,你都要了解清楚你所要涉及的业务的所有需求,不能说了解,应该叫掌握、熟记于心。这是一个很庞大的事情,但是你必须这样,因为只有这样,任何一个改动你都能了如指掌,及时进行跟踪,别其他人问起,你却不知道,这样真的很尴尬。

1、熟悉你所测试的系统

  必须非常熟悉你所测试的系统,知道哪些需求是重要的,哪些的次要的,这样才能更好的合理分配你的测试资源。对于需求文档不全的公司,你可以自己编写需求文档,作为自己的参考红本书,有任何改动实时更新,并及时记到脑子里,这样的你,就像上战场打仗的将军,已经清楚敌人的排兵布阵,你怎么能不赢呢?

2、熟悉跟本系统有关的上下游系统业务

  有些系统会涉及到其他系统,虽然我们不需要测试,但是一些需求以及其他系统业务也是要掌握的,这样也可以给自己提供更广的测试思路。也用打仗来比喻的话,这就是需要知道整个国家之间的状态、彼此错综复杂的关系,才能纵横捭阖,在战场上给与一些意想不到的战术。

3、熟悉数据的交互

  熟悉后台与前台的数据交互,这样可以在你提问题的时候,更加有技术性,不仅仅是描述表面的。

三、掌控Deadline

  如果一个版本需求过多,那么开发的任务就多,测试人员要测试的点也就非常的多。这个时候,如果版本封板的时间都是由项目经理或者PM来定,那测试人员就会很被动。而通过测试自己评估需求需要测试的时间及优先级,就能给出一个合理的时间给项目经理或PM,而这个时间最终点就是Deadline。测试要在这个时间点前各种督促开发,根据优先级安排测试,这样可以掌控整个测试的节奏,不需要拼命的加班,也能高效率的完成工作。

四、测试技术

这一点估计才是大家真正想看的,也是对自己镀金很重要的部分,这决定你将处于什么位置。

1、懂得用jmeter、LoadRunner进行性能测试;

2、懂得搭建性能测试需要的环境,例如服务器、redis、memcache等等;

3、懂得一些抓包工具的使用,fidder、charles、Wireshark等等;

4、懂得一些基本命令(数据库、linux)的使用;

5、懂得一些自动化测试,会写一些基础脚本(java、python)进行接口自动化;

6、懂得如何编写性能测试报告并能够进行分析; 

7、懂得一些安全性能测试。

如果你能慢慢掌握以上四大点,基本你走到哪里都不愁高薪了。看看自己缺少哪点,再根据自己的实际情况去学习,祝愿大家都能学有所成!yes