android测试篇（一）简介

前言

android测试本人接触并不多，也可以说压根没有，原因开发的大部分项目并不需要，或者自身压根没这个意识，之前也初步了解了一下android测试的概念，想了想不就是添加一些test，对当前的UI做个test，对当前的对象做一个test，没那个必要吧，还麻烦！！！

那为什么现在有拾起来学习呢？

首先，加入了测试显得自己更加高逼格了，我想这个肯定是一个原因吧；其次，既然有android测试，那么肯定有测试的好处，不然也不会出现那么多测试工具，也确实，随着项目业务以及体积等逐渐庞大，项目的运行速率比较慢，如果我想测试一个小模块在条件允许的情况下，我肯定更愿意跑一个test测试了，同样的效果，快很多；最后，也是因为最近在深究网络请求和注解，无缘无故进入了一条不归…可不，深挖进入android单元测试，然后看了看，还有android UI测试，android压力测试，那就有了这篇系列文章。番外篇，有人说还有个原因，对新加入的成员在运行测试的时候还可以更好的了解业务逻辑，我不敢苟同，简单的项目不需要测试（因为测试本身就比较麻烦呀），复杂的能通过测试了解业务逻辑！！！不清楚，不了解，不敢乱说！

正文

android测试分为单元测试，UI测试，压力测试，本系列将具体根据这3个分类展开学习与实践，学习肯定是概念性，重点在于实践。当然了，你概念都不知道如何实践，没有实践学习干啥！！！

所以听贫僧一言，一切有个依托的项目作为实践，或者往项目上靠，单纯的学习很容易遗忘

android测试分类如下：

• 本地测试： Junit4、Mockito、PowerMockito、Robolectric
• UI测试（仪器化测试）：Espresso、UI Automator
• 压力测试 ：Monkey

注：这里是结合自己的理解，因为原文分类并非如此，可根据个人理解，我感觉这么分类是比较好的

单元测试的分类：

• 本地测试(Local tests): 只在本地机器JVM上运行，以最小化执行时间，这种单元测试不依赖于Android框架，或者即使有依赖，也很方便使用模拟框架来模拟依赖，以达到隔离Android依赖的目的，模拟框架如google推荐的Mockito；

• 仪器化测试(Instrumented tests): 在真机或模拟器上运行的单元测试，由于需要跑到设备上，比较慢，这些测试可以访问仪器（Android系统）信息，比如被测应用程序的上下文，一般地，依赖不太方便通过模拟框架模拟时采用这种方式。

可能原因不止以上这些，但是我们这里主要针对以上（后续文章中有可能会补充）做讲解