最近在WEB端测试工作中陷入了瓶颈，单纯的手动功能测试在没有成熟的代码规范之前还是很容易坑的，WEB自动化测试一时半会还没有什么进展，所以决定先学习一下网站用的MVC架构，跟着教程写了一个小网站，大概也找到了WEB测试工作的几个突破口。
MVC即为按照分层解耦的思想，将网站结构分成了Model（模型）-View（视图）-Controller（控制器）三层架构，三层架构的职责如下：
Model层：是应用程序中用于处理应用程序数据逻辑的部分，通常模型对象负责在数据库中存取数据；简单来说，就是在Model层进行业务逻辑的处理；
View层：是应用程序中处理数据显示的部分，通常视图是依据模型数据创建的；简单来说，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：
显然，这个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