# 背景
純屬個人總結，總結下目前接觸到測試方法/體系
# 個人總結
從開發架構上來分層
目前接觸到項目，基本上都是如下圖的架構模式（MVC），每一層都衍生出對應的測試
對應的測試：
看看市場上的測試崗位，大多數都是圍繞這這些來設定的：功能測試，自動化測試，測試開發，性能測試，服務端測試
個人最近幾年都是服務端測試，基本上也是在接口層，但目前偏重資料層，也明白了資料的重要性，業務的根源在資料，從資料上可以反應業務的健康度
不要被表象中的自動化，性能所迷惑，覺得做測試往上走就是搞自動化，性能，這樣太局限了；
有這麼一種情況值得思考：即使你自動化搞的非常牛逼，性能也是吊炸天，然而業務沒了怎麼辦？ 即使你是工具組的測試開發，沒有業務團隊接入也是扯淡。是以測試的本質的業務的品質，而不是為了測試而測試
自動化是為了提高效率，是為了保證的解決業務的穩定性，性能是為了保證業務的體感
從流程上來分層
上圖是公司大緻的研測流程，應該都是大同小異，備注是測試可以涉及的點
品質體系的建設都跟跟随研測流程，好的品質體系是非常有必要的
說下目前團隊的建設：
需求階段：研發怼産品在這邊很常見，公司的文化就是人人都是産品，這也是對業務的一種幫助，
要勇于對産品需求提出建議看法，要産品提出資料支撐，不能你想做什麼功能就做什麼功能，要有預期的值的估算，如做了XX項目，可以預計xx名額上升20%；
提測：提測需要研發保證主功能沒有問題，列出測試點和自測結果、測試難點，測試記錄打回次數，這是品質的展現，還有單元測試要全部通過，push代碼觸發；
回歸測試：回歸測試平台保證之前積累的回歸用例全部pass，上線卡點
線上：監控體系建設，伺服器資源的監控依賴于公司部署平台，如500錯誤，CPU資源；核心業務場景接口監控，保證核心業務無誤；接口可用性監控；第三方接口撥測監控...保證線上無重大問題；
資料層：大盤資料的監控（門檻值，波動值），資料分析衡量業務健康度；
監控體系是保證線上的無重大故障，或者提前感覺問題；
自動化是測試效率的提升，保障業務疊代的穩定性；
資料分析是資料的累積，業務健康度的考察；
# 最後
以上每一項展開的話，都是一個個課題，測試的水也很深，個人期望自己也能成為某一方面的專家，随着細化，測試也在慢慢細化，如現在的app專項測試，大資料測試，算法測試....
路很長...
雖千萬人，吾往矣！