APP测试点总结(功能,交互,死机崩溃状态分析,容易出错的检查点) 版权声明:本文为博主原创文章,未经博主允许不得转载. 最近涉足APP端测试,常见检查点总结如下:   一.业务方面: 1.  注册(无效数据剔除),登录(语音和短信验证码),第三方登录(微信,微博,qq),忘记密码处理,注册   (登录后身份判断校验):账号互踢(同一时间一个账号只能在一台设备上登录) 2.tab切换,滑动,标题显示 3.项目列表显示:上下滑动加载(是不是会重复加载数据):显示的条数是否正确:格式,标签是否正确:

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

一说起软件测试,测试员想到肯定是去检查文件,功能,API,性能并确定软件是否安全,以及关于软件特定部分的其他事项.但是对于移动测试,测试员不得不基于用户移动使用模式考虑移动相关的功能. 本文是基于我的工作经验而写的.作为一名敏捷软件开发团队的软件质量保证经理,我一心投入iPhone,Android,WindowsPhone7的移动apps和移动webapps.在XING移动团队的日常工作以及与其他移动测试专家交流的过程中,我深刻了解了移动测试工作的困难.渐渐地,我明确了什么是帮助改进同事们和我的

一说起软件测试,测试员想到肯定是去检查文件,功能,API,性能并确定软件是否安全,以及关于软件特定部分的其他事项.但是对于移动测试,测试员不得不基于用户移动使用模式考虑移动相关的功能. 本文是基于我的工作经验而写的.作为一名敏捷软件开发团队的软件质量保证经理,我一心投入iPhone,Android,WindowsPhone7的移动apps和移动webapps.在XING移动团队的日常工作以及与其他移动测试专家交流的过程中,我深刻了解了移动测试工作的困难.渐渐地,我明确了什么是帮助改进同事们和我的

App测试中ios和Android的区别: 1. Android长按home键呼出应用列表和切换应用,然后右滑则终止应用: 2. 多分辨率测试,Android端20多种,ios较少: 3. 手机操作系统,Android较多,ios较少且不能降级,只能单向升级:新的ios系统中的资源库不能完全兼容低版本中的ios系统中的应用,低版本ios系统中的应用调用了新的资源库,会直接导致闪退(Crash): 4. 操作习惯:Android,Back键是否被重写,测试点击Back键后的反馈是否正确:应用数据从

运筹帷幄之中,决胜千里之外.古人足不出户,通过正确的部署就能决定千里之外战争的胜利!而于测试人员而言,制定正确的测试方案,就是日后测试就是是否顺利的决定性因素. 在整个测试过程中,对测试人员.资源以及时间分配,合理的测试方案,能帮助测试过程有条不紊的进行,避免在测试过程中遭遇人员.时间.资源的冲突,以及测试环境搭建对测试进度的影响. 那么怎样的内容才算得上测试方案呢: 首先,要确定大方针,落实负责人和目标,在根据需求确定具体做什么类型的测试及规划.执行步骤,当然最重要的还是用例的设计 测试负责人

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

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

1 . Android长按home键呼出应用列表和切换应用,然后右滑则终止应用:2. 多分辨率测试,Android端20多种,ios较少:3. 手机操作系统,Android较多,ios较少且不能降级,只能单向升级:新的ios系统中的资源库不能完全兼容低版本中的ios系统中的应用,低版本ios系统中的应用调用了新的资源库,会直接导致闪退(Crash):4.  操作习惯:Android,Back键是否被重写,测试点击Back键后的反馈是否正确:应用数据从内存移动到SD卡后能否正常运行等:5. pus

1.参考连接 https://www.cnblogs.com/raindrop2007/articles/7849905.html 2.在项目中的使用 2.1 设置手机上的“语言输入法”,选择appium的输入法 2.2robot代码上,需要在启动app时加上两句 resetKeyboard=true    unicodeKeyboard=true

原文链接 Emulator Emualor 是 Android Studio 自带的模拟器,是官方提供的工具,Android 开发最常使用的就是这一款. 它功能非常齐全,电话本.通话等功能都可正常使用.用户可以使用键盘输入,鼠标点击模拟器按键输入,甚至还可以使用鼠标点击.拖动屏幕进行操纵. 当然模拟器毕竟是模拟器,和真实的手机设备还是存在差别的. Emualor 模拟器和真机的不同之处: 不支持呼叫和接听实际来电 不支持 USB 连接 不支持相机/视频捕捉 不支持音频输入(捕捉) 不支持扩展耳机

一.常识性区别 二.导航方式 iOS:Tab放在页面底部,不能通过滑动来切换,只能点击.也有放在上面的,也不能滑动,但有些Tab本身可以滑动,比如天猫的.还有新闻类的应用. Android:一般放在页面顶端,可以通过滑动页面来切换Tab,当然Tab可以点击切换,Tab多的话,Tab本身也可以滑动.比如豌豆荚,百度贴吧,QQ.总之,Android啥都可以有.(其他导航方式,见上一篇) 三.单条item的操作 iOS:单条item的操作有两种,点击和滑动,点击一般进入一个新的页面,滑动会出现对这条i

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

测试一个App具体包括哪些方面,以及每个方面有什么关键点呢? 测试人员常被看作bug寻找者,但你曾想过他们实际是如何开展测试的吗? 你是否好奇他们究竟都做些什么,以及他们如何在一个典型的技术项目中体现价值? 本文将带你经历测试人员的思维过程,探讨他们测试app时的各种考虑.本文的目的在于揭示测试人员的这一思维过程,并展示他们通常所考虑内容的广度和深度. (1)   非功能测试 app测试的一个重要方面是app的非功能需求.移动app在推出市场或进行进一步开发前,测试人员有一定的职责做该类需求的跟

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

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

随着智能设备的普及和移动互联网的兴起,各家互联网巨头纷纷在往移动端布局和转型,同时初创的移动互联网公司也都盯着这个市场希望分一杯羹.在这个大环境下,互联网的重心已经慢慢从Web端转向了移动端,而移动端的软件测试也变得越来越重要了. 在移动端的软件里,手游又是其中非常大的一块.从下面的图可以看出,智能手机的普及和手游玩家的增长是密切相关的: 加入鹅厂前,笔者曾经长期从事手机App的测试开发工作.1年前加入鹅厂后转行做了手游测试工作,通过摸索实践,发现两者在相同的测试理论基础之上,其实有着非常不同的

1. UI 测试app主要核ui与实际设计的效果图是否一致:交互方面的问题建议,可以先与产品经理确认,确认通过后,才开始让开发实施更改或优化 2. 功能测试根据软件说明或用户需求验证App的各个功能实现,实际测试过程一般都是根据功能测试用例来执行.测试覆盖率基本上都是有测试用例主导,也就是说在功能测试部分,是检验测试用例是否有效以及完整的,也就导致另外一个问题,测试用例怎么写的问题,将另外一篇文章来单独阐述测试用例的编写方法. 3. 中断测试模拟用户真实使用app是会遇到的中断情况进行测试.如:

(1) 非功能测试 app测试的一个重要方面是app的非功能需求.移动app在推出市场或进行进一步开发前,测试人员有一定的职责做该类需求的跟踪工作. 早期开发阶段要进行的第一个测试应该是实用性测试.通常是由alpha用户或同事进行的.走进一家咖啡馆或餐厅,问问里面的人他们的app使用情况.让他们看看现阶段开发的第一个版本并收集反馈,看看用户是否能很好地使用新功能,以便得出第一印象. (2) 功能测试 每项开发的新功能都需要进行测试.app测试中功能测试是一个重要方面.测试人员应该要进行手动测试和

功能上: 功能上没有什么区别,都是用同样的方法来写用例(等效.边界值...) 架构上: web是B/S架构(浏览器和服务器)代码更新后数据会同步,可以保证所有客户一致 app是C/S架构(客户端和服务器)代码更新后不能保证所有客户端都进行了更新,功能需要进行回归测试 兼容上: web主要关注几大主流浏览器的兼容问题:Google .firefix .ie... app在不同系统上的兼容:ios.安卓  不同机型的兼容安卓有二十多种.. 性能上: web只需要考虑响应时间 app需要考虑电量消耗.

WEB测试和App测试从流程上来说,没有区别.都需要经历测试计划方案,用例设计,测试执行,缺陷管理,测试报告等相关活动.从技术上来说,WEB测试和APP测试其测试类型也基本相似,都需要进行功能测试.性能测试.安全性测试.GUI测试等测试类型. 他们的主要区别在于具体测试的细节和方法有区别,比如:性能测试,在WEB测试只需要测试响应时间这个要素,在App测试中还需要考虑流量测试和耗电量测试. 兼容性测试:在WEB端是兼容浏览器,在App端兼容的是手机设备.而且相对应的兼容性测试工具也不相同,WEB