用例腳本

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. 什麼是測試腳本！它和測試用例有什麼關系

測試腳本是一段代碼不假。但是這段代碼可能是為了執行某一條，或很多條測試用例而寫的。
也有可能 ，本身就是一條用例。

用例本身並不局限在基於功能。

腳本和用例沒有並列的可比性。

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