互聯(lián)網(wǎng)行業(yè)已進(jìn)入小步快跑快速迭代的趨勢(shì)。一個(gè)新版本的上線，不僅需要移動(dòng)端測(cè)試，更需要進(jìn)行服務(wù)端的測(cè)試。服務(wù)端的測(cè)試可能比移動(dòng)端的測(cè)試更重要。服務(wù)端比移動(dòng)端更復(fù)雜交互更多也更考驗(yàn)技術(shù)了。

接下來給大家看一張?jiān)?012年淘寶核心鏈路的應(yīng)用拓?fù)鋱D，給大家看一下真實(shí)的后端服務(wù)是什么樣子的。

如此復(fù)雜的后端服務(wù)，光靠前端的手工測(cè)試和UI測(cè)試是遠(yuǎn)遠(yuǎn)不夠的?？吹缴厦娴耐?fù)鋱D，也不難理解為什么黑盒測(cè)試使出了洪荒之力，但總是會(huì)有漏網(wǎng)的bug了。而且如何判定一個(gè)bug屬于前端還是后端服務(wù)，真的是太考驗(yàn)測(cè)試人員了。于是，原本應(yīng)該是 “守門員” 的測(cè)試人員變成了一上線就「背鍋」的 “背鍋俠” ，真的是誰苦誰知道?。?/p>

做為一個(gè)測(cè)試人員，該如何保證一個(gè)項(xiàng)目可以順利進(jìn)行呢？有哪些工作是低投入高產(chǎn)出？畢竟：一個(gè)員工不能給公司帶來剩余價(jià)值就可能被優(yōu)化。但如果能夠低投入高產(chǎn)出，升職加薪也是指日可待的（誰不喜歡能賺錢的員工呢？反正我喜歡）。

而說到投入產(chǎn)出比，就必須提到馬丁福勒（page object模式的發(fā)起者）在個(gè)人blog中提到的一張圖，很形象的將移動(dòng)互聯(lián)網(wǎng)的流程簡(jiǎn)化成如下的圖。

我們通常所說的點(diǎn)點(diǎn)點(diǎn)，屬于UI層。在整個(gè)測(cè)試過程中，UI層所占的維度低?？梢允鞘止y(cè)試、UI測(cè)試、自動(dòng)遍歷等。在做UI測(cè)試的時(shí)候，UI 的執(zhí)行相對(duì)比較慢，發(fā)現(xiàn) bug 比較晚，bug 修復(fù)成本會(huì)比較高。這時(shí)候需要大量的人力物力，有的時(shí)候投入甚至高于產(chǎn)出。

Unit單元測(cè)試一般由開發(fā)進(jìn)行編寫。國(guó)內(nèi)研發(fā)能做好單元測(cè)試的非常少，有的產(chǎn)品甚至都沒有單元測(cè)試。基于這種現(xiàn)狀，底層的代碼產(chǎn)品也得不到有效的質(zhì)量保障。

而在 UI 和 Unit 之間的接口測(cè)試就顯得特別重要了。不僅在行業(yè)內(nèi)有成熟方案，而且可以更早的發(fā)現(xiàn)問題進(jìn)行質(zhì)量反饋。在Service層進(jìn)行充分測(cè)試，是通過UI測(cè)試很難觸達(dá)的，只有接口測(cè)試才能觸達(dá)，是測(cè)試&交付之間的范疇，屬于服務(wù)端的測(cè)試。

即然接口測(cè)試是測(cè)試&交付之間的范疇，而且在Service層只有接口測(cè)試才能觸達(dá)，在單個(gè)模塊中，只有做好接口測(cè)試，才能保證質(zhì)量。

那接口測(cè)試該從哪里入手呢？有哪些工具可以做好接口測(cè)試？App接口測(cè)試如何進(jìn)行抓包分析呢？我們請(qǐng)來了10+年的測(cè)試架構(gòu)師來給大家進(jìn)行干貨分享，讓你get接口測(cè)試所必知的知識(shí)點(diǎn)，讓你真正實(shí)現(xiàn)接口測(cè)試從入門到掌握。