用例脚本

1. 测试用例、测试数据、测试脚本之间的关系

支持测试用例与业务组件之间的关系管理，通过测试业务组件和数据“搭建”测试用例，
...
测试出错的情况下执行错误处理脚本，保证出错后的测试用例脚本能够继续被执行。
...

2. APP兼容性测试脚本怎么写

兼容性测试，你需要根据测试用例，编写测试脚本，根据用户给出的测试用例，编写可以自动化执行的测试脚本。测试用例的样式，可以是word或者excel格式的。
兼容性测试:就是让APP、小程序、H5程序，在所有的设备上进行适配，兼容性测试，发现潜在的问题。
app兼容性测试使用方法:
1) 登陆您的TestBird账户，进入APP测试系统，如果没有账号可以直接注册一个。
2)点击右上角的“新建测试任务”
3)填写测试需求
4）选择测试机型后创建应用的版本
5)上传APK包，开始测试
6)任务上传成功，可以随时查看测试进展

3. 如何使用python编写测试脚本

1)doctest
使用doctest是一种类似于命令行尝试的方式，用法很简单，如下

复制代码代码如下:

def f(n):
"""
>>> f(1)
1
>>> f(2)
2
"""
print(n)

if __name__ == '__main__':
import doctest
doctest.testmod()

应该来说是足够简单了，另外还有一种方式doctest.testfile(filename)，就是把命令行的方式放在文件里进行测试。

2)unittest
unittest历史悠久，最早可以追溯到上世纪七八十年代了，C++，java里也都有类似的实现，Python里的实现很简单。
unittest在python里主要的实现方式是TestCase,TestSuite。用法还是例子起步。

复制代码代码如下:

from widget import Widget
import unittest
# 执行测试的类
class WidgetTestCase(unittest.TestCase):
def setUp(self):
self.widget = Widget()
def tearDown(self):
self.widget.dispose()
self.widget = None
def testSize(self):
self.assertEqual(self.widget.getSize(), (40, 40))
def testResize(self):
self.widget.resize(100, 100)
self.assertEqual(self.widget.getSize(), (100, 100))
# 测试
if __name__ == "__main__":
# 构造测试集
suite = unittest.TestSuite()
suite.addTest(WidgetTestCase("testSize"))
suite.addTest(WidgetTestCase("testResize"))

# 执行测试
runner = unittest.TextTestRunner()
runner.run(suite)

简单的说，1>构造TestCase(测试用例)，其中的setup和teardown负责预处理和善后工作。2>构造测试集，添加用例3>执行测试需要说明的是测试方法，在Python中有N多测试函数，主要的有：
TestCase.assert_(expr[, msg])
TestCase.failUnless(expr[, msg])
TestCase.assertTrue(expr[, msg])
TestCase.assertEqual(first, second[, msg])
TestCase.failUnlessEqual(first, second[, msg])
TestCase.assertNotEqual(first, second[, msg])
TestCase.failIfEqual(first, second[, msg])
TestCase.assertAlmostEqual(first, second[, places[, msg]])
TestCase.failUnlessAlmostEqual(first, second[, places[, msg]])
TestCase.assertNotAlmostEqual(first, second[, places[, msg]])
TestCase.failIfAlmostEqual(first, second[, places[, msg]])
TestCase.assertRaises(exception, callable, ...)
TestCase.failUnlessRaises(exception, callable, ...)
TestCase.failIf(expr[, msg])
TestCase.assertFalse(expr[, msg])
TestCase.fail([msg])

4. 如何编写脚本自动运行android studio测试用例

测试用例是什么，测试用例其实就是一段普通的程序代码，通常是带有期望的运行结果的，测试者可以根据最终的运行结果来判断程序是否能正常工作。
单元测试是什么，单元测试是指对软件中最小的功能模块进行测试，如果软件的没一个单元都能通过测试，说明代码的健壮性已经非常好了。
在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();
}
}

然后右键这个文件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)
.....


可以看到期望是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目录下编写测试用例。

5. 什么是测试脚本！它和测试用例有什么关系

测试脚本是一段代码不假。但是这段代码可能是为了执行某一条，或很多条测试用例而写的。
也有可能 ，本身就是一条用例。

用例本身并不局限在基于功能。

脚本和用例没有并列的可比性。

脚本可能是用例，也可能是执行用例用的功能。用例也可能是脚本。明白了么