工作总结: 1 这两天由于工作,需要进行抓包,使用了Charles,fidder,发现一个坑点: charles没有抓到返回值的时候,默认是不在列表显示请求信息的,能不能设置,我就不知道了,但是可以在底部时时显示请求信息,一闪而过: fiddler4可以正常抓到没有返回的请求! 2 各类手机使用adb链接不到,1 链接USB时,电脑提示安装失败,点击失败窗口,选择通过windows update安装驱动,正常安装驱动后, 再讲驱动安装选择回不从windows安装驱动,驱动安装成功,再次链接USB

这几天测的一个app,后台从已有服务器搬迁到了阿里云,接口api之类的都没有变化,但测试时发现客户端始终无法使用,每次点击都无法获得服务器反馈 用python编写脚本调接口,没问题,返回数据一切正常,app代码也没有动过,唯一动过的地方就是后台网址. 纳闷,于是在本地电脑利用ccproxy搭建代理,然后在ipad的无线网络连接下面设置本地代理,然后开启wireshark针对app的数据进行抓包,数据包全部抓取到后,将与阿里云交互的数据与现有服务器交互的数据进行比对,发现用post请求调客户端登陆

ADB全称Android Debug Bridge, 是android sdk里的一个工具, 用这个工具可以直接操作管理android模拟器或者真实的andriod设备(手机),故在其实工作可以给我们很多帮助,下面将总结下之前工作中常用到的adb命令: adb help, 列出所有的选项说明及子命令 adb devices , 获取设备列表及设备状态 adb get-state , 获取设备的状态,设备的状态有 3 钟,device , offline , unknown,其中device:设备

1.先确定产生问题的地方是否与服务器产生交互/通信,若无则非服务器问题: 2.通过Fiddler抓包,查看操作时调用的服务器接口是否正常并检查对应返回值: 3.若接口返回值正常,则需查看客户端对业务的逻辑处理.

一.简介 移动应用App已经渗透到每个人的生活.娱乐.学习.工作当中,令人激动.兴奋且具有创造性的各种App犹如雨后春笋般交付到用户手中.各类智能终端也在快速发布,而开发者对于全球移动设备的质量和性能却掌握甚少,App与设备的兼容性问题常常导致用户投诉,令开发者十分沮丧,App测试与服务质量保证矛盾十分突出. 移动开发的一个重要难题,就是应用在开发过程中,必须使用手机真实环境进行系统测试,才有可能进入商用.由于手机操作系统的不同,以及操作系统版本之间的差异,使得真机系统测试这个过程尤其复杂,涉及

目录 1.测试计划内包含的元件 2.HTTP代理服务器的设置内容 3.设置手机的代理服务器 4.录制脚本 5.查看录制的脚本 6.HTTP代理服务器的排除模式 7.保存脚本 8.注意坑点 录制脚本只不过是我们日常工作中的一个小应用而已,只是为了能快速看到应用程序跑的逻辑及实现顺序.并够帮助测试人员,快速查出问题出现的节点. 而对于做有针对性的测试时,比如做某个接口的测试,建议大家还是自己去创建及组织脚本,不过录制的脚本可以拿来做参考,粘贴复制也是可以节省不少的工作量. 在JMeter中可以使用自

(1)App独特测试点: 客户端兼容性测试:系统版本.不同深度定制的rom.屏幕分辨率.中断测试.安装.卸载.升级.对其他程序的干扰等 需要的一些工具: appnium / lr /  jmeter / 打包工具 / 抓包工具等 (2)是否需要搭建环境? 基本不需要,服务端统一搭建部署服务,跟在某个客户端运行关系不大,无需单独部署环境. (3)推荐两个上传App安装包到应用市场的工具网站: ①www.fir.im ②www.pgyer.com (4)网络环境测试: 手机的网络目前主要分为2G.3

APP测试的时候,建议让开发打好包APK和IPA安装包,测试人员自己安装应用,进行测试.在测试过程中需要注意的测试点如下: 1.安装和卸载 ●应用是否可以在IOS不同系统版本或android不同系统版本上安装(有的系统版本过低,应用不能适配) ●软件安装后是否可以正常运行,安装后的文件夹及文件是否可以写到指定的目录里. ●安装过程中是否可以取消 ●安装空间不足时是否有相应提示 ●如果应用需要通过网络验证之类的安装,需要测试一下断网情况下是否有相应提示 ●是否可以删除应用(可通过桌面删除,也可以通

最近较懒,加之闺女出生后记忆没完全恢复,总是忘东忘西,关于安卓APP测试的验证点还是总结一下,方便设计测试用例时查阅,也给各位博友参考! 1.除APP的正常功能点外,还有以下验证点: 安装/卸载(考虑是否清数据) 升级(考虑卸载重新安装.覆盖安装升级.通过无忧通知升级.在线检测新版升级) 升级后新旧数据的兼容性 网络切换是否有相应提示说明?比如wifi切换到正常网络 程序进入输入功能时,是否正常弹出键盘?键盘是否遮挡输入框?键盘的输入法切换 是否有菜单项 home和程序间多次切换 返回上一级操作

1 APP测试基本流程 1.1流程图 1.2测试周期 测试周期可按项目的开发周期来确定测试时间,一般测试时间为两三周(即15个工作日),根据项目情况以及版本质量可适当缩短或延长测试时间.正式测试前先向主管确认项目排期. 1.3测试资源 测试任务开始前,检查各项测试资源. --产品功能需求文档: --产品原型图: --产品效果图: --行为统计分析定义文档: --测试设备(ios3.1.3-ios5.0.1:Android1.6-Android4.0:Winphone7.1及以上:Symbian 

1.从功能测试的来讲的话,在流程和功能测试上是没有区别的.系统测试和一些细节可能会不一样. 那么我们就要先来了解,web和app的区别. web项目,一般都是b/s架构,基于浏览器的,而app则是c/s的,必须要有客户端.那么在系统测试测试的时候就会产生区别了. 首先从系统架构来看的话,web测试只要更新了服务器端,客户端就会同步会更新.而且客户端是可以保证每一个用户的客户端完全一致的.但是app端是不能够保证完全一致的,除非用户更新客户端.如果是app下修改了服务端,意味着客户端用户所使用的核

  以下所有测试最后必须在真机上完整的执行 1.安装.卸载测试 在真机上的以及通过91等第三方的安装与卸载 安装在手机上还是sd卡上 2.启动app测试 3.升级测试 数字签名.升级覆盖安装.下载后手动覆盖安装.跨版本升级.升级后可以正常使用. 覆盖安装要确保数据库有字段更新的话,能正常更新,否则就容易导致app异常. 4.功能测试 包括功能点.业务逻辑.关联性(主要测试客户端与PC端的交互,客户端处理完后,PC端与客户端数据一致).服务端接口测试(主要通过访问服务端接口来验证服务端业务逻辑功能

介绍几款移动App测试的工具: 腾讯测试:http://bugly.qq.com/优测:http://utest.qq.com/fir.im测试:http://bughd.com/ 大致介绍如下: bugly:腾讯推出的移动应用崩溃检测服务,提升团队解决异常的效率. bugHD:开发者可以追踪崩溃信息.崩溃版本.崩溃总数.发生设备和是否修复等信息.是Fir.im 团队做的产品: ----------------------------更多介绍如下,详细请参考个网站官网,及阅读相关帮助 -----

Daniel Knott 用过各种不同编程语言和软件质量保证工具.他在软件开发和测试方面干了七年,自2010年起,他一直在德国汉堡的XING AG公司就职,几个项目里,比如XING调查和XING建议,他负责测试管理,测试自动化和测试执行.Daniel现在是XING移动和XING API团队的质量保证团队负责人.在XING移动团队中,他还负责XING安卓和iPhone Apps的测试管理和测试自动化.Daniel在包括像Robotium, KIF (Keep It Functional), Sel

APP测试的时候,建议让开发打好包APK和IPA安装包,测试人员自己安装应用,进行测试.在测试过程中需要注意的测试点如下: 1.安装和卸载 ●应用是否可以在IOS不同系统版本或android不同系统版本上安装(有的系统版本过低,应用不能适配) ●软件安装后是否可以正常运行,安装后的文件夹及文件是否可以写到指定的目录里. ●安装过程中是否可以取消 ●安装空间不足时是否有相应提示 ●如果应用需要通过网络验证之类的安装,需要测试一下断网情况下是否有相应提示 ●是否可以删除应用(可通过桌面删除,也可以通

移动App测试浅析 1. 移动App测试的现状及其挑战 移动互联网走到今天,App寡头化的趋势已经越来越明显,同时用户的口味越来越高,这对移动App开发者提出了更高的要求.几年前可能你有一个创意,随便做一个App,就算功能简单,Bug很多,也会有不少用户会使用,因为当时的选择少.而现在,如果App的质量不过关,体验不好,还经常崩溃闪退的话,会被好不容易获得的用户立刻卸载掉.这就要求开发者对于App的测试越来越重视,而App的测试和传统测试相比,面临更多挑战: App迭代速度快,测试时间少. 现在

对于手机项目(应用软件),主要是进行系统测试. 而针对手机应用软件的系统测试,我们通常从如下几个角度开展测试工作: 功能模块测试: 交叉事件测试: 性能测试: 安全测试: 容量测试: 兼容性测试: 接口测试: 易用性/用户体验测试: 硬件环境测试 安装/卸载测试: 升级/更新测试: 1.功能模块测试:根据软件需求说明书或者用户需求验证app的各个功能是否实现,采用如下方法实现并评估功能测试过程: 采用时间.地点.对象.行为.和背景五元素或业务分析等方法.提炼app的用户使用场景,对比说明和需求,

开发测试时给 Kafka 发消息的 UI 发送器――Mikasa 说来话长,自从入了花瓣,整个人就掉进连环坑了. 后端元数据采集是用 Storm 来走拓扑流程的,又因为 @Zola 不是很喜欢 Java,所以退而求其次选择了 Clojure,所以正在苦逼地学习 Clojure 和 Storm 中. 目前来说外面的 Storm 拓扑的 Spout 是从 Kafka 中流入数据的.但是我们要给 Kafka 发送测试数据的时候,就需要跑到 Kafka 的测试服务器打开它的一个发送脚本进去发送,非常蛋疼

稳定性测试的概念有2种, 一, 稳定性测试,对应于异常性测试,即发生异常情况时,系统如何反应的测试.包含: 1 交互性测试,被打扰的情况,如来电,短信,低电量等.这些其实在上章的功能测试中有提到. 2 异常性测试,断网,断电,服务器异常等情况 二,稳定性测试指的是性能测试,压力测试 1 基准性能测试,通过压服务器端口及客户端在不同网络环境下响应速度 2 大数据测试,在特定环境下,客户端一次性更新大量数据及人员列表 另有其它文章,提到性能测试,为评估APP的时间和空间特性(真是高深啊,时间和空间,

如今,随着移动互联网的浪潮越翻越涌,移动APP测试工作的现状已经成了那本"家家难念"的经.不管公司大小,不管测试哪种类型的APP,让广泛测试者苦不堪言的就属重复性最多,测试工作量最大的功能测试.而这个系列文章将逐一解构一些问题. 笔者通过对目前大型的安卓市场和APPstore进行调查,其实我们可以发现每天都不乏有有创意的,能够针对市场需求的APP上线,但不管当时这些APP是不是排在榜单前列,过不了多久,它们便在应用市场中销声匿迹,变成所谓的"僵尸"应用. 面对这些如

现在我们测试时,开发会先在本地机上打好测试包,自己安装,轮完一轮,开发修改好后,再打一个包.以下是功能测试时需要注意的点: 1.登录 ●登录用户名和密码错误时,界面有提示信息 ●用户主动退出登录后,下次启动APP时,应该进入登录界面 ●对于支持自动登录的APP,数据交换时  ,是否能自动登录成功且数据库操作无误 ●密码更改后,登录时是否做到了有效数据的校验 ●对于未登录时一些页面的操作,是否做了控制 ●切换账号登录,检验登录的信息是否做到及时更新 ●对于多个端都进行操作时,确保数据库操作无误,且