app测试移动应用测试-功能测试适合0基础学习
app测试移动应用测试 （功能测试）适合0基础学习
文章目录
app测试移动应用测试 （功能测试）0基础
一、背景介绍
• 随着科学技术的飞速发展，当今的计算机发展已进入了移动互
联网时代。在我国，随着3G 、4G网络和智能手机的快速发展，
人们已经逐渐养成通过智能手机进行上网的习惯，由智能手机
带动的新兴应用正在开辟一个新的计算机时代-移动互联网时代。
• 移动互联网无疑是当前世界最关注的领域之一，以苹果、
Google等领衔的智能手机和平板电脑正在悄然改变人们对手机
和电脑的传统观念。可见随着各种有价值、实用的应用软件的
不断产生，一个更加庞大和快速发展的用户市场正在形成，面
对如此庞大的移动互联网应用市场，基于移动互联网的软件测
试也越来越重要。基于移动互联网的软件测试，从技术上来讲
应该是传统软件测试的一个继承和发展。
• 移动终端种类
• 终端OS
• 移动平台两分天下
• 主流移动终端操作系统
• IOS介绍
• IOS是由苹果公司开发的手持设备操作系统。苹果公司最早
于2007年1月9日的Macworld大会上公布这个系统，最初是设
计给iPhone使用的，后来陆续套用到iPod touch、iPad以及
Apple TV等苹果产品上。iOS与苹果的Mac OS X操作系统一
样，它也是以Darwin为基础的，因此同样属于类Unix的商业
操作系统。原本这个系统名为iPhone OS，直到2010年6月7
日WWDC大会上宣布改名为iOS。截止至2011年11月，根据
Canalys的数据显示，iOS已经占据了全球智能手机系统市场
份额的30%，在美国的市场占有率为43% 。
出色的触控体验
强大的APP Store
安全性及扩展性强
• Android介绍
• Android是一种以Linux为基础的开放源代码操作系统，主要
使用于便携设备。尚未有统一中文名称，中国大陆地区较多
人使用“安卓”或“安致”。Android操作系统最初由Andy
Rubin开发，最初主要支持手机。2005年由Google收购注资，
并组建开放手机联盟开发改良，逐渐扩展到平板电脑及其他
领域上。Android的主要竞争对手是苹果公司的iOS以及RIM
的Blackberry OS。2011年第一季度，Android在全球的市场
份额首次超过塞班系统，跃居全球第一。 2012年7月数据，
Android占据全球智能手机操作系统市场59%的份额，中国市
场占有率为76.7%
全新开源系统
自由度高
安全性低
• Android架构
app生命周期图
移动应用与传统PC应用的区别
• 移动端成为主战场
• 移动应用份额增长强劲
二、App项目流程
市场分析
• 产品在投入研发之前，企业高层决策评估项目的必要性。其
内容涉及市场分析，销售策略，盈利预测等。
• 输出产物：商业需求文档（BRD）
• BRD的文档结构主要包括：
– 1.方案形成背景
– 2.方案价值（经济类和非经济类的）
– 3.产品规划
– 4.盈利模式
– 5.收益与成本评估
– 6.风险和对策
需求调研
• 经过一系列的分析后，拿出一套你认为最合理的干某个事情的方法
，调研采用什么样的方式获得BRD里面的商业目标。
• 输入产物：市场需求文档（MRD）
• MRD的文档结构主要包括：
– 1.文档说明
– 2.市场分析
– 3.用户分析
– 4.产品说明
产品制造
• 产品项目由“概念化”阶段进入到“具体化”阶段的最主要的阶段。
该阶段通过产品需求文档（PRD）指导产品的开发实现。
• 产品需求文档（PRD），就像建筑设计师的设计图纸，是整个设计和
思考的结晶；同时，也是思考过程呈现。
• 广义上来讲，产品需求的描述，应该包含有产品的战略和战术，战略
是指：产品定位、目标市场、目标用户、竞争对手等。战术是指产品
的结构、核心业务流程、具体用例描述、功能&内容描述等，本文主
要讨论的是战术部分。
交互设计
• 业务模型框架化
– 在产品的概念阶段时期，交互设计师需要基关注用户界面和整体
结构，这个过程被称作“框架设计”
– 框架设计就是一种基于用户目标的导航架构和流程设计。
– 这个阶段交互的产出物主要有导航架构图，流程图和低保真线框
图。
• 框架界面化
– 在定义完功能模块的页面结构和流程后，交互设计师还需要设计
规划使用者的操作，这些包括页面元素的主次关系，小部件的处
理，元素的组织，界面的引导等等。
– 这个阶段交互设计师需要提供原型demo
产品开发
系统测试
• 1.测试准入
• 2.功能测试
• 3.性能测试
• 4.兼容性测试
• 5.上线步骤测试
• 6.联调测试
产品上线
• 上线及线上检查
– 1.上线前发出测试报告，主要包括结论，存在的问题和风险等
– 2.上线后发出线上验证报告
– 3.添加必要的监控和事故处理预案
• 项目总结
– 1.典型bug分析（建议发现方式）
– 2.项目问题以及与目标匹配程度
– 3.项目经验分享
产品运营
一是APP数据，二是用户反馈，三是需求提取。
1、APP数据
新增用户：第一次启动应用的用户；
新增独立用户：全体应用的新增用户的总和（去重）
活跃用户：当天启动一次的用户即为活跃用户，含新用户和老用户；
活跃独立用户：当天应用的活跃用户总和（去重）
MAU：MAU（monthly active users）月活跃用户人数。
DAU: DAU(Daily Active User)日活跃用户数量。常用于反映网站、互联网应用或网络游戏的运营情况。
用户留存率：在互联网行业中，用户在某段时间内开始使用应用，经过一段时间后，仍然继续使用该应用的用户，被认作是留存用户。这部分用户占当时新增用户的比例即是留存率，会按照每隔1单位时间（例日、周、月）来进行统计。
用户留存率中的40-20-10法则：如果你想让游戏、应用的DAU超过100万，那么日留存率应该大于40%，周留存率和月留存率分别大于20%和10%。
次日留存率：（当天新增的用户中，在往后的第1天还活跃的用户数）/第一天新增总用户数；
第2日留存率：（第一天新增用户中，在往后的第2天还有活跃的用户数）/第一天新增总用户数；
第7日留存率：（第一天新增的用户中，在往后的第7天还有活跃的用户数）/第一天新增总用户数；
第30日留存率：（第一天新增的用户中，在往后的第30天还有活跃的用户数）/第一天新增总用户数。
另外就是APP的埋点数据，这个功能的点击率是多少？这个功能有多少人打开，又有多少人使用了？有多少人在频繁使用这个功能？等等，这些埋点数据要时常关注。结合数据变化来反思功能设计的问题，从而优化产品。
2、用户反馈和评论
产品上线后，用户的反馈和评论对于产品人员来讲是尤为珍贵的材料，一方面这是你的真实用户的直观感受，另一方面他们再表达直接的需求。那么，怎么样处理用户的意见就显得格外重要。用户反馈什么我们就做什么，这是肯定不行的。很多情况下用户表达的只是一种表面现象，要学会去挖掘用户背后的需求本质。多去研究世界上一些革命性的产品，多去了解人。
当看到四处飞来的意见时，我们要学会思考，而不是全盘接受、全盘照抄。
是不是我们的目标？想想我们的目标用户是谁。
使用场景是否成立？还是这只是极个别人的场景需求。
用户目标是否正确？我们的APP是不是用来满足用户这个需求的？
产品定位还正确吗？如果做了这个功能，还符合我们产品的定位吗？
如果要做这个功能，那么自身的项目资源是否能够满足？如果需要举全部资源来做这件事情，那就要慎重再慎重。
3、需求提取
也许用户的意见是个圆形，但经过分析之后，很有可能得到需求是个三角形。
“如果我最初问消费者他们想要什么，他们应该是会告诉我，‘要一匹更快的马！’”
——这是亨利·福特的一句经典名言，如今我们在《乔布斯传》里又见到了它。
100多年前，福特公司的创始人亨利·福特先生到处跑去问客户：“您需要一个什么样的更好的交通工具？”几乎所有人的答案都是：“我要一匹更快的马”。很多人听到这个答案，于是立马跑到马场去选马配种，以满足客户的需求。但是福特先生却没有立马往马场跑，而是接着往下问。
福特：“你为什么需要一匹更快的马？”
客户：“因为可以跑得更快！”
福特：“你为什么需要跑得更快？”
客户：“因为这样我就可以更早的到达目的地。”
福特：“所以，你要一匹更快的马的真正用意是？”
客户：“用更短的时间、更快地到达目的地！”
于是，福特并没有往马场跑去，而是选择了制造汽车去满足客户的需求。
客户需求有显性需求和隐性需求两大类。我们通过市场调查得知的往往都是一些诸如“我要一匹更快的马”这类显性需求。客户的显性需求并不是客户真正的需求。企业需要根据所收集的显性需求信息进行深度挖掘和捕获，以了解客户的隐性需求是什么，进而分析出客户的真正需求是什么（例如：用更短的时间、更快地到达目的地）。这就是一个需求分析的过程。
乔布斯所言：“我们的任务是读懂还没落到纸面上的东西。”实际上就是用户隐性需求的深度挖掘。
4、持续迭代
三、APP测试流程
移动APP测试分类
移动测试与传统测试的区别
什么是移动APP测试？
移动APP测试定义：
移动APP测试就是符合多
种网络，不同系统不同分辨
率下发现软件缺陷，并保证
提高软件质量的过程。
移动APP测试的考虑要点
终端资源有限（CPU、内存、磁盘）
环境特殊（移动空间、网络环境、应用五花八门）
用户为核心（文化背景、操作习惯）
什么操作都有可能
用户体验至关重要
***移动应用测试的重点
用户体验是移动应用成败的关键，所以也是移动应用测试需要
高度关注的地方。
结合移动应用软件的特性, 测试的重点有：
① 操作方式: 触摸是否符合操作系统本身的要求, 一指触摸
和两指触摸是否冲突; 操作步骤是否符合用户习惯, 不同功
能的触摸操作是否存在冲突等；
② 用户界面布局: 对用户是否友好，界面设计是否符合手机平
台的设计规范, 动作按钮和导航按钮安排是否合理, 界面色
调是否统一, 文本字体大小是否合理等；
③ 功能操作流程: 主要功能和次要功能衔接是否合理, 并列
功能之间是否可以平滑过渡, 是否符合用户操作习惯等；
④ 兼容系统平台的限制：功能设计是否考虑到移动设备有限的
存储空间；与网络相关的功能设计是；
⑤ 否考虑到移动设备带宽限制：数据交互设计是否考虑容错处
理: 移动设备的移动性, 3G/Wi-Fi 之间的切换导致的连接不稳
定, 数据过大, 用户频繁操作等导致软件出错是否给出友好的
提示.，以及用户能否承受流量的消耗速度；
⑥ 是否考虑到使用该应用时对电量的消耗程度对于用户能否忍
受。
● **网络连接及安全性检查和用户体验高度相关，是移动应用测试
需要高度关注的另一个重点。**
移动开发平台通常开放了获取设备ID、位置、所连接的网络等信息,用户在
下载应用的时候最关心的是此款应用是否会盗取个人信息,尤其是基于
LBS(Location Based Service)的软件应用;
有的开发平台像Google Android开发平台还提供了下载量统计的功
(GoogleAnalytics),如何合理利用而不过度消耗网络流量也是测试的重要检
查点;
基于移动互联网的移动应用更是离不开网络链接,与网络相关的功能也是测
试的重点;
网络连接及安全性检查主要有以下功能点：
①用户注册登陆信息的安全性：与个人财务账户相关的信息要及时退出,比
如银行账户、支付宝账户等, 防止手机丢失而造成更大的损失;
②位置信息提供启动关闭机制:用户可以随时关闭自己的位置信息而不是一
直暴露信息；
③检测当前网络连接:提示用户当前所用网络是3G还是Wi-Fi以便用户选择是
否继续进行大数据量下载(比如使用3G网络时候打开视频而造成流量费用激
增)；
④产品数据跟踪:检查所跟踪的数据信息是否符合开发平台规范、是否违反
法律、是否占用带宽甚至导致数据流量过大；
⑤数据流量监测:监测所有功能使用的数据流量; 测试同一份数据是否重复
下载上传；是否采取逐次下载而不是全部下载。
App测试管理流程
1.测试计划
– 计划是指用文字和指标等形式所表述的组织以及组织内不同部门和
不同成员，在未来一定时期内关于行动方向、内容和方式安排的管
理事件。
– 测试计划是对系统测试全过程的组织、资源、原则等进行规定和约
束，并制定系统测试全过程各个阶段的任务以及时间进度安排，并
提出对各项任务的评估、风险分析和管理需求。
– 测试计划的要点：
– 确定测试范围和资源安排
– 制定进度安排
– 风险及对策
– 准入标准和准出标准
影响项目成功的要素
• 范围
• 时间
• 成本
• 质量
• 风险
• 人力资源
• 沟通
• 采购
测试方案
2.软件测试流程–测试设计
3.测试准备
• 测试用机准备
– 根据适配测试策略准备测试用机
• 测试数据准备
– 测试团队安排专人进行测试数据的生成
– 测试组提出数据申请要求，由其他项目组配合完成
• 版本提测
– 版本部署
– 冒烟测试
4.测试执行
• 第一轮测试：
– 冒烟测试通过后，开始执行系统测试用例，即进行详细的功能
测试，在功能测试过程中主要以黑盒测试为主，同时执行操作
类型测试。
– 功能测试过程中，若发现大量Bug，在开发Fix bug过程中，快
速执行弱网测试等。
• 第二轮测试：
– 主要为了发现深层次的Bug，除了验证bug fix外，还加入了适
配测试，弱网络测试等非功能测试
缺陷处理过程
测试报告
• 测试的最终成果物，其主要内容包括：
– 1.测试的过程说明（测试实际所花费的时间、人员、所测试的内
容说明：包含执行了多少用例，发现了多少缺陷）
– 2.对系统的质量进行分析与度量（通过缺陷的发现率和修复率）
– 3.测试结论（是否通过，上线是否还存在哪些风险，如何规避）
5.线上监测
• 线上检测是改进APP用户体验的重要手段；
• 主要收集发布后的用户反馈，有无异常情况，排查问题，统计分析等.
APP测试实施流程
四、APP测试方法
App测试层级体系
App测试类型
功能测试
• 功能测试就是对产品的各功能进行验证，根据功能测试用
例，逐项测试，检查产品是否达到用户要求的功能。
• 功能测试也称行为测试，测试一个产品的特性和可操作行
为是否满足其用户需求。所以测试人员要考虑到软件的用
户类型，以及在不同的数据场景下如何进行测试。
根据软件说明或用户需求验证App的各个功能实现，采用如下方
法实现并评估功能测试过程：
• 1)采用时间、地点、对象、行为和背景五元素或业务分析等方
法分析、提炼App的用户使用场景，对比说明或需求，整理出
内在、外在及非功能直接相关的需求，构建测试点，并明确测
试标准，若用户需求中无明确标准遵循，则需要参考行业或相
关国际标准或准则。
• 2)根据被测功能点的特性列丼出相应类型的测试用例对其进行
覆盖，如；涉及输入的地方需要考虑等价、边界、负面、异常
或非法、场景回滚、关联测试等测试类型对其进行覆盖。
• 3)在测试实现的各个阶段跟踪测试实现与需求输入的覆盖情况
，及时修正业务或需求理解错误。
可能的测试场景：
• 测试用户可输入的极限值；
• 用重复的数据进行测试；
• 在全新无数据的手机里测试；
• 在老手机上测试；
• 预先安装不同类型的数据；
• 用一些超出预期的数据去测试，看它是怎么处理的；
• 分析信息和数据是怎么影响用户体验的；
功能测试主要是程序逻辑及相关业务点测试
• 一、应充分考虑各种边缘情况，边界状态
• 二、应多站在用户的角度考虑程序的设计是否合理，是否
充分满足用户的需求
UI测试
• 确保手头的原型图与效果图为当前最新版本。
• 确保产品UI符合产品经理制定的原型图与效果图。
• 测试用户界面(如菜单、对话框、窗口和其它可规控件)布局、风格是
否满足客户要求、文字是否正确、页面是否美观、文字、图片组合是
否完美、操作是否友好等。
• UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相
应的访问或浏觅功能。确保用户界面符合公司或行业的标准。包括用
户友好性、人性化、易操作性测试。
UI测试之导航测试
• 按钮、对话框、列表和窗口等；或在不同的连接页面之间需要导航
• 是否易于导航，导航是否直观
• 是否需要搜索引擎
• 导航帮助是否准确直观
• 导航与页面结构、菜单、连接页面的风格是否一致
UI测试之图形测试
• 横向比较。各控件操作方式统一
• 自适应界面设计，内容根据窗口大小自适应
• 页面标签风格是否统一
• 页面是否美观
• 页面的图片应有其实际意义而要求整体有序美观
• 图片质量要高且图片尺寸在设计符合要求的情况下应尽量小
• 界面整体使用的颜色不宜过多
UI测试之内容测试
• 输入框说明文字的内容与系统功能是否一致
• 文字长度是否加以限制
• 文字内容是否表意不明
• 是否有错别字
• 信息是否为中文显示
• 是否有敏感性词汇、关键词
• 是否有敏感性图片，如：涉及版权、专利、隐私等图片
业务测试的分类
运行APP
• 1）App安装完成后的试运行，可正常打开软件。
• 2）App打开测试，是否有加载状态进度提示。
• 3）App打开速度测试，速度是否可观。
• 4）App页面间的切换是否流畅，逻辑是否正确
• 5）注册
–同表单编辑页面
–用户名密码长度
–注册后的提示页面
–前台注册页面和后台的管理页面数据是否一致
–注册后，在后台管理中页面提示
• 6）登录
–使用合法的用户登录系统。
–系统是否允许多次非法的登陆，是否有次数限制。
–使用已经登陆的账号登陆系统是否正确处理。
–使用禁用的账号登陆系统是否正确处理。
–用户名、口令（密码）错误或漏填时能否登陆。
–删除或修改后的用户，原用户登陆。
–不输入用户口令和用户、重复点（确定或取消按钮）是否允许登陆。
–登陆后，页面中登陆信息。
–页面中有注销按钮。
–登陆超时的处理。
• 7）注销
–注销原模块，新的模块系统能否正确处理。
–终止注销能否返回原模块，原用户。
–注销原用户，新用户系统能否正确处理。
–使用错误的账号、口令、无权限的被禁用的账号进行注销
应用的前后台切换
• 1) APP切换到后台，再回到app，检查是否停留在上一次
操作界面。
• 2) APP切换到后台，再回到app，检查功能及应用状态是
否正常，IOS4和IOS5的版本的处理机制有的不一样。
• 3) app切换到后台，再回到前台时，注意程序是否崩溃
，功能状态是否正常，尤其是对于从后台切换回前台数据
有自动更新的时候。
• 4) 手机锁屏解屏后进入app注意是否会崩溃，功能状态
是否正常，尤其是对于从后台切换回前台数据有自动更新
的时候。
• 5) 当App使用过程中有电话进来中断后再切换到app，功
能状态是否正常
• 6) 当杀掉app进程后，再开启app，app能否正常启动。
• 7) 出现必须处理的提示框后，切换到后台，再切换回来
，检查提示框是否还存在，有时候会出现应用自动跳过提
示框的缺陷。
• 8) 对于有数据交换的页面，每个页面都必需要进行前后
台切换、锁屏的测试，这种页面最容易出现崩溃
免登录
很多应用提供免登录功能，当应用开启时自动以上一次登录
的用户身份来使用app.
• 1) app有免登录功能时，需要考虑IOS版本差异。
• 2) 考虑无网络情况时能否正常进入免登录状态。
• 3) 切换用户登录后，要校验用户登录信息及数据内容是
否相应更新，确保原用户退出。
• 4) 根据MTOP的现有规则，一个帐户只允许登录一台机
器。所以，需要检查一个帐户登录多台手机的情况。原手
机里的用户需要被踢出，给出友好提示。
• 5) app切换到后台，再切回前台的校验
• 6) 切换到后台，再切换回前台的测试
• 7) 密码更换后，检查有数据交换时是否进行了有效身份
的校验
• 8) 支持自动登录的应用在进行数据交换时，检查系统是
否能自动登录成功并且数据操作无误
• 9) 检查用户主动退出登录后，下次启动app，应停留在
登录界面
数据更新
根据应用的业务规则，以及数据更新量的情况，来确定最优的数
据更新方案。
• 1) 需要确定哪些地方需要提供手动刷新，哪些地方需要自动刷
新，哪些地方需要手动+自动刷新。
• 2) 确定哪些地方从后台切换回前台时需要进行数据更新。
• 3) 根据业务、速度及流量的合理分配，确定哪些内容需要实时
更新，哪些需要定时更新。
• 4) 确定数据展示部分的处理逻辑，是每次从服务端请求，还是
有缓存到本地，这样才能有针对性的进行相应测试。
• 5) 检查有数据交换的地方，均有相应的异常处理。
离线浏览
很多应用会支持离线浏览，即在本地客户端会缓存一部分数
据供用户查看。
• 1) 在无网络情况可以浏览本地数据
• 2) 退出app再开启app时能正常浏览
• 3) 切换到后台再切回前台可以正常浏览
• 4) 锁屏后再解屏回到应用前台可以正常浏览
• 5) 在对服务端的数据有更新时会给予离线的相应提示
App更新
• 1) 当客户端有新版本时，有更新提示。
• 2) 当版本为非强制升级版时，用户可以取消更新，老版本能正
常使用。用户在下次启动app时，仍能出现更新提示。
• 3) 当版本为强制升级版时，当给出强制更新后用户没有做更新
时，退出客户端。下次启动app时，仍出现强制升级提示。
• 4) 当客户端有新版本时，在本地不删除客户端的情况下，直接
更新检查是否能正常更新。
• 5) 当客户端有新版本时，在本地不删除客户端的情况下，检查
更新后的客户端功能是否是新版本。
• 6) 当客户端有新版本时，在本地不删除客户端的情况下，检查
资源同名文件如图片是否能正常更新成最新版本。如果以上无
法更新成功的，也都属于缺陷。
定位、照相机服务
• 1) App有用到相机，定位服务时，需要注意系统版本差异
• 2) 有用到定位服务、照相机服务的地方，需要进行前后台的切换测
试，检查应用是否正常。
• 3) 当定位服务没有开启时，使用定位服务，会友好性弹出是否允许
设置定位提示。当确定允许开启定位时，能自动跳转到定位设置中开
启定位服务。
• 4) 测试定位、照相机服务时，需要采用真机进行测试。
时间测试
• 客户端可以自行设置手机的时区、时间，因此需要校验该设置
对app的影响。
• –中国为东8区，所以当手机设置的时间非东8区时，查看需要
显示时间的地方，时间是否展示正确，应用功能是否正常。时
间一般需要根据服务器时间再转换成客户端对应的时区来展示
，这样的用户体验比较好。比如发表一篇微博在服务端记录的
是10：00，此时，华盛顿时间为22：00，客户端去浏览时，
如果设置的是华盛顿时间,则显示的发表时间即为22:00,当时间
设回东8区时间时，再查看则显示为10：00。
PUSH测试
• 1) 检查push消息是否按照指定的业务规则发送
• 2) 检查不接受推送消息时，检查用户不会再接收到push.
• 3) 如果用户设置了免打扰的时间段，检查在免打扰时间
段内，用户接收不到PUSH。
• 在非免打扰时间段，用户能正常收到push。
• 4) 当push消息是针对登录用户的时候，需要检查收到的
push与用户身份是否相符，没有错误地将其它人的消息
推送过来。一般情况下，只对手机上最后一个登录用户进
行消息推送。
• 5) 测试push时，需要采用真机进行测试。
非功能测试
性能测试
• 响应能力测试：测试App中的各类操作是否满足用户响应时间要求。
– App安装、卸载的响应时间
– App各类功能性操作的影响时间
• 压力测试：反复/长期操作下、系统资源是否占用异常。
– App反复进行安装卸载，查看系统资源是否正常
– 其他功能反复进行操作，查看系统资源是否正常
• 性能评估：评估典型用户应用场景下，系统资源的使用情况。
• Benchmark测试（基线测试）：与竞争产品的Benchmarking, 产品
演变对比测试等。
安全性
• 软件测试的依据：需求规则说明书
• 软件安全实现依据：业务需求文档和系统设计文档
• 程序编码安全设计
– 权限控制算法（Private类）
– 数据库视图的引用
– 密钥和加密算法
• 技术方案安全设计
– 验证码
– 多重验证（登录与支付分离、多次密码输入）
– 超时原理（Session、Cookie超时）
– 密码安全（密码键盘 ，简单提示，多重加密）
– *安全证书（CFCA证书等）
– 关键信息屏蔽（银行卡号和证件号屏蔽）
– 后台日志管理
软件权限的安全测试
• 1）扣费风险：包括发送短信、拨打电话、连接网络等
• 2）隐私泄露风险：包括访问手机信息、访问联系人信息等
• 3）对App的输入有效性校验、认证、授权、敏感数据存储、数据加
密等方面进行检测
• 4）限制/允许使用手机功能接人互联网
• 5）限制/允许使用手机发送接受信息功能
• 6）限制/允许应用程序来注册自动启动应用程序
• 7）限制或使用本地连接
• 8）限制/允许使用手机拍照或录音
• 9）限制/允许使用手机读取用户数据
• 10) 限制/允许使用手机写人用户数据
• 11) 检测App的用户授权级别、数据泄漏、非法授权访问等
安装与卸载的安全性测试
• 1）应用程序应能正确安装到设备驱动程序上
• 2）能够在安装设备驱动程序上找到应用程序的相应图标
• 3）是否包含数字签名信息
• 4）JAD文件和JAR包中包含的所有托管属性及其值必需是正确的
• 5）JAD文件显示的资料内容与应用程序显示的资料内容应一致
• 6）安装路径应能指定
• 7）没有用户的允许, 应用程序不能预先设定自动启动
• 8）卸载是否安全, 其安装进去的文件是否全部卸载
• 9）卸载用户使用过程中产生的文件是否有提示
• 10）其修改的配置信息是否复原
• 11）卸载是否影响其他软件的功能
• 12）卸载应该移除所有的文件
数据安全性的安全性测试
• 1）当将密码或其他的敏感数据输人到应用程序时, 其不会被储存在设备中,
同时密码也不会被解码
• 2）输人的密码将不以明文形式进行显示
• 3）密码, 信用卡明细, 或其他的敏感数据将不被储存在它们预输人的位置上
• 4）不同的应用程序的个人身份证或密码长度必需至少在4一8 个数字长度之
间
• 5）当应用程序处理信用卡明细, 或其他的敏感数据时, 不以明文形式将数据
写到其它单独的文件或者临时文件中。以防止应用程序异常终止而又没有侧
除它的临时文件, 文件可能遭受人侵者的袭击, 然后读取这些数据信息。
• 6）当将敏感数据输人到应用程序时, 其不会被储存在设备中
• 7）备份应该加密, 恢复数据应考虑恢复过程的异常ٯ 通讯中断等, 数据恢复
后再使用前应该经过校验
• 8）应用程序应考虑系统或者虚拟机器产生的用户提示信息或安全替告
• 9）应用程序不能忽略系统或者虚拟机器产生的用户提示信息或安全警告, 更
不能在安全警告显示前,，利用显示误导信息欺骗用户，应用程序不应该模
拟进行安全警告误导用户
• 10）在数据删除之前，应用程序应当通知用户或者应用程序提供一个“取
消”命令的操作
• 11）“ 取消” 命令操作能够按照设计要求实现其功能
• 12）应用程序应当能够处理当不允许应用软件连接到个人信息管理的情况
• 13）当进行读或写用户信息操作时, 应用程序将会向用户发送一个操作错误
的提示信息
• 14）在没有用户明确许可的前提下不损坏侧除个人信息管理应用程序中的
任何内容Μ
• 15）应用程序读和写数据正确。
• 16）应用程序应当有异常保护。
• 17）如果数据库中重要的数据正要被重写, 应及时告知用户
• 18）能合理地处理出现的错误
• 19）意外情况下应提示用户
安装测试
• 1.软件安装后的是否能够正常运行，安装后的文件夹及文件是否写到
了指定的目录里。 （结果检查）
• 2.软件安装各个选项的组合是否正确 （操作）
• 3.安装过程中进行取消和意外情况处理（死机、重启、断电等）
• 4.安装后没有生成多余的目录和文件
• 5.安装路径能指定：手机、SD卡
• 6.卸载、升级、重复安装
兼容性测试
兼容性测试—分辨率
需注意：
• 1.不同公司出的系统：MIUI、Flyme等
• 2.现在比较流行做第三方Launcher，需考虑不同公司出的
Launcher兼容性
• 3.与杀毒软件的兼容
• 4.注意最新系统与以前版本的区别
测试时可以考虑云测
如何做兼容测试
• 1.多选择手机排行榜、机型、分辨率、系统来进行综合考虑
• 2.尽可能多的在不同的机器上测试
– 三星华为魅族小米四大厂商的机器肯定是要过到的，用户量比较大
• 3.测试在真机下进行，挑选大功能类用例并执行
兼容性设备选择：市场主流手机设备
兼容性测试自动化
• 1.谷歌是如何做兼容性测试自动化的？
– 工具：Android Compatibility Test Suite（简称Android CTS
）
– 缺点：局限于官方出的系统
• 2.Emulator（Android-sdk自带：AVD Manager）
– 缺点：比较理想环境，测试结果仅供参考，价值不大
• 3.云测平台：testin
– 优点：测试机型很多，可以给出很详细测试报告
– 缺点：测试结果仅供参考，意义不大
• 总结：工具测试只能起到一定辅助作用，无法解决真实用
户场景。
异常测试
• 服务器异常时稳定性
• 外部事件影响（电话，短信等）
• 内存是否有溢出或者泄漏
• 多线程问题
• 是否存在闪退
• 不放SIM卡、不联网
• 放置不同参数和seed值
• 附：Monkey测试可以测试出80%的崩溃。
专项测试
弱网测试
• 无网络测试，需要在页面作请求前关闭移动设备网络，观
察程序是否作友好提示。
• 弱网络测试要复杂得多，存在以下三种类型：
– 1.页面等待请求数据，数据返回后，页面呈现是否正常；
– 2.页面在发出请求后，离开该页面，数据返回后，程序是否正常处
理，是否会发生crash
– 3.页面等待请求数据，造成超时，页面是否作友好提示
网络超时测试
网络超时可通过以下方式来实现，根据实际需要来选择：
• 1.绑定未知服务器，构成网络超时，适用所有类型
• 2.对某类域名作host绑定，适用于越狱机器
• 3.绑定代理服务器，延时某个请求的时间
• 4.修改程序代码，改变某个请求的链接
网络切换测试
• 实际应用场景中，还需要考虑网络之间的切换，具体切换类型如下：
操作类型测试
• 操作类型测试，应根据自身app的应用场景来进行，比如对于有摄像头的
app，应根据使用场景来决定扫描、拍摄角度等；对于支持横竖屏的场景，
要考虑横竖切换的情况。下表给出了操作类型的测试要点：
其他手势操作测试
• 手机开锁屏对运行中的App的影响
• 切换网络对运行中的App的影响
• 运行中的App前后台切换的影响
• 多个运行中的App的切换
• App运行时关机
• App运行时重启系统
• App运行时充电
• App运行时kill掉进程再打开
交叉事件测试
交叉测试又叫事件或冲突测试，是指一个功能正在执行过程
中，同时另外一个事件或操作对该过程进行干扰的测试。
如：App在前/后台运行状态时与来电、文件下载、音乐收听等关键运用
的交互情况测试等。交叉事件测试非常重要，能发现很多应用中潜在的
性能问题。
测试要点：
1、多个App同时运行是否影响正常功能
2、App运行时前/后台切换是否影响正常功能
3、App运行时拨打/接听电话
4、App运行时发送/接收信息
5、App运行时发送/收取邮件
6、App运行时切换网络（2G、3G、4G、WIFI）
7、App运行时浏览网络
8、App运行时使用蓝牙传送/接收数据
9、App运行时使用相机、计算器等手机自带设备
第三方推送测试
• APP消息推送指的是APP开发者通过第三方工具将自己想要推的消息
推送给用户，让用户被动的接收。
PUSH消息推送原理
更新测试
• 当客户端有新版本时，有更新提示。
• 当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在
下次启动app时，仍能出现更新提示。
• 当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出客户端
。下次启动app时，仍出现强制升级提示。
• 当客户端有新版本时，在本地不删除客户端的情况下，直接更新检查是否能
正常更新。
• 当客户端有新版本时，在本地不删除客户端的情况下，检查更新后的客户端
功能是否是新版本。
• 更新完成之后，用户信息是否被清除了。
* 用户体验测试
以主观的普通消费者的角度去感知产品或服务的舒适、有用、易用、友好亲切程
度。通过不同个体、独立空间和非经验的统计复用方式去有效评价产品的体验特性
提出修改意见提升产品的潜在客户满意度。
接口测试
服务端一般会提供JSON格式的数据给客户端，所以我们在服务端需
要进行接口测试，确保服务端提供的接口并转换的JSON内容正确，对分
支、异常流有相应的返回值。此块测试可以采用itest框架进行测试。最
方便的是采用httpclient进行接口测试。
进行服务端测试时，需要开发提供一份接口文档
(JavaScript Object Notation) 是一种轻量 级的数据交换格
Itest测试框架是 TaoBao测试部门开发的 一套单元测试框架
HttpClient 是 Apache Jakarta Common 下的子项目，可以用来 提供高效的、最新的、功能丰富的 支持 HTTP 协议的客户端编程工 具包，并且它支持 HTTP 协议最 新的版本和建议。
客户端数据库测试.
• 1）一般的增、删、改、查测试。
• 2） 当表不存在时是否能自动创建，当数据库表被删除后能否再自建，数据是否还能自动从
服务端中获取回来并保存。
• 3） 在业务需要从服务端取回数据保存到客户端的时候，客户端能否将数据保存到本地。
• 4） 当业务需要从客户端取数据时，检查客户端数据存在时，app数据是否能自动从客户端
数据中取出，还是仍然会从服务器端获取？检查客户端数据不存在时，app数据能否自动从
服务器端获取到并保存到客户端
• 5） 当业务对数据进行了修改、删除后，客户端和服务端是否会有相应的更新
五、APP用例编写
APP测试例编写原则
• 熟悉需求,设计,了解业务
• 测试例命名规则清晰,明了.
• 模块划分,测试例编写具有较强的通用性测试例
• 有明确的测试目的,测试前提条件，优先级别,预期结果
• 好的测试例的要求能够尽量的覆盖典型的，常用的，异常的场景
– 尽量避免重复测试
– 测试例并非越多越好，测试例的数量应该是，尽可能的发现问题
与尽可能的覆盖功能的最小公倍数
– 测试例的编写与测试本身一样，需要不断完善
APP测试例编写要求
• 1. 准确:
按所设计的去测试.对需求及设计理解准确,理解软件及功能特点,积极设想软件
如何才能失败,做到尽可能发现错误
• 2.不冗余:
好的测试例子没有不必要的步骤,每一个测试都应该有不同的用途, 不会太简单
，也不会太复杂。通常每个测试例应独立执行。多个测试例组合，有可能屏
蔽错误。最大操作步骤最好控制在10-15步之间,每个测试步骤应该有一个清
晰的输入或者测试任务,不排除单个测试例子有多个逻辑输入,需要逐一列举
输出结果.
• 3.清晰:
描述清晰,步骤条理清晰,测试层次清晰(由简而繁,从基本功能测试到破坏性测
试).
• 4.可复用:
无论何时何人测试都能得到同样的结论,方便移植。
• 5.可追溯性:
针对特定的需求测试.
• 6.适 当:
测试例应该适合特定的测试环境 以及符合整个团队的测试水平
• 7.可维护性:
好的测试用例应该是可维护的,维护包括添加,删除,更改,特别是对应
需求及功能等变更的维护.象代码一样,不需要维护的测试例是不存在
的,在变更过程中未做维护的测试例将失去它应有价值,甚至带来危害。
测试用例的常见问题
• 单个测试例太长
• 不完善,错误,或者杂乱无端的操作步骤
• 关键步骤遗漏
• 命名域改变或者不再存在
• 描述不清,测试员或者测试系统不清楚实际要测试的步骤及内容
• 不清楚什么样的结果是通过和出错
• 不方便维护(添加,删除,更改等)