MVC架構簡介及其測試策略
最近在WEB端測試工作中陷入了瓶頸，單純的手動功能測試在沒有成熟的代碼規範之前還是很容易坑的，WEB自動化測試一時半會還沒有什麽進展，所以決定先學習一下網站用的MVC架構，跟著教程寫了一個小網站，大概也找到了WEB測試工作的幾個突破口。
MVC即為按照分層解耦的思想，將網站結構分成了Model（模型）-View（視圖）-Controller（控制器）三層架構，三層架構的職責如下：
Model層：是應用程序中用於處理應用程序數據邏輯的部分，通常模型對象負責在數據庫中存取數據；簡單來說，就是在Model層進行業務邏輯的處理；
View層：是應用程序中處理數據顯示的部分，通常視圖是依據模型數據創建的；簡單來說，
Controller層：應用程序中處理用戶交互的部分。通常控制器負責從視圖讀取數據，控制用戶輸入，並向模型發送數據；簡單來說，Controller層用於接收View層發送的請求，收到請求後調用對應Model層進行業務處理，然後將處理後的結果返回給View層。
M-V-C三層的關系大概可以如下圖所示：
根據簽下來的網站代碼調試了之後，發現MVC的實現原理還是很有意思的：
我們以訪問http://localhost:1000/EvectionExpensesManage/EvectionExpensesApply這個為例，來理解MVC的實現原理，調試程序後的結論如下：
View層接到用戶請求，調用EvectionExpensesManageController類下的EvectionExpensesApply方法，根據業務立即得到結果，最後調用對應視圖來顯示結果。
那麽我們仔細對比一下URL的後綴和控制器還有方法的區別，會發現很有意思的一個現象：
/EvectionExpensesManage/EvectionExpensesApply
調用EvectionExpensesManageController控制器下的EvectionExpensesApply方法
也就是說，MVC架構下URL的構成即為對應的控制器類名去掉Controller/調用的方法。
那麽，如果方法有入參怎麽辦？我們再來看另一個URL：
http://localhost:10344/AbnormalPunch/ApplySubmit?ID=13244&EmployeeID=1D2DE5AD8BC74E2A9CA70DE3567472EB
顯然，這個URL即為調用的AbnormalPunchController控制器下的ApplySubmit方法，定位到該方法的代碼為：
public int ApplySubmit(string id, string EmployeeID) { return _AbnormalPunchBLL.ApplySubmit(Convert.ToInt32(id), EmployeeID, Session["UserID"].ToString()); }
再對比一下URL的構成方式，我們很容易就能得到結論：
ID、EmployeeID為參數，控制器調用的方法和參數之間用?分隔，多個參數之間用&分隔
即調用AbnormalPunchController類中的ApplySubmit方法，入參為ID和EmployeeID
當然，/home/index 表示網站首頁，可以省略。
在了解了MVC的基本架構以後，回過頭來反思以前的WEB測試工作，一般就是通過UI/控件/業務功能/跳轉/導航/數據交互幾個方面進行的，在了解了MVC架構以後，發現可以從以下幾個方面突破：
M-V-C三層架構的交互，引入接口測試驗證交互過程中的數據傳輸，保證版本質量：
FireFox瀏覽器下的FireBug插件、Chrome瀏覽器自帶的開發者工具都可以很輕松的看到控制器返回給視圖的數據，可以發現一些只在頁面上測試很容易漏掉的問題。
我之前就遇到過，改了一句sql引發了其他頁面的bug，或者改了一個查詢條件影響到其他查詢條件的情況，現在回想起來，回歸測試沒有做好是一方面，但是如果當時測試的時候關註了返回信息和影響的頁面，這個問題就很容易避免了。
根據URL的構成方式，出現問題時可以快速定位到出現問題的部分，提高定位效率：
自己一直有在嘗試說盡可能的將bug準確定到代碼上，API或WEBSERVICE端的代碼自己也能定位了，但是在真正學習MVC架構之前都是像無頭蒼蠅一樣，在VS如此強大的IDE下勉強行得通，換個IDE怕是早就砸鍵盤了。
初步考慮安全性，比如URL中是否有用戶的重要信息，是否需要加密處理
比如部分參數，可以在URL中屏蔽掉或者進行加密處理展示在URL上，如果明文進行處理，很有可能會造成信息泄露。
既然自己了解了MVC的架構，下一步或許可能會考慮玩一下單元測試吧23333333
MVC架構簡介及其測試策略