1. 程式人生 > >接口測試--知識問答

接口測試--知識問答

修改 攔截 lencod 不一致 ner 工作 聯系 計劃 先生

1 做接口測試當請求參數多時tps下降明顯,此接口根據參數從redis中獲取數據,每個參數與redis交互一次,當一組參數是tps5133,五組參數是tps1169,多次交互影響了處理性能,請詳細闡述如何改進增進效果的方案。

將從redis獲取數據的get改為mget,減少交互次數(參考:http://www.cnblogs.com/dimmacro/p/4849729.html)

2 接口的加密測試中對稱加密與非對稱加密有什麽區別? 如何開展測試? 請詳解

對稱加密是最快速、最簡單的一種加密方式,加密(encryption)與解密(decryption)用的是同樣的密鑰(secret key),這種方法在密碼學中叫做對稱加密算法。 對稱加密的一大缺點是密鑰的管理與分配,換句話說,如何把密鑰發送到需要解密你的消息的人的手裏是一個問題。在發送密鑰的過程中,密鑰有很大的風險會被黑客們攔截。現實中通常的做法是將對稱加密的密鑰進行非對稱加密,然後傳送給需要它的人。 非對稱加密為數據的加密與解密提供了一個非常安全的方法,它使用了一對密鑰,公鑰(public key)和私鑰(private key)。私鑰只能由一方安全保管,不能外泄,而公鑰則可以發給任何請求它的人。非對稱加密使用這對密鑰中的一個進行加密,而解密則需要另一個密鑰。比如,你向銀行請求公鑰,銀行將公鑰發給你,你使用公鑰對消息加密,那麽只有私鑰的持有人--銀行才能對你的消息解密。與對稱加密不同的是,銀行不需要將私鑰通過網絡發送出去,因此安全性大大提高。目前最常用的非對稱加密算法是RSA算法. 開展測試-TBD

3 請詳細闡述接口測試和UI測試在測試活動中是如何協同測試的?

技術分享圖片

接口測試和UI測試這兩塊其實是有一部分是重疊的,UI測試是通過前端寫的界面,來調用接口,而接口測試是直接調接口。所以排除前端的處理的邏輯和調用的正確性,在理論上接口測試是可以覆蓋所有的UI測試。但實際過程中,如果只是在接口層覆蓋所有的業務流,在UI上只測試前端的邏輯,最終的結果可能會是忽視很多原有的功能點,導致了UI測試的不充分。所以存在多人分工且時間充分的時候可以嘗試接口去做業務流的全覆蓋,否則不要輕易嘗試。

4 在手工接口測試或者自動化接口測試的過程中,上下遊接口有數據依賴如何處理?

在工具中可以使用全局變量等方式將需要的數據進行傳送。

5 依賴於第三方數據的接口如何進行測試?

可以使用SoapUI等工具直接調用第三方數據接口的webservice,通過返回值來查看第三方數據的接口是否調用正常。 也可以利用一些MOCK的工具來模擬第三方的數據返回,最大限度的降低對第三方數據接口的依賴。

6 接口測試中依賴登錄狀態的接口如何測試?

依賴登錄狀態的接口的本質上是在每次發送請求時需要帶上Session或者Cookie才能發送成功,在構建POST請求時添加必要的Session或者Cookie

7 http接口測試和web Service接口測試區別是什麽?

區別是有的。主要是傳統ws有一套完整的協議標準。其中有soap協議,用來進行消息的傳遞。以傳統工業標準的ws返回數據為例,返回結果需要包裝在一個soap協議指定的語法格式中。即使你只需要簡單的返回字符1,也需要包裝在協議種返回,協議描述了成功失敗否,結果值等。而普通的get,你輸出1,在調用端得到字符1。 web service和http接口的區別在於: 1.接口中實現的方法和要求參數一目了然。 2.不用擔心大小寫問題。 3.不用擔心中文 urlencode 問題。 4.代碼中不用多次聲明認證(賬號,密碼)參數。 5.傳遞參數可以為數組,對象等。

8 設計接口測試用例例時,涉及的是電商系統,其中包括很多修改,如商品、商家、店鋪等等,針對這些數據的修改,會涉及到很多參數。如商品的名稱,商品的尺碼,商品的顏色等等。那在設計實現“修改”接?口時,如何確定要傳哪些參數?是只需要傳我要修改的參數,還是全部參數都要傳?

關鍵還是看後臺邏輯實現。 舉例:User有兩個屬性username,password 後臺邏輯實現:update User set username=? where id=xxx; 那,如果你只想更新username的時候,可以不傳password,其值是保持不變的。 後臺邏輯實現:udpate User set username=?,password=? where id=xxx; 這種情況下,即使你只想更新username,也需要傳password的值給後臺,不然password就會被更新為空。 此外,還有一些數據如id等,如果sql中沒有寫,那即使傳遞了本字段的參數,數據庫也不會更新。因此,在寫關於“修改”的接口時,需要考慮一下,後臺的邏輯是怎麽實現的,然後確認要傳遞哪些參數。

9 目前接口文檔是由word格式管理理,因叠代快,產生很多文檔,分不不清哪些是不用的接口,哪些是正在用的接口,哪些是更新後的接口,文檔雜亂,另外因是word格式管理,不方便查詢,如何管理?每次查看接口文檔需要下載多個word,不能避免下載操作查看,效率不高,如何提高工作效率?

如果是webservice,使用WSDL的格式來進行查看接口的文檔,以前的接口必要的時候使用一些配置管理的工具,比如wiki之類的系統來實時更新現有的接口狀態

1)什麽是API測試?

  API(應用程序編程接口)指定某些軟件組件應如何與其他組件進行交互,換句話說,它是一組功能和過程,允許創建訪問應用程序或操作系統的功能或數據的應用程序。這些功能的測試稱為API測試。

2)用於API測試的工具是什麽?

  SoapUI Pro Postman/Poster Jmeter Loadrunner

3)對API進行的常見測試是什麽? 對API進行的常見測試

  驗證API是否正在更新任何數據結構 驗證API是否不返回任何內容 根據輸入條件,檢查API的返回值 驗證API是否觸發某些其他事件或調用另一個API

4)提到UI級別測試和API測試之間的關鍵區別?

  UI(用戶界面)是指測試圖形界面,如用戶如何與應用程序交互,測試應用程序元素,如字體,圖像,布局等。UI測試基本上側重於應用程序的外觀和感覺。 而API可以實現兩個獨立的軟件系統之間的通信。實現API的軟件系統包含可由另一軟件系統執行的功能或子例程

5)解釋什麽是SOAP?

  SOAP代表簡單對象訪問控制,它是一種基於XML的協議,用於在計算機之間交換信息。

6)解釋什麽是REST API?

  這是開發人員執行請求並接收響應的一組功能。 在REST API中,通過HTTP協議進行交互

  REST - 代表狀態轉移,它正快速成為API創建的標準。 可參見:RESTful API的最佳設計原則

7)單元測試和API測試的差異?

技術分享圖片

8)如何測試API?

  要測試API,您應該遵循以下步驟:

選擇你想要添加到API測試用例的中的測試套件 選擇測試開發模式 開發所需API方法的測試用例 配置應用程序控制參數 配置測試條件 配置驗證方法 執行API測試 查看測試報告 過濾API測試用例 序列化API測試用例

9)在編寫API文件時,提到要考慮的主要領域?

  內容來源 文件計劃或草圖 發布的界面 文檔中每個功能所需的信息 自動文件創建程序

技術分享圖片

10)在API文檔中解釋如何記錄每個函數?用於文檔的工具是什麽?

  說明:關於什麽功能的簡要說明 語法:關於代碼參數的語法,它們出現的順序,必需和可選元素等。 參數:函數參數 錯誤消息:錯誤消息的語法 示例代碼:小代碼段 相關鏈接:相關功能 用於API文檔的熱門工具是JavaDoc(用於Java代碼)Doxygen(for .Net代碼)

11)解釋API框架?

  API框架是不言自明的。使用測試運行和保存可配置部件的配置文件的值。自動測試用例必須以配置文件中的“parse-table”格式表示。在測試API時,不需要對每個API進行測試,因此配置文件有一些部分的所有API都被激活用於該特定的運行。

12)API Builder如何工作?

  API Builder是一個由四個SQL文件組成的PLSQL程序

要設置API參數並啟動該過程,一個文件是負責的 為臨時表和主包創建兩個文件以創建輸出的代碼 第四個文件將代碼的“假脫機”輸出創建為一個名為“output_script_.sql”的文件

13)解釋什麽是TestApi?

  TestApi是一個實用程序和測試API庫,可讓測試人員和開發人員為.NET和Win32應用程序創建測試工具和自動測試。它提供了一套常見的測試構建塊,類型,數據結構和算法。

14)什麽是輸入註入,有什麽不同的做法?

  輸入註入:模擬用戶輸入的行為,可以通過多種方式模擬用戶輸入。

  直接方法調用 使用可訪問性界面進行調用 使用低級輸入進行仿真 使用設備驅動程序進行仿真 使用機器人進行仿真

15)API測試的主要挑戰是什麽?

  API測試的主要挑戰是 參數選擇 參數組合 調用排序

16)什麽是使用runscope的API測試?

  Runscope是一個Web應用程序,它提供後端服務和易於使用的界面來測試API。(沒用過)

17)解釋API測試設計的原理是什麽?

  API測試設計的原理是

安裝:創建對象,啟動服務,初始化數據等 執行:執行API或場景的步驟,也記錄日誌 驗證:比較預期結果和實際結果 報告:查看執行情況,通過,失敗或阻止 清理:回到最初的測試狀態

18)API測試發現的Bug類型是什麽?

  缺少或重復的功能 無法正常處理錯誤條件 強調 可靠性 安全 未使用的標誌 未實現錯誤 錯誤處理不一致 性能 多線程問題 錯誤不正確 (基本也就是其它測試的發現bug類型)

19)用於API測試自動化的工具是什麽?

  在測試單元和API測試時,既要定位源代碼,如果API方法使用基於.NET的代碼,則支持的工具應該有.NET 用於API測試的自動化工具可以使用NUnit for .NET Java的JUnit HP UFT Soap UI (近年來的Jmeter也挺好用的)

20)提到測試API的步驟?

API測試步驟

選擇必須滿足的測試用例 對於API調用開發一個測試用例 滿足測試用例配置API參數 確定如何驗證成功的測試 使用PHP或.NET等編程語言執行API調用 允許API調用返回數據進行驗證

21)在API測試中測試的常用協議是什麽?

HTTP JMS REST SOAP UDDI

作者:CC先生之簡書 鏈接:https://www.jianshu.com/p/12c5c419814a 來源:簡書 著作權歸作者所有。商業轉載請聯系作者獲得授權,非商業轉載請註明出處。 作者:CC先生之簡書 鏈接:https://www.jianshu.com/p/88f114efa0a0 來源:簡書 著作權歸作者所有。商業轉載請聯系作者獲得授權,非商業轉載請註明出處。

接口測試--知識問答