1、做接口測試當請求參數多時tps下降明顯，此接口根據參數從redis中獲取數據，每個參數與redis交互一次，當一組參數是tps5133，五組參數是tps1169，多次交互影響了處理性能，請詳細闡述如何改進增進效果的方案？
tps就是吞吐量，transaction per second。吞吐量下降是可能因為頻繁訪問redis，而頻繁訪問redis的原因是參數過多，解決的思路很容易想到：減少參數。我們可以把多組參數變成json字符串之類的一個參數，從而達到信息量不減少而參數個數變少的效果。
2、接口的加密測試中對稱加密與非對稱加密有什么區別？如何開展測試？請詳解。
對稱加密：信息交換的雙方使用同一個密鑰加密解密，就像是用同一把鑰匙開一把鎖。 非對稱加密：公開密鑰加密，也稱非對稱加密，是密碼學的一種算法，他需要兩個密鑰，一個是公開密鑰，另一個是私有密鑰；一個用作加密的時候，另一個用作解密。使用其中一個密鑰把明文加密后所得的密文，只能用對應的另一個密鑰 才能解密得到原本的明文；甚至連最初用來加密的密鑰也不能用作解密。由於加密和解密需要兩個不同的密鑰，故被稱為非對稱加密；不同於加密和解密都使用同一個密鑰的對稱加密。顯然兩個密鑰在數學上相關，但如果知道了其中一個，並不能憑此計算出另外一個；因此其中一個可以公開，稱為公鑰，任意對外發布；不公開的密鑰為私鑰，必須由用戶自行嚴格秘密保管，絕不通過任何途徑向任何人提供，也不會透露給需要通信的另一方，即使他被信任。基於公開密鑰加密的特性，它還提供數字簽名的功能，使電子文件可以得到如同在紙本文件上親筆簽署的效果。如何測試？略
3、請詳細闡述接口測試和UI測試在測試活動中是如何協同測試的？
UI與接口測試的協同可以從下面的方向考慮：1）、UI的操作實際上就是用另一種方式調用接口，那么接口有多少種參數組合就要求UI用例要構造多少種操作進行調用。2）、UI操作所需要的數據可以用接口來生成。3）、接口測試可以保證數據和邏輯的准確性，UI測試需要考慮交互和界面展示的邏輯正確性。4）、UI測試需要重視接口調用不成功或者接口異常情況下UI的呈現方式和用戶體驗。5）、UI中可能會有一些狀態的緩存信息（這樣就不需要每次頻繁調用接口去獲取了），比如鑒權信息等，需要重點關注這些緩存的更新策略。
4、在手工接口測試或者自動化接口測試的過程中，上下游接口有數據依賴如何處理？
上下游接口的數據依賴無非就是准備測試數據。假如一個事務需要順序調用3個接口，A B C，C依賴於AB，而AB有數據依賴，這時候就需要准備好A和B的數據。數據一般有兩種方式生成。1）動態方式：假如B依賴A創造的數據，那么每次執行B之前必須執行A去做數據創建。2）、靜態方式：獨立統一的測試數據庫，ABC需要的數據都可以從庫里拿到
5、依賴於第三方數據的接口如何進行測試？
依賴第三方就mock掉，可以自己寫mock server。
6、接口測試中依賴登錄狀態的接口如何測試？
依賴登錄狀態，那么每次測試該接口之前都需要調用登錄的接口。如果是jwt之類的token based auth 的話，每次在調用接口時提供token就可以了。
7、設計接口測試用例時，設計的是電商系統，其中包括很多修改，如商品、商家、店鋪等等，針對這些數據的修改，會涉及到很多參數。如商品的名稱、商品的尺碼、商品的顏色等等，那在設計實現“修改”接口時，如何確定要傳哪些參數？是只需要穿我要修改的參數，還是全部參數都要傳？
修改的接口，也就是update的接口一般只需要傳：被更新了的字段以及被更新實體的主鍵，比如id。這是開發常識，如果大家研究過json api規格的話，可以直接套用json api的設計進行闡述。
8、目前接口文檔是由word格式管理，因迭代快 ，產生很多文檔，分不清哪些是不用的接口，哪些是正在用的接口，哪些是更新后的接口，文檔混亂。另外因是word格式管理，不方便查詢，如何管理？每次查看接口文檔需要下載多個word，不能避免下載操作查看，效率不高，如何提高工作效率？
swagger文檔可以解決這個問題。