Android App测试分析方法(总结 && 重写)

前言：
nick说过，没个人都要有一套自己的测试方法，针对模块有一套自己的解决思路，之后一直在寻找。虽然之前写过一次，但是还是欠缺了什么，至少框架不变，慢慢补充细节吧！

元素分析：

这里之前一篇只分析了静态的元素，经过工作中实践后应该扩展为动态的元素以及关联的元素：元素分析法=静态+动态+关联

静态：
一个activity(界面)中的一个view(组成的最小单元)为一个元素，那么元素分析就是针对这里的没一个view设计测试点。

动态：
这部分主要是事件，拿某捷视频类的互联网软件来说，动态改变的除了键盘事件和触摸事件外，里面还有一个焦点变化，于是我们认为动态事件实际上包含事件和界面动态改变的元素，当然也包括因为用户操作而改变的切后台事件。

关联：
这部分是元素关联，也就是我们说的模块关联，反映在代码中大多数都是消息的各种传递，比如说某登录模块，用静态动态分析完之后，还要考虑模块关联，你这里登录了拉取了资料，没问题，但是得思考，其他关联的模块有没有拉取到信息呢？下载一个视频文件，下载模块下载完了，显示成功了，但是你回到下载页面他的下载按钮有没有同步到呢？等等。

总结：元素分析法设计的初衷是为了解决基本的功能测试的，也就是根据需求文档能列出测试点，纯黑盒测试。前几天做过一次项目的BUG类型分布，发现这类BUG占了70%左右，所以这里是比较重要的。

*****************write by cloudhuan****************

逻辑分析：

上面的部分分析了功能测试的基本问题分析，这一部分分析的是客户端逻辑，会偏向灰盒。那么这里测试的是客户端代码实现逻辑，关键字是 数据流，关键图是下面这个：

后台：

也就是我们所说的服务端，对于客户端来说，和后台交互的架构是c/s架构，交互的信息一般是json或者也有xml，我们这里验证的就是这类请求。思考点分为三类，请求时机+请求间隔+正常+异常+重试

请求时机+请求间隔：
字面的意思啦，某个事件的触发时机，是一进入应用就发送请求呢，还是翻页触发呢，还是进入应用n秒之后触发呢，这个请求有没有间隔呢，也就是我们常说的轮训机制，多长的时间才合理呢，对每一个客户端发过去的请求都要思考这一类问题。

正常：
思考一个正常的请求响应模式，也就是返回码返回200 ok，这里要思考页面有没有做缓存，客户端发送请求有没有带缓存字段，避免过期也不会去拉取新数据，亦或是浪费流量去重复拉取一样的数据。另外，针对请求体内的内容，做一个删删减减，看客户端的容错性，比如返回一个视频列表，返回的json文件中删除视频信息，看客户端的容错性，因为你不可能保证后台哪天不抽风，然后用户一打开应用就crash掉是不。

异常+重试：
异常类的思考是想办法让c/s连接不上，于是就想到一、服务端不反回数据，这类通过fiddle改变响应为404或者502；二、弱网或者网络断开切换，这部分直接断开数据连接，或者通过工具模拟弱网请求。
至于重试机制，失败了一定要求重试的，比如说重试多少次，多少秒后重试，请求退避模式啊这类策略有没有做等等

扩展–接口测试：
在客户端请求和服务器响应这一块一直是重头戏，这里我分析的只有客户端对服务器的处理上，其实这里还有一个测试方向，那就是接口测试，测试的重点是服务器测试，包括不同的参数组合对服务端的正确性验证，并发请求对服务端的压力稳定性验证，这就不在本篇的讨论范围了。

总结：这就是客户端和服务端通讯需要分析到的地方，主要就三点，请求时机+请求间隔+正常+异常+重试，当然还没完，后续我们分析性能这里是重点照顾对象。

客户端处理：

这一块针对的是开发GG的代码逻辑性验证，一问二看，问什么，问开发代码实现逻辑，比如就是上面请求中的请求时机，间隔，下载来的文件有没有缓存，目录在哪里，有新数据缓存会不会清除等不局限的任意问题，当然，还是习惯直接翻看源码，更详细，应该包括我在内的很多组员都被开发坑过，leader也说过，绝对不要信开发…所以条件允许还是直接找到对应源码，直接读吧，只要读到函数调用就行了，具体实现没必要深究，不过业余时间细看肯定会提高你的编程水平哒。

本地存储：

本地存储里面放的一般是配置文件或者资源文件，对于配置文件测试了解目录和字段可以很容易模拟出各种测试条件以及判断bug出现的原因，比方说一个配置没有生效，那么我们就检查本地配置文件有没有down下来，有没有替换成最新的文件，里面我们需要的字段是不是预期的，如果都正确，那么就基本确定是代码‘读’这部分逻辑出问题了。

本地存储的权限：
我们知道移动设备有sd卡和没有sd卡之分，所以要分析的是有sd卡存储目录的优先级，然后没有sd卡程序能不能正常使用，会不会写到/data/分区下面。还有部分设备内置存储没有读写权限的。

容量和‘生命周期’：
这部分考虑的是存储容量满的情况，看下程序能否正常使用，以及对于一些大的缓存数据，比如说图片，音乐和视频的缓存文件有没有定期清理逻辑，亦或是容量满了之后触发清理这块逻辑，这部分至接问开发吧。

**总结：**ok 这一部分客户端逻辑分析就完成了，还是那句话，数据流，从客户端请求到响应，分析各种正常容错和异常情况，然后数据到客户端的进一步加工，最后数据存到本地内置存储，以及存储的缓存消亡的一个周期，这就是逻辑分析法

*****************write by cloudhuan****************

进阶分析：

这部分内容测试中一般是放在最后面做的，因为要么不出问题，要么就出很严重的问题，比如anr crash或者卡顿慢。

网络：
前面的请求响应模式提及到了，考虑的是正常网络，弱网络，无网络以及各种网络状况切换的情况

兼容：
把所有设备过一遍显然不科学，参考友盟的机型活跃分布，覆盖主流机型、rom、处理器，感觉就差不多了。

中断：
这里检查的是App在运行正常过程中的一些第三方事件，比如来电话了，来短信了，低电量了，或者按关机键，home键退出，这一类的中断事件，这里的本质检查的是activity对现场数据保护的能力，处理不好就很有可能crash。

安装/覆盖安装：
相信没一个项目组发布版本之前都会进行一个新安装和覆盖安装的检查吧，检查的是数据继承，一般不会有问题，不过注意的是数据库的表结构发生改变时一定要认真对待。

进程：
对于有些多进程的应用，用的是binder通信机制，这种相互依赖的频繁数据交流，可以试一下代码对某个进程挂掉后客户端的异常处理，不过一般会自启了。

性能专项：
参考另外一篇文章：竟然留在公司了 节后再上传