what-接口是什么？

在計(jì)算機(jī)中，接口是計(jì)算機(jī)系統(tǒng)中兩個(gè)獨(dú)立的部件進(jìn)行信息交換的共享邊界。
舉個(gè)例子，我提供加法的計(jì)算接口，你給我兩個(gè)數(shù)，我就給你返回一個(gè)和。

what-什么是接口測試？

狹義的接口測試指的是對接口進(jìn)行測試，上個(gè)例子中測試的是不同輸入?yún)?shù)時(shí)，我加法的返回是否正確。一般講的接口測試是這種。

廣義的接口測試包含接口提供方、接口調(diào)用方的測試。
比如，你調(diào)用我的接口執(zhí)行加法，我返回錯誤的響應(yīng)，或者我響應(yīng)超時(shí)，這時(shí)你的處理是否正確。

為什么要做接口測試？

一般做接口測試有如下原因：

• 接口是獲取和操作資源的方式，接口大部分內(nèi)容都是數(shù)據(jù)，通過數(shù)據(jù)對比我們可以推測到系統(tǒng)的邏輯，測接口其實(shí)也就是測邏輯。

• 接口測試相對容易實(shí)現(xiàn)自動化，也容易實(shí)現(xiàn)持續(xù)集成，且相對UI自動化也比較穩(wěn)定，可以減少人工回歸測試人力成本與時(shí)間，縮短測試周期，支持后端快速發(fā)版需求。

How-怎么做接口測試？

接口測試實(shí)際上是黑盒測試（功能測試）

作為黑盒測試，基本的測試思路是通過輸入和輸出判斷被測系統(tǒng)或者對象的邏輯

做接口自動化有什么好處？

做接口自動化是為了節(jié)省人力成本而不是為了找bug。

減輕自己工作量

• 把測試從枯燥的重復(fù)勞動中解放出來，

例如：回歸測試等；

• 協(xié)助手工測試完成很難模擬或無法模擬的的工作，

例如：篡改服務(wù)返回的數(shù)據(jù)驗(yàn)證前端對各種數(shù)據(jù)場景的處理，弱網(wǎng)模擬、特殊協(xié)議數(shù)據(jù)包解析驗(yàn)證等；

• 盡早發(fā)現(xiàn)Bug，

例如：數(shù)據(jù)層的存儲過程、Package批量調(diào)用驗(yàn)證、接口自動化等偏底層的問題；

• 協(xié)助定位問題，現(xiàn)在的自動化提出了更高的要求，

例如：接口層發(fā)現(xiàn)問題了，可以通過添加的traceID定位到日志錯誤或錯誤代碼行，

• 線上監(jiān)控報(bào)警，現(xiàn)在的自動化不僅限于線下，線上的也已覆蓋，

例如，測試和運(yùn)維的工作可能存在交集，我們不能把質(zhì)量問題寄托于他人，一旦發(fā)現(xiàn)問題，立即報(bào)警通知到人，讓損失到最小。

• 提高工作效率，

例如，測試環(huán)境的自動化編譯、打包、部署、持續(xù)集成甚至持續(xù)交付等。

關(guān)于自動化介入的若干問題

是否要考慮成本？ 當(dāng)然要考慮，我們總會遇到在成本和質(zhì)量之間找平衡點(diǎn)，可能一些特殊的行業(yè)，特殊的項(xiàng)目，質(zhì)量的權(quán)重更高點(diǎn)，如果引入自動化能提高質(zhì)量，該介入的還是要介入。

是不是只有大公司能做， 小公司和初創(chuàng)公司就不適合搞自動化？這不是絕對的，還是要看公司的資源和人員配備，如果有能力做為什么不？況且小公司的自動化不一定要做到大公司的程度，只要能提高工作效率，提高質(zhì)量就可以，滴水穿石，聚沙成塔。

自動化何時(shí)介入？ 條件許可的還是盡早介入，越是底層的Bug，影響面越廣，修復(fù)成本也是最低的。但這不是硬性標(biāo)準(zhǔn)，一般公司都是從接口自動化開始積累經(jīng)驗(yàn)的，拔苗不能助長。

如何開展自動化工作

抓住業(yè)務(wù)測試工作中的痛點(diǎn)和領(lǐng)導(dǎo)的痛點(diǎn)，多溝通多交流，優(yōu)先解決基層的工作痛點(diǎn)，

技術(shù)選型和方案可行性調(diào)研，多投入時(shí)間和精力，有的人性子急，前期做的很快，如果一開始的方向錯了，最終會得不償失；
如果是比較復(fù)雜的解決方案，盡量前后端分離、保證各模塊的獨(dú)立性、可融合性、解耦不解體，做到靈活可擴(kuò)展。

接口自動化需要的功能

1、校驗(yàn)（斷言）
這個(gè)很好了解，如果沒有校驗(yàn)，單純的執(zhí)行接口的話，那就談不上測試了。所以支持對返回值校驗(yàn)是一個(gè)必須的功能。

2、數(shù)據(jù)隔離
數(shù)據(jù)隔離就是指具體的請求接口、參數(shù)、校驗(yàn)等數(shù)據(jù)做到與代碼相隔離，便于維護(hù)，一旦需要調(diào)整接口用例、新增接口用例時(shí)可很快速的找到位置，隔離的另一個(gè)好處就是可復(fù)用，框架可以推廣給其他團(tuán)隊(duì)，使用者可以使用相同的代碼，只需要根據(jù)要求填寫各自用例即可測試起來。

3、數(shù)據(jù)傳遞
做到數(shù)據(jù)隔離可維護(hù)后，數(shù)據(jù)傳遞是另外一個(gè)更重要的需求。
數(shù)據(jù)傳遞是指接口用例之間可以做到向下傳參，例如我們通過創(chuàng)建訂單接口創(chuàng)建一個(gè)訂單，該接口會返回一個(gè)訂單號，接下來我們要進(jìn)行調(diào)用查詢訂單的接口，從返回的數(shù)據(jù)中與創(chuàng)建訂單用例中的數(shù)據(jù)進(jìn)行校驗(yàn)，此時(shí)第二個(gè)接口的請求數(shù)據(jù)是需要從第一個(gè)接口用例中的返回中提取的。這樣的例子比比皆是，所以支持?jǐn)?shù)據(jù)傳遞是又一個(gè)必不可少的功能。

4、動態(tài)函數(shù)
實(shí)際用例場景中我們可能會有隨機(jī)生成一個(gè)手機(jī)號、字符串加密等需求，在數(shù)據(jù)與代碼隔離之后，此時(shí)我們就需要代碼可以支持做到識別對應(yīng)關(guān)鍵字時(shí)可以執(zhí)行對應(yīng)的函數(shù)進(jìn)行填充。例如在數(shù)據(jù)中填寫phone()時(shí)，具體執(zhí)行時(shí)會被替換成137XXXXXXXX，填寫random(5)時(shí)，會被替換成一個(gè)五位的隨機(jī)數(shù)。等等。

5、可配置
有時(shí)，我們的需求是用例不單單只能在一個(gè)環(huán)境上執(zhí)行，可能需要同一份接口用例可以在QA、預(yù)發(fā)、線上等多個(gè)環(huán)境都可以執(zhí)行。所以框架需要做到可配置，便于切換，調(diào)用不同的配置文件可以在不同的環(huán)境執(zhí)行。

6、日志
日志包含執(zhí)行的具體執(zhí)行接口、請求方式、請求參數(shù)、返回值、校驗(yàn)接口、請求時(shí)間、耗時(shí)等關(guān)鍵信息，日志的好處一來是可以便于在新增用例有問題時(shí)快速定位出哪里填寫有問題，二來是發(fā)現(xiàn)bug時(shí)方便向開發(fā)反饋提供數(shù)據(jù)，開發(fā)可以從觸發(fā)時(shí)間以及參數(shù)等信息快速定位到問題所在。

7、可視化報(bào)告
用例執(zhí)行后，就是到了向團(tuán)隊(duì)展示結(jié)果的時(shí)候了，一個(gè)可視化的報(bào)告可以便于團(tuán)隊(duì)成員了解到每次自動化接口用例執(zhí)行的成功數(shù)、失敗數(shù)等數(shù)據(jù)。

測試工具（框架）脫離業(yè)務(wù)使用場景都是耍流氓！所以我們不妨先來看下日常工作中的一些常見場景。

• 測試或開發(fā)人員在定位問題的時(shí)候，想調(diào)用某個(gè)接口查看其是否響應(yīng)正常；（斷言）

• 測試人員在手工測試某個(gè)功能點(diǎn)的時(shí)候，需要一個(gè)訂單號，而這個(gè)訂單號可以通過順序調(diào)用多個(gè)接口實(shí)現(xiàn)下單流程；（數(shù)據(jù)傳遞）

• 測試人員在開始版本功能測試之前，可以先檢測下系統(tǒng)的所有接口是否工作正常，確保接口正常后再開始手工測試；（回歸）

• 開發(fā)人員在提交代碼前需要檢測下新代碼是否對系統(tǒng)的已有接口產(chǎn)生影響；（兼容性）

• 項(xiàng)目組需要每天定時(shí)檢測下測試環(huán)境所有接口的工作情況，確保當(dāng)天的提交代碼沒有對主干分支的代碼造成破壞；（持續(xù)集成）

• 項(xiàng)目組需要定時(shí)（30分鐘）檢測下生產(chǎn)環(huán)境所有接口的工作情況，以便及時(shí)發(fā)現(xiàn)生產(chǎn)環(huán)境服務(wù)不可用的情況；（自動化監(jiān)控）

• 項(xiàng)目組需要不定期對核心業(yè)務(wù)場景進(jìn)行性能測試，期望能減少人力投入，直接復(fù)用接口測試中的工作成果。（可持續(xù)性）

流程

接口測試的根源就是從接口文檔開始的，接口文檔中的參數(shù)貫穿了整個(gè)接口測試測生命周期。

API接口在設(shè)計(jì)時(shí)往往需要編寫大量的文檔，而且編寫完成之后還會經(jīng)常改動，文檔編寫維護(hù)工作量大。接口文檔編寫好后，實(shí)際的代碼可能會與文檔有出入，這個(gè)時(shí)候文檔是不準(zhǔn)確的，文檔與代碼保持修改同步也是一個(gè)很大的工作量。隨著接口版本的迭代，接口文檔需要同步更新，所以很多開發(fā)甚至都不去編寫接口文檔，項(xiàng)目小還好辦，當(dāng)項(xiàng)目大了，需要對接的地方多了，就會很麻煩。特別是接口數(shù)量多，參數(shù)復(fù)雜的情況，測試工作量大。接口在版本迭代后，舊的接口常常需要做回歸測試，這個(gè)工作量也是非常大的。

解決思路

API接口管理系統(tǒng)化或平臺化，可以直接在可視化API管理界面上方便的維護(hù)接口。而且最好有版本管理和權(quán)限管理?？梢暬S護(hù)好的接口可以直接生成對應(yīng)語言的代碼，節(jié)省代碼開發(fā)量。

代碼有變更時(shí)，最好還可以與界面上的接口進(jìn)行同步。API界面能夠提供模擬接口實(shí)現(xiàn)方的調(diào)用功能，這樣就能解耦接口調(diào)用方與服務(wù)方的強(qiáng)進(jìn)度依賴，可以先按API接口的消費(fèi)方基于接口管理系統(tǒng)或平臺模擬調(diào)用，待服務(wù)方準(zhǔn)備好后再真實(shí)調(diào)用（mock）。而且這里的模擬最好能做到自定義規(guī)則的模擬返回。接口實(shí)際開發(fā)完成后，可以根據(jù)接口管理系統(tǒng)或平臺的可視化測試界面，直接進(jìn)行接口的實(shí)際調(diào)用測試。

附加點(diǎn)：接口平臺能夠支持自動化測試，可以自定義測試案例，然后自動化測試并生成可視化報(bào)告。這個(gè)功能在舊版本接口復(fù)測時(shí)非常有用。

國內(nèi)解決方案

EasyAPI

這是一家國內(nèi)的在線API管理平臺，提供API管理、API測試、API監(jiān)控、API文檔管理的綜合性API服務(wù)。在前面提到的解決思路上額外還提供了API監(jiān)控的功能。另外平臺在一定使用人數(shù)下提供免費(fèi)服務(wù)。

eoLinker

這是一家國內(nèi)的在線API管理平臺，同時(shí)也提供開源精簡版本。該平臺提供的功能非常全面，除了代碼生成與同步這個(gè)功能外，基本涵蓋了前面提到的解決思路中的所有功能。

DOClever

這是國內(nèi)一家在線API接口管理平臺,完全開源免費(fèi)；該平臺的功能十分全面，也十分完善；擁有根據(jù)業(yè)務(wù)場景進(jìn)行接口自動化測試、API管理、API文檔管理、團(tuán)隊(duì)協(xié)作、版本快照與回滾、Mock無縫對接、狀態(tài)碼管理等；可以說是現(xiàn)階段國內(nèi)接口管理平臺中功能做的最好最完善的一家；產(chǎn)品更新迭代比較頻繁

RAP

這是阿里巴巴公司的團(tuán)隊(duì)做的一個(gè)開源的API管理系統(tǒng)，功能也還比較全面。除了沒有代碼生成與同步、自動化測試、狀態(tài)碼管理功能，解決思路中提到的功能基本都有。
RAP的應(yīng)用范圍非常明確，是一個(gè)面向開發(fā)人員自測和聯(lián)調(diào)的工具性平臺，它更適合以開發(fā)為核心對接口進(jìn)行維護(hù)，但目前基本不在維護(hù)

CrapApi

這是國內(nèi)的一個(gè)開源的API管理系統(tǒng)，提供了文檔管理、項(xiàng)目/組織管理相關(guān)的功能，在測試管理與代碼管理這塊是缺失的。

國外解決方案

SwaggerHub

這是國外的一個(gè)非常有名的基于Swagger的一個(gè)在線平臺，提供了API全生命周期管理的工具集，基本涵蓋了解決思路中提到的全部功能。Swagger是一個(gè)開源的設(shè)計(jì)與描述Rest API的框架，它有自定義的接口規(guī)范和很多非常實(shí)用的工具集，比如Swagger Editor可以用來設(shè)計(jì)接口，Swagger Codegen可以用來生成代碼和測試樁，Swagger UI可以用來生成可視化接口文檔等。

Swagger更多的是用在開發(fā)的層面上，Swagger的學(xué)習(xí)和接入成本相對較高，需要開發(fā)與測試的深入配合

Apiary

這是Oracle公司收購的一家API管理的公司，也是一個(gè)在線的API管理平臺，除了代碼生成功能，基本提供了解決思路中提到的所有功能。它有自己定義的接口描述語言API Blueprint。
這個(gè)也是一個(gè)基于Swagger的在線API管理平臺，可以做接口管理、接口模擬測試。整體的功能相對比較簡單。

從設(shè)計(jì)上來說，國外的Swagger和apiary都有統(tǒng)一的開源接口規(guī)范，這樣就有了搭建生態(tài)的前提，然后創(chuàng)建對應(yīng)的工具集就會非常實(shí)用有效。這里相比而言Swagger的生態(tài)又更加成熟些。

從功能完備度或商業(yè)化程度上來說，國內(nèi)的EasyAPI、eoLinker、DOClever、RAP，國外的Swagger、apiary都還不錯；

其中以DOClever、Swagger最為突出。綜合比較下來，
Swagger是在API管理這方面做得最好的，商用的話eoLinker和EasyAPI都可以考慮，如果考慮到成本或者需要開源的系統(tǒng)，那DOClever系統(tǒng)不錯。當(dāng)然實(shí)際需求不同公司是千差萬別的，最適合的才是最好的，至于哪個(gè)更適合就需要自己根據(jù)實(shí)際情況去比較了

API測試的工具

Postman

有Mac, Windows, Linux, and Chrome 各平臺對應(yīng)的軟件，可以支持API接口的記錄和測試。另外也支持接口的文檔化與監(jiān)控。

Soapui

自稱是最好的REST & SOAP 測試工具，跟Swagger一樣都是smartbear這個(gè)公司做的產(chǎn)品?？梢灾С肿鼋涌诘墓δ軠y試、壓力測試、安全測試、模擬測試。-------商業(yè)收費(fèi)

還有就是開發(fā)自己的debug接口

接口自動化框架

讓“自動化”代替“手動”

在我看來，初期的自動化測試，目標(biāo)很明確，就是要讓“自動化”代替“手動”，讓自動化真正地跑起來，凡是“自動化”跑過的內(nèi)容，盡量不要用手工重復(fù)執(zhí)行一遍。這樣至少有一個(gè)很明確的收益：每完成一條自動化用例，就減少了一條手工用例的執(zhí)行時(shí)間。

必須要提醒的是，讓“自動化”完全替代“手動”，其實(shí)對自動化用例的穩(wěn)定性、容錯都有一定的要求。需要花一定時(shí)間去思考用例執(zhí)行過程中的異常場景，是否足以充分替代手工測試。

讓“回歸”自動化

讓每次回歸或上線驗(yàn)證“不得不”執(zhí)行的用例優(yōu)先自動化進(jìn)行收益最大化。如果完成了回歸用例集的全部自動化，就可以用它來替代版本的日?；貧w，和上線回歸工作，極大地釋放手工驗(yàn)證時(shí)間。

我們的調(diào)度項(xiàng)目其實(shí)是一個(gè)對系統(tǒng)穩(wěn)定性的要求比較高的后臺項(xiàng)目，所以它的核心功能是比較固定的，核心功能聚合、對系統(tǒng)的穩(wěn)定性要求高。這就需要保障系統(tǒng)的核心功能完善。所以我們可以先將“核心功能”的驗(yàn)證完成自動化。

讓“自動化”持續(xù)進(jìn)行

自動化是一個(gè)持續(xù)的過程，我們會不斷的加入新的用例來完善自動化的過程，所以，發(fā)展了持續(xù)集成CI，通過對自動化的持續(xù)集成，我們也可以對自動化過程的質(zhì)量進(jìn)行監(jiān)控。

持續(xù)集成的優(yōu)點(diǎn)

• “快速失敗”，在對產(chǎn)品沒有風(fēng)險(xiǎn)的情況下進(jìn)行測試，并快速響應(yīng)；
• 最大限度地減少風(fēng)險(xiǎn)，降低修復(fù)錯誤代碼的成本；
• 將重復(fù)性的手工流程自動化，
• 保持頻繁部署，快速生成可部署的軟件；
• 提高項(xiàng)目的能見度，方便團(tuán)隊(duì)成員了解項(xiàng)目的進(jìn)度和成熟度；
• 增強(qiáng)開發(fā)人員對軟件產(chǎn)品的信心，幫助建立更好的工程師文化。

使用自部署CI（Jenkins）能對構(gòu)建環(huán)境有完全的控制權(quán)，夠得到完全的定制性，使得效率最高，但需要花費(fèi)很多的精力來搭建環(huán)境和配置，尤其是當(dāng)規(guī)模變大了之后，想要優(yōu)化資源的配置，需要花費(fèi)更大的精力。

使用云CI（阿里云持續(xù)交付平臺CRP），在基本上不用自己去配置相應(yīng)的環(huán)境------商業(yè)軟件，它就可以能夠滿足大多數(shù)場景的需求，但是對構(gòu)建環(huán)境缺乏控制權(quán)，構(gòu)建環(huán)境也非完全定制化的，所以很難保證效率最高。

技術(shù)選型

在明確了目標(biāo)后，要開始技術(shù)選型。常見的自動化測試類型，包括

接口自動化

UI自動化

基于shell交互命令執(zhí)行的自動化

此外，不屬于測試范疇，但是也可以實(shí)現(xiàn)自動化、釋放手工時(shí)間的還有
1.數(shù)據(jù)準(zhǔn)備自動化
2.環(huán)境編譯、部署、打包自動化
3.穩(wěn)定性測試/性能測試結(jié)果指標(biāo)獲取、校驗(yàn)自動化
4.機(jī)器資源監(jiān)控、報(bào)警自動化
5.其它所有手工重復(fù)執(zhí)行的操作

在開始自動化之前，首先要分析項(xiàng)目的架構(gòu)和狀況。對于一個(gè)后端的服務(wù)，它如果是純粹以接口的形式提供給其它組件去調(diào)用，那可以采取“接口自動化”；對于一個(gè)Web產(chǎn)品，如果前后端都在測試的保障范圍，而且前端頁面相對比較穩(wěn)定，可以考慮采用“UI自動化”（此時(shí)接口自動化其實(shí)已經(jīng)不足以保障產(chǎn)品的端到端功能）；對于更后端的組件，如果想測試組件自身的基礎(chǔ)核心功能，可以采用“基于shell交互命令執(zhí)行的自動化”，通過自動化腳本的方式封裝shell命令的調(diào)用。

此外，還需要對編程語言的選擇，是用Java還是Python還是Shell，或者其它語言等等。這個(gè)我覺得其實(shí)沒有定論，可以根據(jù)自己對語言的偏好和熟練程度，但是必須要考慮團(tuán)隊(duì)成員的普遍技術(shù)棧，因?yàn)楹笃诳赡芷渌藖斫邮诌@個(gè)項(xiàng)目時(shí)需要代替你去維護(hù)測試工程。通常來說，測試框架的選擇（不管是接口自動化、UI自動化）推薦使用Java的TestNG框架；對于簡單的基于命令行執(zhí)行的自動化腳本的編寫推薦使用Shell（Shell非常地強(qiáng)大）；對于稍復(fù)雜的一些自動化的腳本的編寫，推薦使用Python，在Python中可以非常方便地封裝Shell命令，同時(shí)Python區(qū)別于Shell的一個(gè)特性就是它支持面向?qū)ο蟮姆庋b，可以將一些對象封裝在特定的類中，增加程序的可讀性和健壯性。

編寫代碼的方式：

優(yōu)點(diǎn)：提升自己的編碼能力，問題定位能力，具備更高的靈活性和可操作性。
缺點(diǎn)：結(jié)果展示不直觀，不易于協(xié)作。其他人維護(hù)代碼困難，難以推動開發(fā)執(zhí)行。

接口平臺的方式：

優(yōu)點(diǎn)：簡便，上手容易，可以在項(xiàng)目組間很好的協(xié)作和維護(hù)，測試記錄和結(jié)果一目了然。
缺點(diǎn)：離開了平臺，可能又要回歸手動。

建議使用接口平臺加編寫代碼的模式來實(shí)現(xiàn)接口自動化

對于測試人員而言，如果有精力和時(shí)間的話，我建議是兩種都要掌握，甚至是自己去開發(fā)接口測試平臺的能力。

分割線------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Jmeter+Ant/Mavan+Jenkins

jmeter工具特征，jmeter是以線程請求為單位，不是以腳本或測試用例為單位，既然這樣，就可以每次循環(huán)獲取接口或?qū)?yīng)數(shù)據(jù)進(jìn)行測試了，
而且jmeter有可視化界面，我們只需要調(diào)用它的邏輯處理器，基本上可以幫助我們解決大部分問題。jmeter是由java開發(fā)并且開源的，我們可以根據(jù)自身情況對jmeter的函數(shù)做定制，和二次開發(fā)。

參考：https://testerhome.com/topics/10160

image.png

Robotframwork+Requests+Jenkins

Robotframwork在業(yè)界也算是大名鼎鼎了，是一款通用型自動化框架，也被稱為關(guān)鍵字框架，主要使用就是在于封裝關(guān)鍵字，然后進(jìn)行調(diào)用，

Robotframwork是使用Python來開發(fā)的，對測試的學(xué)習(xí)來說是非常友好的。使用Robotframwork來進(jìn)行接口自動化的話，主要是通過Python的一個(gè)庫Requests，來對接口進(jìn)行請求，當(dāng)然，我也可以對它進(jìn)行二次開發(fā)，封裝我們自己需要的關(guān)鍵字。

參考：https://testerhome.com/topics/5596

TestNG+Ant/Maven+Jenkins

TestNG是一個(gè)設(shè)計(jì)用來簡化廣泛的測試需求的測試框架，從單元測試（隔離測試一個(gè)類）到集成測試（測試由有多個(gè)類多個(gè)包甚至多個(gè)外部框架組成的整個(gè)系統(tǒng)，會用在開發(fā)的單元測試比較多，主要寫的話是使用XML格式把用例關(guān)聯(lián)起來，需要比較深入了解代碼，

Hitchhiker

Hitchhiker 是一款開源的 Restful Api 測試工具，支持Schedule, 數(shù)據(jù)對比，壓力測試，支持上傳腳本定制請求，可以輕松部署到本地，和你的team成員一起管理Api

功能

• Team協(xié)作開發(fā)Api
• Api歷史修改記錄及diff
• 基于UI的斷言
• 支持多環(huán)境變量及運(yùn)行時(shí)變量，可以處理Api依賴問題
• 超強(qiáng)腳本，支持require，可以上傳JS包，讀excel，加解密，
• 參數(shù)化請求，把query/body里的變化點(diǎn)提取出來，構(gòu)建出參數(shù)列表，極大減少request的數(shù)量
• 支持Schedule及批量run
• 不同環(huán)境下的請求數(shù)據(jù)對比 (eg: stage vs product)
• 支持在數(shù)據(jù)對比前對數(shù)據(jù)進(jìn)行處理
• 易部署 (支持 docker, windows, linux), 數(shù)據(jù)都存在自己這里，不會-
  上傳及丟失
• 會記往任何修改，不用怕沒保存時(shí)session失效或系統(tǒng)重啟
• 支持導(dǎo)入Postman v1 collections
• 分布式壓力測試
• 自動同步Team成員的Collection數(shù)據(jù)
• Api文檔 (計(jì)劃中...)

參考：http://doc.hitchhiker-api.com/cn/

HttpRunner

HttpRunner 是一款面向 HTTP(S) 協(xié)議的通用測試框架，只需編寫維護(hù)一份 YAML/JSON 腳本，即可實(shí)現(xiàn)自動化測試、性能測試、線上監(jiān)控、持續(xù)集成等多種測試需求。

因?yàn)楹笈_做了大量工作，因此我們只需要維護(hù)少量的json數(shù)據(jù)，工作量減少，效率提高。

靈活性：可根據(jù)自己需要，定義合適的方法或者數(shù)據(jù)緩存機(jī)制。

httprunner也提供了基于locust的性能測試，可根據(jù)需要直接運(yùn)行json文件即可！

同時(shí)，最重要的是，測試用例和代碼的分離。這樣使得稍有編碼功底的人迅速上手。

接口用例可通過har文件錄制轉(zhuǎn)換得到，也可自己定義.

image.png

核心特性

• 繼承 Requests 的全部特性，輕松實(shí)現(xiàn) HTTP(S) 的各種測試需求
• 測試用例與代碼分離，采用YAML/JSON的形式描述測試場景，保障測試用例具備可維護(hù)性
• 測試用例支持分層機(jī)制，充分實(shí)現(xiàn)測試用例的復(fù)用
• 測試用例支持參數(shù)化和數(shù)據(jù)驅(qū)動機(jī)制
• 使用 skip 機(jī)制實(shí)現(xiàn)對測試用例的分組執(zhí)行控制
• 支持熱加載機(jī)制，在文本測試用例中輕松實(shí)現(xiàn)復(fù)雜的動態(tài)計(jì)算邏輯
• 基于 HAR 實(shí)現(xiàn)接口錄制和用例生成功能（har2case）
• 結(jié)合 Locust 框架，無需額外的工作即可實(shí)現(xiàn)分布式性能測試
• 執(zhí)行方式采用 CLI 調(diào)用，可與 Jenkins 等持續(xù)集成工具完美結(jié)合
• 測試結(jié)果統(tǒng)計(jì)報(bào)告簡潔清晰，附帶詳盡統(tǒng)計(jì)信息和日志記錄
• 具有可擴(kuò)展性，便于擴(kuò)展實(shí)現(xiàn) Web 平臺化（HttpRunnerManager）

參考：http://cn.httprunner.org/

自己研發(fā)

Rest-Assured