1.  原始需求

 收发文流程原始需求如下：



2.  需求说明

 

2.1. 收文登记

普通环节处理（普通用户任务)

 

2.2. 收文拟办

选择1：领导阅示（1)、领导阅（2)、主办（3)、协办（4)可以选四者之一、四者的自由组合、四者全部；且这四者可以自由组合。

选择2：移交归档，如果选择移交归档的前提是承办环节必须被办理过，否则不能选择移交归档。

注意：选择1与选择2是互斥，不能同时选；收文拟办办理完毕后可以补发或撤回领导阅示、领导阅、主办、协办环节上的办理人，当都全部撤回完时，收文拟办会拥有初始时所有操作，不再有补发或撤回操作。

 

2.3. 领导阅示

办理完毕后，等待领导阅、主办、协办、承办办理，都办理完毕后流到收文拟办环节。

 

2.4. 领导阅

办理完毕后，等待领导阅示、主办、协办、承办办理，都办理完毕后流到收文拟办环节。

2.5. 主办

选择1：承办（3.1)、协办（3.2)以选二者之一、二者全部；

选择2：直接办理完毕，等待领导阅、领导阅示、协办办理，都办理完毕后流到收文拟办环节。

 

注意：

1、主办办理完毕后可以补发或撤回承办（3.1)、协办（3.2)环节上的办理人，当都全部撤回完时，主办会拥有初始时所有操作，不再有补发或撤回操作。

 

2.6. 移交主办

就是办理权移交给其他人

2.7. 承办

选择1：协办；

选择2：直接办理完毕，等待领导阅、领导阅示、主办、协办办理，都办理完毕后流到收文拟办环节。

注意：承办办理完毕后可以补发或撤回协办环节上的办理人，当都全部撤回完时，承办会拥有初始时所有操作，不再有补发或撤回操作。

 

2.8. 协办

办理完毕，等待领导阅、领导阅示、主办、承办、协办办理，都办理完毕后流到收文拟办环节。

 

2.9. 移交归档

流程结束。

 

3.  收发文需求特色

上述的收发文流程，需要工作流引擎具有如下几个能力。

1、任务节点定义人、办理能力。

2、流程部分区间支持排列组合产生任务的能力。（领导阅、主办、协办、承办)可以随便组合使用。

3、流程部分区间的任务可能没有连线的概念。任务的办理没有先后顺序，且可以无限的添加和删减。（这个与BPM2.0的部分概念有些冲突)。比如BPM有严格的先后顺序，任务节点必须有出线，否则实例会卡顿不前。流程部分区间的任务可能没有出线和入线。

4、任务的标记能力。流程部分区间的任务需要进行标记，否则引擎也不知道该区间的任务什么时候创建。

5、流程要有预测的功能，因为每一个节点可能要指定下一个处理的任务节点。

6、任务具有选择执行功能。比如流程节点预测要执行的任务节点是a/b两个节点，那么实际执行的时候，可能进行二选一或者全选执行的功能。

 

 

4.  收发文需求落地

 

4.1. 流程绘制



4.2. 流程区间子流程配置

1、点击容器面板，选择展开子流程。

 

2、选择流程并删除开始节点，如下所示。

 

3、对需要执行的节点进行标记，如下所示。



自定义属性需要增加标记。

adHocInit true

只有该标记的节点才可以任意选择创建。

4、对需要选择执行的任务的节点配置按钮，如下所示。


 

“可选按钮”可以在任务办理的时候，进行任务的选择。效果如下：

 

 

5.  收发文需求执行效果

5.1 流程启动

在申请事务选项卡中找到发起流程菜单，点击“发起流程”菜单，进入当前流程列表页，我们找到“收发文”并点击该流程，如下所示：



 

在流程启动页面，我们填写请假表单：开始时间、结束时间、请假天数、请假事由；填写完成之后，点击启动按钮，如下所示：



5.2 审批流程

在我的任务选项卡中找到我的任务菜单，点击“我的任务”菜单，进入我的任务列表页，在任务列表页，找到“收文登记”数据，并点击后面的“办理”按钮，如下所示：



进入办理页面，我们点击“办理”按钮，如下所示：



5.3 收文登记-办理

在办理页面，可以看到下一个节点是“收文拟办”可以再次选择下一个节点的审批人员，设置优先级，设置任务标题，填写意见，信息核对无误后点击确定按钮，如下所示：



5.4 收文拟办-办理

在我的任务选项卡中找到我的任务菜单，点击“我的任务”菜单，进入我的任务列表页，在任务列表页，找到“收文拟办”数据，并点击后面的“办理”按钮，如下所示：



在办理页面，点击可选办理，如下所示：



在办理页面，我们可以看到下一个节点信息多选框：领导阅示、领导阅、协办、主办，根据排列组合方式可知一共有24种情况，我们可以根据实际需求，选择哪些节点成为我们的下一个节点，在此处我们从24种情况中选择稍微复杂的主办，填写意见，并点击确定按钮，如下所示：



5.5 主办-办理

在我的任务选项卡中找到我的任务菜单，点击“我的任务”菜单，进入我的任务列表页，在任务列表页，找到“主办”数据，并点击后面的“办理”按钮，如下所示：



 

在办理页面，点击“可选办理”，如下所示：



如果在此处您想看流程运转的流程图，可以点击流程图按钮，流程运转情况如下所示：



在办理页面，我们可以看到下一个节点信息多选框，根据需求说明我们可知，主办的下一个节点可选协办和承办，根据排列组合方式一共有3种情况，此处我们验证两个节点都勾选的情况，并填写审批意见，点击确定按钮，如下所示：



5.6 协办-办理

在我的任务选项卡中找到我的任务菜单，点击“我的任务”菜单，进入我的任务列表页，在任务列表页，可以看到有两条数据，一条“协办”数据，另一条“承办”数据；我们可以根据喜好选择先办哪条数据，此处我们选择协办数据，点击该数据后面的办理按钮，如下所示：



在办理页面，点击“办理”，如下所示：



如果在此处您想看流程运转的流程图，可以点击流程图按钮，流程运转情况如下所示：



在办理页面，我们可以看到下一个节点显示：动态流程无需预测，填写审批意见，并点击确定按钮，如下所示：



5.7 承办-办理

在我的任务选项卡中找到我的任务菜单，点击“我的任务”菜单，进入我的任务列表页，在任务列表页，现在只可以看到有一条“承办”数据，我们选择承办数据，点击该数据后面的办理按钮，如下所示：



在办理页面，点击“办理”，如下所示：



如果在此处您想看流程运转的流程图，可以点击流程图按钮，流程运转情况如下所示：



在办理页面，我们可以看到下一个节点显示：协办，填写审批意见，并点击确定按钮，如下所示：



5.8 协办-办理

在我的任务选项卡中找到我的任务菜单，点击“我的任务”菜单，进入我的任务列表页，在任务列表页，现在只可以看到有一条“协办”数据，我们选择协办数据，点击该数据后面的办理按钮，如下所示：



在办理页面，点击“办理”，如下所示：



如果在此处您想看流程运转的流程图，可以点击流程图按钮，流程运转情况如下所示：



在办理页面，我们可以看到下一个节点显示：协办，填写审批意见，并点击确定按钮，如下所示：



5.9 收文拟办-办理

在我的任务选项卡中找到我的任务菜单，点击“我的任务”菜单，进入我的任务列表页，在任务列表页，此时只有一条数据“收文拟办”，点击该数据后面的办理按钮，如下所示：



在办理页面，点击“办理”，如下所示：



如果在此处您想看流程运转的流程图，可以点击流程图按钮，流程运转情况如下所示：



在办理页面，我们可以看到下一个节点信息多选框：领导阅示、领导阅、协办、主办，根据排列组合方式可知一共有24种情况，我们可以根据实际需求，选择哪些节点成为我们的下一个节点，在此处我们从24种情况中选择稍微复杂的主办，填写意见，并点击确定按钮，如下所示：



（后续的操作，可以参考上文操作步骤）

5.10 移交归档

如果流程审核完成之后，需要移交归档，则在办理页面，我们选择移交归档，填写意见，并点击确定按钮，如下所示：



在我的任务选项卡中找到我的任务菜单，点击“我的任务”菜单，进入我的任务列表页，在任务列表页，此时只有一条数据“移交归档”，点击该数据后面的办理按钮，如下所示：



在办理页面，点击“办理”，如下所示：



如果在此处您想看流程运转的流程图，可以点击流程图按钮，流程运转情况如下所示：



在办理页面，我们可以看到下一个节点信息为：结束，填写意见，并点击确定按钮，如下所示：



流程结束。

 

 

原来在github上断断续续给许多项目提交过pr（pull requests），比较有成就感的是参与的datax-web项目，目前已近1.8k star。现将开源项目贡献代码流程成文，方便后续更多的同学参与到开源社区。

一.整体流程如下图

二.详细步骤
1.fork

作用：在GitHub（或gitlab，gitee）上，将别人项目引出一个新的分支到你的GitHub账号（fork字面意思“叉子”）
操作：github项目右上角点击fork，如下图(因为我已经fork过，所以没有fork到waterWang的选项)；



效果：自己的github上有了别人项目，可以看到项目从哪里fork过来的；


2.clone

作用：将fork到自己github账户的项目，从github克隆到自己机器，以便开发修改代码；
操作：git命令行或可视化git工具都可以（我习惯git命令行）。克隆如下图有三种方式，a地址克隆（又分https，SSH，GitHub CLI），b GitHub Desktop，c下载zip包



>git clone url-xxx # 输入命令后安静的等待进度达到100%



效果：本地文件夹中出现datax-web项目



3.checkout

作用：clone的下来默认的是master分支，但是开发尽量避免在master上—要开发，先切糕（checkout）
操作：命令行

 >git checkout -b newBranchName 
 # 默认以当前本地分支为基准，创建并切换到新分支。
 #也可以以远程分支为基准，创建并切换到新分支 ,如下命令 
  git chekcout -b origin/master newBranchName  #origin/master 是远程地址别名为origin上的master分支；


效果：创建出了一个新分支，并切换当前分支到新分支


4.add/commit

作用：上步骤切出新分支后，可以书写自己代码，本地测试通过，可以进行代码的提交
操作：git命令行

>git add .  # git add 还有很多用法，本文不再赘述
>git commit -m 'sth msg' # git commit 还有很多用法，已经msg的规范，本文不赘述


效果：代码已经全部存在本地仓库（git status后提示nothing to commit, working tree clean）

5.push

作用：从本地仓库将分支推到远程自己GitHub上。
操作：git命令行

>git push origin branchName



效果：GitHub上对应项目上多看一个分支；



6.pull request

作用：将上步骤的远程分支请求合并到原作者的项目上（真正意义上为开源项目提交代码）
操作：GitHub页面。在原作者的项目页面点击pull request–》new pull request,(也可以直接点击compare and pull request)



注意选择从哪里合并到哪里（注意箭头方向），GitHub会检测代码是否可以合并，如果可以就会出现Able to merge,反之需要先解决代码冲突。



效果：“pull request”合并请求已经发生，安静的等待原作者处理该请求。

最近在为面试新工作做准备，所以想想整理一下软件测试的基本工作流程，大致梳理一遍，这样也便于自己在面试过程中可以沉着的面对面试管的测试工作如何进行的问题。

首先，作为测试人员需要学习并了解业务，分析需求点

为什么测试人员要参加需求分析？也就是进行测试需求分析的目的是什么？

第一、把用户需求转化为功能需求：1）对测试范围进度量    2）对处理分支进行度量   3）对需求业务的场景进行度量   4）明确其功能对应的输入、处理和输出   5）把隐式需求转变为明确。

第二、明确测试活动的五个要素：测试需求是什么、决定怎么测试、明确测试时间、确定测试人员、确定测试环境：测试中需要的技能，工具以及相应的背景知识，测试过程中可能遇到的风险等等。测试需求需要做到尽可能的详细明确，以避免测试遗漏和误解。

怎么进行测试需求分析？

第一、确认功能（业务功能、辅助功能、数据约束、易用性需求、编辑约束、参数需求、权限需求、性能约束）：

1、业务功能：与用户实际业务直接相关的功能或者细节

2、辅助功能：辅助完成业务功能的一些功能或者细节，例如：设置过滤条件

3、数据约束：功能的细节，主要是用于控制在执行功能时，数据的显示范围，数据之间的关系等

4、易用性需求：功能的细节，产品中必须提供，便于功能操作使用的一些细节，例如：快捷键等

5、编辑约束：功能的细节，在功能执行时，对输入数据项目的一些约束条件，例如：只能输入数字等

6、参数需求：功能的细节，在功能执行时，需要根据参数设置不同，进行不同处理的细节

7、权限需求：功能的细节，在功能执行的过程，根据不同的权限进行不同的处理，不包括直接限制某个功能的权限

8、性能约束：功能的细节，执行功能时，必须满足的性能需求

第二、场景分析

1、考虑场景的调用者：考虑每一个场景提供的服务是供哪些外部模块或者系统调用的，找出所有调用者。调用前提，约束都要考虑。每一个调用都可以考虑成一个大的业务流程（一般和外部有交互的业务出错率比较大，需要重点关注）

2考虑系统内部各个场景之间的：形成内部业务流程，需要分析每个场景之间的约束关系，执行条件，组织出各种业务流程图

第三、挖掘隐性需求

这需要测试工程师的经验积累：1）常用的或者规定的业务流程   2）各个业务流程分支的遍历   3）明确规定不可使用的业务流程   4）没有明确规定但是应该不可使用的业务流程   5）其他异常或者不符合规定的操作

以上是粗略的讲解了如何进行测试需求分析，详细的测试需求方法可以参考《软件测试需求分析方法》这篇博客。在需求分析过程中编写整个测试计划，在这个过程中需要参考需求规格说明书，这个阶段一般情况下是测试主管编写的。包括测试人员，测试时间，测试工具，以及测试方法等。这是在测试需求分析中的产物《测试计划》，如何编写测试计划，请参考以下文章《如何编写一个好的测试计划》。

接下来就是测试用例设计：

测试用例是测试工作的最核心的模块，在执行任何测试之前，首先必须完成测试用例的编写。测试用例是指导你执行测试，帮助证明软件功能或发现软件缺陷的一种说明。用例设计好后进行审核。这个地方该讲的东西就多了，如何设计测试用例，设计测试用的方法，怎么进行测试用例的审核等等。

第一、如何进行测试用例的设计

编写测试用例之前我们需要对项目的需求有清晰的了解，对要测试什么，按照什么顺序测试，覆盖哪些需求做到心中有数，作为测试用例的编写者不仅了解要有常见的测试用例编写方法，同时需要了解被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构。

步骤：

1、测试需求分析：从项目部拿到软件的需求规格说明书后，开始对项目的需求进行分析，通过自己的分析、理解，整理成为测试需求， 清楚分析出被测试对象具有哪些功能。 明确测试用例中的测试集用例与需求的关系，即一个或多个测试用例集对应一个测试需求。

2、业务流程分析：分析完需求后，明确每一个功能的业务处理流程，不同的功能点作业务的组合，以及项目的隐式需求。如遇复杂的测试用例设计前，先画出软件的业务流程。从业务流程上，应得到以下信息：

A、 主流程是什么?

B、 条件备选流程是什么?

C、 数据流向是什么?

D、 关键的判断条件是什么?

3、测试用例设计

完成以上两步则可进行测试用例设计，功能测试用例，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题。设计测试用例的常见方法：1）等价类    2）边界值    3）因果图    4) 判定表    5) 状态迁移    6) 正交实验    7) 场景法    8) 错误推断（注意：编写测试用例时，我们尽可能取的不应该是有效等价类而应该是无效等价类）

4.编写完成后自我检查以及部门内部评审：

1）测试用例本身的描述是否清晰，语言准确；是否存在二义性；

2）测试用例内容是否完整，是否清晰的包含输入和预期输出的结果；测试步骤是否清晰；

3）测试用例中使用的测试数据是否恰当，准确；

4）测试用例是否具有指导性，是否能灵活的指导软件测试工程师通过测试用例发现更多的缺陷，而不是限制他们的思维；

5）是否考虑到测试用例执行的效率。对于不断重复执行的步骤，是否保证了验证点相同；或者测试用例的设计是否存在冗余性等。这些都可能导致测试用例执行效率低下；

6）画出软件需求跟踪矩阵，验证测试用例是否完全覆盖了需求，验证测试用例的覆盖性；

7）测试用例是否完全遵守了软件需求的规定。这一点其实有一些难做到。考虑到时间/成本的关系，应该视具体情况而定。

具体详细内容可参考《如何有效的进行测试用例评审》

5.测试用例更新完善

测试用例编写完成之后需要不断完善，如遇需求更改或功能新增时，测试用例必须配套修改更新，同时在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善;在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。

紧接着就是在测试过程中占很大一部分比重得测试用例执行过程

首先搭建测试环境，准备好测试数据，进行预测，预测通过之后，按照测试用例进入正式测试，有效的测试执行可以将测试用例发挥最大的价值。因此，测试用例规范执行有助于更好的发现代码中存在的缺陷。根据个人测试工作经验，好的测试执行应该包含如下内容：

1、测试执行中评估测试执行时间不足，需及时上报风险。满足质量优先，进度其次原则。

2、测试用例按优先级顺序执行，通常是基本、详细和异常顺序执行。

3、未执行用例、标志为删除或者无效的用例，需注明原因。

4、执行过程中有疑问的测试用例（场景、操作步骤、检查点等）需找测试设计人员澄清。

5、测试执行需对用例描述的检查点逐一检查，避免遗漏。

6、重视不易重现的缺陷场景，可能是一个bug。

7、执行过程中发现有前期设计遗漏用例需补充到用例文档并执行验证。

8、建议测试人员交叉执行重复测试用例，用例执行对相同测试人员有免疫性。避免可能的缺陷一直遗漏到现网。

9、如有需要，建议保留测试结果，结果可视。也便于不同版本间的测试结果对比。

10、已确认问题需及时按照问题单提单要求（规范和缺陷定级）提单。

11、跟踪问题单修复情况并回归验证问题单。

12、每轮次测试结束，find一下是否有core文件产生。

13、测试结束，将最终测试用例文档上传到归档目录，实现用例重用。

以上是争对一般的软件测试流程，如果是自动化测试得话，应该还有根据测试用例进行脚本编写，运行脚本等。此处可能写的不详细，希望大家可以再下方评论让我完善。

在测试用例执行过程中，包含了：功能测试阶段、缺陷跟踪阶段（bug tracking）、回归测试阶段、系统测试阶段、验收测试阶段等（系统已满足测试条件（开发完成），按照已经评审过的测试用例依次执行，执行过程中及时记录问题，将问题及时提交到QC上，要跟踪缺陷。等开发修复后进行回归测试，确认修复后关闭缺陷，如果说该问题要更新而生产上未进行验证，就把缺陷状态改为生产未验证。对有异议的缺陷经甲方、开发和测试三方进行沟通讨论，由甲方最终确定处理方式。在测试过程中也会碰到对需求有异议，会反馈给经理，由经理与甲方沟通来对该需求提出一些可行性建议，最终还是由甲方来确定具体根据各个公司的业务流程而不一样）。

最后已达到准出要求的根据测试情况写测试报告，对整个测试过程和版本的质量做一个评估

测试报告是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。测试报告是测试阶段最后的文档产出物。优秀的测试经理或测试人员应该具备良好的文档编写能力，一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。

测试报告的内容可以总结为以下目录：

 首页
	
 引言（目的、背景、缩略语、参考文献）
	
 测试概要(测试方法、范围、测试环境、工具)
	
 测试结果与缺陷分析（功能、性能）
	
 测试结论与建议（项目概况、测试时间 测试情况、结论性能汇总）
	
 附录（缺陷统计）
 

至此并不算最后的完结工作，软件测试还包含了线上功能检查、当前版本问题反馈以及改进建议 等。这样才算是软件测试最终结束，软件测试是贯穿于整个软件生命周期的。

 

小生不才还望大家多多包涵，此文章是用来帮助自己应付面试用的，大家多多提意见，完善该文章。

最后祝大家和自己，能够有所收获，面试顺利（Interview success）。



 

一、简介

    Spring MVC属于SpringFrameWork的后续产品，已经融合在Spring Web Flow里面。Spring 框架提供了构建 Web 应用程序的全功能 MVC 模块。SpringMVC是一种web层的mvc框架，用于替代servlet（处理响应请求，获取表单参数，表单验证等）

二、工作流程



1、用户发送请求至前端控制器DispatcherServlet。

2、DispatcherServlet收到请求调用HandlerMapping处理器映射器。

3、处理器映射器找到具体的处理器(可以根据xml配置、注解进行查找)，生成处理器对象及处理器拦截器(如果有则生成)一并返回给DispatcherServlet。

4、 DispatcherServlet调用HandlerAdapter处理器适配器。

5、HandlerAdapter经过适配调用具体的处理器(Controller，也叫后端控制器)。

6、Controller执行完成返回ModelAndView。

7、HandlerAdapter将controller执行结果ModelAndView返回给DispatcherServlet。

8、DispatcherServlet将ModelAndView传给ViewReslover视图解析器。

9、ViewReslover解析后返回具体View.

10、DispatcherServlet根据View进行渲染视图（即将模型数据填充至视图中）。 

11、DispatcherServlet响应用户。

三、理解

1、为什么要使用springMVC？

    SpringMVC是一种基于Java，实现了Web MVC设计模式，请求驱动类型的轻量级Web框架，即使用了MVC架构模式的思想，将Web层进行职责解耦。基于请求驱动指的就是使用请求-响应模型，框架的目的就是帮助我们简化开发，SpringMVC也是要简化日常Web开发。（处理业务数据的对象和显示业务数据的视图之间存在紧密耦合）

2、什么是MVC设计模式？

    MVC即Model-View-Controller，将应用按照Model（模型）、View（视图）、Controller（控制）这样的方式分离。

    视图(View)：代表用户交互界面，对于Web应用来说，可以是HTML，也可能是jsp、XML和Applet等。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。

    模型(Model)：是业务的处理以及业务规则的制定。模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计是MVC最主要的核心。MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，抽象与具体不能隔得太远，也不能太近。MVC并没有提供模型的设计方法，而只是组织管理这些模型，以便于模型的重构和提高重用性。

    控制(Controller)：可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。

3、SpringMVC的特点

清晰的角色划分：控制器（controller）、验证器（validator）、 命令对象（command object）、表单对象（formobject）、模型对象（model object）、 Servlet分发器（DispatcherServlet）、处理器映射（handler mapping）、视图解析器（view resolver）等。每一个角色都可以由一个专门的对象来实现。
	
强大而直接的配置方式：将框架类和应用程序类都能作为JavaBean配置，支持跨多个context的引用，例如，在web控制器中对业务对象和验证器（validator）的引用。
	
可适配、非侵入：可以根据不同的应用场景，选择合适的控制器子类 （simple型、command型、form型、wizard型、multi-action型或者自定义），而不是从单一控制器 （比如Action/ActionForm）继承。
	
可重用的业务代码：可以使用现有的业务对象作为命令或表单对象，而不需要去扩展某个特定框架的基类。
	
可定制的绑定（binding） 和验证（validation）：比如将类型不匹配作为应用级的验证错误， 这可以保存错误的值。再比如本地化的日期和数字绑定等等。在其他某些框架中，你只能使用字符串表单对象，需要手动解析它并转换到业务对象。
	
可定制的handlermapping和view resolution：Spring提供从最简单的URL映射， 到复杂的、专用的定制策略。与某些webMVC框架强制开发人员使用单一特定技术相比，Spring显得更加灵活。
	
灵活的model转换：在Springweb框架中，使用基于Map的 键/值对来达到轻易地与各种视图技术的集成。
	
可定制的本地化和主题（theme）解析：支持在JSP中可选择地使用Spring标签库、支持JSTL、支持Velocity（不需要额外的中间层）等等。
	
简单而强大的JSP标签库（SpringTag Library）：支持包括诸如数据绑定和主题（theme） 之类的许多功能。
	
JSP表单标签库：在Spring2.0中引入的表单标签库，使得在JSP中编写 表单更加容易。
	
Spring Bean的生命周期可以被限制在当前的HTTP Request或者HTTP Session。
4、SpringMVC的优点

让我们能非常简单的设计出干净的Web层和薄薄的Web层
	
进行更简洁的Web层的开发
	
天生与Spring框架集成（如IoC容器、AOP等）
	
提供强大的约定大于配置的契约式编程支持
	
非常灵活的数据验证、格式化和数据绑定机制
	
支持Restful风格
5、SpringMVC的入门程序

web.xml

<web-app>
    <servlet>
        <!-- 加载前端控制器 -->
        <servlet-name>springmvc</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <!-- 
  	       加载配置文件
  	       默认加载规范：
  	       * 文件命名：servlet-name-servlet.xml====springmvc-servlet.xml
  	       * 路径规范：必须在WEB-INF目录下面
  	       修改加载路径：
        -->
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>classpath:springmvc.xml</param-value>   
        </init-param>
    </servlet>
    <servlet-mapping>
        <servlet-name>springmvc</servlet-name>
        <url-pattern>*.do</url-pattern>
    </servlet-mapping>
</web-app>

springmvc.xml

<beans>
	<!-- 配置映射处理器：根据bean(自定义Controller)的name属性的url去寻找handler；springmvc默认的映射处理器是BeanNameUrlHandlerMapping-->
	<bean class="org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping"></bean>
	
	<!-- 配置处理器适配器来执行Controller ,springmvc默认的是SimpleControllerHandlerAdapter
	-->
	<bean class="org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter"></bean>
	
	<!-- 配置自定义Controller -->
	<bean id="myController" name="/hello.do" class="org.controller.MyController"></bean>
	
	<!-- 配置sprigmvc视图解析器：解析逻辑视图； 
		后台返回逻辑视图：index
		视图解析器解析出真正物理视图：前缀+逻辑视图+后缀====/WEB-INF/jsps/index.jsp
	-->
	<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
		<property name="prefix" value="/WEB-INF/jsps/"></property>
		<property name="suffix" value=".jsp"></property>		
	</bean>
</beans>


自定义处理器

public class MyController implements Controller{

	public ModelAndView handleRequest(HttpServletRequest arg0,
			HttpServletResponse arg1) throws Exception {
		ModelAndView mv = new ModelAndView();
		//设置页面回显数据
		mv.addObject("hello", "欢迎学习springmvc！");
		
		//返回物理视图
		//mv.setViewName("/WEB-INF/jsps/index.jsp");
		
		//返回逻辑视图
		mv.setViewName("index");
		return mv;
	}
}


6、SpringMVC常用注解及其作用

@Controller：标识这个类是一个控制器

@RequestMapping：给控制器方法绑定一个uri

@ResponseBody：将java对象转成json，并且发送给客户端

@RequestBody：将客户端请求过来的json转成java对象

@RequestParam：当表单参数和方法形参名字不一致时，做一个名字映射

@PathVarible：用于获取uri中的参数,比如user/1中1的值

Rest风格的新api

@RestController相当于@Controller+ @ResponseBody

@GetMapping@DeleteMapping@PostMapping@PutMapping

其他注解

@SessionAttribute：声明将什么模型数据存入session

@CookieValue：获取cookie值

@ModelAttribute：将方法返回值存入model中

@HeaderValue：获取请求头中的值

7、SpringMVC和Struts2的对比

框架机制：SpringMVC的入口是servlet，而Struts2是filter。

Filter在容器启动后就初始化，服务停止后销毁，晚于Servlet；Servlet在是在调用时初始化，先于Filter调用，服务停止后销毁。

拦截机制：

    Struts2：1、Struts2框架是类级别的拦截，每次请求就会创建一个Action，和Spring整合时Struts2的ActionBean注入作用域是原型模式prototype（否则会出现线程并发问题），然后通过setter，getter吧request数据注入到属性；

    2、一个Action对应一个request，response上下文，在接收参数时，可以通过属性接收，说明属性参数是让多个方法共享的；

    3、Action的一个方法可以对应一个url，而其类属性却被所有方法共享，这也就无法用注解或其他方式标识其所属方法了。

    SpringMVC:1、SpringMVC是方法级别的拦截，一个方法对应一个Request上下文，所以方法直接基本上是独立的，独享request，response数据。而每个方法同时又何一个url对应，参数的传递是直接注入到方法中的，是方法所独有的。处理结果通过ModeMap返回给框架；

    2、在Spring整合时，SpringMVC的Controller Bean默认单例模式Singleton，所以默认对所有的请求，只会创建一个Controller，有应为没有共享的属性，所以是线程安全的，如果要改变默认的作用域，需要添加@Scope注解修改；

Struts2有自己的拦截Interceptor机制，SpringMVC这是用的是独立的Aop方式，这样导致Struts2的配置文件量还是比SpringMVC大。

性能方面：SpringMVC实现了零配置，由于SpringMVC基于方法的拦截，有加载一次单例模式bean注入。而Struts2是类级别的拦截，每次请求对应实例一个新的Action，需要加载所有的属性值注入，所以，SpringMVC开发效率和性能高于Struts2。

配置方面：spring MVC和Spring是无缝的。从这个项目的管理和安全上也比Struts2高（当然Struts2也可以通过不同的目录结构和相关配置做到SpringMVC一样的效果，但是需要xml配置的地方不少）；

SpringMVC可以认为已经100%零配置。

设计思想：Struts2更加符合OOP的编程思想， SpringMVC就比较谨慎，在servlet上扩展。

集成方面：SpringMVC集成了Ajax。

注意：springmvc是单例模式的框架,但它是线程安全的,因为springmvc没有成员变量,所有参数的封装都是基于方法的,属于当前线程的私有变量. 因此是线程安全的框架。所以效率高。

struts action是多例的。所以可以使用成员变量获取参数。所以效率低。