android单元测试,android单元测试用例编写

android什么叫单元测试

单元测试是参与项目开发的工程师在项目代码之外建立的白盒测试工程，用于执行项目中的目标函数并验证其状态或者结果，其中，单元指的是测试的最小模块，通常指函数。如图1所示的绿色文件夹即是单元测试工程。这些代码能够检测目标代码的正确性，打包时单元测试的代码不会被编译进入APK中。

处于高速迭代开发中的Android项目往往需要除黑盒测试外更加可靠的质量保障，这正是单元测试的用武之地。单元测试周期性对项目进行函数级别的测试，在良好的覆盖率下，能够持续维护代码逻辑，从而支持项目从容应对快速的版本更新。

相关问答

Q1: Android单元测试都是测一些什么

单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

在一种传统的结构化编程语言中，比如C，要进行测试的单元一般是函数或子过程。在像C++这样的面向对象的语言中， 要进行测试[1] 的基本单元是类。对Ada语言来说，开发人员可以选择是在独立的过程和函数，还是在Ada包的级别上进行单元测试。单元测试的原则同样被扩展到第四代语言（4GL)的开发中，在这里基本单元被典型地划分为一个菜单或显示界面。

经常与单元测试联系起来的另外一些开发活动包括代码走读（Code review)，静态分析（Static analysis)和动态分析（Dynamic analysis)。静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。

Q2: Android Test测试

              在实际的开发中几乎访问网络已经成为一个app的标配，那么每次写完一个网络请求都要重新打包在模拟器或者真机上运行一次，当然这种方式是可以的，但是打包一个apk花费相对较多的时间。我们可以使用android官方提供给我们的test框架，通过测试框架编写相应的测试用例，每次只测试相对较小的方法，打包到真机或者模拟器上的时间相对较小提升编码效率，大大降低bug出现的几率。

               使用android studio2.2.3导入使用android studio1.5编写的项目时使用Android Test出现了问题，运行报错：“Test running failed: Unable to find instrumentation info for: ComponentInfo”这句话的意思是没有找到instrumentation这个类，"Run"-"Edit Configurations"-"Android Tests"-选择你的单元测试-"Specific instrumentation runner" -选择"InstrumentationTestRunner"即可解决问题。

               出现这个问题的原因nstrumentation runner默认是MutidexTestRunner，入MultiDex后单元测试工具默认变成了MultiDexTestRunner，需要在build.gradle指定分包之前用的InstrumentationTestRunner工具，按照上面修改就可以解决这个问题。

Q3: 做Android手机软件测试需要掌握哪些工具？

请注意测试本身不是靠工具的而是靠设计，这是我的理念，所以我一向觉得，很多人认为做测试做的好就是靠掌握一门好的工具，这个观点是不正确的，所以我可以负责任的告诉你，做Android手机需要掌握的不是工具、而是理念、思维、以及框架，总的来说是本质，而工具只是辅助，那么现在我来介绍一些我了解的工具（仅仅是了解，很多没用过）

开源 Android 软件测试工具包括：Android Test Kit, AndroidJUnit4, Appium, calabash-android, Monkey, MonkeyTalk, NativeDriver, Robolectric, RoboSpock, Robotium, UIAutomator, Selendroid。

Android Test Kit

Android Test Kit 是一组 Google 开源测试工具，用于 Android 平台，包含 Espresso API 可用于编写简洁可靠的 Android UI 测试。

AndroidJUnit4

AndroidJUnit4 是一个让 JUnit 4 可以直接运行在 Android 设备上的开源命令行工具。

Appium

Appium 是一个开源、跨平台的自动化测试工具，用于测试原生和轻量移动应用，支持 iOS, Android 和 FirefoxOS 平台。Appium 驱动苹果的 UIAutomation 库和 Android 的 UiAutomator 框架，使用 Selenium 的 WebDriver JSON 协议。Appinm 的 iOS 支持是基于 Dan Cuellar's 的 iOS Auto. Appium 同时绑定了 Selendroid 用于老的 Android 平台测试。

Calabash-android

calabash-android 是一个基于 Cucumber 的 Android 的功能自动化测试框架。Calabash 允许你写和执行，是开源的自动化移动应用测试工具，支持 Android 和 iOS 原生应用。Calabash 的库允许原生和混合应用的交互测试，交互包括大量的终端用户活动。Calabash 可以媲美 Selenium WebDriver。但是， 需要注意的是 web 应用和桌面环境的交互跟触摸屏应用的交互是不同的。Calabash 专为触摸屏设备的原生应用提供 APIs。

Monkey

Monkey 是 Google 开发的 UI/应用测试工具，也是命令行工具，主要针对压力测试。你可以在任意的模拟器示例或者设备上运行。Monkey 发送一个用户事件的 pseudo-random 流给系统，作为你开发应用的压力测试。

MonkeyTalk

MonkeyTalk 是世界上最强大的移动应用测试工具。MonkeyTalk 自动为 iOS 和 Android 应用进行真实的，功能性交互测试。MonkeyTalk 提供简单的 "smoke tests"，复杂数据驱动的测试套件。MonkeyTalk 支持原生，移动和混合应用，真实设备或者模拟器。MonkeyTalk 使得场景捕获非常容易，可以记录高级别，可读的测试脚本。同样的命令可以用在 iOS 和 Android 应用上。你可以记录一个平台的一个测试，并且可以在另外一个平台回放。MonkeyTalk 支持移动触摸和基于手势交互为主的移动体验。点击，拖拽，移动，甚至是手指绘制也可以被记录和回放。

NativeDriver

NativeDriver 是 WebDriver API 的实现，是原生应用 UI 驱动，而不是 web 应用。

Robolectric

Robolectric 是一款Android单元测试框架，使用 Android SDK jar，所以你可以使用测试驱动开发 Android 应用。测试只需几秒就可以在工作站的 JVM 运行。Robolectric 处理视图缩放，资源加载和大量 Android 设备原生的 C 代码实现。Robolectric 允许你做大部分真实设备上可以做的事情，可以在工作站中运行，也可以在常规的 JVM 持续集成环境运行，不需要通过模拟器。

RoboSpock

RoboSpock 是一个开源的 Android 测试框架。提供简单的编写 BDD 行为驱动开发规范的方法，使用Groovy 语音，支持 Google Guice 库。RoboSpock 合并了 Robolectric 和 Spock 的功能。

Robotium

Robotium 是一款国外的Android自动化测试框架，主要针对Android平台的应用进行黑盒自动化测试，它提供了模拟各种手势操作（点击、长 按、滑动等）、查找和断言机制的API，能够对各种控件进行操作。Robotium结合Android官方提供的测试框架达到对应用程序进行自动化的测 试。另外，Robotium 4.0版本已经支持对WebView的操作。Robotium 对Activity，Dialog，Toast，Menu 都是支持的。

UIAutomator

uiautomator 测试框架提高用户界面（UI）的测试效率，通过自动创建功能 UI 测试示例，可以在一个或者多个设备上运行你的应用。

Selendroid

Selendroid 是一个 Android 原生应用的 UI 自动化测试框架。测试使用 Selenium 2 客户端 API 编写。Selendroid 可以在模拟器和实际设备上使用，也可以集成网格节点作为缩放和并行测试。

Q4: android 单元测试有什么用

其实单元测试不仅能保证项目进度还能优化你的设计。有些开发者会说，写单元测试代码太费劲了，比写业务代码还麻烦。可是如果强迫开发者必须写单元测试代码的时候。聪明且又想‘偷懒’的开发人员为了将来可以更方便地编写测试代码。唯一的办法就是通过优化设计，尽可能得将业务代码设计成更容易测试的代码。慢慢地开发者就会发现。自己设计的程序耦合度也越来越低。每个单元程序的输入输出，业务内容和异常情况都会尽可能变得简单。最后发现自己的编程习惯和设计能力也越来越老练了。

其实容易测试的代码基本上可以和设计良好的代码划等号。因为一个单元测试用例其实就是一个单元的最早用户。容易使用显然意味着良好的设计。

有着良好设计的项目一直是很注重代码重用的。代码重用的好处在这里就不多说了。但是要做到代码重用首先要保证被重用的单元程序必须是个非常优秀的程序，除了良好的设计，还要有详细的文档。另外最重要的其实是单元测试代码。不知道大家有没有这样的经历？当大家不清楚一个API 函数如何使用而去寻找文档的帮助时，往往会跳过大段的英文说明而去直接看文档中提供的样例程序，然后在自己的程序中依葫芦画瓢调用这个函数。那么，您有没有意识到，被重用的代码如果有了单元测试代码。你的测试代码就可以成为这个函数最好的API 了。

单元测试代码还可以通过简单的事务回滚功能在生产环境上做基于真实数据的测试而不用担心会产生不必要的数据。利用这样的测试代码我们可以在发布程序后check 刚才的发布是否成功。以往发布的时候我们经常会碰到一种比较尴尬的情况，当我们将程序发布到正式环境上后，我们每个人心里一直还是有点后顾之忧。因为我们不能在正式环境上运行我们的程序，只能被动地等待客户操作过后才知道发布的程序是否正常。这种情况让我们非常被动，如果运气好可能不出什么问题，可是一旦客户在正式环境上发现报了个系统异常之类的错误或者出现错误数据，那就后果很严重了，这将影响到产品的声誉，显然这样也是很没面子事。如果我们运行过单元测试代码，万一有问题我们就可以主动的发现并且修改后重新发布。