如何做接口測試.docx

如何做好接口測試？發(fā)布時間: 2012-1-19 10:44 作者: 小刀 來源: 51Testing軟件測試論壇 字體: 小 中 大 | 上一篇 下一篇 | 打印 | 我要投稿 | 推薦標簽： 軟件測試 接口測試 sgbtmy：基于selenium的自動化框架開發(fā)，我主要是想問一下，你的框架除了前臺的自動化，后臺的數(shù)據(jù)的測試是否集成在你的測試框架中？小刀：你好，個人理解的你所說的后臺的數(shù)據(jù)的測試是指的是對數(shù)據(jù)的校驗，不知理解的是否正確，那么根據(jù)這個理解，我的解釋是，在我們框架中，增加了很多的功能方法用來幫助進行自動化腳本的編寫和結(jié)果校驗，其中就包括后臺數(shù)據(jù)校驗方法，當我們的測試用例需要在后臺進行數(shù)據(jù)校驗的時候，調(diào)用這些數(shù)據(jù)校驗方法即可。相當于是，前臺頁面操作的自動化是封裝selenium的方法去操作頁面，而對后臺數(shù)據(jù)的校驗是通過增加功能方法來實現(xiàn)的，可以理解為不同的兩部分，但是在編寫測試腳本的似乎，根據(jù)測試用例的設(shè)計，這兩部分都可以拿過來使用。不知道是否解答了你的疑問，如果沒有，請你指出，謝謝你。tjy688：你們做接口測試的流程一般是怎么樣的？小刀：接口測試的流程其實和功能測試的流程類似，因為接口測試依賴的主要對象也是需求說明書，所以，最初的流程就是參與需求討論，評審需求。需求確定以后，開發(fā)會根據(jù)需求進行接口設(shè)計，會產(chǎn)出接口定義，在開發(fā)設(shè)計過程中，有能力的話，可以給出一些針對設(shè)計的建議，提高可測性，針對需求及設(shè)計，進行測試計劃，測試設(shè)計，然后還需要和配管確定測試環(huán)境相關(guān)的事情。在開發(fā)完成接口定義之后，就根據(jù)需求文檔及接口定義進行測試用例設(shè)計，測試用例設(shè)計主要從業(yè)務(wù)場景，功能，以及異常測試幾個方面考慮。測試用例設(shè)計完成后，針對測試用例進行評審，然后，如果開發(fā)代碼部分可測時，即可進入測試了，因為是部分可測，可能會使用到mock方法。已有測試代碼時，就要進行測試代碼的持續(xù)集成了，我們是使用hudson來進行持續(xù)集成的在項目結(jié)束后，會對每個項目進行總結(jié)。如果有問題，請指出，我們一起討論。xinhuayw：我想了解一下你們現(xiàn)在是怎樣保證項目測試用例的重復(fù)運行的。小刀：對于接口測試來說，項目測試用例的重復(fù)運行首先是表現(xiàn)在單個測試用例的獨立性方面的，也就是說，每一個測試用例的運行除了依賴被測對象和對應(yīng)的數(shù)據(jù)庫環(huán)境外，是不依賴于其他任何測試用例的，并且這個測試用例執(zhí)行完畢后，對系統(tǒng)來說，也是沒有任何痕跡的，這樣就保證了每個測試用例運行時，都在一個干凈的環(huán)境中運行。要實現(xiàn)測試用例的獨立性，就必須對被測系統(tǒng)的設(shè)計有詳細的了解，這樣，不會出現(xiàn)測試用例執(zhí)行后遺漏數(shù)據(jù)，環(huán)境未改變，另外，還需要對測試用例進行詳細的設(shè)計。另外，要保證測試用例的重復(fù)使用，還需要做到測試用例的及時更新，在這個方面，我們是做接口測試的人會維護對應(yīng)的系統(tǒng)的接口測試用例，要保證，代碼每次更新，測試用例都必須全部執(zhí)行通過。csun888：什么是接口測試，基礎(chǔ)知識什么的講講吧！小刀：你好，接口可以分下面幾種1、系統(tǒng)與系統(tǒng)之間的調(diào)用，比如銀行會提供接口供電子商務(wù)網(wǎng)站調(diào)用，或者說，支付寶會提供接口給淘寶調(diào)用2、上層服務(wù)對下層服務(wù)的調(diào)用，比如service層會調(diào)用DAO層的接口，而應(yīng)用層又會調(diào)用服務(wù)層提供的接口，一般會通過3、服務(wù)之間的調(diào)用，比如注冊用戶時，會先調(diào)用用戶查詢的服務(wù)，查看該用戶是否已經(jīng)注冊。而我們所要做的接口測試，先要了解是基于哪一種類型的接口測試，不同類型的接口測試方法可能是不一致的，總體來說，不管是那種類型，我們只要把被測接口當做是服務(wù)方，而把我們的測試手段當做是客戶方，我們的目的就是，通過我們的測試手段，去驗證服務(wù)端滿足了他聲明提供的功能。至于說到具體的測試方法，http協(xié)議的接口測試，一般會用jmeter去測試，jmeter的好處是不用寫測試代碼，直接使用jmeter提供的http請求去測試，也可以使用HTTPClient去測試，好處是可以方便集成和自動化。java接口的測試，則需要編寫測試代碼去測試，有點類似于單元測試，但是需要更多的考慮業(yè)務(wù)場景。gulun：接口測試的數(shù)據(jù)準備，應(yīng)該怎么做呢？小刀：接口測試的數(shù)據(jù)準備，可以從下面幾個方面去考慮：1、如果是只測試一次的接口，可以使用硬編碼的方式準備測試數(shù)據(jù)，在寫測試代碼的時候，使用到什么數(shù)據(jù)就寫什么數(shù)據(jù)，為了避免數(shù)據(jù)重復(fù)，可能比較多的會用到隨機字符或隨機數(shù)2、可以直接通過調(diào)用其他API的方式準備測試數(shù)據(jù)，這種情況在測試最上層服務(wù)的時候比較有用，比如測試團購購買服務(wù)，就需要準備要購買的團購數(shù)據(jù)，購買團購的用戶數(shù)據(jù)，這個時候，可以直接調(diào)用生產(chǎn)團購的api和生成用戶的api直接生成測試數(shù)據(jù)3、使用excel或xml準備測試數(shù)據(jù)，這種準備測試數(shù)據(jù)的方式，主要針對對象數(shù)據(jù)的準備，比如可以將一條團購數(shù)據(jù)對應(yīng)excel中的一條數(shù)據(jù)，因為一般開發(fā)都會使用pojo映射，而在準備測試數(shù)據(jù)的時候，這些pojo對象屬性的設(shè)置往往是重復(fù)和大工作量的，用excel或XML方式準備，則可以減少在代碼當中重復(fù)去準備這些數(shù)據(jù)。4、也可以使用工具方法的形式去準備測試數(shù)據(jù)，通過在代碼中寫工具方法去實現(xiàn)數(shù)據(jù)生成，而在測試代碼中調(diào)用工具方法去得到所需數(shù)據(jù)。水生哥哥：你好，我想問一下：接口測試怎么設(shè)計測試用例呢？小刀：你好，我覺得接口測試用例的設(shè)計方法其實和功能測試用例的設(shè)計方法是類似的，因為接口是需要滿足需求的，而接口測試所依賴的也是需求說明書，但是，因為接口測試畢竟是通過代碼去測試代碼，所以，為了保證覆蓋率，可能會使用到單元測試的方法，具體的測試用例設(shè)計，我考慮的如下，請參考，如果有錯誤，一起討論。輸入?yún)?shù)測試：針對輸入的參數(shù)進行測試，也可以說是假定接口參數(shù)的不正確性進行的測試，確保接口對任意類型的輸入都做了相應(yīng)的處理：輸入?yún)?shù)合法，輸入?yún)?shù)不合法，輸入?yún)?shù)為空，輸入?yún)?shù)為null，輸入?yún)?shù)超長；功能測試：接口是否滿足了所提供的功能，相當于是正常情況測試，如果一個接口功能復(fù)雜時推薦對接口用例進行結(jié)構(gòu)劃分，這樣子用例具有更好的可讀性和維護性。邏輯測試：邏輯測試嚴格講應(yīng)為單元測試，單元測試應(yīng)保持內(nèi)部邏輯的正確性，可單元測試和接口測試界限并不是那么清楚，所以我們也可以從給出的設(shè)計文檔中考慮內(nèi)部邏輯錯誤的分支情況和異常；異常情況測試：接口實現(xiàn)是否對異常情況都進行了處理，接口輸入?yún)?shù)雖然合法，但是在接口實現(xiàn)中，也會出現(xiàn)異常，因為內(nèi)部的異常不一定是輸入的數(shù)據(jù)造成的，而有可能是其他邏輯造成的，程序需要對任何的異常都進行處理。永遠的測試者：才開始測試，對接口測試感興趣，可是，當前的能力又無法進行接口測試，怎么樣才能進入接口測試呢？小刀：你好，如果要做接口測試，是需要一定的編程能力的，需要學習相對應(yīng)的開發(fā)語言的，然后還需要學習開發(fā)所使用的一些框架，比如ibatis，spring等，對數(shù)據(jù)庫的操作也需要了解一些，還有eclipse操作，這些內(nèi)容并不需要了解的多么深入，如果只是一般的做做接口測試，這些能夠使用就可以了，當然，要做好接口測試，就另當別論了。我不知道你當前是什么樣的能力，所以，我的建議就是，1、學習編程語言，基礎(chǔ)的語法，循環(huán)，條件等2、學習項目工程管理及開發(fā)框架：eclipse，maven，svn，ibatis，spring等3、學習Xunit4、自己嘗試去寫測試代碼其實，上面的過程除了第一步是必須具備的意外，其他的都可以一邊寫測試代碼，一邊學習，最好的辦法就是看開發(fā)寫的代碼，并且，請開發(fā)寫一個正常的測試代碼，然后照著開發(fā)的測試代碼去模仿。iTest99：你認為接口測試由開發(fā)團隊做好還是測試團隊好？各有什么優(yōu)勢和弱點？小刀：我覺得，還是要區(qū)分一下單元測試和接口測試，單元測試一般來說，是針對具體的代碼邏輯進行測試，盡量減少這些功能單元集成起來出錯的可能性，一般是由開發(fā)人員來完成，而接口測試，更注重從用戶的角度設(shè)計用例，更偏向于功能測試，單元測試設(shè)計測試用例的時候，可能更多的考慮是代碼覆，而接口測試，則需要更多的考慮業(yè)務(wù)覆蓋。單元測試由開發(fā)人員來做，可以保證從代碼角度來看是沒有問題的，但服務(wù)保證業(yè)務(wù)角度來看也是沒有問題的，而接口測試，則通過業(yè)務(wù)的角度去設(shè)計測試用例，其實，也可以說是從更早的時候，以功能測試的方法，先保證項目的流程及功能是正常的，而不至于在頁面開發(fā)完成后，又修改主要功能代碼，導(dǎo)致項目趕工及一系列的重寫。所以，我覺得，單元測試由開發(fā)人員來做，接口測試由測試人員來做。至于你說的學習接口的成本，我覺得這個成本并不高，原因是：1、接口測試的用例也是依賴需求文檔的，并不是根據(jù)開發(fā)代碼去設(shè)計2、接口測試的用例可以在功能測試中復(fù)用。3、接口測試看似增加測試時間，實則不然，因為，接口測試會更早的發(fā)現(xiàn)bug，而使得修改bug的成本更低，接口測試會減少功能測試的時間，應(yīng)該接口測試會確保主要流程功能的正確性，接口測試更容易實現(xiàn)持續(xù)集成，從而減少回歸測試的次數(shù)。txTester11：我想請問：接口測試盒單元測試有什么區(qū)別？接口測試和白盒測試又有什么區(qū)別？小刀：單元測試是針對具體的代碼邏輯進行測試，主要測試被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數(shù)的行為。例如，你可能把一個很大的值放入一個有序list 中去，然后確認該值出現(xiàn)在list 的尾部?；蛘撸憧赡軙淖址袆h除匹配某種模式的字符，然后確認字符串確實不再包含這些字符了。盡量減少這些功能單元集成起來出錯的可能性，單元測試一般