大資料的測試思維與探索

導讀

　　隨著大資料時代的跨入，對測試人員的要求又提升到了一個新高度，這個高度讓一部分測試人員感到措手不及，甚至對未來產生了迷茫。

　　1、如何做到與時俱進

　　2、如何讓自己成為一個優秀的測試人員

　　3、如何轉變自己的思考方式

　　4、如何讓技術能夠有一個質的飛越

　　……

　　每一個測試人員在這個時代都應該認真思考，但僅僅思考並不能解決所有問題，如何做才是關鍵。

 

在這裡我還是要推薦下我自己建的大資料學習交流qq裙： 957205962， 裙 裡都是學大資料開發的，如果你正在學習大資料 ，小編歡迎你加入，大家都是軟體開發黨，不定期分享乾貨（只有大資料開發相關的），包括我自己整理的一份2018最新的大資料進階資料和高階開發教程，歡迎進階中和進想深入大資料的小夥伴
 
 

大資料思維

　　大資料，已經成為了一個時代的代名詞，當今的網際網路屬於大資料時代。大資料時代的到來，顛覆了以往對資料的慣性思考方式。保證資料質量、軟體質量、測試質量、資料利用率、資料使用場景等，都需要重新換一個角度，站在更高的高度進行全方面的思考。這種思考方式稱為大資料思維，即從資料的應用場景切入，思考如何挖掘資料本身的價值，並將其轉變為市場價值。

　　在具有大資料思維之前，需要引發對大資料定義的一個思考，到底什麼才能稱之為大資料？大資料具有三個維度的定義： Volume, Velocity, Variety，而字面上對於大資料的理解，簡單來說就是具備很大的資料量，很大很大的資料量。這就又引出了另外一個問題：多大的資料才能算大資料呢？隨著技術不斷的進步，回望5年、10年前，我們曾經認為已經足夠大的、以GB衡量的資料量，現在已經不能夠稱之為大資料了；也許用不了幾年，TB、PB、EB、ZB，甚至於YB都會成為過去式。既然我們不能夠在數量上對大資料進行一個定義，那麼就需要從另一個角度去重新思考大資料，那就是資料思維，擁有了資料思維，便擁有了大資料的思考方式，也就擁有了大資料。

　　思維是思想層面的、是意識層面的，如果連思維方式都不具備，那麼空有再強的技術也是無用。一切技術都是為業務服務，脫離業務的技術一文不值。這句話在大資料時代的今天，仍然適用，並且會一直適用下去。在普惠大資料中心，每天都面對著海量資料，如何去應用這些資料，如何將資料實現它應有的價值，是最重要也是最需要思考的問題點之一，只有懂得資料的應用場景與方式，才能夠明白資料的重要性，才算是真正跨入大資料思維的門檻。

　　資料思維，直指問題核心，即解決問題的思維。在企業中，作為一名技術人員，就是圍繞著解決問題而進行思考，為此必須要深入需求、瞭解資料建模、懂演算法，一切思考都是為了解決問題，將資料實現它應有的價值。

　　只有真正掌握了核心思想，才能夠更好、更強、更深的提高資料的使用率，因此我們不再以資料量的大小來定義大資料的含義，而是如何使用資料，這便是我們的測試思維、資料思維、質量思維、價值思維。

 

 

傳統測試思維

　　以產品需求為最根本依據，無論測試用例的書寫還是使用者場景的設計全部依照固定的產品需求來進行。

　　示例：

　　傳統測試在產品需求確定完畢後，那麼使用者使用場景已經固定。假設此次測試的產品是一個傳統的電商網站業務，按照使用者的使用行為我們首先要做的就是註冊頁面功能的測試，以黑盒用例設計模式為用例設計思想對輸入框等進行功能性測試、然後進行的是效能測試以及安全測試。

 

 

大資料測試思維

　　以從資料的應用場景挖掘市場價值為最根本的依據，測試人員以質疑的方式針對模型進行測試，同時可以對任何資料使用方式提出合理化建議。

　　示例：

　　知識圖譜專案的測試，關係建立如下：（具體關於知識圖譜相關知識請參閱公眾微訊號中《知識圖譜的應用》文章）

　　以上知識圖譜描述的事實（Fact）是張三是李四的父親，那麼在測試過程中如果測試人員認為張三是李四的父親(is_father_of)的關係形容並不夠精準，那麼我們可以提出自己認為更精準的關係描述，或者是說張三或李四是否具備單獨成為一個實體的條件，(當然在提出質疑前一定是已經進行過深層次的考慮過，並且能夠給出解決方案的建議，我們堅決抵制無解決方案的質疑)對一切質疑、對一切思考，讓一切變的合理，在質疑與思考中不斷的成長。

　　做好測試的前提便是需要這種思維方式，直指問題本身，站在一定高度的思考。

 

 

高效快速的計算

　　具備了資料思維、思考的高度及方式還遠遠不夠，從技術的角度來講，這只是實現了我們如何使用資料的功能、如何使用資料來應對企業各類需求、為企業創收的最基本要求。做到了最基本的要求之後，如何能夠應對大的併發、高效的計算是之後要面臨的一個重要挑戰。

　　· 如何利用好每一塊記憶體區域?

　　jvisualvm、jconsole結合底層命令等觀察記憶體堆疊區域與類物件記憶體佔用生命週期變化。

　　· 如何高效的使用cpu的計算能力?

　　cacti、zabbix、lepux等叢集監控應用程式cpu利用率、記憶體、IO、網路等伺服器資源以及打點計算類執行時間。

　　· 如何從技術以及業務角度優化我們的應用程式架構?

　　滲透學習業務以及擴大知識面，將業務場景與應用程式架構相結合。

　　· 如何利用最少的資源去提升我們程式碼工作的效率?

　　極限優化我們的程式程式碼，優化每一個演算法，不斷的向上抽象，程式碼模組化，以最少的程式碼實現我們的業務場景。

　　· 如何保證我們的程式碼質量?

　　CodeReview、CodeStyle、結對程式設計、TDD多層機制保證程式碼質量。

　　......

　　思考著每一個變慢的可能，思考著如何應對某一天突發的資料量暴增該採取的應對方案。

　　不斷的思考、不斷的準備、不斷的進步，為現在面臨的問題提供最優的解決方案，為將來可能面臨的問題進行預估，做好應急方案。

　　一個優秀的測試人員要習慣變化、擁抱變化並且適應變化，要有危機意識與未來的規劃能力，只有這樣才能夠在危機突然來臨時，有足夠的方案去選擇、應對；即便是沒有預估到某一類危機，也擁有了足夠多的思想準備與方案准備，不至於措手不及與驚慌失措，以最少的時間成本最快地去解決問題。

 

在這裡我還是要推薦下我自己建的大資料學習交流qq裙： 957205962， 裙 裡都是學大資料開發的，如果你正在學習大資料 ，小編歡迎你加入，大家都是軟體開發黨，不定期分享乾貨（只有大資料開發相關的），包括我自己整理的一份2018最新的大資料進階資料和高階開發教程，歡迎進階中和進想深入大資料的小夥伴

安全

　　如何在錯綜複雜的網路環境中保障自己資料的安全性已經成為了一個世界性的課題，網站當機、癱瘓等問題的影響範圍遠遠不能與資料丟失對客戶所造成的傷害相比，傷害客戶的行為就是損害公司利益的行為。

　　國內知名網站被拖庫的事件大大地傷害了一批使用者，在這方面使用者是脆弱的，被傷害了也許這輩子就再也不會回來了（當然壟斷行業就不說了）。為此需要一直從安全的角度進行思考：如何做到不被拖庫、一旦被拖庫後黑客能夠看到哪些資訊；以此來保護使用者以及企業的利益。

　　在如此開放的網路平臺上，為保證安全性，所有的測試人員需要不停地扮演著各種角色，黑帽子、白帽子，不停的演練攻防，自己與自己博弈，既是攻城者又是守城者。感受著不同格式的資料流在程式中流轉、提防著不同的資料可能會給應用程式帶來的危害。可以偽裝成身份合法的使用者來進行訪問(csrf身份偽裝，其實我們是間諜)，也可以變身成為大批量的攻擊者以蠻橫的方式來對網站進行訪問，如同古代攻城般，進行純力量的碰撞(ddos最野蠻的攻擊模式)，變換攻擊手法，變換不同的身份，樂衷於此，在此中體會那一份獨屬於測試人員的樂趣。

　　不過這些手法已經屬於比較大眾的攻擊手法，測試人員的榮譽則是探索到還未普及、周知的手法，這需要永不止步的前進和努力。

　　資訊爆炸的社會，技術的進步也是飛速的。ddos、xss、csrf、sql注入等等攻擊手法五花八門，只有不斷的學習，不斷的成長，不斷的進步才能夠保證與時俱進。

 

 

結語

　　大資料時代已經進入了高速發展的時期，這個時代對測試人員的要求與以往都有所不同，不僅僅是技術，更多的是前面提到的資料思維，只有抓住了問題核心才能夠從根本上解決問題。

　　我們在向著國內頂尖的測試團隊方向努力，全力打造一個一流的、全能的、高精尖的測試團隊。這將是我們不斷奮進、努力的目標。

 

在這裡我還是要推薦下我自己建的大資料學習交流qq裙： 957205962， 裙 裡都是學大資料開發的，如果你正在學習大資料 ，小編歡迎你加入，大家都是軟體開發黨，不定期分享乾貨（只有大資料開發相關的），包括我自己整理的一份2018最新的大資料進階資料和高階開發教程，歡迎進階中和進想深入大資料的小夥伴