簡(jiǎn)介
1. 單元測(cè)試框架
幾乎所有的主流語(yǔ)言，都會(huì)有其對(duì)應(yīng)的單元測(cè)試框架,下面簡(jiǎn)單介紹一下python,java,C#三種語(yǔ)言的常見(jiàn)單元測(cè)試框架
1.1 Python
python常見(jiàn)單元測(cè)試框架包括unittest, pytest
1.1.1 unittest
- unittest單元測(cè)試框架不僅可以適用于單元測(cè)試，還可以適用WEB自動(dòng)化測(cè)試用例的開(kāi)發(fā)與執(zhí)行，該測(cè)試框架可組織執(zhí)行測(cè)試用例，并且提供了豐富的斷言方法，判斷測(cè)試用例是否通過(guò)，最終生成測(cè)試結(jié)果。
- unittest為python內(nèi)置庫(kù),不需要單獨(dú)安裝(好像也和版本有關(guān)系)
1.1.2 pytest
pytest是一個(gè)非常成熟的全功能的Python測(cè)試框架，主要有以下幾個(gè)特點(diǎn)：
- 簡(jiǎn)單靈活，容易上手
- 支持參數(shù)化
- 能夠支持簡(jiǎn)單的單元測(cè)試和復(fù)雜的功能測(cè)試，還可以用來(lái)做selenium/appnium等自動(dòng)化測(cè)試、接口自動(dòng)化測(cè)試（pytest+requests)
- pytest不是python內(nèi)置庫(kù),需要單獨(dú)安裝
1.1.3 unittest與pytest對(duì)比
- unittest提供了test cases、test suites、test fixtures、test runner相關(guān)的類,讓測(cè)試更加明確、方便、可控。使用unittest編寫用例,必須遵守以下規(guī)則:
（1）測(cè)試文件必須先import unittest
（2）測(cè)試類必須繼承unittest.TestCase
（3）測(cè)試方法必須以“test_”開(kāi)頭
（4）測(cè)試類必須要有unittest.main()方法
- pytest是python的第三方測(cè)試框架,是基于unittest的擴(kuò)展框架,比unittest更簡(jiǎn)潔,更高效。使用pytest編寫用例,必須遵守以下規(guī)則:
（1）測(cè)試文件名必須以“test_”開(kāi)頭或者"test"結(jié)尾(如:test_ab.py)
（2）測(cè)試方法必須以“test”開(kāi)頭。
（3）測(cè)試類命名以"Test"開(kāi)頭。
- unittest提供了setUp/tearDown，只能針對(duì)所有用例。
- pytest提供了模塊級(jí)、函數(shù)級(jí)、類級(jí)、方法級(jí)的setup/teardown，比unittest的setUp/tearDown更靈活。
模塊級(jí)（setup_module/teardown_module）開(kāi)始于模塊始末，全局的
函數(shù)級(jí)（setup_function/teardown_function）只對(duì)函數(shù)用例生效（不在類中）
類級(jí)（setup_class/teardown_class）只在類中前后運(yùn)行一次(在類中)
方法級(jí)（setup_method/teardown_method）開(kāi)始于方法始末（在類中）
類里面的（setup/teardown）運(yùn)行在調(diào)用方法的前后
- pytest還可以在函數(shù)前加@pytest.fixture()裝飾器，在測(cè)試用例中裝在fixture函數(shù)。fixture的使用范圍可以是function,module,class,session。
- fixture相對(duì)于setup和teardown來(lái)說(shuō)有以下幾點(diǎn)優(yōu)勢(shì)：
(1)命名方式靈活，不局限于setup和teardown這幾個(gè)命名
(2)conftest.py 配置里可以實(shí)現(xiàn)數(shù)據(jù)共享，不需要import就能自動(dòng)找到一些配置，可供多個(gè)py文件調(diào)用。
(3)scope="module" 可以實(shí)現(xiàn)多個(gè).py跨文件共享前置
(4)scope="session" 以實(shí)現(xiàn)多個(gè).py跨文件使用一個(gè)session來(lái)完成多個(gè)用例
(5)用yield來(lái)喚醒teardown的執(zhí)行
斷言方面:
unittest提供了assertEqual、assertIn、assertTrue、assertFalse.
pytest直接使用assert 表達(dá)式,相對(duì)而言更簡(jiǎn)單且高效.unittest不支持失敗重跑,pytest支持
unittest依賴ddt庫(kù)參數(shù)化，pytest直接使用@pytest.mark.parametrize裝飾器
pytest總的來(lái)說(shuō)優(yōu)于unittest,提供了更多的功能和可拓展性
1.2 Java
Java常見(jiàn)單元測(cè)試框架包括Junit、testNG
1.3 C#
C#常見(jiàn)單元測(cè)試框架包括NUnit
2. Web自動(dòng)化測(cè)試框架
2.1 Selenium
Selenium是一個(gè)用于Web應(yīng)用程序測(cè)試的工具。支持的瀏覽器包括IE、Mozilla Firefox、Mozilla Suite等。這個(gè)工具的主要功能包括：測(cè)試與瀏覽器的兼容性——測(cè)試你的應(yīng)用程序看是否能夠很好得工作在不同瀏覽器和操作系統(tǒng)之上。Selenium 是一套完整的web應(yīng)用程序測(cè)試系統(tǒng)，包含了測(cè)試的錄制（selenium IDE）,編寫及運(yùn)行（Selenium Remote Control）和測(cè)試的并行處理（Selenium Grid）。Selenium的核心Selenium Core基于JsUnit，完全由JavaScript編寫，因此可以用于任何支持JavaScript的瀏覽器上。Selenium可以模擬真實(shí)瀏覽器，自動(dòng)化測(cè)試工具，支持多種瀏覽器，爬蟲(chóng)中主要用來(lái)解決JavaScript渲染問(wèn)題。
selenium 1.0 包括以下兩部分：selenium server、 Client Libraries組成
2.1.1 selenium server
selenium server負(fù)責(zé)控制瀏覽器的行為。主要有l(wèi)auncher，Http Proxy，selenium core。selenium core使用Selenium Server嵌入到瀏覽器頁(yè)面中。實(shí)質(zhì)上，selenium core是由JS函數(shù)組成，這樣我們可以實(shí)現(xiàn)用程序?qū)g覽器進(jìn)行操作。
2.1.2 client Libraries
編寫測(cè)試用例時(shí)控制selenium server的庫(kù)
下圖介紹了testcase的執(zhí)行過(guò)程：
(1).測(cè)試案例（Testcase）通過(guò)Client Lib的接口向Selenium Server發(fā)送Http請(qǐng)求，要求和Selenium Server建立連接。
為什么要通過(guò)發(fā)送Http請(qǐng)求控制Selenium Server而不采用其他方式呢？從上文可以看出，Selenium Server是一個(gè)獨(dú)立的中間服務(wù)器（確切地說(shuō)是代理服務(wù)器），它可以架設(shè)在其他機(jī)器上！所以測(cè)試案例通過(guò)發(fā)送HTTP請(qǐng)求去控制Selenium Server是很正常的。
(2).Selenium Server的Launcher啟動(dòng)瀏覽器，把Selenium Core加載入瀏覽器頁(yè)面當(dāng)中，并把瀏覽器的代理設(shè)置為Selenium Server的Http Proxy。
(3).測(cè)試案例通過(guò)Client Lib的接口向Selenium Server發(fā)送Http請(qǐng)求，Selenium Server對(duì)請(qǐng)求進(jìn)行解析，然后通過(guò)Http Proxy發(fā)送JS命令通知Selenium Core執(zhí)行操作瀏覽器的動(dòng)作。
(4).Selenium Core接收到指令后，執(zhí)行操作。
(5).瀏覽器收到新的頁(yè)面請(qǐng)求信息（因?yàn)樵?4)中，Selenium Core的操作可能引發(fā)新的頁(yè)面請(qǐng)求），于是發(fā)送Http請(qǐng)求，請(qǐng)求新的<u style="box-sizing: border-box; font-family: __SYMBOL, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Helvetica, "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", SimSun, sans-serif; font-variant-ligatures: none; font-variant-numeric: tabular-nums; -webkit-tap-highlight-color: rgba(0, 0, 0, 0);">Web</u>頁(yè)面。
由于Selenium Server在啟動(dòng)瀏覽器時(shí)做了手腳，所以Selenium Server會(huì)接收到所有由它啟動(dòng)的瀏覽器發(fā)送的請(qǐng)求。
(6).Selenium Server接收到瀏覽器的發(fā)送的Http請(qǐng)求后，自己重組Http請(qǐng)求，獲取對(duì)應(yīng)的Web頁(yè)面。
(7).Selenium Server的Http Proxy把接收的Web頁(yè)面返回給瀏覽器。
2.2 Selenium2(Webdriver)
Selenium 2將瀏覽器原生的API封裝成WebDriver API，可以直接操作瀏覽器頁(yè)面里的元素，甚至操作瀏覽器本身（截屏，窗口大小，啟動(dòng)，關(guān)閉，安裝插件，配置證書之類的）,所以就像真正的用戶在操作一樣。
下圖介紹了Selenium2的架構(gòu):
webdriver按照server–client的經(jīng)典設(shè)計(jì)模式設(shè)計(jì)
server端就是remote server，可以是任意的瀏覽器：我們的腳本啟動(dòng)瀏覽器后，該瀏覽器就是remote server，它的職責(zé)就是等待client發(fā)送請(qǐng)求并做出相應(yīng)；
client端簡(jiǎn)單說(shuō)來(lái)就是我們的測(cè)試代碼：們測(cè)試代碼中的一些行為，比如打開(kāi)瀏覽器，轉(zhuǎn)跳到特定的url等操作是以http請(qǐng)求的方式發(fā)送給被server端（也就是被測(cè)瀏覽器）server接受請(qǐng)求，并執(zhí)行相應(yīng)操作，并在response中返回執(zhí)行狀態(tài)、返回值等信息；
the WebDriver Wire Protocol是Selenium自己設(shè)計(jì)定義的協(xié)議，這套協(xié)議非常之強(qiáng)大，幾乎可以操作瀏覽器做任何事情，包括打開(kāi)、關(guān)閉、最大化、最小化、元素定位、元素點(diǎn)擊、上傳文件等。
WebDriver Wire協(xié)議是通用的，也就是說(shuō)不管FirefoxDriver還是ChromeDriver，啟動(dòng)之后都會(huì)在某一個(gè)端口啟動(dòng)基于這套協(xié)議的Web Service,例如FirefoxDriver初始化成功，默認(rèn)從http://localhost:7055開(kāi)始，IE則是http://localhost:52432
webdriver的工作原理：
(1)啟動(dòng)瀏覽器后，selenium-webdriver會(huì)將目標(biāo)瀏覽器綁定到特定的端口，啟動(dòng)后的瀏覽器則作為webdriver的remote server。
(2)客戶端(也就是測(cè)試腳本)，借助ComandExecutor發(fā)送HTTP請(qǐng)求給sever端（通信協(xié)議：The WebDriver Wire Protocol，在HTTP request的body中，會(huì)以WebDriver Wire協(xié)議規(guī)定的JSON格式的字符串來(lái)告訴Selenium我們希望瀏覽器接下來(lái)做什么事情）。
(3)Sever端需要依賴原生的瀏覽器組件，轉(zhuǎn)化Web Service的命令為瀏覽器native的調(diào)用來(lái)完成操作。
3. iOS自動(dòng)化測(cè)試框架
3.1 XCTest
XCTest是蘋果在iOS 7和Xcode5引入的一個(gè)簡(jiǎn)單而強(qiáng)大的測(cè)試框架，它的測(cè)試編寫起來(lái)非常簡(jiǎn)單，并且遵循xUnit風(fēng)格。XCTest的優(yōu)點(diǎn)是與Xcode深度集成，有專門的Test導(dǎo)航欄，但因?yàn)槭芟抻诠俜綔y(cè)試API，因此功能不是很豐富。
3.2 UIAutomation
UIAutomation是蘋果提供的UI自動(dòng)化測(cè)試框架，使用Javascript編寫?；赨IAutomation有擴(kuò)展型的工具框架和驅(qū)動(dòng)型的框架。擴(kuò)展型框架以JavaScript擴(kuò)展庫(kù)方法提供了很多好用js工具，注入式的框架通常會(huì)提供一些Lib或者是Framework，要求測(cè)試人員在待測(cè)應(yīng)用的代碼工程中導(dǎo)入這些內(nèi)容，框架可以通過(guò)他們完成對(duì)app的驅(qū)動(dòng)。驅(qū)動(dòng)型UI Automation 在自動(dòng)化測(cè)試底層使用了UI Automation庫(kù)，通過(guò)TCP通信的方式驅(qū)動(dòng)UI Automation來(lái)完成自動(dòng)化測(cè)試，通過(guò)這種方式，編輯腳本的語(yǔ)言不再局限于JavaScript。
3.3 Frank
http://www.testingwithfrank.com/
Frank是iOS平臺(tái)一款非常受歡迎的app測(cè)試框架，它使用Cucumber語(yǔ)言來(lái)編寫測(cè)試用例， Frank包含一個(gè)強(qiáng)大的“app inspector”–Symbiote，可以用它來(lái)獲得運(yùn)行中app的詳細(xì)信息，便于開(kāi)發(fā)者將來(lái)進(jìn)行測(cè)試回顧。 它允許使用Cucumber編寫結(jié)構(gòu)化英語(yǔ)句子的測(cè)試場(chǎng)景。 Frank要求測(cè)試時(shí)在應(yīng)用程序內(nèi)部編譯，這意味著對(duì)源代碼的改變是強(qiáng)制性的。操作方式為使用Cucumber和JSON組合命令，將命令發(fā)送到在本地應(yīng)用程序內(nèi)部運(yùn)行的服務(wù)器上，并利用UISpec運(yùn)行命令。
**優(yōu)點(diǎn)： **測(cè)試場(chǎng)景是在Cucumber的幫助下，用可理解的英語(yǔ)句子寫的。強(qiáng)大的Symbiote實(shí)時(shí)檢查工具。 活躍的社區(qū)支持。 不斷擴(kuò)大中的庫(kù)。
缺點(diǎn)：對(duì)手勢(shì)的支持有限。 在設(shè)備上運(yùn)行測(cè)試有點(diǎn)難。 修改配置文件需要在實(shí)際設(shè)備上運(yùn)行。 記錄功能不可用。
3.4 KIF
http://www.oschina.net/translate/ios-ui-testing-with-kif
KIF是Keep It Functional項(xiàng)目的縮寫，是一款iOS app功能性測(cè)試框架，使用Objective-C語(yǔ)言編寫，對(duì)蘋果開(kāi)發(fā)者來(lái)說(shuō)非常容易上手，更是一款開(kāi)發(fā)者廣為推薦的測(cè)試工具。KIF tester使用私有API來(lái)了解App中的視圖層級(jí)。但缺點(diǎn)是運(yùn)行較慢。
3.5 Calabash-ios
詳見(jiàn)Calabash-android 描述。
3.6 Subliminal
http://inkling.github.io/Subliminal/
Subliminal是另一款與XCTest集成的框架。與KIF不同的是，它基于UIAutomation編寫，旨在對(duì)開(kāi)發(fā)者隱藏UIAutomation中一些復(fù)雜的細(xì)節(jié)。
3.7 Kiwi
https://github.com/kiwi-bdd/Kiwi/wiki/Getting-Started-with-Kiwi-2.0
Kiwi是對(duì)XCTest的一個(gè)完整替代，使用xSpec風(fēng)格編寫測(cè)試。 Kiwi帶有自己的一套工具集，包括expectations、mocks、stubs，甚至還支持異步測(cè)試。它是一個(gè)適用于iOS 開(kāi)發(fā)的Behavior Driven Development（BDD）庫(kù)，優(yōu)點(diǎn)在于其簡(jiǎn)潔的接口和可用性，易于設(shè)置和使用，非常適合新手開(kāi)發(fā)者。Kiwi使用Objective-C語(yǔ)言編寫，易于IOS開(kāi)發(fā)人員上手。
3.8 Appium
Appium是一個(gè)開(kāi)源的、跨平臺(tái)的自動(dòng)化測(cè)試工具，支持IOS、Android和FirefoxOS平臺(tái)。 通過(guò)Appium，開(kāi)發(fā)者無(wú)需重新編譯app或者做任何調(diào)整，就可以測(cè)試移動(dòng)應(yīng)用，可以使測(cè)試代碼訪問(wèn)后端API和數(shù)據(jù)庫(kù)。它是通過(guò)驅(qū)動(dòng)蘋果的UIAutomation和Android的UiAutomator框架來(lái)實(shí)現(xiàn)的雙平臺(tái)支持，同時(shí)綁定了Selenium WebDriver用于老的Android平臺(tái)測(cè)試。開(kāi)發(fā)者可以使用WebDriver兼容的任何語(yǔ)言編寫測(cè)試腳本，如Java， OC， JS， PHP，Python， Ruby， C#，Clojure 和Perl語(yǔ)言。
總結(jié):IOS自動(dòng)化測(cè)試框架繼承關(guān)系如下. XCTest與 Xcode 的 IDE 直接集成,使用簡(jiǎn)單, 但其不支持stub和mock, 所以單使用XCTest框架的較少. Kiwi是一個(gè)iOS平臺(tái)十分好用的行為驅(qū)動(dòng)開(kāi)發(fā)BDD的測(cè)試框架，有著非常漂亮的語(yǔ)法，可以寫出結(jié)構(gòu)性強(qiáng)，非常容易讀懂的測(cè)試。UI Automation是Apple官方提供的UI自動(dòng)化測(cè)試的解決方法,但接口不夠豐富。
KIF、Frank、Calabash都是通過(guò)使用代碼的形式來(lái)模擬事件觸發(fā)，使得被測(cè)代碼就像是由用戶行為所觸發(fā)的一樣。但這樣的代價(jià)是插入一個(gè)額外層的復(fù)雜度。
IOS測(cè)試框架中支持BDD的有calabash 和Kiwi。
可選用的單元測(cè)試框架有Kiwi，Specta，Quick等，而KIF，Subliminal和calabash更適用于UI級(jí)驗(yàn)收測(cè)試。
4. Android自動(dòng)化測(cè)試框架
4.1 Instrumentation
https://developer.android.com/reference/android/app/Instrumentation.html
Instrumentaion 是Android自帶的一個(gè)測(cè)試框架，是很多其它測(cè)試框架的基礎(chǔ)，可以在同進(jìn)程中加載被測(cè)組件。它有很多豐富的高層封裝，使用者可以使用基于instrumentation的其他框架，避免過(guò)多二次開(kāi)發(fā)量。但I(xiàn)nstrumentation不支持跨應(yīng)用，導(dǎo)致基于instrumentation的框架都繼承了這個(gè)缺點(diǎn)。
4.2 Robotium
https://github.com/robotiumtech/robotium
Robotium是基于Instrumentation框架開(kāi)發(fā)的一個(gè)更強(qiáng)的框架. 對(duì)常用的操作進(jìn)行了易用性的封裝. 用于開(kāi)發(fā)功能性、系統(tǒng)和驗(yàn)收測(cè)試場(chǎng)景。它運(yùn)行時(shí)綁定到GUI組件。它安裝了一個(gè)測(cè)試用例套件作為在Android設(shè)備或仿真器上的應(yīng)用程序，并提供用于執(zhí)行測(cè)試的真實(shí)環(huán)境。
優(yōu)點(diǎn)： 容易在最短的時(shí)間內(nèi)編寫測(cè)試腳本，易用性高。自動(dòng)跟隨當(dāng)前activity。 由于運(yùn)行時(shí)綁定到GUI組件，所以相比Appium，它的測(cè)試執(zhí)行更快，更強(qiáng)大。 不訪問(wèn)代碼或不了解app實(shí)現(xiàn)，也可以工作。 支持Activities、Dialogs、Toasts、Menus、Context Menus和其他Android SDK控件。
缺點(diǎn)： 不能處理flash和web組件。在舊設(shè)備上會(huì)變得很慢。 由于不支持iOS設(shè)備,當(dāng)自動(dòng)化測(cè)試同時(shí)覆蓋 android與iOS的情況時(shí)，測(cè)試會(huì)被中斷。沒(méi)有內(nèi)置的記錄和回放功能.，使用記錄功能需要 TestDroid 和 Robotium Recorder 這樣的收費(fèi)工具。
4.3 UIAutomator
https://google.github.io/android-testing-support-library/docs/uiautomator/
UIAutomator是由谷歌提供的測(cè)試框架，它提供了原生Android app和游戲的高級(jí)UI測(cè)試。這是一個(gè)包含API的Java庫(kù)，用來(lái)創(chuàng)建功能性UI測(cè)試，還有運(yùn)行測(cè)試的執(zhí)行引擎。該庫(kù)自帶Android SDK。
優(yōu)點(diǎn)：它在運(yùn)行訪問(wèn)不同的進(jìn)程時(shí)，會(huì)給JUnit測(cè)試案例特權(quán)。庫(kù)由谷歌社區(qū)支持和維護(hù)。
缺點(diǎn)：僅支持android4.1（API level 16）及以上。 不支持腳本記錄。 支持的重點(diǎn)是Java。 你不能獲得當(dāng)前活動(dòng)或儀表化。目前不支持web視圖。 庫(kù)僅支持使用Java，因此很難和使用Ruby的cucumber混合。如想支持BDD框架，建議使用Java自己的BDD框架，例如Jbehave。
4.4 Espresso
https://google.github.io/android-testing-support-library/docs/espresso/index.html
Espresso是Google的開(kāi)源自動(dòng)化測(cè)試框架。相對(duì)于Robotium和UIAutomator，它的特點(diǎn)是規(guī)模更小、更簡(jiǎn)潔、API更加精確、編寫測(cè)試代碼簡(jiǎn)單、容易快速上手。因?yàn)槭腔贗nstrumentation的，所以不能跨App。
4.5 Calabash
Calabash是一個(gè)適用于iOS和Android開(kāi)發(fā)者的跨平臺(tái)app測(cè)試框架，可用來(lái)測(cè)試屏幕截圖、手勢(shì)和實(shí)際功能代碼。Calabash開(kāi)源免費(fèi)并支持Cucumber語(yǔ)言，Cucumber能讓你用自然的英語(yǔ)語(yǔ)言表述app的行為，實(shí)現(xiàn)BDD（Behavior Driven Development，行為驅(qū)動(dòng)開(kāi)發(fā)）。 Cucumber中的所有語(yǔ)句使用Ruby定義。
**優(yōu)點(diǎn)： **有大型社區(qū)支持。列表項(xiàng) 簡(jiǎn)單，類似英語(yǔ)表述的測(cè)試語(yǔ)句支持在屏幕上的所有動(dòng)作，如滑動(dòng)，縮放，旋轉(zhuǎn)，敲擊等。 跨平臺(tái)開(kāi)發(fā)支持（同樣的代碼在Android和iOS設(shè)備中都適用）。
缺點(diǎn)：測(cè)試步驟失敗后，將跳過(guò)所有的后續(xù)步驟，這可能會(huì)導(dǎo)致錯(cuò)過(guò)更嚴(yán)重的產(chǎn)品問(wèn)題。測(cè)試耗費(fèi)時(shí)間，因?yàn)樗偸悄J(rèn)先安裝app。 需要Calabash框架安裝在ios的ipa文件中， 因此測(cè)試人員必須要有iOS的app源碼。 除了Ruby，對(duì)其他語(yǔ)言不友好。
4.6 Appium
Appium是一個(gè)開(kāi)源的、跨平臺(tái)的自動(dòng)化測(cè)試工具，支持IOS、Android和FirefoxOS平臺(tái)。 通過(guò)Appium，開(kāi)發(fā)者無(wú)需重新編譯app或者做任何調(diào)整，就可以測(cè)試移動(dòng)應(yīng)用，可以使測(cè)試代碼訪問(wèn)后端API和數(shù)據(jù)庫(kù)。它是通過(guò)驅(qū)動(dòng)蘋果的UIAutomation和Android的UiAutomator框架來(lái)實(shí)現(xiàn)的雙平臺(tái)支持，同時(shí)綁定了Selenium WebDriver用于老的Android平臺(tái)測(cè)試。開(kāi)發(fā)者可以使用WebDriver兼容的任何語(yǔ)言編寫測(cè)試腳本，如Java， OC， JS， PHP，Python， Ruby， C#，Clojure 和Perl語(yǔ)言。
4.7 Selendroid
https://www.gitbook.com/book/lihuazhang/selendroid/details
Selendroid 是一個(gè)基于Instrumentation的一個(gè)框架. 完全兼容Webdriver協(xié)議。 Selendroid 可以在模擬器和實(shí)際設(shè)備上使用，也可以集成網(wǎng)格節(jié)點(diǎn)作為縮放和并行測(cè)試。
4.8 Robolectric
Robolectric 是一款A(yù)ndroid單元測(cè)試框架，但它并不依賴于Android提供的測(cè)試功能，它通過(guò)實(shí)現(xiàn)一套JVM能運(yùn)行的Android代碼，然后在unit test運(yùn)行的時(shí)候去截取android相關(guān)的代碼調(diào)用，然后轉(zhuǎn)到Robolectric實(shí)現(xiàn)的代碼（shadow objects）去執(zhí)行這個(gè)調(diào)用的過(guò)程。因此它不像模擬器或設(shè)備需要dexing（Android dex編譯器將類文件編譯成Android設(shè)備上的Dalvik VM使用的格式）、打包、部署和運(yùn)行的過(guò)程，大大減少了測(cè)試執(zhí)行的時(shí)間。Pivotal實(shí)驗(yàn)室聲稱使用Robolectric可以在28秒內(nèi)運(yùn)行1047個(gè)測(cè)試。
除了實(shí)現(xiàn)Android里面的類的現(xiàn)有接口，Robolectric還給每個(gè)Shadow類額外增加了很多接口，可以讀取對(duì)應(yīng)的Android類的一些狀態(tài)。比如它為ImageView提供了getImageResourceId()方法，測(cè)試者可以通過(guò)getImageResourceId()接口來(lái)確定是不是正確顯示了期望的Image。
4.9 RoboSpock
RoboSpock是一個(gè)開(kāi)源的Android測(cè)試框架，它提供了簡(jiǎn)單的編寫B(tài)DD行為驅(qū)動(dòng)開(kāi)發(fā)規(guī)范的方法，使用Groovy語(yǔ)言，支持Google Guice庫(kù)。RoboSpock合并了Robolectic和Spock的功能。
4.10 Cafe
Cafe是百度出品的一個(gè)基于Robotium的測(cè)試框架，它提供了跨進(jìn)程的測(cè)試解決方案。
4.11 Athrun
http://code.taobao.org/p/athrun/wiki/index/
Athrun 是taobao出的一個(gè)移動(dòng)測(cè)試框架，它支持Android和IOS。Android部分是基于Instrumentation，在Android原有的ActivityInstrumentationTestCase2類基礎(chǔ)上進(jìn)行了擴(kuò)展，提供了一整套面向?qū)ο蟮腁PI。 IOS上的自動(dòng)化測(cè)試包括注入式自動(dòng)化框架AppFramework，和基于錄制的自動(dòng)化框架Athrun_IOS, InstrumentDriver。
4.12 其他
其他自動(dòng)化框架還有應(yīng)用于穩(wěn)定性測(cè)試的Monkey系列（Monkey, Monkeyrunner, MonkeyTalk）, 其中MonkeyTalk 支持iOS 和 Android，它可以為應(yīng)用進(jìn)行真實(shí)的，功能性交互測(cè)試。MonkeyTalk 提供簡(jiǎn)單的 “smoke tests”，復(fù)雜數(shù)據(jù)驅(qū)動(dòng)的測(cè)試套件。MonkeyTalk 支持原生，移動(dòng)和混合應(yīng)用，真實(shí)設(shè)備或者模擬器。MonkeyTalk 使得場(chǎng)景捕獲非常容易，可以記錄高級(jí)別，可讀的測(cè)試腳本。還有適用于瀏覽器自動(dòng)測(cè)試的Selenium WebDriver，可以真實(shí)測(cè)試用戶行為，用戶交互如觸摸、手指滾動(dòng)、長(zhǎng)按等，還支持HTML5的一些特性，比如本地存儲(chǔ)、session存儲(chǔ)、應(yīng)用緩存等。而CTS則是應(yīng)用于兼容性測(cè)試的自動(dòng)化工具， CTS大部分是基于Junit和儀表盤技術(shù)編寫的。還擴(kuò)展了自動(dòng)化測(cè)試過(guò)程，可以自動(dòng)執(zhí)行用例，自動(dòng)收集和匯總測(cè)試結(jié)果。CTS采用XML配置文件的方式將這些測(cè)試用例分組成多個(gè)測(cè)試計(jì)劃（plan）,第三方也可以創(chuàng)建自己的plan。
總結(jié):
各個(gè)測(cè)試框架的繼承關(guān)系如下,繼承關(guān)系決定了有些框架的先天優(yōu)勢(shì)或先天不足. 在實(shí)際應(yīng)用中可以集成多個(gè)框架。
基于Instrumentation的測(cè)試框架，比如Espresso，Robotium，Selendroid等，都不能支持跨APP使用。 如自動(dòng)化測(cè)試中有跨APP操作，可以結(jié)合UiAutomator實(shí)現(xiàn)。
支持BDD的自動(dòng)化框架比較少，可以在calabash 和 RoboSpock及Jbehave之間選擇。
若想同時(shí)支持Android和IOS，可選框架有Appium和Calabash，或AthRun。
若為單元測(cè)試選擇框架，可選Instrumentation或Robolectric。Robolectric實(shí)現(xiàn)了shadow object 類，耗時(shí)短。
