手机app测试分析方法 -- 逻辑分析法(数据测试方法)
那么这一篇呢，针对的是逻辑做的灰盒测试，一般是指需求文档上没有的内容，但却是技术方案的核心，逻辑分析针对的就是实现测试。
那么什么是逻辑呢？比方说一个记事本，具有新建，修改删除的功能，如果是功能测试，那么依照元素分析法就是新建 修改 删除 展示这几个要点，
新建 普通文本 数字 表情 特殊字符 空格等一些字符
展示 能否展示空格 过短过长字符展示效果 横竖屏是否支持
修改 修改后展示 修改后重进 修改后的列表展示顺序等等
删除 删除某条记录展示 删除重进展示 删除后再次新建相同内容
好了，差不多了，单纯页面来测试这样就算ok了 下面是逻辑分析法：
假设我们要去了解逻辑，首先是要有提问的艺术，根据这个需求我列了以下几点，仅供参考：
1.数据保存在哪里 以什么方式保存的
2.数据量如果比较大 会不会出现问题 有没有清除逻辑 有没有存储上限 有没有展示上限
3.什么时机保存的 按home键/back键/中断事件 会不会丢失数据
4.有没有加密存储
5.是否及时关闭cursor，避免内存泄露
提问之后假设开发给的逻辑是这样的：
展示采用listview展示，并且重用了contentView；数据采用sqlite存储，存储在手机的/data/data/xxx.xxx/databases下，保存的时机是在onPause()函数，存储的数据都是明文写入的。
好的，我们再来设计思考点：
新建 null
展示 通过自动化脚本构建多条数据，或者直接导出sqlite插入数据
修改 null
删除 删除后进入数据库查看数据，看是否删除完全
好了，这就是最基本的逻辑分析法，说白了就是站在数据的角度分析需求。，上面那个例子说明的是一个非联网程序的简单思考方向，这在实际的测试工作中基本不会遇到不联网的程序，下面就来介绍商业联网程序的逻辑分析法。
先说说思路，很简单的一条线，从后台取得数据--客户端对数据处理并展示--存储数据到本地
后台取得数据
这里的核心是请求后台数据，并返回json或者xml，关于请求，分为正常和异常情况，其中异常情况我们一般要求要有重试机制(tcp的超时重传...不关事不关事),正常情况我们要想到(请求头 响应头是否带lastmodify或者cache时间；正常请求流程应该保证ok；2g3g4gwifi应该保证正常请求；请求时机；请求间隔；客户端对响应内容的容错性；)，异常情况(模拟后台返回404或者502等；断网；切换网络；)，以及发生异常的重试，这个就是一个请求需要思考的点，重点的验证是在后台返回数据正确性验证上，它将消耗我们70的时间。
客户端处理逻辑，这部分一般根据需求和开发描述来思考，也可以自己看代码(不嫌麻烦的话),这部分也是精华所在，拿到数据，过滤什么样的字段，展示什么样的字段，存储什么字段，各个组件之间的数据如何配合，是否跨进程，是否用了binder通讯机制，等等，这部分模块的逻辑取决于开发的实现方案，不同项目有不同逻辑，没什么共性的东西，就不多说了。
本地存储，数据只是拉取展示而不做存储的应用是不完整的，我们知道安卓的存储无非就4类，file sharePreference sqlie net，对于缓存，文字类的一般是sqlie，文件类包括图片的一般是二进制file流保存，简单的key-value则是SharePreference保存，当然，还有各个文件类型保存路径也是需要测试人员知道的。好了，有了这些基础之后，我们开始测试我们的存储数据，和请求一样，首先测试的是写入时机，为了避免LMK机制杀掉activity，保存数据的时机必须要选对，也就是activity的生命周期哪个函数保存的问题，这一块容易出问题，要特别注意。其二，保存数据内容，重要数据必须优先且写入。其三，读取的时机，要清楚知道从哪里读，缓存有内存和本地两种，该从内存却读了本地数据，可能会有nullpointexception问题，第四呢，只存只读还不行，空间就这么大，还要有清除逻辑，比如缓存图片而不清除，就会越用越大，造成的后果是用户怒删之，数据库也一样，越用越大导致读取缓慢，这里要特别留意时长第三方的清除垃圾软件，没准会把重要数据删除了。
其他，我们说了一大堆，都是围绕着这个功能，其实眼界可以放宽一点，比如说视野放到整个app的进程，是否会出什么问题(尤其是多进程的app)，考虑一些中断事件，比如来电话了，闹钟响了等等，一些系统按键，比如home，power键，这些，想办法破坏系统，正式测试所追求的。
这里找不到例子了，毕竟公司的产品逻辑也不能随随便便拿出来是不，不过也可以考虑读一下开源软件的代码，也可以讲讲，有时间再说吧～
那么下一篇打算是针对常用模块整理成一个测试思路，比如上面提到的，一个请求，你应该考虑什么方面，希望做成一个参考的文章，以备不时之需吧。