不知道是否解答了你的疑問,如果沒有,請你指出,謝謝你。
需求确定以後,開發會根據需求進行接口設計,會産出接口定義,在開發設計過程中,有能力的話,可以給出一些針對設計的建議,提高可測性,針對需求及設計,進行測試計劃,測試設計,然後還需要和配管确定測試環境相關的事情。
在開發完成接口定義之後,就根據需求文檔及接口定義進行測試用例設計,測試用例設計主要從業務場景,功能,以及異常測試幾個方面考慮。
測試用例設計完成後,針對測試用例進行評審,然後,如果開發代碼部分可測時,即可進入測試了,因為是部分可測,可能會使用到mock方法。
已有測試代碼時,就要進行測試代碼的持續內建了,我們是使用hudson來進行持續內建的
在項目結束後,會對每個項目進行總結。
如果有問題,請指出,我們一起讨論。
xinhuayw:我想了解一下你們現在是怎樣保證項目測試用例的重複運作的。
csun888:什麼是接口測試,基礎知識什麼的講講吧!
小刀:你好,接口可以分下面幾種
1、系統與系統之間的調用,比如銀行會提供接口供電子商務網站調用,或者說,支付寶會提供接口給淘寶調用
2、上層服務對下層服務的調用,比如service層會調用DAO層的接口,而應用層又會調用服務層提供的接口,一般會通過
3、服務之間的調用,比如注冊使用者時,會先調用使用者查詢的服務,檢視該使用者是否已經注冊。
而我們所要做的接口測試,先要了解是基于哪一種類型的接口測試,不同類型的接口測試方法可能是不一緻的,總體來說,不管是那種類型,我們隻要把被測接口當做是服務方,而把我們的測試手段當做是客戶方,我們的目的就是,通過我們的測試手段,去驗證服務端滿足了他聲明提供的功能。
gulun:接口測試的資料準備,應該怎麼做呢?
小刀:接口測試的資料準備,可以從下面幾個方面去考慮:
1、如果是隻測試一次的接口,可以使用寫死的方式準備測試資料,在寫測試代碼的時候,使用到什麼資料就寫什麼資料,為了避免資料重複,可能比較多的會用到随機字元或随機數
2、可以直接通過調用其他API的方式準備測試資料,這種情況在測試最上層服務的時候比較有用,比如測試團購購買服務,就需要準備要購買的團購資料,購買團購的使用者資料,這個時候,可以直接調用生産團購的api和生成使用者的api直接生成測試資料
3、使用excel或xml準備測試資料,這種準備測試資料的方式,主要針對對象資料的準備,比如可以将一條團購資料對應excel中的一條資料,因為一般開發都會使用pojo映射,而在準備測試資料的時候,這些pojo對象屬性的設定往往是重複和大工作量的,用excel或XML方式準備,則可以減少在代碼當中重複去準備這些資料。
4、也可以使用工具方法的形式去準備測試資料,通過在代碼中寫工具方法去實作資料生成,而在測試代碼中調用工具方法去得到所需資料。
水生哥哥:你好,我想問一下:接口測試怎麼設計測試用例呢?
小刀:你好,我覺得接口測試用例的設計方法其實和功能測試用例的設計方法是類似的,因為接口是需要滿足需求的,而接口測試所依賴的也是需求說明書,但是,因為接口測試畢竟是通過代碼去測試代碼,是以,為了保證覆寫率,可能會使用到單元測試的方法,具體的測試用例設計,我考慮的如下,請參考,如果有錯誤,一起讨論。
輸入參數測試:針對輸入的參數進行測試,也可以說是假定接口參數的不正确性進行的測試,確定接口對任意類型的輸入都做了相應的處理:輸入參數合法,輸入參數不合法,輸入參數為空,輸入參數為null,輸入參數超長;
功能測試:接口是否滿足了所提供的功能,相當于是正常情況測試,如果一個接口功能複雜時推薦對接口用例進行結構劃分,這樣子用例具有更好的可讀性和維護性。
邏輯測試:邏輯測試嚴格講應為單元測試,單元測試應保持内部邏輯的正确性,可單元測試和接口測試界限并不是那麼清楚,是以我們也可以從給出的設計文檔中考慮内部邏輯錯誤的分支情況和異常;
異常情況測試:接口實作是否對異常情況都進行了處理,接口輸入參數雖然合法,但是在接口實作中,也會出現異常,因為内部的異常不一定是輸入的資料造成的,而有可能是其他邏輯造成的,程式需要對任何的異常都進行處理。
永遠的測試者:才開始測試,對接口測試感興趣,可是,目前的能力又無法進行接口測試,怎麼樣才能進入接口測試呢?
小刀:你好,如果要做接口測試,是需要一定的程式設計能力的,需要學習相對應的開發語言的,然後還需要學習開發所使用的一些架構,比如ibatis,spring等,對資料庫的操作也需要了解一些,還有eclipse操作,這些内容并不需要了解的多麼深入,如果隻是一般的做做接口測試,這些能夠使用就可以了,當然,要做好接口測試,就另當别論了。
我不知道你目前是什麼樣的能力,是以,我的建議就是,
1、學習程式設計語言,基礎的文法,循環,條件等
2、學習項目工程管理及開發架構:eclipse,maven,svn,ibatis,spring等
3、學習Xunit
4、自己嘗試去寫測試代碼
其實,上面的過程除了第一步是必須具備的意外,其他的都可以一邊寫測試代碼,一邊學習,最好的辦法就是看開發寫的代碼,并且,請開發寫一個正常的測試代碼,然後照着開發的測試代碼去模仿。
iTest99:你認為接口測試由開發團隊做好還是測試團隊好?各有什麼優勢和弱點?
小刀:我覺得,還是要區分一下單元測試和接口測試,單元測試一般來說,是針對具體的代碼邏輯進行測試,盡量減少這些功能單元內建起來出錯的可能性,一般是由開發人員來完成,而接口測試,更注重從使用者的角度設計用例,更偏向于功能測試,單元測試設計測試用例的時候,可能更多的考慮是代碼覆,而接口測試,則需要更多的考慮業務覆寫。單元測試由開發人員來做,可以保證從代碼角度來看是沒有問題的,但服務保證業務角度來看也是沒有問題的,而接口測試,則通過業務的角度去設計測試用例,其實,也可以說是從更早的時候,以功能測試的方法,先保證項目的流程及功能是正常的,而不至于在頁面開發完成後,又修改主要功能代碼,導緻項目趕工及一系列的重寫。
是以,我覺得,單元測試由開發人員來做,接口測試由測試人員來做。
至于你說的學習接口的成本,我覺得這個成本并不高,原因是:
1、接口測試的用例也是依賴需求文檔的,并不是根據開發代碼去設計
2、接口測試的用例可以在功能測試中複用。
3、接口測試看似增加測試時間,實則不然,因為,接口測試會更早的發現bug,而使得修改bug的成本更低,接口測試會減少功能測試的時間,應該接口測試會確定主要流程功能的正确性,接口測試更容易實作持續內建,進而減少回歸測試的次數。
txTester11:我想請問:接口測試盒單元測試有什麼差別?接口測試和白盒測試又有什麼差別?
小刀:單元測試是針對具體的代碼邏輯進行測試,主要測試被測代碼的一個很小的、很明确的功能是否正确。通常而言,一個單元測試是用于判斷某個特定條件(或者場景)下某個特定函數的行為。例如,你可能把一個很大的值放入一個有序list 中去,然後确認該值出現在list 的尾部。或者,你可能會從字元串中删除比對某種模式的字元,然後确認字元串确實不再包含這些字元了。盡量減少這些功能單元內建起來出錯的可能性,單元測試一般是由開發人員自己去完成,單元測試可能不會考慮業務是如何的,會更多的考慮,我這個單元子產品邏輯是否正确。
接口測試指的是針對程式内部的或者外部的接口進行的測試,一個接口方法可能會包含多個單元子產品,而且,一個接口會有自己特定的業務定義,是以,做接口測試的時候,更多的需要從業務的角度去考慮如何測試這個接口。
不管是接口測試還是單元測試,其實都屬于白盒測試的一個階段,白盒測試具體的方法有很多種,比如代碼審查,比如代碼覆寫。
技術改變世界!
--狂詩絕劍