java的反射和依賴注入、控制反轉(spring思想):
反射：1，反射機制指的是程序在運行時能夠獲取自身的信息，實現動態創建對象和編譯，比較靈活。缺點是對性能有影響。
2，.class-->.java
3，通過反射機制訪問java對象的屬性，方法。
IOC是概念，實現的是DI。 AOP也算是一種IOC
依賴注入:在運行期，由外部容器spring動態地將依賴對象注入到組件中
控制反轉:spring容器初始化，創建並管理bean對象，以及銷毀它
從Spring的角度看，AOP最大的用途就在於提供了事務管理的能力。事務管理就是一個關注點，你的正事就是去訪問數據庫，而你不想管事務（太煩），所以，Spring在你訪問數據庫之前，自動幫你開啟事務，當你訪問數據庫結束之后，自動幫你提交/回滾事務！
DI其實就是IOC的另外一種說法。DI是由Martin Fowler 在2004年初的一篇論文中首次提出的。他總結：控制的什么被反轉了？就是：獲得依賴對象的方式反轉了。
1，sql的多表聯查各種方式
——內連接，左連接，右連接
2，測試計划
——分幾輪測試，提測的時間節點，各個模塊完成時間，
——測試內容，測試分工，測試方法和測試進度
3，測試報告
——風險點、改動內容、測試過程碰到的問題、測試點、遺留問題、建議
——項目基本情況（比如提測時間、提測次數、參與人員）
4，測試case如何寫覆蓋的更廣（更成熟的測試用例）
——1，測試前，了解項目需求，關注可測性，列出功能划分圖。
——2，根據功能的復雜程度按照每個功能；或一個功能點分多頁；或多個功能點合成一頁來進行用例的撰寫。這是按照功能切面來說，其他方法比如說等價划分類(有效、無效)、臨界值、因果圖等，都是在用例編寫時自然會用到的，包括正向和反向。還有后台功能，界面上不會體現的，需要了解業務的后台服務系統再去編寫，最后還需要進行風險分析。保證覆蓋高風險的，低風險的盡量覆蓋。
5，Linux查進程，強制殺死進程、看內存、查看日志
——ps -ef e是列出所有進程 f是顯示格式
——kill -9。如果還殺不掉，那就殺掉這個進程的父進程(PPID)
——top和free -m .free比較簡單、占用很少的系統資源。
——grep
6，loadrunner的組件、關聯函數、其他主要函數
——虛擬用戶生成器、控制器、負載發生器和分析器
——關聯函數web_reg_save_param
——web_custom_request, web_submit_data,web_url
7，string a = new string(“abc” )有幾個對象？
——兩個，一個a，一個”abc”
8，sql去重語句、兩條完全重復的記錄如何查詢，用關鍵字
——delete from xxx group by x having count(x)>1
——distinct
刪除一張表
——DROP TABLE
9. 在測試的過程中發現的最有趣的bug是什么？
——我們以前有個群組記賬項目。從其他群組添加成員，但當前列表中列出的成員還會有當前群組的成員。這個是要排除掉的，因為選的是其他群組
(1)是怎么發現的？
——1，客戶端發現選擇從其他群組添加成員的時候，也顯示了當前群組的成員
2，抓包看請求，/api/book/members/other，確實客戶端也發了這個請求
3，看接口文檔，接口文檔確實也是這樣寫的，請求是對的
4，分析接口的參數，請求其他的群組成員什么信息都不帶，只發個other請求看似是不行的
5，問服務端開發這個接口怎么定義的，探討結果發現需要帶參數booKID
10. 對這個有趣的bug是怎么處理的？
——服務端開發更新接口文檔，和客戶端重新聯調，接口上傳參數bookID
11. 為什么要做測試(我之前是做開發的)
——測試和開發是兩個關注點不一樣的工作。開發的目標是實現功能，測試的目標是確定功能是否能夠正常運作。那么它的樂趣在於兩個關鍵詞：“發現”和“分析”。
如何發現？通過用例設計，了解項目架構去發現缺陷
如何分析？基本的原因定位，模塊划分，減少開發分析bug的時間。
開發也要盡量將測試帶入開發過程，讓大家都知道各個功能進度的細節，這樣能減少需求變更時重新設計用例的時間。
12. 談了談之前我做過的一些項目，印象最深的項目有哪些？並由此進行了一些交流
——
13. 之前項目中都遇到了什么困難，都是怎么解決的？
——1，需求變化太亂。讓產品每次修改和產出新的需求都要發郵件或者其他方式通知相關人員。2，沒有獨立穩定的測試環境，開發也在同一個環境下開發。測試團隊申請搭建了一個測試環境。3，自動化維護成本高。盡量地把可以復用的類和方法都封裝起來，建立UI對象庫。
14，robotium為什么要重簽名？
——Robotium是基於Instrumentation框架的。Robotium編寫的測試腳本與被測程序運行在同一個進程里面，所以這需要測試程序與被測程序擁有相同的簽名
15，java的線程安全，有哪些類是
——實現了同步機制的，在多線程同時訪問某一個資源的輸出結果和單線程運行是一樣的。StringBuffer ,vector ,hashtable。
16，Junit和testNG的區別
——結論是兩者差不多，一般人用用testng就好。
原因：1.testng底層調用junit
2.歷史上曾有testng優於junit的一段時期，但隨后junit已更新並追趕上來
3.testng的data provider使用較方便
4.testng能做的事情junit都能做，但是有的地方會比較麻煩，例如，數據驅動，多線程並發執行測試用例。testng更便捷，自帶。junit則要依靠第三方工具提供。
5.junit能做的事情testng也都能做，但junit也有更便捷的時候。比如soft assertion，junit可以直接繼承jassert做，testng你要自己去實現靜態類來做。
6.junit是testng的底層，靈活度上更高。testng調用junit，對測試員來說用戶體驗更好。
17，testNG原理
18，loadrunner響應時間在哪里看
19，如何成為一個優秀的android測試，規划是什么。
——核心工作是項目質量保障，上游包括需求評審和用例評審。檢查需求是否完整，有漏洞，並且如何細化測試都要體現在用例里。下游：自動部署，灰度發布，代碼review，冒煙自測，引入產品，交互在測試階段進行UI走查。 （整理項目對應的工程和服務，部署方式，對應機器，依賴關系，責任人）
——比產品人員更了解產品的細節方面，能看懂代碼，能調試源代碼，能發現各種奇葩的bug。目的主要是為了提高測試的效率和開發迭代的速度，而不是為了自動化而自動化，
——理解測試流程、懂業務模型、主動補位
——然后想自己寫一個接口自動化的平台。能夠提高測試的效率和開發迭代的速度。
20，android底層SDK
——
21，多線程了解
——兩種方式實現，繼承thread類，實現runnable接口。線程安全就是實現了同步機制的，同一時間內資源只能被一個線程訪問。
22，https了解
——https實際就是在TCP層與http層之間加入了SSL/TLS來為上層的安全保駕護航，主要用到對稱加密、非對稱加密、證書，等技術進行客戶端與服務器的數據加密傳輸，最終達到保證整個通信的安全性。
23，320表示什么。
——重定向
24，java常見的異常。
——NullPointerException - 空指針引用異常
——ClassCastException - 類型強制轉換異常。
——IndexOutOfBoundsException - 下標越界異常
——RunTimeException（運行時異常）
25，linux下通過一個字段遍歷文件夾
——find grep
26，linux怎么創建軟連接、linux文件里怎么刪除一行。
——ln -s f1 a （a就是文件f1的軟連接，ln -s）
——刪除文件夾 rm -rf
——在查看模式按dd，刪除光標所在的一行。(也可以用sed命令)
27，linux。直接殺掉一個java進程。改變用戶組，775。chmod修改權限。
——pkill -9 java
——777， 順序第一二三分別表示用戶，用戶組，其他人。
數字代表讀、寫、執行操作權限（二進制111代表3個操作權限）
——chmod 修改權限。 chmod g+rwx a.txt 給同組用戶增加讀寫執行權限。
——chown 修改文件的擁有者（一般只有root權限者使用）
28，數據庫端口號和tomcat沖突，怎么辦。MySQL數據庫默認端口是多少。
——
——3306。
29，重寫的方法的權限。
——被重寫的方法的訪問權限不能為private
——子類的訪問權限不能小於父類的訪問權限
30，因果圖。使用場景。
——因果圖法就是從程序規格說明書的描述中找出因（輸入條件）和果（輸出或程序狀態的改變），通過因果圖轉換為判定表，最后為判定表中的每一列設計一個測試用例。
——使用場景：充值金額是因，返回結果是果。
31，java多態存在的必要條件。
——1、要有繼承；2、要有重寫；3、父類引用指向子類對象。
32，java注解和反射？如何寫。
——注解：自定義注解，跟創建java類的形式差不多。只是把class換成了@interface 例：java public @interface test
——反射:就是在運行期間，如果我們要產生某個類的對象，Java虛擬機（JVM）會檢查該類型的Class對象是否已被加載。如果沒有被加載，JVM會根據類的名稱找到.class文件並加載它。一旦某個類型的Class對象已被加載到內存，就可以用它來產生該類型的所有對象
——Class tc = Class.forName(className)，
——employee = (Employee)tc.newInstance()
33，loadrunner關聯
——設置了關聯，所以無論是錄制過程還是回放過程，只要是服務器返回的，都記到一個變量里面，這樣一來，服務器反饋什么，腳本就記錄什么，而且是動態的。
34，接口測試，測試數據、參數、期望值都可以存放在數據庫里。提升效率主要體現在回歸這一方面，舊的接口可以都跑一邊，驗證是否有問題。
——1，如果接口的返回值不一定是正確的，也可以直接驗證數據庫和文件系統
——2，如果接口是異步的，需要等待它執行結束。那么就需要一個邏輯輪詢接口狀態
35，runnable比thread好。
——1，避免點繼承的局限，一個類可以實現多個接口。
——2，適合於資源的共享
36，如何保障產品質量？
—— 1，業務邏輯
2，工程/服務的關聯
3，代碼提交記錄
4，開發設計文檔
5，Case/技術評審
6，需求范圍
7，多詢問
8，內部評審
9，項目review
10，歷史上的坑。
—— 1，建立完善的測試流程，開發自測，QA主測，產品驗收。
2，bug是不可避免的，關鍵是不產生故障（即嚴重bug），以及發生線上bug后有及時的處理措施。依靠用戶反饋和其他渠道，獲得bug信息用於復現。
37，json解析原理
——
1.碰到[或{就new一個對象，並將對象存放到collections中去
2.碰到'\\'需要轉義的，得直接跳過去，並存放到掃描出來的臨時變量中去。比如\\{就不需要new一個對象
3.碰到"符號，就要打個標記，在下一個"出現之前，把掃描出來的都當成一個字符串放到臨時變量中去。
4.碰到:符號，就要開始標記是個map的開始了，並把之后出現的字符串都存放到另一個臨時變量中去。
5.碰到,符號，就要開始處理臨時變量了，如果是map就把之前存的兩個昨時變量，一個作為KEY，一個作為VALUE，都放到collections中對應的map中去，如果是list,則把之前存的第一個臨時變量，放到collections對應的list中去。
6.碰到]或}符號，則表示一個list或map被解析完全了，則這時候要去更新index中的對應的list或map的狀態了。
39，怎么自動部署
——自己寫shell腳本 我用的java+svn+maven。shell執行 deploy api自動完成以下過程：
1.svn update 最新代碼
2.maven進行package打包
3.將生成的war包移動到tomcat/webapps目錄下，並且將tomcat restart
40，tcp/ip以及和http的關系
1，TPC/IP協議是傳輸層協議，主要解決數據如何在網絡中傳輸，而HTTP是應用層協議，主要解決如何包裝數據
2，get和post的區別
get是從服務器上獲取數據，post是向服務器傳送數據。
get傳送的數據量較小，不能大於2KB。post傳送的數據量較大，一般被默認為不受限制。但理論上，IIS4中最大量為80KB，IIS5中為100KB。 get安全性非常低，post安全性較高。但是執行效率卻比Post方法好。
參數的傳遞方式不同(get用url或者cookies，post放在body里)
41，工作3年的感悟，客戶端和web端的區別。
1，中斷的情況（來電、短信等）
2，卸載安裝
3，兼容性考慮的去web多（橫豎屏、手機型號、廠家、分辨率和屏幕大小）
4，手機系統自身的限制，導致死機、重啟之類的。（web端很少會有這個問題）
42，測試流程
1，需求給出並召開需求評審
2，開發根據需求給出開發計划，測試根據開發計划給出測試計划（分幾輪測試，提測的時間節點，各個模塊完成時間。測試內容，測試分工，測試方法和測試進度）
3，在開發提測前進行冒煙case和全部case的評審，並在提測前一天提供給開發冒煙case自測，如果不通過，打回。期間進行部分接口測試。
4，開發提供測試包后，根據測試用例執行，發現問題並提交。
5，開發修復並發出新測試版本時，需要給出releasenote（修復的問題，可能影響的地方，打包分支）
6，確認bug修復並關閉。項目上線前重復循環這個過程，（在這個過程中，我一般會去了解下工程/服務之間的關聯，然后也會去看下開發的代碼提交記錄，進行簡單的review）。最終合並代碼后，進行全面的回歸測試。
7，上線后進行線上驗證並編寫測試報告（遺留問題、風險點、建議，其他項目的基本情況，比如冒煙不通過次數，bug reopen次數）
43，專項測試
1，電量測試：收集和分析那些直接間接會影響耗電的數據。
2，內存測試：adb命令獲取，adb shell dump sys memento.
Memory Monitor查看內存風險
MAT分析內存泄露
3，應用響應時間：chrome://inspect
4，弱網測試。（Charles可以設置）
5，卡頓測試。Systrace和TraceView
6，界面流暢度。GPU繪制消耗
44，UI自動化的框架搭建以及測試報告
——數據模板、配置中心、參數中心（把excel讀取出來的轉化為參數對象）、觸發器（封裝請求方式）、監聽器（監聽運行狀態、失敗重跑、超時報警、異常停止報警）、期望檢查、輸出報告。
——測試報告
45，你覺得自動化能做什么？
——用自動化做什么了？為什么用自動化？自動化帶來多少好處。
——持續集成后每次都可穩定跑才算是一個真正的自動化
——自動化只是眾多手段中的一種，最終做到更有效的質量監控才是核心
46，UI自動化的作用
——每一次的迭代的UI自動只是做一些核心業務的冒煙、回歸，並不能發現什么問題，只是保證核心問題沒問題
47，什么是持續集成。
——持續集成是頻繁、持續的在多個團隊成員的工作中進行集成，並且給與反饋。一個典型的持續集成周期包括以下幾個步驟：
- 持續集成服務器不斷從版本控制服務器上檢查代碼狀態，看代碼是否有更新。
- 如果發現代碼有最新的提交，那么就從版本控制服務器下載最新的代碼。
- 等代碼完全更新以后，調用自動化編譯腳本，進行代碼編譯。
- 運行所有的自動化測試。
- 進行代碼分析。
- 產生可執行的軟件，能夠提供給測試人員進行測試。