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