按照v模型進行劃分層次：
單元測試
模組測試又稱組建測試，整合測試
系統測試
unit層的測試物件是函式或方法；
service層的測試物件是模組和介面；
ui層的主要測試物件是展示和互動
unit層的測試策略：
1、**走查：開發人員自己檢查自己的**
2、**評審code review：開發團隊組織評審會，應避免走馬觀花，應注重效率
3、單元測試：自動化單元測試，編寫測試**或使用測試工具，缺點：入門門檻高，沒有好的實踐方法（覆蓋率和編寫標準），則可能無法推行，最終淪為雞肋或是詬病。優點能今早的執行，降低測試成本，復用性好，可反覆執行
service層的測試策略：
自動化的元件測試，
自動化的整合測試
自動化的api測試
與單元測試比較：執行速度慢，測試環境搭建困難，case數量較少，
ui層的測試策略：
手工測試：純手工測試執行速度慢，無法重複使用
自動化測試：穩定模組
與其它層面的測試比較：自動化開發難度大，執行速度慢，測試環境搭建困難
對應自動化測試形式：
automated unit tests代表的是unit層
automated component tests(自動化元件測試)/automated integration tests(自動整合測試）automated api test(自動化api測試)代表的是service層
automated gui tests代表的是ui層
分層測試的優勢：
單元測試盡量多做，ui級的測試可以少做一點；
ui測試難度相對較大；
ui測試更接近於真實使用者；
手工ui測試只佔據了塔頂一點點的位置，而大部分的測試工作是手工測試人員所難以介入的，這讓只會手工測試的同學有一定的危機感；
開發人員是質量保障的最關鍵因素，因為測試金字塔的大部分測試工作都需要開發或者是具備開發技能的同學去完成；
正三角是穩固的，如果按照測試金字塔的模型去組織測試工作的話，在一切相對正常的情況下，產品/專案/系統的質量是處在可控的狀態下的。
現實生活中能做到正三角的團隊往往是少數，大部分測試同學接觸到的團隊應該是倒三角的，也就是沒有或只有少量的單元測試，隨心所欲的做一些介面測試，把大量的人力集中在ui測試。這樣的產品質量往往難以控制或者需要花費大量的時間和人力成本才能控制。
前文也提到過偉大的產品剛橫空出世的時候往往是沒有單元測試和ui自動化測試的，但這些產品剛發布時的質量卻是可以接受的或者甚至是優秀的，這是為什麼呢？這是因為偉大的產品往往由天才的開發者建立或實現，天才的**在不做單元測試的情況下也是質量可期的，這就等於是測試金字塔的最底層相當牢固，整個產品質量就自然由保障了；另外這些產品發布的初期規模也相對較小，也比較難出現一些在頻繁協作過程中會出現的問題（比如修改了不是自己寫的**而造成了缺陷），規模小質量控制起來也相對容易些。
總而言之，如果你的產品/專案/系統的開發團隊大部分人都不是天才而且需要進行頻繁協作的話，按照測試金字塔模型去做可能是乙個比較好的方式。另外很多偉大產品剛發布的時候也是沒有測試人員的，這是不是說明沒有專業的測試人員參與的情況下，產品的質量也是可以很好的控制的呢？我相信各位讀者都有自己的答案。
MVP基本思想
mvp的邏輯性思維都在p層,他降低了頁面的耦合度,具備低耦合的特性,mvp的出現使 更具邏輯性 首先我們看到分包的嚴謹性 mvp的結構分析 p層負責整體邏輯並且將m層和v層聯絡起來,m層主要負責 塊,callback將結果集返回p層,v層最後展示檢視 注意以下介面 public inte ce my...
git基本思想
git相比叫傳統的基於檔案svn優勢明顯，主要體現在天然分布式不怕丟失 不以檔案為為基礎，基於git的資料庫 commit雜湊健值檔案 的版本管理，分支 標籤等操作飛速，而不是緩慢地檔案和目錄操作 git下每個人都有乙個獨特的工作區和分支，不必實時和中心伺服器同步就可以 帶有社交性質的基於fork ...
深度學習基本思想 分層的特徵表示（三）
假設我們有乙個系統 s，它有n層 s1,sn 它的輸入是 i，輸出是 o，形象地表示為 o等於輸入 i，即輸入 i經過這個系統變化之後沒有任何的資訊損失 呵呵，大牛說，這是不可能的。資訊理論中有個 資訊逐層丟失 的說法 資訊處理不等式 設處理 a資訊得到 b，再對 b處理得到 c，那麼可以證明 a和...