转自：//www.greatytc.com/p/a2ee554869ef

1. 权限测试**

1)软件权限　　-扣费风险：包括发送短信、拨打电话、连接网络等　　-隐私泄露风险：包括访问手机信息、访问联系人信息等　　-新增风险项

2)开发者官方权限列表信息比对分析

2.下载、安装、运行、卸载测试**从市场下载app，验证能否验证App是否能 正常下载、正确安装、运行、卸载，以及操作过程和操作前后对系统资源的使用情况，主要包括：

1).检测软件是否能正确安装、运行、卸载；

2).安装、卸载、更新错误报告；

3).其他辅助信息：

-位置和文件夹是否合理；

-组件是否正确注册或删除；

-评估操作前后，CPU、Memory（内存占用）、Storage（磁盘占用）等系统资源的使用情况。

3.UI测试

测试用户界面(如菜单、对话框、窗口和其它可视控件)布局、风格是否满足客户要求，文字是否正确，页面是否美观，文字，图片组合是否完美，操作是否友好等。

UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

4.功能测试：根据软件说明或用户需求验证App的各个功能实现，采用如下方法实现并评估功能测试过程：

1)采用时间、地点、对象、行为和背景五元素或业务分析等方法分析、提炼App的用户使用场景，对比说明或需求，整理出内在、外在及非功能直接相关的需求，构建测试点，并明确测试标准（若用户需求中无明确标准遵循，则需要参考行业或相关国际标准或规则）。

2)根据被测功能点的特性列举出相应类型的测试用例对其进行覆盖，如：涉及输入的地方需要考虑等价、边界、负面、异常或非法、场景回滚、关联测试等测试类型对其进行覆盖。

3)在测试实现的各个阶段跟踪测试实现与需求输入的覆盖情况，及时修正业务或需求理解错误。

5.性能测试评估App的时间和空间特性

1)极限测试：在各种边界压力情况下（如电池、存储、网速等），验证App是否能正确响应。

2)响应能力测试：测试App中的各类操作是否满足用户响应时间要求

3)压力测试：反复/长期操作下，系统资源是否占用异常；

4)性能评估：评估典型用户应用场景下，系统资源的使用情况。

5).基准性能测试：主要通过压服务器端接口及客户端在不同网络环境下响应速度。

6).大数量的测试：主要在特定环境下，客户端一次性更新大量的数据及人员列表时，客户端能否正常处理，分为三种情况：

客户端第一次使用，第一次就更新大量数据及人员列表。

客户端在平时更新中，更新大量的数据

客户端已经在手机本地下载很多数据后，再次更新大量

6.异常测试： 　针对智能终端应用的服务等级划分方式及实时特性所提出的测试方法，如：App在前/后台运行状态时与来电、文件下载、音乐收听等关键运用的交互情况测试等。

1).交互异常性测试：客户端作为手机特性测试，包括被打扰的情况；如来电、来短信、低电量测试等，

还要注意手机端硬件上，如：待机，插拔数据线、耳机等操作不会影响客户端。

2).异常性测试：主要包含了断网、断电、服务器异常等情况下，客户端能否正常处理，保证数据正确性。

7.兼容测试主要测试内部和外部兼容性

1).与本地及主流App是否兼容；

2).检验在各种网络连接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等)，App的数据和运用是否正确；

3).与各种设备是否兼容（若有跨系统支持则需要检验是否在各系统下，各种行为是否一致）。

8.安全测试 ,安全测试显得尤为重要，粗心、不谨慎的数据存储或传输方式使得非法、恶意目的有可乘之机。

智能终端安全涉及各信息交互、存储接点，借鉴于网络传输和相关安全测试经验，

App安全测试大概划分为以下几类：

1)从数据的本地存储到数据的传输、处理以及远程访问等各个环节，基于相应的安全标准/行业标准评估App的安全特性；

2)借鉴在Web App和网络安全测试的一些成功经验在智能终端App测试中进行裁减或适配；

3)检测App的用户授权级别，数据泄漏，非法授权访问等；

4)对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测,以期发现潜在的安全问题；

5)基于各种通信协议或相应的行业安全标准检视App是否满足相应的要求

9.网络测试, 相关的App，有三个非常重要的最佳实践。

1)、 2G、3G、wifi都要覆盖

这三者之间不仅仅只是网络速度的差别，它们代表了三种不同的网络环境。另外你可能没有想到一种特殊的情况可以用它们来测出问题：开发环境和生产环境。

一个有经验的开发团队会在内网搭建测试环境来进行开发时的测试，在上线时将配置切换到线上的生产环境。这个切换应该是在发布流程中需要Check的一个环节。但是，我们有可能遗漏。

所以这个测试用例可以用来防止这种情况的出现，在wifi下内网环境可以work fine，但是2G和3G就不行，只有真实的环境下2G和3G才能正常工作（想想2G和3G是否可以正常访问http://192.168.1.xxx这样的地址就可以了）。

a.外网测试主要现实模拟客户使用网络环境，检验客户单程序在实际网若环境中使用情况及进行业务操作。

b.外网测试主要覆盖到wifi\2G\3G\4G ,.net\wap 、 电信\移动\联通、所有可能的组合进行测试。

原则：

1.尽可能全面覆盖用户的使用场景，测试用例中需要包含不同网络排列组合的各种可能。

2.还有模拟信号被屏蔽时候。客户端的影响 等。还有做外包场景测试，在高山、丘陵、火车上等特殊环境下进行全面测试

2)、HTTP、HTTPS都要覆盖

许多App和后台服务都是通过HTTP来交互的，正常情况下都一切正常。为什么需要测试HTTPS环境？在一些免费上网的环境中，例如在麦当劳、星巴 克里，它们的网络环境都要输入用户名和密码，通过SSL认证来访问网络。如果你使用HTTP Client的library对这种异常没有做捕获处理，那么你的App必定会崩溃掉。

3)、进行网络异常、服务器宕机或出现404、502等情况下的测试

后台服务的稳定性是你有时很难去控制的，尤其是牵涉到DNS、空间服务商的情况下。国内某著名DNS服务商经常出现大规模域名解析故障，碰到这种情 况，你对后台API的请求很可能就会出现404错误。而你和API交互的数据应该是某种固定格式例如JSON和XML，这样你的数据解析必然会出现错误， 抛出异常。如果你对异常没有进行正确的处理可能会导致程序不能正常工作。

以下用伪代码解释一下逻辑：

try {

if(request() == success) {

callSuccess();

} else {

callFail();

}

hidePopup();

} catch(e) {

// do nothing, just wait….now popup window will show forever on the screen!!!

// if it is a iOS app, the popup window will lock the screen

}

10.接口性测试：

1.client端和service端的交互

2.client端的数据更新和service端的数据是否一致

3.client端更新时断开了。

4.client端更新时service端挂了。

11.业务逻辑测试：

1.业务逻辑测试：主要测试客户端业务能否正常完成。

2.功能点测试：主要测试客户端功能点是否正常使用

3.关联性测试：主要测试客户端与pc端的交互，客户端处理完后，pc端与客户端数据一致

12.移动App崩溃的测试场景

1 验证在有不同的屏幕分辨率， 操作系统 和运营商的多个设备上的App行为。

2 用新发布的操作系统版本验证App的行为。

3 验证在如隧道，电梯等网络质量突然改变的环境中的App行为。

4 通过手动网络从蜂窝更改到Wi-Fi ，或反过来，验证App行为。

5 验证在没有网络的环境中的App行为。

6 验证来电/短信和设备特定的警报（如警报和通知）时的App行为。

7 通过改变设备的方向，以不同的视图模式，验证App行为。

8 验证设备内存不足时的App行为。

9 通过用测试工具施加载荷验证App行为。

10 用不同的支持语言验证App行为。

13.输入项测试

1.植入的单引号。大多数基于SQL的数据库系统在用户存储包含一个单引号的信息时会出现问题，例如John's car。每一个可以接受文字数字型数据条目的屏幕都要试试输入包含一个或多个单引号的文本。

，其实不只是单引号，基本上测试人员应该测试所有的特殊字符和空/空格（单纯的空格和文本前后的空格）。单引号，逗号，/，<， >（对于web的应用程序）都是很容易引发错误的。

2.必需输入的数据条目。功能说明书上应该清楚的指出屏幕上必须输入数据条目的字段。测试屏幕上每一个被说明为必须输入的字段以保证它强制要求你在字段中输入数据。

对于强制输入的字段，在屏幕上最好有些标识以说明其为必须输入的字段。一般在字段前或后用红色的*号表示。测试时必须要检查有标识的字段是否和功能说明书或其他参考文档一致，错误信息提示是否正确，强制输入的字段 是否真的必须输入。

3.字段类型测试。功能说明书上应该清楚的指出要求特定数据输入要求（日期字段，数字字段，电话号码，邮编等等）的字段。测试屏幕上每一个被指出有特定类 型的字段以保证你输入了基于字段类型的符合正确格式的数据（数字型字段应该不允许字符或特殊字符，日期型的字段应该允许输入一个正确的日期等等）

其实这里还有一个字段格式和字段内容的测试。有些字段对输入的格式有要求，这些字段的格式一般在屏幕上也有相应的提示。所以在测试时需要 测试提示的格式是否合理（和功能说明书或其他参考文档相一致）以及系统是否正确识别输入的格式。有些字段对字段的内容有限制，如常见的用户名，不能包含特 殊字符，首字不能未数字等要求。所以在测试时需要测试提示的格式是否合理（和功能说明书或其他参考文档相一致）还有不符合内容要求的数据输入时系统是否正 确的处理。

4.字段长度测试。功能说明书上应该清楚的指出可以在字段中输入的字符数（例如，first name必须是50个或更少的字符）。写测试用例以保证你只可以输入特定的字符数。防止用户输入比允许范围更多的字符比因用户已输入过多的字符而给出的错 误信息更加的文雅些。

一般对于限制长度的字段，现在开发大多采用限制输入的方法（设置字段的长度）来处理。所以测试时需要测试限制的长度是否合理（和功能说明 书或其他参考文档相一致），对于没有限制长度的字段，要测试无穷输入时是否出错，有问题报bug时建议开发人员根据需要限制长度。

5.数字型的边界测试。对于数字型的字段，测试上下边界是非常重要的。例如，如果你正在计算某个账户的利息时，你永远不会输入一个负的利息数给应该赢取利 息的账户。因此，你应该尝试用负数测试。同样，如果功能说明书上要求字段在某一个特定的范围（如从10～50），你就应该尝试输入9或51，它应该给出一 个得体的信息表示失败。

边界值的测试同时，最好结合等价类以及一些特殊数字进行开展，如这里面的负数，虽然账户利息永远不会出现负数，但是如果系统中一旦输入负数，系统就崩溃，那么这样的系统对于客户来说也是非常危险的。

6.数字的约束测试。大多数数据库系统和编程语言允许数字条目被识别为整数或长整数。通常，整数的范围是从-32,767~32,767，长整数的范围从 -2,147,483,648~2,147,483,647。对于那些没有特定边界限制的数字数据条目，用这些限制测试以确保不会出现数字的溢出错误。

小数型的数字字段同样也需要格外的测试。一般对于未指出数字类型的字段，尝试输入负整数，负小数，0，正整数，正小数进行测试。

不管是哪种数据库系统，对于数字一般都有多种数字类型。所以测试人员一定要测试的全面。

7.日期边界测试。对于日期型的字段，测试上下边界是很重要的。例如，如果你正在检查一个出生日期的字段，很大可能出生日期不能早于150年前。同样，出生日期应该不是将来的某一天。

一般来说，每种数据库系统的日期都有个范围，如SQL Server最小日期是1753年1月1日，所以如果是输入型的日期字段同样也应该测试早于1753的日期。

8.日期的有效性。对于日期字段，确保不允许无效的日期是很重要的（04/31/2007是一个无效的日期）。测试用例也应该检查闰年（每个第4年和第400年是一个闰年）。

9.web会话测试。很多的web应用程序依赖浏览器的会话来追踪已登录的用户，应用程序的设置等等。应用程序的大多数屏幕不被设计为没有首次登录就可以被运行。应用程序应该确保在打开应用程序的某一页面之前会话里有一个有效的登录。

14.app 功耗、流量测试:针对app对手机电量、流量方面损耗情况的测试

1.功耗测试主要测试app使用过程中耗费电量情况的测试，主要依据一些主流app的功耗作为对照参数

2.流量测试：检测app对流量损耗问题，主要依据一些主流app的流量损耗作为对照参数