测试是软件工程中一个非常重要的环节，而测试用例又可以显著地提高测试的效率和准确性。App测试用例其实就是一段普通的程序代码，通常是带有期望的运行结果的，测试者可以根据最终的运行结果来判断程序是否能正常工作。
我相信大多数的程序员都是不喜欢编写测试用例的，因为这是一件很繁琐的事情。明明运行一下程序，观察运行结果就能知道对与错了，为什么还要通过代码来进行判断呢？确实，如果只是普通的一个小程序，编写测试用例是有些多此一举，但是当你正在维护一个非常庞大的工程时，你就会发现编写测试用例是非常有必要的。
举个例子吧，比如你确实正在维护一个很庞大的工程，里面有许许多多数也数不清的功能。某天，你的领导要求你对其中一个功能进行修改，难度也不高，你很快就解决了，并且测试通过。但是几天之后，突然有人发现其他功能出现了问题，最终定位出来的原因竟然就是你之前修改的那个功能所导致的！这下你可冤死了。不过千万别以为这是天方夜谭，在大型的项目中，这种情况还是很常见的。由于项目里的很多代码都是公用的，你为了完成一个功能而去修改某行代码，完全有可能因此而导致另一个功能无法正常工作。
所以，当项目比较庞大的时候，一般都应该去编写测试用例的。如果我们给项目的每一项功能都编写了测试用例，每当修改或新增任何功能之后，就将所有的测试用例都跑一遍，只要有任何测试用例没有通过，就说明修改或新增的这个功能影响到现有功能了，这样就可以及早地发现问题，避免事故的出现。
1、创建测试工程
介绍了这么多，也是时候该动手尝试一下了，下面我们就来创建一个测试工程。在创建之前你需要知道，测试工程通常都不是独立存在的，而是依赖于某个现有工程的，一般比较常见的做法是在现有工程下新建一个tests文件夹，测试工程就存放在这里。
那么我们就给刚创建的项目test创建一个测试工程吧。在Eclipse的导航栏中点击File→New→Other，会打开一个对话框，展开Android目录，在里面选中Android Test Project，如图1所示。
点击Next后会弹出创建Android测试工程的对话框，在这里我们可以输入测试工程的名字，并选择测试工程的路径。按照惯例，我们将路径选择为test项目的tests文件夹下，如图2所示。
继续点击Next，这时会让我们选择为哪一个项目创建测试功能，这里当然选择test了，如下图所示。
现在点击Finish就可以完成测试工程的创建了。观察测试工程中AndroidManifest.xml文件的代码，如下所示：
|
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.test.test" android:versionCode="1" android:versionName="1.0" > <uses-sdk android:minSdkVersion="8" /> <instrumentation android:name="android.test.InstrumentationTestRunner" android:targetPackage="com.example.test" /> <application android:icon="@drawable/ic_launcher" android:label="@string/app_name" > <uses-library android:name="android.test.runner" /> </application> </manifest> |
其中<instrumentation>和<uses-library>标签是自动生成的，表示这是一个测试工程，在<instrumentation>标签中还通过android:targetPackage属性指定了测试目标的包名。
2、进行单元测试
创建好了测试工程，下面我们来对BroadcastBestPractice这个项目进行单元测试。单元测试是指对软件中最小的功能模块进行测试，如果软件中的每一个单元都能通过测试，说明代码的健壮性就已经非常好了。
test项目中有一个ActivityCollector类，主要是用于对所有的Activity进行管理的，那么我们就来测试这个类吧。首先在testTest项目中新建一个ActivityCollectorTest类，并让它继承自AndroidTestCase，然后重写setUp()和tearDown()方法，如下所示。
public class ActivityCollectorTest extends AndroidTestCase {
@Override
protected void setUp() throws Exception {
super.setUp();
}
@Override
protected void tearDown() throws Exception {
super.tearDown();
}
}
其中setUp()方法会在所有的测试用例执行之前调用，可以在这里进行一些初始化操作。tearDown()方法会在所有的测试用例执行之后调用，可以在这里进行一些资源释放的操作。
那么该如何编写测试用例呢？其实也很简单，只需要定义一个以test开头的方法，测试框架就会自动调用这个方法了。然后我们在方法中可以通过断言（assert）的形式来期望一个运行结果，再和实际的运行结果进行对比，这样一条测试用例就完成了。测试用例覆盖的功能越广泛，程序出现bug的概率就会越小。
比如说ActivityCollector中的addActivity()方法是用于向集合里添加活动的，那么我们就可以给这个方法编写一些测试用例，代码如下所示：
|
public class ActivityCollectorTest extends AndroidTestCase { @Override protected void setUp() throws Exception { super.setUp(); } public void testAddActivity() { assertEquals(0, ActivityCollector.activities.size()); MainActivity main = new MainActivity(); ActivityCollector.addActivity(main); assertEquals(1, ActivityCollector.activities.size()); } @Override protected void tearDown() throws Exception { super.tearDown(); } } |
可以看到，这里我们添加了一个testAddActivity()方法，在这个方法的一开始就调用了assertEquals()方法来进行断言，认为目前ActivityCollector中的活动个数是0。接下来new出了一个LoginActivity的实例，并调用addActivity()方法将这个活动添加到ActivityCollector中，然后再次调用assertEquals()方法进行断言，认为目前ActivityCollector中的活动个数是1。
现在可以右击测试工程→Run As→Android JUnit Test来运行这个测试用例，结果如图
转自51testing
TestBird正好能够帮到他，比如我们可以快速在几百台手机上自动进行APP的兼容性测试，测试之后能够输出详尽的测试报告，他通过日志和截图就能定位问题。而我们的云手机也能帮助到他，这里有2000多台真实设备，能够方便开发者进行远程真机调试。善用这些工具，BUG可以被更快修复，时间也会变得更加充足。