1 做接口測試當請求參數(shù)多時tps下降明顯癞谒，此接口根據(jù)參數(shù)從redis中獲取數(shù)據(jù)，每個參數(shù)與redis交互一次榄融，當一組參數(shù)是tps5133缕贡，五組參數(shù)是tps1169翁授，多次交互影響了處理性能，請詳細闡述如何改進增進效果的方案晾咪。
將從redis獲取數(shù)據(jù)的get改為mget收擦，減少交互次數(shù)(參考：http://www.cnblogs.com/dimmacro/p/4849729.html)
2 接口的加密測試中對稱加密與非對稱加密有什么區(qū)別? 如何開展測試? 請詳解
對稱加密是最快速、最簡單的一種加密方式谍倦，加密（encryption）與解密（decryption）用的是同樣的密鑰（secret key）,這種方法在密碼學中叫做對稱加密算法塞赂。
對稱加密的一大缺點是密鑰的管理與分配，換句話說昼蛀，如何把密鑰發(fā)送到需要解密你的消息的人的手里是一個問題宴猾。在發(fā)送密鑰的過程中圆存，密鑰有很大的風險會被黑客們攔截。現(xiàn)實中通常的做法是將對稱加密的密鑰進行非對稱加密仇哆，然后傳送給需要它的人沦辙。
非對稱加密為數(shù)據(jù)的加密與解密提供了一個非常安全的方法，它使用了一對密鑰讹剔，公鑰（public key）和私鑰（private key）油讯。私鑰只能由一方安全保管，不能外泄延欠，而公鑰則可以發(fā)給任何請求它的人陌兑。非對稱加密使用這對密鑰中的一個進行加密，而解密則需要另一個密鑰由捎。比如兔综，你向銀行請求公鑰，銀行將公鑰發(fā)給你隅俘，你使用公鑰對消息加密，那么只有私鑰的持有人--銀行才能對你的消息解密笤喳。與對稱加密不同的是为居，銀行不需要將私鑰通過網(wǎng)絡(luò)發(fā)送出去，因此安全性大大提高杀狡。目前最常用的非對稱加密算法是RSA算法.
開展測試-TBD
3 請詳細闡述接口測試和UI測試在測試活動中是如何協(xié)同測試的蒙畴？
接口測試和UI測試這兩塊其實是有一部分是重疊的，UI測試是通過前端寫的界面呜象，來調(diào)用接口膳凝，而接口測試是直接調(diào)接口。所以排除前端的處理的邏輯和調(diào)用的正確性恭陡，在理論上接口測試是可以覆蓋所有的UI測試蹬音。但實際過程中，如果只是在接口層覆蓋所有的業(yè)務(wù)流休玩，在UI上只測試前端的邏輯著淆，最終的結(jié)果可能會是忽視很多原有的功能點，導致了UI測試的不充分拴疤。所以存在多人分工且時間充分的時候可以嘗試接口去做業(yè)務(wù)流的全覆蓋永部，否則不要輕易嘗試。
4 在手工接口測試或者自動化接口測試的過程中呐矾，上下游接口有數(shù)據(jù)依賴如何處理苔埋？
在工具中可以使用全局變量等方式將需要的數(shù)據(jù)進行傳送。
5 依賴于第三方數(shù)據(jù)的接口如何進行測試蜒犯？
可以使用SoapUI等工具直接調(diào)用第三方數(shù)據(jù)接口的webservice组橄，通過返回值來查看第三方數(shù)據(jù)的接口是否調(diào)用正常荞膘。
也可以利用一些MOCK的工具來模擬第三方的數(shù)據(jù)返回，最大限度的降低對第三方數(shù)據(jù)接口的依賴晨炕。
6 接口測試中依賴登錄狀態(tài)的接口如何測試衫画？
依賴登錄狀態(tài)的接口的本質(zhì)上是在每次發(fā)送請求時需要帶上Session或者Cookie才能發(fā)送成功，在構(gòu)建POST請求時添加必要的Session或者Cookie
7 http接口測試和web Service接口測試區(qū)別是什么瓮栗？
區(qū)別是有的削罩。主要是傳統(tǒng)ws有一套完整的協(xié)議標準。其中有soap協(xié)議费奸，用來進行消息的傳遞弥激。以傳統(tǒng)工業(yè)標準的ws返回數(shù)據(jù)為例，返回結(jié)果需要包裝在一個soap協(xié)議指定的語法格式中愿阐。即使你只需要簡單的返回字符1微服，也需要包裝在協(xié)議種返回，協(xié)議描述了成功失敗否缨历，結(jié)果值等以蕴。而普通的get，你輸出1辛孵，在調(diào)用端得到字符1丛肮。
web service和http接口的區(qū)別在于：
1.接口中實現(xiàn)的方法和要求參數(shù)一目了然。
2.不用擔心大小寫問題魄缚。
3.不用擔心中文 urlencode 問題宝与。
4.代碼中不用多次聲明認證（賬號，密碼）參數(shù)冶匹。
5.傳遞參數(shù)可以為數(shù)組习劫，對象等。
8 設(shè)計接口測試用例例時嚼隘，涉及的是電商系統(tǒng)诽里，其中包括很多修改，如商品飞蛹、商家须肆、店鋪等等，針對這些數(shù)據(jù)的修改桩皿，會涉及到很多參數(shù)豌汇。如商品的名稱，商品的尺碼泄隔，商品的顏色等等拒贱。那在設(shè)計實現(xiàn)“修改”接?口時，如何確定要傳哪些參數(shù)？是只需要傳我要修改的參數(shù)逻澳，還是全部參數(shù)都要傳闸天？
關(guān)鍵還是看后臺邏輯實現(xiàn)。
舉例：User有兩個屬性username,password
后臺邏輯實現(xiàn)：update User set username=? where id=xxx;
那斜做，如果你只想更新username的時候苞氮，可以不傳password，其值是保持不變的瓤逼。
后臺邏輯實現(xiàn)：udpate User set username=?,password=? where id=xxx;
這種情況下笼吟，即使你只想更新username,也需要傳password的值給后臺，不然password就會被更新為空霸旗。
此外贷帮，還有一些數(shù)據(jù)如id等，如果sql中沒有寫诱告，那即使傳遞了本字段的參數(shù)撵枢，數(shù)據(jù)庫也不會更新。因此精居，在寫關(guān)于“修改”的接口時锄禽，需要考慮一下，后臺的邏輯是怎么實現(xiàn)的靴姿，然后確認要傳遞哪些參數(shù)沃但。
9 目前接口文檔是由word格式管理理，因迭代快空猜，產(chǎn)生很多文檔绽慈，分不不清哪些是不用的接口恨旱，哪些是正在用的接口辈毯，哪些是更新后的接口，文檔雜亂搜贤，另外因是word格式管理谆沃，不方便查詢，如何管理仪芒？每次查看接口文檔需要下載多個word唁影，不能避免下載操作查看，效率不高掂名，如何提高工作效率据沈？
如果是webservice，使用WSDL的格式來進行查看接口的文檔饺蔑，以前的接口必要的時候使用一些配置管理的工具锌介，比如wiki之類的系統(tǒng)來實時更新現(xiàn)有的接口狀態(tài)
以上面試的問題為網(wǎng)絡(luò)收集，答案為個人理解，服用不適者請留言孔祸。
