功能测试层面经过两年多的踩坑和总结，测试思路基本稳定下来了。工作一年的时候有过一次测试方法和测试思路的总结，本篇正是在这篇基础上的扩充完善，基础思路就这么多，剩下的只是根据项目变化，所以命名为2.0的总结 :)
每一个优秀的测试人员都会在工作中形成自己测试方法—我刚毕业的时候一个大牛和我说的一句话，影响至今
测试模式？建模！
在编程中我们把一类问题的解决方法抽象成设计模式，那么测试也是一样的，可以抽象成测试模式，初期的想法是把一类问题的思考点抽象出来，形成测试思路，但是后来发现抽象的高度拿捏不准，代码是非常自由的，需求也是非常灵活的，导致某些固定的模式是浪费时间，所以只能往更高的方面去抽象，是的也就是思想层面，测试分析方面。建模这个词最早出现在腾讯的tmq小组，发现思想还是相近的，所以，测试的设计模式就是建模。
阶梯分析
上面画了一幅图，说明的是测试成本的趋势，越往下成本越大，对产品质量的要求就越高。
有：有是什么，需要迅速占领市场，时间就是生命，初期创业团队模式，或是只有一两个功能测试人员帮助开发分担测试任务
优：当具有一定规模，已经有一定用户量，更多考虑的是如何更好地留住用户，普通的功能测试已经满足不了产品需求，更多的是关注产品的内在，而不是乱加新功能。这时，项目更多关心的是效率问题，也会开发出各种工具提高效率(平台建设，自动化等等)，并且已经意识到，质量不仅仅是测试人员的事，整个产品的人员都是测试人员(google例子)。
测试思路：
下面的测试方法和上面的阶梯其实想对应，在有的阶段，功能测试为主，你只要掌握场景分析和元素分析就完成了，因为项目根本不会给你时间也没有机会让你接触数据测试更别说性能自动化了;在一定量的项目下，数据的深入测试和性能和自动化就会被引入，更多的是技术型验证替代手工验证，功能测试人员全部转为外包形式。
思路 && 方法
场景和元素分析建模
这个分析方法是根据流程走，根据流程里面的元素逐一验证。比如air/nano的拍照界面,应该这样思考：
1.从哪里进入
2.干了什么事
3.干的事界面有什么元素，每个元素影响的东西是什么
4.干完这件事怎么出去，怎么结束
5… …
那么再加上一些需求特性，比如:GPS开关、插不插入相机硬件、电量充不充足、有没有自动旋转等，就可以形成覆盖率比较高的用例了:
比如：
例子1) 本地应用：
先来上例子，测试一下播号页面：
步骤一：场景建模
输入号码—拨号—挂断
步骤二：组合用例
1.拨号面板输入正常号码正常点击拨号后挂断
2.拨号面板输入异常号码正常点击拨号后挂断
3.拨号面板输入空号码正常点击拨号后挂断
4…. …
步骤三：完善
在这一步，是对上两部的扩充，往往不易发现的bug都出现在破坏性实验上，所以这里扩展的基础是探索性测试，这里只列出来我自己用的比较多的方法，更多方法可以网络获取
指南法
地标测试法
取消法
测一赠一法
懒汉法
极限法
反叛法
那么根据这些方法，我们可以这么干：
1.不输入文本播放
2.输入超长文本播放
3.拨号后马上取消，重复
4.不停旋转屏幕，拨号
5…. …
数据流分析
对于网络性应用，跟随的是数据流过程，这类应用无外乎都是这样一个流程：
首先，服务器暴露给客户端的接口只有一个json文件，客户端通过http|s请求，拿到响应后解析json文件里面的不同字段，按需求封装成不同类型的数据，加载各种显示控件，并把数据赋值给UI控件，最后对重要的数据做内存缓存和磁盘缓存，以便下次不重复加载。
上面这是一句很简单的流程，但是实现起来却不简单，我们每一句话来分析：
客户端通过http|s请求：什么时候请求、请求的频率是否合理、数据是否过多、是否重复拉取、无网络还会拉取吗、弱网会怎么样、对各种响应码是否正常处理、服务器端有没有对不常刷新的数据做缓存、这个接口性能怎么样…
拿到响应后解析json文件里面的不同字段：json字段的容错性、客户端使用里面的哪里字段来展示、数据刷新后是否成功替换UI数据…
加载各种显示控件，并把数据赋值给UI控件：控件是否及时加载、加载的数据符不符合需求、有没有默认图…
对重要的数据做内存缓存和磁盘缓存：存储在哪里、什么时候会存、存储的数据格式是什么、清缓存重装对数据的影响、误删部分数据是否正常生成、存储目录合不合理(避免使用系统目录)、是否针对低内存做限制…
扩展阅读：通过codereview方法跟踪数据流和分析(还没有写)
例子2)
我们以某项目的精选页面为例来进行讲解
在上图中建立起了接口–数据的一一对应关系，有助于我们理解数据走向。
有了对应关系，我们测试就变得非常简单了：
入口：需要验证各个启动方式进入精选页是否刷新
数据拉取：验证各个网络情况下数据拉取
数据展示：验证各个字段在控件内的展示(过长、为空、刷新等)、数据刷新、对应需求正确性
数据存储：做缓存
其他：不同机型分辨率的兼容性、新安装和覆盖安装数据展示等
性能自动化分析(进阶)
前者是为了更好的体验，增加用户粘度，后者节省手工人力成本，提高精确度节省开销。我们直接看例子1和例子2能做什么样的测试。
例子1是一个拨号应用，所以对耗时比较看重；拨号设计到硬件底层的调用，如果代码不够健壮可能会存在内存泄漏。综上，会有如下的性能测试点：
1.新开机打开拨号面板耗时
2.后台留有进程打开拨号面板
3.输入号码点击拨打到呼叫等待页面时间
4.我挂断/对方挂断到回到拨号面板的时间
5.多次拨打接通并挂断，查看内存
对于自动化，覆盖也是比较好覆盖的，各个按钮的点击、拨打和挂断都可以形成多次有效的用例
例子2是一个数据展示需求，负责数据拉取和展示，可以进行流量和内存的测试，对于自动化，可以在用例解析json文件来对应到对应的界面展示，剩下的都是一些需求特性了。另外对于拉取接口的数据，更具要求还会进行多并发测试和接口测试。
