如何编写脚本自动运行android studio测试用例
2个回答
2016-10-25 · 知道合伙人软件行家
关注
展开全部
测试用例是什么,测试用例其实就是一段普通的程序代码,通常是带有期望的运行结果的,测试者可以根据最终的运行结果来判断程序是否能正常工作。
单元测试是什么,单元测试是指对软件中最小的功能模块进行测试,如果软件的没一个单元都能通过测试,说明代码的健壮性已经非常好了。
在Eclipse下也没编写过测试用例,总觉得多此一举。然后看了Android Studio新建的工程目录下总会自动生成test文件夹,看着很不爽,所以需要了解它是怎么工作的。
在工程目录与main同级的test文件夹下的包下,建立一个Java文件叫HaolvTest继承自AndroidTestCase,在里面写了一个方法如下:
public class HaolvTest extends AndroidTestCase{
@Override
protected void setUp() throws Exception {
super.setUp();
}
public void testAddAct(){
assertEquals(0, AppManager.getInstance().actSize());
SplashActivity splashActivity = new SplashActivity();
AppManager.getInstance().addActivity(splashActivity);
assertEquals(1, AppManager.getInstance().actSize());
}
@Override
protected void tearDown() throws Exception {
super.tearDown();
}
}1234567891011121314151617181912345678910111213141516171819
然后右键这个文件Run,等了一会儿,看到控制台输出错误日志如下:
java.lang.RuntimeException: Method setUp in android.test.AndroidTestCase not mocked. See http://g.co/androidstudio/not-mocked for details.
at android.test.AndroidTestCase.setUp(AndroidTestCase.java)
at com.example.admin.myapplication.HaolvTest.setUp(HaolvTest.java:18)
at junit.framework.TestCase.runBare(TestCase.java:139)
......
Process finished with exit code -1123456789123456789
然后简单搜索了一下,也没发现什么有价值的答案,后来直接看了原来默认的ExampleUnitTest的编写方式,发现它并没有继承自AndroidTestCase,而是直接在方法上加了一个Test注解,然后我也把我的测试用例代码改成这样,果然可以测试通过,然后添加了一个已知的错误来测试,如下:
@Test
public void testAddAct(){
assertEquals(0, AppManager.getInstance().actSize());
SplashActivity splashActivity = new SplashActivity();
AppManager.getInstance().addActivity(splashActivity);
assertEquals(1, AppManager.getInstance().actSize());
AppManager.getInstance().addActivity(splashActivity);
assertEquals(1, AppManager.getInstance().actSize());
}123456789123456789
这个时候执行的结果是错误的,如下:
Expected :1
Actual :2
<Click to see difference>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at com.example.admin.myapplication.HaolvTest.testAddAct(HaolvTest.java:25)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
.....
1234567891011121312345678910111213
可以看到期望是1,实际值是2,所以可以测试出addActivity这个方法还需要优化。
总结:在AS环境下,写测试用例更方便了,啥都不用准备了,直接在ExampleUnitTest写个方法@Test就行,方法内容主要就是通过assertEquals去判断等,后面再细细研究,这里先开个头,做个准备工作。。(以上部分文字和代码参考《第一行代码》13.5小节)
在新建一个Android Project后,会发现在在src目录下有三个子目录,分别是androidTest、main、test目录,搜索了一下,得知androidTest目录是Android Instrumentation Tests的文件夹(Instrumentation :模拟、使用仪器),test目录是Unit Tests的文件夹。
看来要进行真正的Android测试,应该是在androidTest目录下编写测试用例。
单元测试是什么,单元测试是指对软件中最小的功能模块进行测试,如果软件的没一个单元都能通过测试,说明代码的健壮性已经非常好了。
在Eclipse下也没编写过测试用例,总觉得多此一举。然后看了Android Studio新建的工程目录下总会自动生成test文件夹,看着很不爽,所以需要了解它是怎么工作的。
在工程目录与main同级的test文件夹下的包下,建立一个Java文件叫HaolvTest继承自AndroidTestCase,在里面写了一个方法如下:
public class HaolvTest extends AndroidTestCase{
@Override
protected void setUp() throws Exception {
super.setUp();
}
public void testAddAct(){
assertEquals(0, AppManager.getInstance().actSize());
SplashActivity splashActivity = new SplashActivity();
AppManager.getInstance().addActivity(splashActivity);
assertEquals(1, AppManager.getInstance().actSize());
}
@Override
protected void tearDown() throws Exception {
super.tearDown();
}
}1234567891011121314151617181912345678910111213141516171819
然后右键这个文件Run,等了一会儿,看到控制台输出错误日志如下:
java.lang.RuntimeException: Method setUp in android.test.AndroidTestCase not mocked. See http://g.co/androidstudio/not-mocked for details.
at android.test.AndroidTestCase.setUp(AndroidTestCase.java)
at com.example.admin.myapplication.HaolvTest.setUp(HaolvTest.java:18)
at junit.framework.TestCase.runBare(TestCase.java:139)
......
Process finished with exit code -1123456789123456789
然后简单搜索了一下,也没发现什么有价值的答案,后来直接看了原来默认的ExampleUnitTest的编写方式,发现它并没有继承自AndroidTestCase,而是直接在方法上加了一个Test注解,然后我也把我的测试用例代码改成这样,果然可以测试通过,然后添加了一个已知的错误来测试,如下:
@Test
public void testAddAct(){
assertEquals(0, AppManager.getInstance().actSize());
SplashActivity splashActivity = new SplashActivity();
AppManager.getInstance().addActivity(splashActivity);
assertEquals(1, AppManager.getInstance().actSize());
AppManager.getInstance().addActivity(splashActivity);
assertEquals(1, AppManager.getInstance().actSize());
}123456789123456789
这个时候执行的结果是错误的,如下:
Expected :1
Actual :2
<Click to see difference>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at com.example.admin.myapplication.HaolvTest.testAddAct(HaolvTest.java:25)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
.....
1234567891011121312345678910111213
可以看到期望是1,实际值是2,所以可以测试出addActivity这个方法还需要优化。
总结:在AS环境下,写测试用例更方便了,啥都不用准备了,直接在ExampleUnitTest写个方法@Test就行,方法内容主要就是通过assertEquals去判断等,后面再细细研究,这里先开个头,做个准备工作。。(以上部分文字和代码参考《第一行代码》13.5小节)
在新建一个Android Project后,会发现在在src目录下有三个子目录,分别是androidTest、main、test目录,搜索了一下,得知androidTest目录是Android Instrumentation Tests的文件夹(Instrumentation :模拟、使用仪器),test目录是Unit Tests的文件夹。
看来要进行真正的Android测试,应该是在androidTest目录下编写测试用例。
展开全部
测试用例是什么,测试用例其实就是一段普通的程序代码,通常是带有期望的运行结果的,测试者可以根据最终的运行结果来判断程序是否能正常工作。
单元测试是什么,单元测试是指对软件中最小的功能模块进行测试,如果软件的没一个单元都能通过测试,说明代码的健壮性已经非常好了。
在Eclipse下也没编写过测试用例,总觉得多此一举。然后看了Android Studio新建的工程目录下总会自动生成test文件夹,看着很不爽,所以需要了解它是怎么工作的。
在工程目录与main同级的test文件夹下的包下,建立一个Java文件叫HaolvTest继承自AndroidTestCase,在里面写了一个方法如下:
public class HaolvTest extends AndroidTestCase{
@Override
protected void setUp() throws Exception {
super.setUp();
}
public void testAddAct(){
assertEquals(0, AppManager.getInstance().actSize());
SplashActivity splashActivity = new SplashActivity();
AppManager.getInstance().addActivity(splashActivity);
assertEquals(1, AppManager.getInstance().actSize());
}
@Override
protected void tearDown() throws Exception {
super.tearDown();
}
}1234567891011121314151617181912345678910111213141516171819
然后右键这个文件Run,等了一会儿,看到控制台输出错误日志如下:
java.lang.RuntimeException: Method setUp in android.test.AndroidTestCase not mocked. See http://g.co/androidstudio/not-mocked for details.
at android.test.AndroidTestCase.setUp(AndroidTestCase.java)
at com.example.admin.myapplication.HaolvTest.setUp(HaolvTest.java:18)
at junit.framework.TestCase.runBare(TestCase.java:139)
......
Process finished with exit code -1123456789123456789
然后简单搜索了一下,也没发现什么有价值的答案,后来直接看了原来默认的ExampleUnitTest的编写方式,发现它并没有继承自AndroidTestCase,而是直接在方法上加了一个Test注解,然后我也把我的测试用例代码改成这样,果然可以测试通过,然后添加了一个已知的错误来测试,如下:
@Test
public void testAddAct(){
assertEquals(0, AppManager.getInstance().actSize());
SplashActivity splashActivity = new SplashActivity();
AppManager.getInstance().addActivity(splashActivity);
assertEquals(1, AppManager.getInstance().actSize());
AppManager.getInstance().addActivity(splashActivity);
assertEquals(1, AppManager.getInstance().actSize());
}123456789123456789
这个时候执行的结果是错误的,如下:
Expected :1
Actual :2
<Click to see difference>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at com.example.admin.myapplication.HaolvTest.testAddAct(HaolvTest.java:25)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
.....
1234567891011121312345678910111213
可以看到期望是1,实际值是2,所以可以测试出addActivity这个方法还需要优化。
总结:在AS环境下,写测试用例更方便了,啥都不用准备了,直接在ExampleUnitTest写个方法@Test就行,方法内容主要就是通过assertEquals去判断等,后面再细细研究,这里先开个头,做个准备工作。。(以上部分文字和代码参考《第一行代码》13.5小节)
在新建一个Android Project后,会发现在在src目录下有三个子目录,分别是androidTest、main、test目录,搜索了一下,得知androidTest目录是Android Instrumentation Tests的文件夹(Instrumentation :模拟、使用仪器),test目录是Unit Tests的文件夹。
看来要进行真正的Android测试,应该是在androidTest目录下编写测试用例。
单元测试是什么,单元测试是指对软件中最小的功能模块进行测试,如果软件的没一个单元都能通过测试,说明代码的健壮性已经非常好了。
在Eclipse下也没编写过测试用例,总觉得多此一举。然后看了Android Studio新建的工程目录下总会自动生成test文件夹,看着很不爽,所以需要了解它是怎么工作的。
在工程目录与main同级的test文件夹下的包下,建立一个Java文件叫HaolvTest继承自AndroidTestCase,在里面写了一个方法如下:
public class HaolvTest extends AndroidTestCase{
@Override
protected void setUp() throws Exception {
super.setUp();
}
public void testAddAct(){
assertEquals(0, AppManager.getInstance().actSize());
SplashActivity splashActivity = new SplashActivity();
AppManager.getInstance().addActivity(splashActivity);
assertEquals(1, AppManager.getInstance().actSize());
}
@Override
protected void tearDown() throws Exception {
super.tearDown();
}
}1234567891011121314151617181912345678910111213141516171819
然后右键这个文件Run,等了一会儿,看到控制台输出错误日志如下:
java.lang.RuntimeException: Method setUp in android.test.AndroidTestCase not mocked. See http://g.co/androidstudio/not-mocked for details.
at android.test.AndroidTestCase.setUp(AndroidTestCase.java)
at com.example.admin.myapplication.HaolvTest.setUp(HaolvTest.java:18)
at junit.framework.TestCase.runBare(TestCase.java:139)
......
Process finished with exit code -1123456789123456789
然后简单搜索了一下,也没发现什么有价值的答案,后来直接看了原来默认的ExampleUnitTest的编写方式,发现它并没有继承自AndroidTestCase,而是直接在方法上加了一个Test注解,然后我也把我的测试用例代码改成这样,果然可以测试通过,然后添加了一个已知的错误来测试,如下:
@Test
public void testAddAct(){
assertEquals(0, AppManager.getInstance().actSize());
SplashActivity splashActivity = new SplashActivity();
AppManager.getInstance().addActivity(splashActivity);
assertEquals(1, AppManager.getInstance().actSize());
AppManager.getInstance().addActivity(splashActivity);
assertEquals(1, AppManager.getInstance().actSize());
}123456789123456789
这个时候执行的结果是错误的,如下:
Expected :1
Actual :2
<Click to see difference>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at com.example.admin.myapplication.HaolvTest.testAddAct(HaolvTest.java:25)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
.....
1234567891011121312345678910111213
可以看到期望是1,实际值是2,所以可以测试出addActivity这个方法还需要优化。
总结:在AS环境下,写测试用例更方便了,啥都不用准备了,直接在ExampleUnitTest写个方法@Test就行,方法内容主要就是通过assertEquals去判断等,后面再细细研究,这里先开个头,做个准备工作。。(以上部分文字和代码参考《第一行代码》13.5小节)
在新建一个Android Project后,会发现在在src目录下有三个子目录,分别是androidTest、main、test目录,搜索了一下,得知androidTest目录是Android Instrumentation Tests的文件夹(Instrumentation :模拟、使用仪器),test目录是Unit Tests的文件夹。
看来要进行真正的Android测试,应该是在androidTest目录下编写测试用例。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询
广告 您可能关注的内容 |