手机APP项目测试点(内容)总结
对于手机项目（应用软件），主要是进行系统测试。
而针对手机应用软件的系统测试，我们通常从如下几个角度开展测试工作：
功能模块测试
交叉事件测试
性能测试
安全测试
容量测试
兼容性测试
接口测试
易用性/用户体验测试
硬件环境测试
安装/卸载测试
升级/更新测试
1、功能模块测试：
根据软件需求说明书或者用户需求验证app的各个功能是否实现，采用如下方法实现并评估功能测试过程：
采用时间、地点、对象、行为、和背景五元素或业务分析等方法、提炼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时，需要采用真机进行测试。
2、交叉事件测试：又叫事件冲突测试
是指一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰测试。如：App在前/后台运行状态时与来电、文件ixaz、音乐收听等关键运用的交互情况测试等。
多个App同时运行是否影响正常功能。
App运行时前/后台切换是否影响正常功能。
App运行时拨打/接听电话。
App运行时发送/接收信息。
App运行时发送/收取邮件。
App运行时切换网络（2G/3G/WIFI）.
App运行浏览网页。
App运行时使用蓝牙传送/接收数据。
App运行时使用相机、计算器手机自带设备。
App运行时插拔充电器。
执行干扰的冲突事件不能导致软件应用软件异常、手机死机或者花屏等严重问题，还需要注意各交叉事件的优先级别，检验系统是否能依据各事件的优先级别依次进行处理。不能因执行优先级别高的事件而导致优先级别较低的事件吊死。另外有中英文模式切换的手机要注意中英文模式切换后的功能实现存在的问题。
3、性能测试：评估App的时间和空间特性
极限测试：
在各种边界压力情况下，如电池、存储、网速等，验证App是否能正确响应。
–内存满时安装App
–运行App时手机断电
–运行App时断掉网络
响应能力测试：
测试App中的各类操作是否满足用户响应时间要求 。
–App安装、卸载的响应时间
–App各类功能性操作的影响时间
压力测试：
反复/长期操作下、系统资源是否占用异常。
–App反复进行安装卸载，查看系统资源是否正常
–其他功能反复进行操作，查看系统资源是否正常
性能评估：
评估典型用户应用场景下，系统资源的使用情况。
Benchmark测试（基线测试）：与竞争产品的Benchmarking, 产品演变对比测试等。
特定场景测试
1.通过模拟终端低电量（例如5%电量）的状态来测试功能在该状态下的正确性
2.通过模拟终端处于特殊地理位置（例如上海）来测试功能在该状态下的正确性
3.通过模拟终端处于特定网络状态下（例如3G）来测试功能在该状态下的正确性
深度性能测试
1.获取App在典型使用场景及状态下消耗的电量流量消耗
2.获取App在典型使用场景及待机状态下消耗的流量
3.获取App在典型使用场景及待机状态下的CPU占用率
4.获取App在典型使用场景及待机状态下内存量
5.获取App冷启动和热启动耗时内容
6.获取App特定页面的内容加载耗时
7.获取App退出的耗时
8.获取App在典型使用场景下帧率
4、安全测试：
软件权限
–扣费风险：包括发送短信、拨打电话、连接网络等
–隐私泄露风险：包括访问手机信息、访问联系人信息等
–对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测
–限制/允许使用手机功能接人互联网
–限制/允许使用手机发送接受信息功能
–限制/允许应用程序来注册自动启动应用程序
–限制或使用本地连接
–限制/允许使用手机拍照或录音
–限制/允许使用手机读取用户数据
– 限制/允许使用手机写人用户数据
–检测App的用户授权级别、数据泄漏、非法授权访问等
安装与卸载安全性
–应用程序应能正确安装到设备驱动程序上
–能够在安装设备驱动程序上找到应用程序的相应图标
–是否包含数字签名信息
–JAD文件和JAR包中包含的所有托管属性及其值必需是正确的
–JAD文件显示的资料内容与应用程序显示的资料内容应一致
–安装路径应能指定
–没有用户的允许, 应用程序不能预先设定自动启动
–卸载是否安全, 其安装进去的文件是否全部卸载
–卸载用户使用过程中产生的文件是否有提示
–其修改的配置信息是否复原
–卸载是否影响其他软件的功能
–卸载应该移除所有的文件
–验证App是否能正确安装、运行、卸载，以及操作过程和操作前后对系统资源的使用情况，主要包括：
–检测软件是否能正确安装、运行、卸载；大量真机多维度测试,兼容性测试无死角
–安装、卸载、更新错误报告；包含安装、卸载、高/低版本覆盖安装
–用于检测的安全软件包括：百度手机管家、LBE、QQ手机管家、网秦、安卓优化大师
数据安全性
–当将密码或其他的敏感数据输人到应用程序时, 其不会被储存在设备中, 同时密码也不会被解码
–输人的密码将不以明文形式进行显示
–密码, 信用卡明细, 或其他的敏感数据将不被储存在它们预输人的位置上
–不同的应用程序的个人身份证或密码长度必需至少在4一8 个数字长度之间
–当应用程序处理信用卡明细, 或其他的敏感数据时, 不以明文形式将数据写到其它单独的文件或者临时文件中。以
–防止应用程序异常终止而又没有侧除它的临时文件, 文件可能遭受人侵者的袭击, 然后读取这些数据信息。
–当将敏感数据输人到应用程序时, 其不会被储存在设备中
–备份应该加密, 恢复数据应考虑恢复过程的异常.
安全测试清单
1. 不登录系统，直接输入登录后的页面的URL是否可以访问；
2. 不登录系统，直接输入下载文件的URL是否可以下载文件；如输入：http://url/download?name=file是否可以下载文件file
3. 退出登录后，后退按钮能否访问之前的页面；
4. ID/密码验证方式中能否使用简单密码；如密码标准为6位以上，字母和数字的组合，不包含ID，连接的字母或数字不能超过n位
5. ID/密码验证方式中，同一个帐号在不同的机器上不同时登录
6. ID/密码验证方式中，连续数次输入错误密码后该帐户是否被锁定
7. 重要信息（如密码，身份证，信用卡号等）在输入或者查询时是否明文显示；在浏览器地址栏中输入命令javascript:alert(doucument.cookie)时是否有重要信息；在html源码中能否看到重要信息；
8. 手动更改URL中的参数值能否访问没有权限访问的页面。如普通用户对应的URL中的参数为l＝e，高级用户对应的URL中的参数为l＝s，以普通用户的身份登录系统后将URL中的参数e改为s来访问没有权限访问的页面
9. URL里不可修改的参数是否可以被修改；
10. 上传与服务器端语言（jsp，asp，php）一样扩展名的文件或exe等可执行文件后，确认在服务器端是否可直接运行
11. 注册用户时是否可以以‘--’or1＝1—等做为用户名
12. 传送给服务器的参数（如查询关键字，URL中的参数等）中包含特殊字符（‘.’and1＝1--.‘and1＝0--.’.‘or 1＝0--）时是否可以正常处理
13. 执行新增操作时，在所有的输入框中输入脚本标签（<script>alert(“”)</script>）后能否保存；
14. 新增或修改重要信息（密码，身份证号码，信用卡号等）时是否有自动完成功能（在form标签中使用autocomplete＝0来关闭自动完成功能）
15. 在URL中输入下面的地址是否可以下载http://url/download.jsp?file=c:\windows\system32\drivers\etc\hosts,http://url/download.jsp?file=/etc/password
16. 是否对session的有效期进行处理
17. 错误信息中是否含有SQL语句，SQL错误信息以及web服务器的绝对路径的等
常见App测试用例
移动App测试这个主题已成为需要考虑的一个无法避免的问题。根据最近的调查研究，用户难以容忍有bug的移动App。
移动App Bug的影响是用户体验差、App的商店评级下降、用户换用竞争对手的App，声誉和信誉损失、最后销售量减少，如果它是一个付费App的话。
移动App测试与传统台式机测试相比有一定的复杂性。这些复杂性可以被分类为：
环境（大量的设备，各种移动OSs，适应频繁OSs变化） 。
设备（触摸式和非触摸式设备，有限的内存容量，电池耗电量） 。
网络（不同的网络和运营商，在不好或无网络的情况下的App行为，离线支持） 。
可用性（方向，触摸，多触摸，缩放，分页和导航的局限性，各种干扰，如来电，来电短信，闹钟，和低电量警报） 。
所有这些手机专有的复杂性需要新的针对移动App测试的测试用例设计方案。
最常见的移动App Bug
为了确定最常见的移动App Bug，进行了一次研究，其结果发表在国际测试会议上[ 1 ] 。
为了这个目的，准备了一次在线调查思考参与者的移动测试经验并发表在移动App开发和测试相关的专业社会团体内。
有针对性的参加本次调查的主要有移动App测试人员和开发人员。结合几个结果，最常见的移动App Bug在对调查结果进行统计分析后确定。
根据调查的结果，移动App崩溃是最常见的移动App Bug ，这是预料中的结果，因为很容易发现一个移动App崩溃。Android OS上一个写着“强制关闭错误”的弹出窗口跳上屏幕；当发生崩溃时，iOS中App屏幕突然消失消失。最坏的情况下，App崩溃可能会导致系统故障，操作系统崩溃。
移动App崩溃原因
为什么移动App经常崩溃？App崩溃有几个原因：从平台或环境到开发问题。
一些崩溃原因（排名不分先后） ：
设备碎片化：由于设备极具多样性，App在不同的设备上可能有表现不同。
带宽限制：带宽不佳的网络对App所需的快速响应时间可能不够。
网络的变化：不同网络间的切换可能会影响App的稳定性。
内存管理：可用内存过低，或非授权的内存位置的使用可能会导致App失败。
用户过多：连接数量过多可能会导致App崩溃。
代码错误：没有经过测试的新功能，可能会导致App在生产环境中失败。
第三方服务：广告或弹出屏幕可能会导致App崩溃。
移动App崩溃的测试用例设计
测试用例是移动测试最重要部分之一。
准备和执行预先定义的针对移动App崩溃的测试用例将简化和加速移动App崩溃的测试。
一些通用的触发移动App崩溃的测试场景，如下：
1 验证在有不同的屏幕分辨率，操作系统和运营商的多个设备上的App行为。
2 用新发布的操作系统版本验证App的行为。
3 验证在如隧道，电梯等网络质量突然改变的环境中的App行为。
4 通过手动网络从蜂窝更改到Wi-Fi ，或反过来，验证App行为。
5 验证在没有网络的环境中的App行为。
6 验证来电/短信和设备特定的警报（如警报和通知）时的App行为。
7 通过改变设备的方向，以不同的视图模式，验证App行为。
8 验证设备内存不足时的App行为。
9 通过用测试工具施加载荷验证App行为。
10 用不同的支持语言验证App行为。
显然，还会有更多的导致App崩溃的App特定场景。
结论
在这项研究中，展示了针对移动App崩溃的通用测试案例。
如果移动测试团队在他们的测试场景中准备并执行这些测试用例，那么早在开发周期就可以找到崩溃相关的Bug。 然后，开发团队将阐明崩溃原因，并找出一个解决所有Bug的通用方法。最后，App质量和用户满意度就会增加。
来源：oschina
链接：https://my.oschina.net/u/4332051/blog/3960186