app测试用例设计

各个页面的样式风格是否统一；
各个页面的大小是否一致；同样的LOGO图片在各个页面中显示是否大小一致；页面及图片是否居中显示；
各个页面的title是否正确；
栏目名称、文章内容等处的文字是否正确，有无错别字或乱码；同一级别的字体、大小、颜色是否统一；
提示、警告或错误说明应清楚易懂，用词准确，摒弃模棱两可的字眼；
按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置；避免空旷的界面上放置很大的按钮；按钮的样式风格要统一；按钮之间的间距要一致；
页面颜色是否统一；前景与背景色搭配合理协调，反差不宜太大，最好少用深色或刺目的颜色；
导航处是否按相应的栏目级别显示；导航文字是否在同一行显示；
文字颜色与页面配色协调，不使用与背景色相近的颜色；
首页、各栏目一级页面之间互链，各栏目一级和二级页面之间互链；
导航的文字要简明扼要，字数限制在一行以内；
如有多个页面展现同一数据源时，应保证其一致性；
界面内容更新后系统应提供刷新功能；
在多个业务功能组成的一个业务流程中，如果各个功能之间的执行顺序有一定的制约条件，应通过界面提示用户；
用户提示信息应具有一定的指导性，在应用程序正在进行关键业务的处理时，应考虑在前台界面提示用户应用程序正在进行的处理，以及相应的处理过程，在处理结束后再提示用户处理完毕；
在某些数据输入界面，如果要求输入的数据符合某项规则，应在输入界面提供相应的规则描述；当输入数据不符合规则时应提示用户是否继续；
界面测试不光要考虑合理的键盘输入，还应考虑是否可以通过拷贝粘贴输入；
页面确保数据精度显示的统一：热度、数量、时间等；
对所有可能产生的提示信息界面内容和位置进行验证，确保所有的提示信息界面应居中；
存在虚拟键盘时、虚拟键盘隐藏时不影响页面展示；

2、APP界面测试之测试点（页面文字、按钮等测试）

1、文字

内容一致性：

文字的一致性，例如各种宣传文字、注册的协议条款、版权信息等；
各处相同含义文字的一致性，例如标题栏文字、页面主题文字、弹出窗口文字、菜单名称、功能键文字等；

样式一致性：

各类文字字体、字号、样式、颜色、文字间距、按钮的文字间距、对齐方式一致性；
链接文字，同一类，菜单、小标题、页角文字链接，在点击时颜色变化要相同；
对齐方式，页面上文字的对齐，例如表单、菜单列、下拉列表中文字的对齐方式（左、右、居中等要统一）；

语言习惯：

中文：文字简单，含义明确，无歧异，无重复，无别字，正确运用标点符号；
英文；

2、按钮

文字按钮、图片按钮；

按钮的样式整体要统一；
采用的图片表述相同功能，要采用单一图标；
按钮点击效果要统一；如：点击有置灰效果等；
按钮触碰区域：大小；
点击响应时长；

3、文本框

录入长度限制，根据数据库的设计，页面直接限定录入长度（特殊处屏蔽复制、粘贴 (一般是需要重复确认输入的地方) ）；
文本框自身的长度限制，主要考虑页面样式；
支持的数据类型：文本、颜文字、表情、字母、特殊字符、空格、敏感词等；

4、选择框

默认情况要统一，已选择，还是未选；
单选按钮不能同时选中，只能选中一个；
逐一执行每个单选按钮的功能，如分别选择了“男”、“女”后，保存到数据库的数据应该相应的分别为“男”、“女”；
多选框（仅选择一项、多项、全选）；

5、提示信息

操作类提示准确、无歧义：如：收藏成功；
异常提示语：展示时长、是否醒目、提示语是否准确；
静态提示信息，在录入框中，应有录入信息的相应要求的提示文字，达到方便操作的目的；
必输项提示信息，必输项提示信息采用统一的标志；
取消类提示语是否有：提示、警告、或错误说明应该清楚、明了、恰当；

6、导航测试

切换导航tab测试、切换不会卡顿；
与H5 tab栏应不冲突；

7、返回键

页面左上角返回键，返回上级页面；
Android 物理返回键功能；
iOS左滑返回上级页面；

8、分辨率机型

页面文字显示、样式、图片显示等要支持常见分辨率适配，在不同、分辨率下图片是否能正确显示（包括位置、大小）；

三、兼容性（操作系统、屏幕尺寸、分辨率）

1、系统兼容性

iOS系统
Android系统

2、屏幕兼容性

iOS

刘海屏
非刘海屏

Android

全面屏
非全面屏
曲面屏
折叠屏

3、分辨率兼容性

iOS
Android

4、尺寸兼容性

iOS主要机型尺寸：4寸-6.7寸
Android主要机型尺寸：5寸-6.7寸

5、不同网络兼容性

Wi-Fi切换4G/5G网络情况下功能是否正常
4G/5G网络切换Wi-Fi情况下功能是否正常
有网切换无网情况下功能是否正常
无网切换有网情况下功能是否正常

四、安全性测试

1、安装包测试

1、关于反编译

目的是为了保护公司的知识产权和安全方面的考虑等，一些程序开发人员会在源码中硬编码一些敏感信息，如密码。而且若程序内部一些设计欠佳的逻辑，也可能隐含漏洞，一旦源码泄漏，安全隐患巨大。
为了避免这些问题，除了代码审核外，通常开发的做法是对代码进行混淆，混淆后源代码通过反软件生成的源代码是很难读懂的，测试中，我们可以直接使用反编译工具（dex2jar和jd-gui工具）查看源代码，判断是否进行了代码混淆，包括显而易见的敏感信息。

2、关于签名

这点IOS可以不用考虑，因为APP stroe都会校验。但Android没有此类权威检查，我们要在发布前校验一下签名使用的key是否正确，以防被恶意第三方应用覆盖安装等。可使用下列命令检查：
jarsigner -verify -verbose -certs apk包路径
若结果为“jar 已验证”，说明签名校验成功。

3、完整性校验

为确保安装包不会在测试完成到最终交付过程中因为知足者趾问题发生文件损坏，需要对安装包进行完整性校验，通常做法是检查文件的md5值，而且一般可以通过自动化做校验。

4、权限设置检查

一般用户对自己的隐私问题十分敏感，因此，我们需要对APP申请某些特定权限的必要性进行检查，如访问通讯录等。对于没有必要的权限，一般都建议开发直接支除。
Android：直接检查manifest文件来读取应用所需要的全部权限，并结合需求进行校验此权限是否为必须的。manifest文件的修改也需要关注，在增加新权限前需要进行评估。
IOS：没有类似manifest文件来查看，IOS的用户权限只有在用户使用APP到了需要使用的权限时，系统才会弹出提示框，提示用户当前APP需要访问照片、联系人列表等组件。我们可以扫描代码来查看项目工程中有哪些权限设置。通过搜索关键类名，如通讯录一般需要访问ABAddressBookRef，照片是UIImagePickerController等。如果是纯黑盒测试，则必须覆盖到所有代码路径才能保证没有遗漏，也可使用代码覆盖率测试判断是否覆盖。

2、敏感信息测试

数据库是否存储敏感信息，某些应用会把cookie类数据保存在数据库中，一旦此数据被他人获取，可能造成用户账户被盗用等严重问题，测试中在跑完一个包含数据库操作的测试用例后，我们可以直接查看数据库里的数据，观察是否有敏感信息存储在内。一般来说这些敏感信息需要用户进行注销操作后删除。如果是cookie类数据，建议设置合理的过期时间。

日志是否存在敏感信息，一般开发在写程序的过程中会加入日志帮助高度，所有可能会写入一些敏感信息，通常APP的发布版不会使用日志，但也不排除特殊情况。

配置文件是否存在敏感信息，与日志类似，我们需要检查配置文件中是否包含敏感信息。

3、软键盘劫持

如果用户安装了第三方键盘，可能存在劫持情况，对此，我们在一些特别敏感的输入地方可以做检查，例如金融类APP登录界面的用户名密码输入框等，看是否支持第三方输入法，一般建议使用应用内的软键盘。

4、账户安全

密码是否明文存储在后台数据库，在评审和测试中需要关注密码的存储。
密码传输是否加密，测试中我们需要查看密码是否被明文传输，如果是HTTP接口，我们可以使用FIddler等工具直接查看。
账户锁定策略。对于用户输入错误密码次数过多的情况，是否会将账户临时锁定，避免被暴力破解，
同时会话情况。一些应用对同时会话会有通知功能，这样至少可以让用户知识他的账户可能已经被泄漏了。在一定程度上能免提升用户体验。
注销机制。在客户端注销后，我们需要验证任何的来自该用户的，需要身份验证的接口调用都不能成功。

5、数据通信安全

关键数据是否散列或加密。密码在传输中必须是加密的，其他敏感信息传输前也需要进行散列或者加加密，以免被中间节点获取并恶意利用。
关键连接是否使用安全通信，例如HTTPS。在获知接口设计后我们需要评估是否其中内容包含敏感信息，如果未使用安全通信，需要知会开发修改。
是否对数字证书合法性进行验证。即便使用了安全通信，例如HTTPS，我们也需要在客户端代码中对服务端证书进行合法性校验。测试中可以使用Fiddler工具模拟中间人攻击方法。如果客户端对于Fiddler证书没有校验而能正常调用，则存在安全隐患。
是否校验数据合法性。在一些情况下，我们需要有方法来确保服务端下发的明文数据不被篡改。通常开发侧的实现方式是对数据进行数字签名并在客户端进行校验。我们可以模拟后台返回进行相关的测试工作。此外，对于其他一些客户端未进行数据校验的接口，我们也需要有意识地思考如果不进行校验是否会产生问题，并通过模拟后台返回验证。

6、组件安全测试

这里主要是指Android平台各个组件是否能被外部应用恶意调用从而带来一些安全问题。包括Activity、Service、ContentProvider、Broadcast等等。采用的测试方法是通过使用drozer工具结合查看代码的方式，具体使用方法可查看官方文档。

7、服务端接口测试

主要关注服务端接口是否存在以下问题

SQL注入
XSS跨站脚本攻击
CSRF跨站请求伪造
越权访问

除了上述服务端问题外，我们还需要结合实际的需求，设计和代码，分析是否需求或设计本身就会带来安全问题。

举个例子：如一个购物的应用，下单地的流程包含两个接口，接口A返回订单详情，其中包括订单号码和金额总价。调用接口A后用户在客户端看到一个订单页面。用户点击提交后调用接口B，客户端传给接口B的参数为接口A返回的订单号码和金额总价，接口B的后台根据传给接口B的金额总价从用户账户中扣款，扣款成功后即根据订单号码发货。

这一设计有什么问题呢？那就是接口B完全信任了客户端传入的金额总价而未做校验。恶意用户可以直接调用接口B，传入伪造的金额和真实订单号，这样就能以便宜的价格购物。

8、附录

1、软件权限

扣费风险：包括短信、拨打电话、连接网络等。
隐私泄露风险：包括访问手机信息、访问联系人信息等。
对App的输入有效性校验、认证、授权、数据加密等方面进行检测
限制/允许使用手机功能接入互联网
限制/允许使用手机发送接收信息功能
限制或使用本地连接
限制/允许使用手机拍照或录音
限制/允许使用手机读取用户数据
限制/允许使用手机写入用户数据
限制/允许应用程序来注册自动启动应用程序

2、数据安全性

当将密码或其它的敏感数据输入到应用程序时，其不会被存储在设备中，同时密码也不会被解码。
输入的密码将不以明文形式进行显示。
密码、信用卡明细或其他的敏感数据将不被存储在它们预输入的位置上。
不同的应用程序的个人身份证或密码长度必须至少在4-8个数字长度之间。
当应用程序处理信用卡明细或其它的敏感数据时，不以明文形式将数据写到其他单独的文件或者临时文件中。以防止应用程序异常终止而又没有删除它的临时文件，文件可能遭受入侵者的袭击，然后读取这些数据信息。
党建敏感数据输入到应用程序时，其不会被存储在设备中。
应用程序应考虑或者虚拟机器产生的用户提示信息或安全警告
应用程序不能忽略系统或者虚拟机器产生的用户提示信息或安全警告，更不能在安全警告显示前，利用显示误导信息欺骗用户，应用程序不应该模拟进行安全警告误导用户。
在数据删除之前，应用程序应当通知用户或者应用程序提供一个“取消”命令的操作。
应用程序应当能够处理当不允许应用软件连接到个人信息管理的情况。
当进行读或写用户信息操作时，应用程序将会向用户发送一个操作错误的提示信息。
在没有用户明确许可的前提下不损坏删除个人信息管理应用程序中的任何内容。
如果数据库中重要的数据正要被重写，应及时告知用户。
能合理的处理出现的错误。
意外情况下应提示用户。

3、通讯安全性

在运行软件过程中，如果有来电、SMS、蓝牙等通讯或充电时，是否能暂停程序，优先处理通信，并在处理完毕后能正常恢复软件，继续其原来的功能。
当创立连接时，应用程序能够处理因为网络连接中断，进而告诉用户连接中断的情况。
应能处理通讯延时或中断。
应用程序将保持工作到通讯超时，进而给用户一个错误信息指示有链接错误。
应能处理网络异常和及时将异常情况通报用户。
应用程序关闭网络连接不再使用时应及时关闭，断开。

4、人机接口安全测试

返回菜单应总保持可用。
命令有优先权顺序。
声音的设置不影响使用程序的功能。
应用程序必须能够处理不可预知的用户操作，例如错误的操作和同时按下多个键。

五、中断测试

来电中断：呼叫挂断，被呼叫挂断，通话挂断，通话被挂断
短信中断：接收短信、查看短信
蓝牙：使用APP的时候连接、断开蓝牙
闹钟：操作APP的时候，突然闹钟来了，测试APP的各项操作是否正常
插拔数据线：使用APP的时候进行数据线插拔，测试APP的功能
手机锁定：操作APP的时候突然锁屏，解锁成功后再次进入APP的情况
手机断电：操作的时候突然断电，测试APP的情况
系统重启：操作的APP时重启手机，启动后观察APP的是否运行正常
电源不足：手机电量不足的时候，进行操作APP，观察APP的运行情况
应用切换：开启很多应用时，操作APP是否出现异常。在使用被测APP进行某些业务流程，进行到中间的某一步，切换到常见的APP如微信、支付宝、QQ、王者荣耀等操作一下，再切换回去，看看APP是否正常，之前数据是否丢失。
实体键中断：主要包括back、home、munu ，其中home键有两种情况不能忽略：home出去马上唤醒时应用是否正常；home出去，开多个应用比如5个以上，再唤醒时应用是否正常。

六、网络测试

1、正常网络

正常网络下各个模块的功能是否正常可用
正常网络下页面元素/数据显示是否正常

2、无网络

无网络时是否会导致闪退、卡死等异常情况
无网络时各个页面是否显示完整美观、未剧新的页面是否做相应提示和处理
无网络时数据完整性、session一致性
无网络时的提示信息是否友好
无网络时各个页面之间切换是否正常

3、弱网络

1、弱网功能测试

2G、3G、4G、5G、WIFI、高延迟、高丢包下的基本功能点是否正常
升级是否会发生Crash（程序崩渍或闪退）、ANR（程序未响应）等严重错误

2、弱网用户体验

页面图片、进度条加载，版式结构是否混乱，加载异常提示（要与无网络状态区分）

3、弱网Ul测试

页面元素完整性、数据一致性

4、弱网下的响应时间

2G、3G下的热启动、冷启动、页面切换、前后台切换等重要换作的响应时间

（热启动：app没有被杀死，仍在后台运行，然后我们再次去打开这个app）
（冷启动：app已被杀死，然后我们重新去打开这个app）

2、5、10原则

用户能够忍受的最佳响应时间是2秒以内；

- 超过5秒无响应的话，一般性子比较急躁的用户很可能就会直接退出页面了；
- 如果超过10秒无响应，很多人都会选择杀掉APP；

4、强网络形态场景测试

1、制式切换

WIFI->3G/4G/5G时，是否会有页面的crash以及显示的错乱、session是否一致、请求堆积处理
WIFI->无网络时，是否会有页面的crash以及显示的错乱、session是否一致、请求堆积处理
3G/4G/5G->WIFI时，是否会有页面的crash以及显示的错乱、session是否一致、请求堆积处理
3G/4G/5G->无网络时，是否会有页面的crash以及显示的错乱、session是否一致、请求堆积处理

2、大流量动作

应用升级：即有些场景是必须连着WIFI才能做的，如升级提示等
下载文件等大流量动作

5、异常测试

①. 异常提示：弱网和无网络下的异常信息要区分

②. 容错机制：常考虑弱网下带来的不稳定，如等待超时了如何处理，是否合理

③. 超时处理：多长时间内未接收到反铁则判定为超时

④. 重连机制：客户端/服务端是否能重发请求/接受重连？配合超时机制，多久未接收到反馈才发起重连？失败几次则不允许主连等？

⑤. 请求堆积

从无网络->有网络时，是否有请求堆积？
弱网络时，是否有请求堆积？

七、性能测试

1、客户端性能测试常见指标：

内存
CPU
流量
电量
启动速度
滑动速度、界面切换速度
与服务器交互的网络速度

2、预期标准指定原则

分析竞争对手的产品，所有指标要强于竞品
产品经理给出的预期性能指标数据
符合业内行业标准

3、测试方法及工具

内存：使用adb shell脚本进行测试，查看Log数据。adb shell dump meminfo
CPU：使用adb shell脚本进行测试，查看Log数据。adb shell top
注意：程序持续运行及操作过程中，内存不能一直增加，不然系统会自动kill掉该进程。
流量监控：可以借用网易的开源工具：Emmagee
电量监控：和竞品做对比测试，同一机型的测试机在不同时间，不同网络条件，不同功能使用的情况下分别测试电量使用情况。
启动速度和滑动、界面切换速度：编写测试代码（Android Instrumentation），打桩到源码中，运行后通过log数据进行分析。
其他测试工具：腾讯开发的工具：GT随身调。下载地址：http://gt.qq.com/

不可置否，在对APP的整个测试环节中，性能测试是一个很重要的环节，它直接影响了用户的体验，那么，对于APP的性能测试，我们到底需要关注那些点呢？

其实，我们可以想想在软件设计、部署、使用、维护中一共有哪些角色参与，然后再考虑这些角色各自关注的性能点是什么，那么作为一个软件性能测试工程师，我们就能够从中总结出，对于APP的性能测试主要应该关注哪些比较重要的点。

4、从用户角度出发（操作的响应时间）

开发软件的目的是为了让用户使用，我们先站在用户的角度分析一下，用户需要关注哪些性能。

对于用户来说，当点击一个按钮、链接或发出一条指令开始，到系统把结果已用户感知的形式展现出来为止，这个过程所消耗的时间是用户对这个软件性能的直观印象。也就是我们所说的响应时间，当响应时间较小时，用户体验是很好的，当然用户体验的响应时间包括个人主观因素和客观响应时间，在设计软件时，我们就需要考虑到如何更好地结合这两部分达到用户最佳的体验。如：用户在大数据量查询时，我们可以将先提取出来的数据展示给用户，在用户看的过程中继续进行数据检索，这时用户并不知道我们后台在做什么。

简单地说，用户最关注的其实就是其操作的响应时间。

5、站在管理员的角度考虑需要关注的性能点

响应时间
服务器资源使况是否合理
应用服务器和数据库资源使用是否合理
系统能否实现扩展
系统最多支持多少用户访问、系统最大业务处理量是多少
系统性能可能存在的瓶颈在哪里
更换那些设备可以提高性能
系统能否支持7×24小时的业务访问

6、站在开发（设计）人员角度去考虑

架构设计是否合理
数据库设计是否合理
代码是否存在性能方面的问题
系统中是否有不合理的内存使用方式
系统中是否存在不合理的线程同步方式
系统中是否存在不合理的资源竞争

7、站在测试工程师角度考虑

那么从用户、管理员、开发者的角度去总结了其关注的性能指标之后，对于测试工程师来说，他们在做性能测试的时候，主要应该关注的测试指标应该是：

连接超时：这个是App关闭的首要问题，而在移动应用中网络错误数据比例报错中最高的就是连接超时错误。想象一下当花重金好不容易把你的App推广到用户手机上，而在用户初次尝试时发生连接超时无法正常使用，多数用户会选择再也不会打开应用第二次。
崩溃：这个已无需多言。APP的崩溃，就是用户的崩溃。当用户使用你的App出现闪退或崩溃时，他们很有可能跑去App Store赠送你一个“一星”差评。
系统交互（电话短信干扰，低电量提醒，push提醒，usb数据线插拔提醒，充电提醒等）在APP使用过程中，可能会遇到各种中断场景，那么一旦发生这些场景，APP就卡死或者闪退，想必也没有多少用户愿意持续使用你的APP。
弱网下的运行情况：电梯里、地铁上，网络信号差时，APP页面的菊花转不停，界面卡死，同时错误提示一堆，这样的情况怎能不让用户抓狂。
CPU使用问题：CPU频率设置过高时会导致过热,过热导致耗电更严重,CPU频率设置过低导致手机滞后,应用处理缓慢同样会导致耗电。更多时候，用户解决CPU超载问题只能关闭甚至卸载App，App就被Kill了!