介面參數是否加密怎麼測

① jmeter如何測試加密過的登錄介面

1.用jemter做介面
1.我們先建立一個線程組
2.我們要設置一個http,發送http默認請求值，放入你需求測試的地址
3.在建立一個http請求
4.添加監控器，主要是監控結果，查看結果樹
5.查看請求，發現請求是成功了的，但是響應數據是錯誤，登錄失敗了，因為請求失敗以後的數據是以下的數據
"State":9999, // 9999
至於為什麼，是因為登錄需要加密的key，有一個加密的演算法，那如果這樣，就只能用java來手寫這個介面了，就在下次共享出來吧。

② 測試工程師面試，介面測試問題總結

1、什麼是介面？

2、什麼是介面測試？

3、介面組成的要素有哪些？

4、Python 的 requests 包是干什麼的？

5、如何使用 Python 的 requests 包？

6、為什麼開展介面測試？

7、為什麼要寫介面測試用例？

8、介面測試用例設計主要考慮哪些？

9、介面測試用例包含哪些內容？

10、介面測試如何設計用例？

11、通用介面用例設計？

12、介面測試報告包含哪些內容？

13、測試指標范圍包含哪些？

14、做介面測試運用過哪些測試工具？

15、抓包工具用過哪些？

16、為什麼進行抓包測試？

17、TCP/IP 參考模型有哪幾層？

18、常用協議的埠號？

19、常見的狀態碼有哪些？

20、你們公司的介面測試流程是怎樣的？

21、請詳細闡述介面測試和 UI 測試在測試活動中是如何協同測試的？

22、介面測試注意事項？

23、介面測試執行中對比資料庫嗎？

24、請簡述一下 cookie、session 以及 token 的區別？

25、談談你對 HTTP 協議的了解？

26、你對 http 請求跟 webservice 請求的了解？

27、在介面測試中關聯是什麼含義？如何使用 Postman 設置關聯？

28、介面自動化測試框架一般分為幾層？

29、測試框架里如何做到數據和代碼分離？

1、什麼是介面？

介面就是 API，意思是應用程序編程介面。

介面本質上是程序開發的函數和方法，提供參數和返回值。

2、什麼是介面測試？

介面測試是測試系統組件間介面的一種測試，介面測試主要用於檢測外部系統和內部系統之間以及各個子系統之間的交互點。測試的重點是檢查數據的交換、傳遞和控制管理的過程，以及系統間的相互邏輯依賴關系等。

3、介面組成的要素有哪些？

介面訪問的地址、請求的方法、參數、返回值

（1）介面訪問的地址 協議://IP 地址或域名:埠號/應用名/功能名

（2）請求的方法 get、post 等

（3）參數 用戶使用介面時，需要向介面提供的數據。

（4）返回值 介面給用戶的反饋結果。

4、Python 的 requests 包是干什麼的？

requests 是一個 HTTP 庫，作用是發送 HTTP 請求，獲得響應，往往使用在網路爬蟲，介面自動化測試中。

5、如何使用 Python 的 requests 包？

（1）安裝 Python

（2）安裝 requests 模塊

（3）創建.py 文件

（4）導入 requests 模塊

（5）編寫 Python 代碼

（6）調用 requests 方法

6、為什麼開展介面測試？

介面測試屬於集成測試、測試接入越早，就越能在項目早期發現問題，修復問題成本降低。

介面測試非常快速，UI 自動化執行一個測試用例 10s 左右，介面用例執行一般毫秒級。

7、為什麼要寫介面測試用例？

（1）理清思路，避免漏測和重復測試。

（2）提高測試效率、跟進測試進度、告訴領導做過、跟進重復性工作。

（3）更好的記錄問題、發現問題、復現問題、同時這也是介面測試流程中的一個產物。

8、介面測試用例設計主要考慮哪些？

（1）功能是否正常。

（2）功能是否按照介面文檔實現、是否依賴業務、異常情況（參數異常、數據異常）、安全測試等。

9、介面測試用例包含哪些內容？

用例名稱、介面地址、請求方式、前置條件、描述、請求頭部、請求參數、狀態碼、預期返回結果

10、介面測試如何設計用例？

介面測試一般考慮入參形式的變化和介面的業務邏輯。

一般設計介面測試用例採用等價類、邊界值、場景法居多。

介面測試用例設計思路：

（1）介面業務邏輯測試，介面邏輯測試是指根據業務邏輯，輸入參數，輸出值的描述，對正常輸入情況下所得輸出值是否正確的測試，也就是測試對外提供的介面服務是否正常。

（2）模塊介面測試，模塊介面測試是為了保證數據的安全及程序在異常情況下的邏輯正確性而進行的測試模塊，介面測試主要包括以下幾個方面

a.鑒權碼 token 異常（為空、沒有、錯誤、過期）

b.其他參數的異常，必填項的檢查，參數的長度、類型、格式異常。常規的參數有數字，字元串，日期；參數長度，位數、身份證、電話的長度；參數的類型，數字精度，字母，中文，帶空格的參數，特殊字元；日期格式，日期年月日，年月日時分秒，日期格式（包含/-:等）

c.錯誤碼異常覆蓋

11、通用介面用例設計？

（1）通過性驗證：首先肯定要保證這個介面功能是好使的，也就是正常的通過性測試，按照介面文檔上的參數，正常傳入，是否可以返回正確的結果。

（2）參數組合：現在有一個操作商品的介面，有個欄位 type，傳 1 的時候代表修改商品，商品 id、商品名稱、價格有一個是必傳的，type 傳 2 的時候是刪除商品，商品 id 是必傳的，這樣就要測參數組合了，type 傳 1 的時候，只傳商品名稱能不能修改成功，id、名稱、價格都傳的時候能不能修改成功。

（3）介面安全：繞過驗證，比如說購買了一個商品，它的價格是 300 元，那我在提交訂單時候，我把這個商品的價格改成 3 元，後端有沒有做驗證，更狠點，我把錢改成-3，是不是我的余額還要增加？繞過身份授權，比如說修改商品信息介面，那必須得是賣家才能修改，那我傳一個普通用戶，能不能修改成功，我傳一個其他的賣家能不能修改成功。參數是否加密，比如說我登陸的介面，用戶名和密碼是不是加密，如果不加密的話，別人攔截到你的請求，就能獲取到你的信息了，加密規則是否容易破解。密碼安全規則，密碼的復雜程度校驗。

（4）異常驗證：所謂異常驗證，也就是我不按照你介面文檔上的要求輸入參數，來驗證介面對異常情況的校驗。比如說必填的參數不填，輸入整數類型的，傳入字元串類型，長度是 10 的，傳 11，總之就是你說怎麼來，我就不怎麼來，其實也就這三種，必傳非必傳、參數類型、入參長度。

12、介面測試報告包含哪些內容？

系統介面概況、測試目的與范圍、測試工具與資源、測試記錄及結果分析（單場景介面、混合場景介面）、測試結論

13、測試指標范圍包含哪些？

（1）被測介面接收請求和返回報文。

（2）被測介面返回狀態、被測介面對應業務邏輯處理、涉及數據沉澱的處理、復雜場景下多個介面串聯交互。

14、做介面測試運用過哪些測試工具？

（1）Postman

（2）JMeter

（3）SoapUI

（4）Python + requests

（5）Java + HttpClient

（6）Java + OkHttp

15、抓包工具用過哪些？

（1）Fiddler

（2）Charles

（3）Wireshark

16、為什麼進行抓包測試？

有些時候公司沒有標準的介面文檔，測試人員只能抓包來獲取介面信息。

抓包可以迅速找到請求，通過抓包可以查看整個請求過程，以及響應過程，可以通過抓包來分辨前台還是後台 bug。

通過抓包，可以查看是否有敏感信息泄露，比如用戶密碼和個人賬號信息等數據。

通過抓包進行測試，攔截請求，修改請求數據，查看對應響應結果，抓包本身就是介面測試的一部分。

17、TCP/IP 參考模型有哪幾層？

應用層、傳輸層、網路層、網路介面層

18、常用協議的埠號？

（1）21/tcp FTP 文件傳輸協議

（2）22/tcp SSH 安全登錄、文件傳送（SCP）和埠重定向

（3）23/tcp Telnet 不安全的文本傳送

（4）25/tcp SMTP Simple Mail Transfer Protocol（E-mail）

（5）69/udp TFTP Trivial File Transfer Protocol（微型文件傳輸協議）

（6）80/tcp HTTP 超文本傳送協議（WWW）

（7）110/tcp POP3 Post Office Protocol（E-mail）

（8）443/tcp HTTPS used for securely transferring web pages

（9）3389/tcp 遠程訪問 5631/tcp

（10）5632/udp pcanywhere 埠號

（11）1433 SqlServer 服務埠號

（12）1521 Oracle 服務埠號

（13）3306 Mysql 服務埠號

（14）8080 Tomcat 默認服務埠號

19、常見的狀態碼有哪些？

（1）1XX 信息提示，用於指定客戶端相應的某些動作。

（2）2XX 成功，用於表示請求成功。

（3）3XX 重定向，用於移動的文件並且常被包含在定位頭信息中制定的新的地址信息。

（4）4XX 客戶端錯誤，用於指出客戶端的錯誤。

（5）5XX 伺服器錯誤，用於指出伺服器的錯誤。

20、你們公司的介面測試流程是怎樣的？

（1）從開發中取得介面文檔，了解介面業務，主要包括介面地址、請求方式、入參、出參、返回格式等信息。

（2）使用 Jmeter 進行介面測試，創建一個線程組，然後建立一個 http 請求默認值，再新建很多 http 請求，一個請求是一個用例，輸入相應介面路徑、訪問方式、參數等，創建斷言和察看結果樹。

（3）最後調用並執行測試用例，編寫測試報告。

（4）在做介面測試的時候遇到過很多問題，都是自己獨立解決的，比如返回值亂碼（修改 Jmeter 的配置文件為 UTF-8）。

21、請詳細闡述介面測試和 UI 測試在測試活動中是如何協同測試的？

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

22、介面測試注意事項？

（1）改變請求參數，看響應結果是否和介面文檔一致。

（2）查看參數是否有敏感信息（比如個人賬戶信息，資金信息）。

（3）查看是否對關鍵參數進行加密處理（密碼信息）。

（4）所有列表頁介面必須考慮排序值。

（5）介面返回的圖片地址能否打開，圖片尺寸是否符合需求。

（6）介面有翻頁時，頁碼與頁數的異常值測試。

（7）當輸出參數有聯動性時，需要校驗返回兩參數的實際結果是否都符合需求每個介面入參的默認值、異常類型、非空校驗。

（8）入參支持多個值時，要考慮傳的值的個數多的情況下，介面會不會報錯。

23、介面測試執行中對比資料庫嗎？

肯定要對比，因為介面返回值的數據來源於資料庫，介面對數據的操作還要進行深層次的資料庫檢查。

24、請簡述一下 cookie、session 以及 token 的區別？

cookie 數據存放在客戶的瀏覽器上、session 數據放在伺服器上、token 是介面測試時鑒權碼，一般情況下登陸後才可以獲取到 token，然後在每次請求介面時需要帶上 token 參數。

cookie 不安全，別人可以分析存在本地的 cookie 並進行 cookie 欺騙，考慮到安全應當使用 session 可以將登錄信息等重要信息存放為 session，其他信息可以保存在 cookie。

25、談談你對 HTTP 協議的了解？

超文本傳輸協議，埠為 80，是由請求和響應兩部分組成的。

請求是由請求頭，請求行，請求正文組成；響應是由響應頭、響應行、響應正文組成。

面向安全的話使用 https。

26、你對 http 請求跟 webservice 請求的了解？

（1）http api 介面：是走 http 協議，通過路徑來區分調用的方法，請求報文都是 key-value 形式的，返回報文一般都是 json 串，有 get 和 post 等方法，這也是最常用的兩種請求方式。可以使用的工具有 postman、RESTClient、jmeter、loadrunner 等。

（2）webservice 介面：是走 soap 協議通過 http 傳輸，請求報文和返回報文都是 xml 格式的，都是通過工具才能進行調用與測試。可以使用的工具有 SoapUI、jmeter、loadrunner 等。

27、在介面測試中關聯是什麼含義？如何使用 Postman 設置關聯？

關聯就是把上一個介面返回值的部分截取出來，作為下一個介面的參數，能讓介面串聯運行。

在 Postman 中設置關聯的步驟如下：

（1）通過正則表達式提取的方式或 json 取值的方式把下一個介面需要的信息從上一個介面截取出來。

（2）使用設置全局變數的代碼把取出來的值保存到全局變數里。

（3）在下一個介面中，使用(全局變數)代替要替換的靜態值。

28、介面自動化測試框架一般分為幾層？

自動化測試框架一般分為 5 層（配置層，腳本層，數據層，測試報告層，驅動層）

介面項目工程規劃大致可分為幾類，首先是測試結果類，比如說叫 test_rusult，裡面存放一些比如日誌文件，測試報告。然後是測試用例 testcase，裡面分模塊存放測試用例。接下來是公共方法類，比如說叫 public，或者是 tools，裡面存放一些，讀取 excel 數據的方法，發送 http 請求的方法，收集 log 日誌的方法，發送郵件，操作資料庫等方法。還有就是配置文件類，比如說叫 config，裡面存放一些指定運行部分用例的配置文件，連接資料庫的配置文件。最後是寫一個 run 方法，運行所有的用例。

29、測試框架里如何做到數據和代碼分離？

第一種：寫在 excel 表格里，像這種主要是讀取 excel 數據有點麻煩，常用的用來讀取 excel 的第三方庫有 openpyxl，xlrd 等。當然讀取 excel 數據最好用的還是用來做數據分析的 pandas 模塊，不用寫那麼多 for 循環。

第二種：數據存放到 yaml 文件里，一個模塊或者是一個功能寫一個 yaml 文件，最後寫個讀取 yaml 文件的公共方法就行了。yaml 格式的文件比較簡單。

第三種：存放在資料庫裡面。

第四種：數據存放在 json 文件里。

③ MeterSphere介面測試中使用beanshell腳本進行參數哈希sha1加密

需求是這樣的，token是從第三步介面進行產生的。通過腳本

import org.apache.commons.codec.digest.DigestUtils;

//導入org.apache.commons.codec.digest.DigestUtils包;

String sign = DigestUtils.sha1Hex ("${__time}${token}xxxxx").toUpperCase( );

//定義sign=伺服器時間+token+固定密碼xxxxx;然後.toUpperCase( )大寫傳出;

vars.put("sign", sign); 

//導出簽名以第四條介面使用;

第4條case直接使用${sign}就可以使用上一步的sign進行加密

④ 介面測試注意的點

介面測試作為集成測試的一部分，通過直接調用被測試的介面來確定系統在功能性、可靠性、安全性和性能方面是否能達到預期，有些情況是功能測試無法覆蓋的，所以介面測試是非常必要的。

介面測試分為兩種，一種是webservice介面，走soap協議通過http傳輸，請求報文和返回報文都是xml格式的，測試時通過工具soapUI進行測試。使用情況比較少；另一種http api介面，走http傳輸協議，通過路徑來區分調用的方法，最常用的是get和post請求。

get請求和post請求的區別在哪裡呢？網上的答案為：

1、get請求可以在瀏覽器中請求到，post請求的測試需要藉助工具

2、get請求使用url和cookie傳參，post的數據放在body中

3、post比get更安全，因為傳遞的參數在url上是看不到的

4、get請求的url會有限制，而post請求的數據可以非常大

5、一般get請求是來獲取數據，post請求是傳遞數據的

其實，對於現在飛速發展的 互聯網來說，上面的說法已經不嚴謹了。首先，post請求的參數也可以寫在url里，但是這種情況不多見；其次表面上看起來，post利用body傳參，比get的url傳參安全，但其實只要用抓包工具（fiddler，Charles等），post的參數也是一覽無余；再次，現在的瀏覽器非常強大，可以輸入支持很長的URL，所以也不再有限制一說了。這么說來，種種區別只有最後一條是最根本的了。

怎麼來測試介面呢？根據什麼來測呢？這就需要開發提供的介面文檔了，介面文檔和功能測試的需求說明書的功能是一樣的。包括：介面說明、調用的url，請求方式（get or post），請求參數、參數類型、請求參數說明，返回結果說明。這里介面文飢枯檔生成可以使用apipost介面文檔生成工具。有了介面文檔後，我們就可以設計用例了，一般介面測試的用例分為以下幾種：

1、通過性驗證，說白了就是傳遞正確的參數，是否返回正常的結果

2、參數組合，因為參數有必傳和非必傳，參數的類型和長度，以及傳遞時可能業務上的一些限制，所以在設計用例時，就要排列組合這些情況，保證所有情況都能覆蓋到

3、介面的安全性，這個又分為幾種情況：

1)繞過驗證，比如提交訂單時，在傳遞商品價格參數時，修改商品價格，就要看後端有沒有驗證了。或者我支付時，抓個包將訂單金額一改，如果能以我改後的金額陵返支付，那這個借口就有問題了。

2）繞過身份驗證，就是某個功能只有有特殊許可權的用戶才能操作，那我傳遞一個普通的用戶，是不是也能操作呢

3）參數是否加密，這個關繫到一些賬戶的安全，比如我們在登錄一些網站時，它要將我們的登錄信尺肢飢息進行加密，如果不加密我們的信息就會暴露，危害性極大。

4) 密碼安全規則，設置密碼時復雜程度的校驗。

4、根據業務邏輯來設計用例

用例設計完了，用什麼來測試介面呢？我們可以藉助一些工具，比如apipost和jmeter。apipost使用比較簡單，可以在列表中選擇請求方式，在輸入框中輸入URL，如果是get請求，直接點擊發送就可以看返回結果了。

如果是post請求，會涉及到幾種參數的上傳方式和添加請求頭、許可權驗證還有添加cookie等操作。apipost都可以簡單實現

還有一種測試介面的工具是jmeter，用途比較廣泛，不但能測介面的功能，還能對介面進行性能測試。比如：壓力測試、負載測試等。在jmeter中需要創建線程組，如圖：

Apipost官方鏈接： https://console.apipost.cn/register?utm_source=10008

⑤ 介面測試怎麼才能做好

這個問題還是從需求、測試用例設計、執行來說吧。

首先要了解這個介面提供的服務的需求定義，那麼我們就知道大概測試的結果是啥。同時理論上要先提供介面規范，方便後續測試，以及給調用者聯調的一個文檔約定。

根據測試的介面規范，基於業務進行場景設計，再結合邊界值設計方法、等價類劃分等常用設計方法進行用例設計。

1.設計的方向是常規的測試用例設計：協議規范測試、介面入參、介面出參。

協議規范測試：比如HTTP協議：URL地址、Header測試。不過一般情況下，默認調用者按照介面規范正常調用。這個不用過於詳細測試。

2.介面入參：參數個數測試(注意是否必傳欄位），參數值測試（為空、正常值、非法值等，以及首尾有空格是否過濾）。

3.介面出參：至少涵蓋一條成功的響應和一條失敗的響應，當然我們測試出更多錯誤碼，我們的覆蓋率也就更全面。

4.業務場景用例： 這個需要你對於這個介面的業務的了解程度，而且這是最重要的部分。

比如中間使用了緩存服務（第一次緩存沒有，是不是直接讀數據源，並存入緩存；第二次直接讀取緩存是否正確）；

比如需要考慮請求外部的介面獲取相應的信息的時間損耗（連接不上外部介面，外部介面下線了，外部介面響應太慢）；

1.需要你對介面協議有一定的了解，選擇適當的開源工具（如postman）或者自己編寫腳本進行模擬請求。

2.需要熟悉介面所使用的中間件等知識（比如redis、kafka、mysql資料庫）。

3.需要模擬外部介面返回給你現在正在驗證的程序的介面。（比如扣費業務，你不可能每測一個業務，就去調真實扣費）。

是web開發介面嗎？建議使用Postman

一、什麼是介面？

介面測試主要用於外部系統與系統之間以及內部各個子系統之間的交互點，定義特定的交互點，然後通過這些交互點來，通過一些特殊的規則也就是協議，來進行數據之間的交互。

二、 常用介面採用方式：

1、webService介面：是走soap協議通過http傳輸，請求報文和返回報文都是xml格式的，我們在測試的時候都用通過工具才能進行調用，測試。可以使用的工具有apipost、jmeter、loadrunner等；

2、http api介面：是走http協議，通過路徑來區分調用的方法，請求報文都是key-value形式的，返回報文一般都是json串，有get和

post等方法，這也是最常用的兩種請求方式。可以使用的工具有apipost、jmeter、loadrunner等；

三、前端和後端

前端：網站前端是對網頁靜態頁面的設計，通俗的來說，就是我們肉眼能看的到的東西，當我們瀏覽網站的時候所看到的頁面上的內容幾乎都是屬於前端，前端的工作就是網站頁面，靜態的頁面是沒有後端成分的，前端主要包括html和css外加js等一些樣式和布局。

後端: 網站的後端就是動態網站的技術，比如網站上的一些注冊登錄和一些彈窗，這些都是後端的邏輯，常用的後端語言有php，jsp等，後端的資料庫也包含myspl等，都是對後端進行存儲數據。

四、 介面測試概念

介面測試是測試系統組件間介面的一種測試。介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等(通俗來說就是，檢查業務邏輯是否滿足業務需求，校驗欄位是否正常你實際結果是否滿足預期)

五、 介面的組成:

a、介面說明

b、調用url

c、請求方法（getpostput等）

d、請求參數、參數類型、請求參數說明

e、返回參數說明

六、為什麼要做介面測試，介面測試的目標

介面其實app和前端交互用的,所以好多人問，為啥做功能測試還要測介面，目標是啥不是多此一舉嗎?首先我告訴大家，這種想法是錯誤的

那麼舉一個例子:

例如一個登陸介面，例如產品上規定用戶名6-10個字元數字下劃線，但後端沒做判斷。但我們業務人員測試肯定驗證，但只是前端做了校驗，後端壓根就忘了這個小需求.那麼後果來了如果一個懂的直接抓包去篡改你的介面，然後繞過校驗，通過sql注入直接隨意登錄。如果你這是一個下單業務，是不是給公司造成了很大損失

所以此時此刻介面測試目標來了:

1.可能發現客戶端沒有發現的bug(那麼也叫隱藏bug)

2.及早爆出風險（保證質量正常上線）

3.介面穩定了，前端隨便改

4.最重要檢查系統安全性，穩定性

七、如何進行介面測試

1.使用介面測試工具進行測試，介面測試和介面文檔生成工具apipost，介面測試和性能測試工具jmeter

2.介面狀態碼表示含義

例如:200(成功)/300（重定向別的地方）/400（請求語法錯誤）/500(伺服器異常)

測試點:

B. 參數組合（傳入不同值）

C. 介面安全(繞過驗證/繞過身份驗證/參數是否加密等)

D. 異常驗證（輸入異常參數邊界值）

練

⑥ Springboot之介面簡單加密和驗證

跟第三方系統打交道時一般會雙方協商一組秘鑰，然後將介面的參搭埋豎數進行約定的處理，防止介面被盜刷。

通用參數，在header上加入兩個參數，參數知大信息如下：

同一組參數只在液族10s內有效，考慮到伺服器和客戶端時間差，前後5秒有效。

入口函數

倆個驗證函數

⑦ 介面sign加密怎麼做介面測試

對於介面測試來說，項目測試用例的重復運行首先是表現在單個測試用例的獨立性方面的，也就是說，每一個測試用例的運行除了依賴被測對象和對應的資料庫環境外，是不依賴於其他任何測試用例的，並且這個測試用例執行完畢後

⑧ 介面測試中的加密演算法如何實現

加密實現對於測試而言，的確是件頭疼的事情，畢竟大多數測試沒有編碼基礎，即便有編程也是短板，要是實現加密演算法的話，主要有兩種方式:
1. 可以以純編碼的方式實現,比如使用 Java 或 Python等
2. 如果是測試工具的話，比如Jmeter，可以求助開發將加密演算法導出為 jar 包，然後我們測試再在 Jmeter 中導入jar包，再調用類似於 BeanShell 取樣器的組件，調用開發提供的加密函數(可以一定程度的減少代碼量) 獲得更多關於測試的知識，建議你去找視頻學習一下，黑馬程序員官網就有很多專業的視頻，應該挺適合你的。

⑨ type-c介面的IP67防水測試/氣密性檢測流程是怎樣的呢

IP67標准為水深度為1米（測試壓力設置在10kPa左右）。一般測試時會提高壓力，在15-20kPa壓力下,將測試夾具與Type-C介面氣密性測試機連接後進行防水性能測試。設置好測試參數後，即可將Type-C待測產品放置在測試模具中進行檢彎褲塌測純春。具體測試步驟是，將Type-C介面待測產品放置在夾具中埋圓，按下工裝的開始按鈕，氣缸自動下壓將密封圈壓緊,側位氣缸實現密封，啟動戈埃爾（GOEL）Type-C介面氣密性測試機（氣密性測試儀）依據設定好的參數實現自動檢測。水槽若有氣泡產生，證明不合格，若無氣泡產生，就證明是合格的。檢測結束氣缸自動抬起，作業員取出產品，放入下一個產品繼續進行下一輪密封性測試/防水檢測。

type-c介面的IP67防水測試/氣密性檢測

⑩ 如何做介面測試

然後，根據該介面功能及代碼寫測試用例：根據該介面參數，構造不同的用例，測試介面在參數合法及非法情況下能否達到預期效果，根據該介面中的邏輯，測試該介面實現代碼的邏輯，進行容錯及健壯性測試，靜態檢測代碼，看是否有內存泄露、或永遠走不到的分支、代碼規范及邏輯是否合理，對碰圓搏於一些介面，需要進行多線程測試。