軟件測試和Java大數據哪個更好？
1. 軟件測試工作即為測試人員，所需要做的就是將程序員寫出的程序進行各種測試案例的測試，流程測試、自動化測試都是測試人員應該掌握的技能。
2. Java大數據，感覺對於沒有3-5年工作經驗的人來說的話屬於談空話了，這個設計的技能比較高深，而且得根據實際需求來進行分析與制定相應的開發策略。
請問什麼是大數據測試和疲勞強度測試?
大數量測試，其實就是用大批量數據來進行測試，我們需要用一定的腳本代碼或者是工具，幫我們生成大量可用的測試數據。比如說：編寫sql腳本（存儲過程）在數據庫端直接生成、編寫程序代碼生成（實際上也是要寫sql）、使用批量數據生成工具（DataFactory、PL/SQL Developer、TOAD等都可以）、使用工具錄製業務參數化之後長時間運行來生成。舉個例子：你需要測試一個註冊功能，需要提供手機號碼以及註冊名以及密碼，那麼你如果要做大數據量測試，要提前準備好很多有效的手機號以及註冊名、密碼，最少是百萬級數據。 疲勞強度測試隸屬於壓力測試範疇，指的的是服務器在長時間下持續接受大批量的用戶請求操作。這個設計到軟件和服務器的穩定性。
大數據技術在APP測試上面如何應用？
都說現在是大數據時代，各行各業在運用大數據上獲得效率提升或者精確度提升，可是測試彷彿還是老樣子，在APP測試行業有沒有我不瞭解的大數據應用呢。
數據獲取手段、數據處理技術的改進導致"大數據"爆發。測試行業對於大數據的應用也是很多的，比如TestBird在做測試時是基於大量的數據基礎的，對於測試的分析和bug探索效果都能有很大的提升。
當然，在測試技術上，也有很好的大數據運用例子。比如你可以通過大數據統計點來寫測試用例。產品需要快速迭代，又要保證版本質量不下降，就必須做到精準測試的用例精簡。
也就是統計用戶行為預埋下的點，用戶使用次數的數據穩健並且有跡可循，測試路徑就非常的清晰明朗。
Hibernate進行大數據量性能怎麼測試？
在項目中使用Hibernate進行大數據量的性能測試，有一些總結，
1. 在處理大數據量時，會有大量的數據緩衝保存在Session的一級緩存中，這緩存大太時會嚴重顯示性能，所以在使用Hibernate處理大數據量的，可以使用session.clear()或者session. Evict(Object) 在處理過程中，清除全部的緩存或者清除某個對象。
2. 對大數據量查詢時，慎用list()或者iterator()返回查詢結果，使用List()返回結果時，Hibernate會所有查詢結果初始化為持久化對象，結果集較大時，會佔用很多的處理時間。而使用iterator()返回結果時，在每次調用iterator.next()返回對象並使用對象時，Hibernate才調用查詢將對應的對象初始化，對於大數據量時，每調用一次查詢都會花費較多的時間。當結果集較大，但是含有較大量相同的數據，或者結果集不是全部都會使用時，使用iterator()才有優勢。對於大數據量，使用qry.scroll()可以得到較好的處理速度以及性能。而且直接對結果集向前向後滾動。
3. 對於關聯操作，Hibernate雖然可以表達複雜的數據關係，但請慎用，使數據關係較為簡單時會得到較好的效率，特別是較深層次的關聯時，性能會很差。
4. 對含有關聯的PO（持久化對象）時，若default-cascade="all"或者 "save-update"，新增PO時，請注意對PO中的集合的賦值操作，因為有可能使得多執行一次update操作。
5. 在一對多、多對一的關係中，使用延遲加載機制，會使不少的對象在使用時方會初始化，這樣可使得節省內存空間以及減少的負荷，而且若PO中的集合沒有被使用時，就可減少互數據庫的交互從而減少處理時間。
什麼叫n+1次select查詢問題?
在Session的緩存中存放的是相互關聯的對象圖。默認情況下，當Hibernate從數據庫中加載Customer對象時，會同時加載所有關聯的Order對象。以Customer和Order類為例，假定ORDERS表的CUSTOMER_ID外鍵允許為null，圖1列出了CUSTOMERS表和ORDERS表中的記錄。
該如何檢查代碼錯誤呢？
特別是邏輯錯誤，能通過題目和自己的小測例，但是不能通過大數據測試。
可以在網上尋找標準程序(一般都會有)，如果沒有的話寫一個可以確保正確的暴力代碼，然後寫一個隨機生成數據的程序，用一個bat文件，不斷的造小數據讓自己的代碼和標算(暴力)跑，校對答案。(以上方法俗稱對拍)
bat 文件如下
:1
make_data
a
a_
fc a.out a_.out
if errorlevel==1 pause
goto 1
a為你的程序的名稱，a_為標算或暴力，fc如果不能使用可以去C盤裡找出來，然後放到程序邊上。
由於數據是隨機生成的，所以如果代碼有明顯的漏洞，很容易就拍出來(尤其是一些細節上的問題)，當然也有代碼在隨機數據的情況下表現的非常好，但是會被構造的數據卡掉，可以嘗試構造極端的數據來進行測試。
總的來說對拍對的代碼不一定就是正確的，遇到錯誤時最好還是先再理一遍自己的思路，跟著自己的代碼走一遍，確認思路沒有錯之後再使用對拍。
有大數據測試崗位嗎？
大數據分析其實沒有那麼玄乎，對於測試來說你可以這樣分解一下。首先大數據分析=一個計算器，只不過可能是一個性能功能很強大的計算器；如果把計算器視作黑盒，那麼你可以沿用構造輸入，驗證輸出的模式來製作測試用例。但輸入部分如何構造海量數據，如何隨機插值這就需要你自己研究了。其次如果我們關注計算器本身，那麼涉及到的一般就是性能測試。所以目前好像並沒有在大數據分析上分化出一個獨立的測試分支。
一般來說大數據領域並沒有說對應傳統軟件開發那樣的測試崗位，或者相關的職能。如果說框架測試，或者部分分佈式存儲的讀寫測試，其實一般的大數據平臺開發工程師來勝任，來做框架的初期選型調研，或者一些分佈式文件系統的讀寫性能測試等等。總的來說，這個模塊相對較少相關的需求，即使有，偏集群運維的數據開發工程師也是可以做的，所以應該是沒有專門的測試崗位的。
閱讀更多 51Testing企業服務 的文章
