必须在IIS中启用32位应该程序才可以正常使用

无论是哪种开发模式，软件的开发过程都可以归结为：人、工具和过程这三个因素，三者的有机结合才能更高效的完成任务。有人会说：《敏捷宣言》四条主旨精神的第一条就是“个体和交互重于过程和工具”，工具还有那么重要吗？回答是肯定的，工具很重要，这条主旨所提到的是“重于”而不是不要。为了支持敏捷开发，Visual Studio 2010（以下简称为VS 2010）应用程序生命周期管理中引入了MSF for Agile Software Development v5.0过程模板，用于辅助敏捷团队在实际工程中进行敏捷实践，它支持Scrum敏捷开发过程框架。本文将从工具角度出发， 介绍Visual Studio 2010如何帮助测试人员更胜任敏捷项目中的测试工作。对于工具与人的关系而言，好的工具应该是将人从重复和机械的劳动中解脱出来，让人有更多的精力和时间花在有创造性地劳动上，而由工具去完成将繁琐和冗余的事务性操作；而对于工具和过程的关系，工具是过程能够得到确实落实和准确执行的基石，很多时候我们总是依赖于人去执行某个过程或者流程要求，但人的执行往往带有一定不稳定性和主观性，而工具则可以帮助我们准确客观的执行。

团队有效协作的基石——Team Foundation Server

敏捷开发强调人与人之间的有效沟通和紧密的团队协作。对于测试团队和测试人员而言，首先应该需要考虑的是：如何让测试工作更有效的集成整个敏捷开发的活动中去？而不是将测试工作仅作为一个“附件”或者可有可无的副产品。当然，这会受到团队组织形式和开发过程的限制，例如：采用功能小组模型的团队，所有角色成员（PM、开发人员、测试人员）隶属于同一个功能团队，客观上其沟通就更为方便；而对于采用纵向按职能划分团队的公司而言，测试和开发在隶属关系上是分开的，相对在沟通上障碍就会更多些。无论是哪种组织形式，好的工具能帮助促进和统一各个角色间的信息互通和共享，而不是要让他们彼此之间更为孤立、工作在各自的一亩三分地（Silo）中。Team Foundation Server 2010（以下简称为TFS 2010）就是这样的工具，作为整个团队协作的核心，它统一了团队不同角色信息、实现了信息之间的有效互联互通、彼此之间的共享和关联，例如：TFS 2010定义6种默认的工作项类型，如下图所示。

图1：TFS 2010定义6种默认的工作项类型

其中，Test Case和 Shared Steps是2010专门为测试新加入的。不要小看这些工作项，它们之间有着丰富的关联关系，这种关系背后所代表是角色之间的关系。对于测试而言，它将测试和团队紧密的结合在一起。例如：Test Case工作项用来详细定义和管理测试用例，它还可以和User Story相关联，也就是将测试和用户需求进行了关联，用户可以从需求追溯到覆盖的它的测试用例，这背后体现的是测试人员和需求人员/PM的协作；Test Case还可以与Bug关联，通过这种关联可以挖掘出哪些 Bug被测试用例覆盖，哪些还没有，这种关联体现了测试人员与开发人员的写作，如果是自动化测试用例，则体现了手工测试人员和自动化工程师的协作；Bug还可以可以和签入集（Change-set）关联，可以找到为了修复Bug，开发人员修改过哪些产品代码，这体现了测试人员和开发的关联。

敏捷开发频繁的迭代和较短的迭代周期，对项目管理的精确性、透明性和可见性都提出了更高的要求， 尤其对于那些项目复杂和人员较多的团队。Task是另一个重要的工作项类型，它用于管理开发过过程中的所有任务项，包括：开发、测试以及需求等任务，统一管理开发中的所有任务，统一计算项目的开销和剩余工作量等。例如，项目的燃尽图就是由它产生出来的。现在，人们虽然在理论和概念上已经非常认同软件测试的在工程中的重要地位，但在具体实际操作中，测试却仍然被看作是低于开发和需求分析等的“二等公民”。当然这是由于多方面的综合因素造成的，从管理技术角度讲，这是由于测试工作本身缺乏可度量性和可见性，从导致了测试工作的透明性的缺失，团队往往看不到测试工作的进度和所带来的成果，从而意识不到测试的真正作用。对于测试人员自身而言，缺乏可度量性也让自己无法对工作进度准确把握，进而失去了对自己工作的目标感和认同感。将测试工作同其他工作一样的用Task工作项管理起来，增加了它的可度量性和可见性。将测试工作和其它任务一起统筹，时刻确保测试被作为整体中的一部分进行考虑，所有的测试任务都被作为Task工作项记录下来，例如：编写测试计划、设计测试用例、自动化测试用例等等，每项任务都有三个默认时间估计数据需要填写，它们是：Original Estimate、Remaining和Completed，分别代表了任务的预估时间、剩余工作量和完成工作量。

为了增强敏捷过程的透明性和可见性，TFS 2010定义了很多的报表和仪表板（Dashboard），它们会自动生成各种报表，以可见的方式描述敏捷项目的健康状况，这其中就有很多反映测试工作的报表，如下面所示。Stories Overview展示了用户故事的进展情况，包括了每个用户故事的测试用例覆盖数量和执行结果，以及相应的Bug数量；Test Dashboard显示了测试用例的状态，包括正在设计的用例以及设计完毕可以执行的用例数量，现实当前Bug的状况，包括未被修复和以修复Bug的数量。

图2：Stories Overview展示了用户故事的进展情况

图3：Test Dashboard显示了测试用例的状态

集成测试环境——Microsoft Test Manager

在过去的十几年中，为了适应了软件项目的复杂度和规模的不断膨胀，软件开发工具和框架得到了长足的发展，而测试工具则始终是块短板 ，特别是对于那些需要手工完成的测试任务而言，进展就更为缓慢，例如：现在很多团队仍然使用Word或者Excel这样“原始”工具来管理测试用例。通过对业界的调查和分析，我们发现70%的软件测试工作仍然是通过手工或者简单的脚本来完成的，在测试团队中不具备编程能力和仅有基本脚本编写能力的测试人员仍然是测试的主力。

要让你的项目敏捷起来，对于那些仍以手工测试为主的团队而言是一个非常大的挑战，如何提高手工测试工作的效率将是实现敏捷的成败关键。在VS 2010中，微软首次为测试人员设计了一款专用的集成测试环境，称为微软测试管理器2010（Microsoft Test Manager 2010，以下简称为MTM）。之所以称之为集成测试环境，是因为MTM的功能涵盖了测试计划、测试用例、手动测试用例的执行和录制回放、自动测试用例执行、创建信息丰富的Bug、验证Bug、以及与测试实验室管理相关的对策是自动化相关的功能等。下图展示的是MTM测试计划的操作界面，它以树形的层次结构来组织测试用例。

图4：MTM测试计划的操作界面

《敏捷序言》强调：“可工作的软件重于完备的文档”，那么是不是意味着敏捷测试也不需要测试计划呢？当然不是。敏捷的本质是要去除软件过程所有造成时间浪费地方，不需要的是那些动辄就几十或上百页的文档。敏捷对文档要求是要简明扼要，一两页列出测试要点计划还是必须的，较短迭代周期（1-4周）也不可能要求文档面面俱到。敏捷需要更快的对功能进行验证，是不是不需要编写测试用例直接根据用户故事或者功能需求进行探索性测试就可以了？当然也不是。功能需求和用户故事勾画出的是一棵大树躯干和主要枝杈，而那测试用例则不但要准确描述出躯干和主枝，还要描述出细小的枝杈和绿叶的正确位置。从某种意义上讲，测试用例在敏捷中的作用和地位应该更为加强，它扮演着详细功能文档的角色。功能需求和设计文档可以简单，但测试用例可不是这样，相反我认为敏捷对测试用例的设计和管理要求更高。

每个迭代周期，团队都会专注于实现不同的产品功能，用户故事虽然描述了功能的内容，但并不足以覆盖所有相关的内容。很多由用户故事展开和关联的功能一般在文档中会体现出来，需要测试人员在早期围绕着用户故事测试展开需求文档测试（需求评审），已明确那些未严格定义出来的内容，以测试用例的形式明确和记录下来。由1个简单用户故事就有可能扩展为1+N用户可能执行的执行片段，也就我们测试用例。当你有M个用故事，需要Ｍ个迭代周期来完成产品，那么就会有 ( M + N₁ + N_{2 …} + N_M) 个测试用例，不把它们落实到笔头上，很容易就会丢失一些重要的测试细节。此外，在敏捷方法中需求变化比较快，随着多个迭代的深入，文档的变化往往赶不上产品功能的变化，这时唯一能够赶上这个变化的只有测试用例，应为只有它准确地反映了产品的变化，否则测试用例就是无法通过的。

图5：测试用例

在MTM 中，测试用例被分类至各个测试用例集，结构十分清晰。测试用例只是逻辑上从属于某个测试用例集，并没有物理从属关系，即一个测试用例可以同时被分在多个测试用例集内，比如某个测试用例性质上是一个性能测试，但是由于该用户故事的诉求就是性能改进，我们也就很自然得可以将其作为该用户故事的验收测试，此时我们就可以将此测试用例添加到验收测试和性能测试两个测试用例集中；另一个例子是给每个用户故事都定义了不少测试，这些测试用例都应该能在用户故事测试用例集下找到，但是这些测试既可能是手动测试也可能是自动化测试用例，所以它们又会被本别归类至这两个测试用例集。在这种逻辑分类的支持下，我们可以很容易的根据需要指定运行测试集中一部分测试用例。比如，我们可以定义一个签入测试的测试用例集，挑选最基本的若干个测试置入其中，这样在每次签入前通过运行这个测试用例集就能帮助我们确保签入的代码不至于破坏最基本的功能，即保证了版本随时可运行可测试，这无疑为测试带来了更多的方便。具体如何创建测试用例集的结构，团队可以根据自己项目的特点，灵活运用此功能，制定分类规则以提高工作的效率。

很多测试团队仍然在使用Word或者是Excel管理测试用例，有些是使用专门的测试用例管理工具，使用独立的数据库来存储测试用例信息。MTM相对于这些工具的优点在于，它的所有数据都是存储在TFS上，测试用例使用的是Test Case工作项。由于同存储在TFS 上，所以可以轻松的实现与其它数据项的关联，例如：在上一部分我们介绍的不同类型工作项之间关联，此外还可以把Test Case与代码关联，即将测试用例与自动化测试代码关联。这样在MTM中，也可以直接管理和运行自动化测试用例，使MTM兼具了管理手工测试用例和自动化测试用例的能力。

探索性测试（Exploratory Testing）是测试人员在对被测试系统的功能进行不断了解和学习的过程中进行测试，包括：设计测试用例、执行测试、以及汇报测试结果。与传统的测试相比，它不需要事先定义好的齐备的测试文档，更强调测试人员在对系统不断地学习中，边了解边测试，它在很大程度上给测试人员更多地自由和想象空间，充分发挥他们的创造力，在不断地学习中找到测试的灵感和快乐。这种测试的灵感和快乐对于组建和培养一支热爱测试的团队是非常非常重要，它会让测试人员觉得自己不是执行重复测试劳动机器，而是一个有着创造力和灵光的团队成员。MTM也支持探索测试功能，用户可以使用MTM创建一个仅有一个测试步骤的测试用例，然后执行它，Test Runner工具会辅助执行手动测试。它会记录下所有用户的操作，一旦发现有Bug时候，可以直接选择‘Create exploratory bug’直接创建一个Bug。

图6：创建一个Bug

Bug是测试工作最重要的产出之一，也是测试和开发人员之间重要接触点。每个提交的Bug都应该详细记录下如何重现（reproduce）的步骤，这是衡量Bug质量的重要因素之一。因为不可重现的Bug是没有意义的，只会耽误开发人员和项目经理的时间。偶尔出现不可重现的Bug还是可以理解的，但如果经常出现，那就会引来开发人员的抱怨和不满，久而久之会造成开发和测试之间的不信任。 好的Bug应该是有清晰和详细的重现步骤，期望的结果和实际得到结果，并提供尽可能多的信息，例如：出现问题的产品版本编号、语言、操作系统的版本以及日志信息等。大多数情况下，用文字进行描述的内容就可以了，但如果能配上一张问题现场截图，或者对于更为复杂的Bug，配上一段小的录像，这样的Bug会给开发人员快速诊断和修复产品问题带来很大帮助，大大提升测试和开发人员之间的协作效率，避免了不可重现Bug在开发和测试之间推来推去的“Bug乒乓”现象。然而要收工创建这样一个信息丰富的Bug，是需要很多时间的。MTM提供了这样的功能为帮助测试人员创建这样高质量Bug，它实现了多种诊断数据适配器（Diagnostic Data Adapters），在测试确认Bug的过程中，这些适配器会在后台运行收集大量的数据，包括：执行操作、系统配置、IntelliTrace已经操作过程的录像等，当测试人员要创建一个Bug时，这些信息会被自动添加的Bug中，如下图所示，测试仅需填写很少的内容就可以创建好一个信息丰富的Bug。

图7：信息丰富的Bug

实现自动化测试用例——自动化测试用例框架

随着需求的不断变化和迭代的深入，代码库不可避免的会有频繁的签入和签出，此时测试人员一项很重要的任务就是要预防回归问题发生。执行手工测试用例可以帮助我们预防及和发现回归问题，但是它的执行效率太低，无法胜任频繁执行的要求。这时就我们需要考虑采用自动化测试用例完成这项工作。决定是否采用自动化测试是有很多因素决定，其中很重要的一条就是自动测试的收益，下面的公式从概念上解释了如何来计算这个收益，当收益值大于1的时候，实施自动化测试就是合算的；否则，就是不合算的。

图1：计算收益公式

这其中，开发和维护自动测试的成本是影响这个收益的重要因素，为此VS 2010提供了一整套的解决方案，帮助测试团队减少这部分成本，这包括前面我们所提到的测试计划和用力管理工具，以及后面将会要介绍的生成和实验室管理。此外，Visual Studio 提供了多种测试工程模板，帮助测试人员开发自动化的测试用例，如下图所示。

图2：Visual Studio提供的多种测试模板

这些测试工程模板可以帮助测试自动化工程师，在Visual Studio 集成开发环境中创建和管理单元测试、功能测试、Web性能测试、负载测试等等一系列的自动化测试用例。这其中，编码的UI测试（Coded UI Test，以下简称为CUIT）是首次出现，是VS 2010测试部分一大亮点。测试人员可以通过它使用C#或者 VB.NET语言编写自动化测试用例，从用户界面层驱动Web、Winform或者是WPF的应用。CUIT为测试用例的自动化提供了一个框架、API和可扩展的接口，测试人员可以很轻松地开发出所要的自动化测试用例。其实CUIT背后的测试自动化实现技术对大家并不陌生，下面列出针对Web、WinForm和WPF应用的测试技术基础。对每种技术的支持采用的是插件的形式实现的，VS 2010包括了如下的三种插件：

• Document Object Model（DOM）插件 : IE 7/8 HTML/AJAX
• User Interface Automation（UIA）插件 : WPF
• Microsoft Active Accessibility（MSAA）插件 : Winform，Win32和MFC 。MSAA插件是默认选项，用来支持出其它两者之外的任何应用。

CUIT 现在支持主要的微软平台，详细的内容可以参见MSDN : Supported Configuration and Platforms for Coded UI Tests and Action Recordings。对于那些尚不支持的平台或者UI控件，CUIT提供了很好的扩展机制，允许大家针对自己的特殊应用进行扩充，下图就是CUIT框架的体系结构图 。

图3：CUIT框架的体系结构

开发自动化测试用例对于有效预防回归问题的出现时非常必要，在实际应用中应该特别注意它的合理比例关系和灵活的策略，包括：自动化用例和手工用例的比例、UI和非UI测试用例的比例关系。自动化测试用例、执行、分析和维护它们都是需要一定投入的，对于敏捷项目而言时间资源的紧缺尤为突出，所以在任何时候团队都要根据自身的资源，有选择性进行测试用例的自动化，通常情况下应该优先自动化那些高优先级的测试用例。

对于UI和非UI的自动化测试用例而言，应该是以非UI 的单元测试和功能测试为主，UI测试未必要的补充。基于UI自动化测试用例有它独特优点，例如：它从真实用户角度出发进行测试，即涵盖了界面层、逻辑层和数据层，自动化人员不需要了解被测试应用的代码实现细节等；但是相对于非UI测试它也有着先天的不足，包括：执行速度相对比较慢、易受干扰不稳定等。所以在自动化过程中，能用非UI测试覆盖的功能尽可能采用非UI的测试覆盖，如：API单元测试等，UI测试用例只用来实现最基本用户故事的验收测试（Acceptance Test）。

早测试和经常测试——封闭签入和滚动生成

敏捷开发中最可怕的事情莫过于在迭代最后一两天进行测试，结果发现了严重功能缺陷或者回归缺陷，导致不能按计划发布给用户试用。要想彻底解决这样的问题，一方面要在迭代开发阶段测试人员就要参与进来，从客户的角度出发对功能需求和设计文档进行文档测试，即文档评审。测试人员和开发还有项目经理一起从源头上保障将要实现的功能是用户想要的。另一方面就是要在迭代的早期就开始就开始测试，特别前几个迭代已经实现好的自动化测试用例，尽早的执行它们可以有效地避免回归问题的出现。在TFS 2010上专门提供封闭签入（Gated Check-in）、滚动生成（Rolling Builds）和持续集成（Continuous Integration）等功能，帮助敏捷团队实现早测试和经常测试。这其中封闭签入和滚动生成是对敏捷团队比较实用的功能。

图4：选择签入方式

封闭签入是TFS 2010提供的一种新的代码签入方式，在配置这项功能后，当用户要签入任何代码时，系统会先将用户本地要签入的代码打包成一个搁置集（shelve-set），然后提交到服务器端，TFS生成（Build）服务先从TFS源代码控制器中同步项目的最新代码，再将提交的代码与之进行自动合并，然后进行编译，如果编译成功，则执行配置的自动化测试用例，如果测试用例全部通过则代码会被自动签入到代码库中，否则返回错误信息给用户，代码是不会进入到代码库。表面上看是与产品测试没有直接关系，但实际上它和测试以及最终产品质量的密不可分。因为代码签入是整个开发过程中发生最为频繁的操作，每次签入代码的质量直接影响着日常的开发活动。对于绝大多数的开发团队来说，check in代码前不仅要保证编译通过，同时还要最大限度的保证新代码不会破坏已有的功能，也就是要执行测试用例去验证。Gated Check-in中提到的“Build成功”，实际上包含两部分内容：编译成功和测试用例执行成功，有了它作为保护代码库的第一道屏障，就可以保证它在任何适合都是可编译，并且达到一定质量标准的。

滚动生成是在VS 2008种就有的功能，当TFS检测到在它所监控的范围内有任何新的代码变化被签入后，它就启动对最新的代码库进行生成验证，该验证包括编译和运行指定的自动化测试用例。之所以称之为“滚动”，因为它是在一个生成验证操作完成后再去探测有没有新的签入发生，对这期间发生的所有新签入进行新的生成验证。这里需要再强调一下滚动生成的重要意义：它看似只是一个自动生成代码的功能，但实际上起着协调整个开发团队、时刻监控代码库质量、以及尽早暴露产品问题的作用。因为滚动生成时刻都在不停的运转着，对于任何代码签入它都保持着警觉，会去自动验证编译是否成功，自动化测试用例是否都能通过。它就像一个不知疲倦的“代码守护者”一样监控着代码库，第一时间发现其中的任何问题，将问题通知给整个团队，从而避免了问题的积累和拖延。这非常符合敏捷开发中“今日问题今日解决，不要拖到以后”的原则，它帮你最早的发现问题、报告问题，开发团队则应该建立制度要及时响应滚动生成所报告的问题，把它作为Priority 为0或1的高优先级问题去对待和解决。

封闭签入和滚动生成都是来保护代码库的正确性和产品质量，它们是否在功能上重复反而让我们不敏捷了呢？其实两者并不重复，只是各有侧重，将它们搭配使用才会发挥其最大效能。封闭签入是在代码进入代码库之前进行验证，签入提交者一般希望竟快知道结果，以便决定下一步的工作，所以封闭签入的时间（编译和运行测试用例）不要太长（10-20分钟）。这也就决定了我们加入的测试用例不能太多，只添加那些高优先级的测试用例，保证主要的用户故事不被破坏。滚动生成是在代码签入后在后台执行的，由于不存在着与用户的交互等待，所以它执行时间可以更长（几个小时），可以为它加入更多的测试用例，从而全面验证代码库的质量，一旦有任何问题它可以及时通知团队进行修复，这种验证是在几个小时或者每天都在发生的，保证了敏捷对频繁测试的。

完整的自动化测试解决方案——实验室管理

在谈到软件自动化测试的时候，很多人会误以为实现了自动化测试用例就是自动化测试，其实不然，自动化测试仅是测试自动化的一个重要步骤，绝对不等同于自动化测试。一个完整的自动化测试应该包括：构建、部署、执行测试用例、分析测试结果并作出结论。在前面的自动测试的收益公式中，我们可以看到减少自动测试的维护成本，是提高自动测试收益的重要因素之一。VS 2010的实验室管理（Lab Management）与测试用例管理、生成管理、源代码控制、工作项管理等功能相结合，为自动化测试提供了这样一个完整的解决方案，目标就是要降低了自动测试的运营和非维护成本，下面这张图展示了实验室环境的系统构架图。

图5：实验室环境的系统构架图

实验室管理功能充分利用了微软的虚拟化技术，包括：Hyper-V和 System Center Virtual Machine Manager （SCVMM），快速创建干净的虚拟测试环境并进行产品生成和部署，然后执行指定的测试用例集，将结果以报表的形式呈现出来，方便对此产品质量进行分析，如下图所示：

图6：虚拟测试环境

图7：测试结果

同时，利用虚拟技术的环境快照功能，对于那些难于复现或者环境相关的Bug，利用虚拟环境的快照技术，可以为开发人员准确的复现Bug出现的环境，从而能够快速的进行诊断和及时修复。

总结

Visual Studio 2010作为Visual Studio系列中一个非常重要的版本，为测试人员和团队提供了一整套解决方案，包括：测试计划和用例管理、创建自动化测试用例、测试用例的自动执行、以及实验室管理等。这些功能强调了测试作为整个软件过程的重要角色的作用，促进了测试人员与其它角色的有效沟通与协作，非常适合于敏捷团队使用来完成测试工作。

去年我写了一篇ASP.NET MVC 1.0的教程，发表在博客和一本书里。这篇教程捋了一遍创建一个叫做“NerdDinner”的简单程序的过程，这个程序方便人们在线组织、主办和参加餐会。可以在这里参阅我原先的ASP.NET V1 NerdDinner教程。新书ASP.NET MVC 2高级编程也包含了更新过的教程。

这篇NerdDinner教程原先使用的是“数据库优先”的方式，也就是预先定义好数据库结构，然后使用Visual Stduio设计器创建LINQ to SQL或LINQ to Entities等模型对象来做映射。

下面我将演示如何用EF 4的“代码优先”的方式来创建NerdDinner的模型层和数据库结构，然后使用ASP.NET MVC创建一个增删改查程序。

我们将一步一步地创建这个程序，本文的最后有完整示例代码的下载链接。

第一步：新建一个空的ASP.NET MVC 2程序

我们从在Visual Studio 2010新建一个ASP.NET MVC 2项目开始，选择文件 -> 新项目并使用“ASP .NET MVC 2空 Web 应用程序”项目模板就行了。

这样就会新建一个空的ASP.NET MVC 2工程，里面没有什么控制器、模型和视图。

下一步我们将定义NerdDinner“模型”——表示程序中数据的对象，以及包含验证机制和业务规则等的逻辑。模型是基于MVC程序的“心脏”，实际上掌控了程序的行为。我们将使用EF 4新的“代码优先”方式来创建这个模型层。

第二步：创建模型

现在假设我们尚未创建数据库，从头开始创建NerdDinner程序。

我们不需要从数据库开始

当使用代码优先的开发流程时，我们不需要从先创建数据库或者定义数据库结构来开始程序开发。而可以从定义最适合我们程序的模型对象的标准.NET类开始——免除在里面混杂数据持久化逻辑的烦恼。

创建模型类型

NerdDinner是一个小程序，所需要的数据存储非常简单。我们希望能定义和存储代表人们可参加的事件——“Dinners（餐会）”。我们还希望能够定义和存储参加餐会的人员——“RSVP”，用来跟踪有兴趣参加特定餐会的人。

让我们来创建两个类（Dinner和RSVP）来表现这个概念。在我们的ASP.NET MVC项目中添加两个类——“Dinner”和“RSVP”就可以了：

上面的“Dinner”和“RSVP”模型类就是“简单CLR对象”（即POCO）。它们不需要继承什么基类或者实现什么接口，而且里面定义的属性都是标准的.NET数据类型。里面没有添加数据持久化属性和操作数据的代码。

不需要在定义模型类时将他们绑定到特定的数据库、数据库API和数据库结构的功能的确很好，很强大——而且也让我们有了更弹性的数据访问方式。这样我们就能专注于程序和业务需求上，而不用过多考虑持久化的实现方式。另外，它还为我们提供了更换数据库结构或者存储实现方式的弹性空间—不需要重写模型对象或者与它们交互的代码。

创建Context类来处理数据持久化

我们已经定义了两个POCO模型类，现在让我们创建一个类来处理在数据库获取或保存Dinner和RSVP实例的工作。

我们将这个类命名为“NerdDinners”。它继承于DbContext基类，并且定义了两个公开属性——一个用来公开Dinner对象集合，另外一个公开RSVP对象集合：

上面用到的DbContext和DbSet类是EF 4代码优先函数库自带的。你需要添加对System.Data.Entity.CTP程序集的引用，它位于目录\Program Files\Microsoft ADO.NET Entity Framework Feature CTP4\Binaries中。另外在“NerdDinners”类型定义文件中，你需要添加“using System.Data.Entity”命名空间的引用。

这就是所有我们需要编写的代码了

上面三个类就是为我们NerdDinner程序实现一个基本的模型和数据持久层所需要的所有代码了。我们不需要配置额外的数据库结构影射信息，不需要运行任何工具，不需要编写什么XML文件，不需要用什么设计器来使用我们的类在数据库中获取、更新和存储数据。

基于惯例的持久化影射

不需要写什么额外代码，不需要创建什么XML文件，不需要运行什么工具来在数据库中映射我们的模型类。你可能会问，这可能吗？

默认情况下，EF代码优先库支持一个“惯例高于配置”的方式，它使用常见的映射习惯，从而避免显式地做任何配置。如果你想使用自定义的数据库映射规则的话，可以复写这些惯例。但如果你使用惯例的话，你会发现你自己需要写的代码真的很少，在不需要添加额外的代码和配置的前提下，90%的常见情况都可以正常工作。

在上面我们的例子当中，NerdDinner Context类默认会将“Dinners”和“RSVPs”属性映射为数据库的“Dinners”和“RSVPs”数据表。“Dinners”表里每一行都被映射成“Dinner”类型的一个实例。当然啦，“RSVPs”表里每一行都被映射成“RSVP”类型的一个实例。“Dinner”和“RSVP”类型里的属性也就随之被映射成“Dinners”和“RSVPs”表里的列。

EF支持的其它的惯例包括通过常见命名模式自动识别主键和外键（例如：根据Dinner类里的ID或者DinnerID属性推断出主键）。EF还灵巧地支持在两个模型间绑定相联关系的惯例。这里有一篇EF团队的博客讲解了所支持的默认惯例的工作方式。

使用我们模型的代码示例

前面我们创建的三个类包含了所有实现NerdDinner模型和数据持久化的所有代码。现在我们来看一些代码示例，看看如何使用这些类来执行常见的数据库操作：

使用LINQ表达式执行查询

用下面的LINQ查询表达式从数据库中获取数据。下图使用了LINQ表达式来获取所有将要举行的餐会：

我们在写LINQ表达式的时候也可以利用Dinners和RSVPs存在的关系。留意下图“where”子句过滤出参加人数大于0的餐会的方式：

要注意的是上面的查询的“where”子句（即只获取至少有一人参加的餐会）是在服务器端执行的——使执行查询和加载的数据量更为高效。

获取一个实例

我们可以使用LINQ的Single()函数，加上Lamda查询来获取Dinner的一个实例，如下面的代码所示：

或者，我们也可以利用EF“代码优先”函数库提供的Find()函数，根据ID来加载一个实例：

举办新餐会

下面的代码演示了如何创建一个新的Dinner实例并把它添加到数据库中。所有我们需要做的工作就是“new”一个Dinner对象，设置它的属性，最后把它加到NerdDinner Context对象的Dinners属性中。NerdDinner Context类支持 “工作单元”的模式，即你可以在Context中添加多个模型，然后调用“SaveChanges()”以事务的方式保存所有的数据库变动。

更新餐会信息

下面的代码演示了获取一个Dinner实例，更新其中一个属性，然后将改动保存到数据库的过程：

第三步：创建使用我们的模型的ASP.NET MVC控制器

现在来看看使用模型的更完整的场景，使用一个控制器类型来公布即将到来的餐会列表，并允许用户添加新的餐会：

右键单击“Controllers”文件夹，然后选择“添加->控制器”菜单项，我们把新的控制器命名为“HomeController”。

接着添加三个“动作函数”用来处理前面使用EF“代码优先”函数库创建的NerdDinners模型：

.

“Index”动作函数加载并显示即将到来的餐会列表。

而“Create”动作函数允许用户发布新的餐会。第一个“Create”函数用来处理用户访问/HOME/Create页面时，处理“HTTP GET” 的场景，以及发一个“New Dinner”表单让用户填写。而第二个“Create”函数用来处理跟那个表单关联起来的“HTTP POST”场景—将新餐会信息保存到数据库中。如果有任何验证错误，它会重新显示表单并加上相应的错误消息。

给我们的控制器加上视图

下一步将是给项目里加两个“视图模板”——一个给“Index”，另外一个给“Create”。

把鼠标放在控制器里的Index函数里，就可以在项目中为它添加一个视图了，然后单击右键在菜单中选择“添加视图”，弹出“添加视图”对话框。我们将创建一个强类型视图，然后给它传入一个包含“Dinner”模型对象的IEnumerable列表：

单击“添加”后，Visual Studio会创建一个/Views/Home/Index.aspx文件。再添加以下这些代码——为餐会信息生成一个<ul>列表，然后显示创建餐会的链接：

把光标放在控制器的Create函数来在项目中添加“Create”视图，单击右键菜单里的“添加视图”命令。在“添加视图”对话框中，我们还是指定创建一个强类型视图，然后传给它一个Dinner对象。另外还说明了我们希望使用“Create”模板搭个框架：

单击“添加”后，Visual Studio会创建一个/Views/Home/Create.aspx文件，里面有一个包含了为“Dinner”对象生成的HTML <form>表单的草案。我们做一点点的调整，并删掉了为DinnerID属性生成的input元素。最终的视图模板如下所示：

迄今为止，我们已经写好了网站里实现列出餐会清单和创建餐会信息的控制器和视图的所有代码。

第四步: 数据库

代码已经写好了。现在让我们来运行程序。

但数据库呢？

我们现在还没有数据库呢——其实到目前为止也没有必要，因为我们“代码优先”的开发流程并不要求数据库来定义和使用我们的模型类。

但当我们实际运行我们的应用程序时，我们要存储Dinner和 RSVP对象的。我们可以用下面的两种方式之一去创建数据库：

1. 使用数据库工具（如SQL Management Studio或 Visual Studio）去手动创建和定义数据库结构；

2. 使用EF代码优先类库根据我们定义好的模型自动创建和生成数据库结构。

第二种方式非常酷，而且我们要把它用在我们的NerdDinner程序中。

配置数据库连接字符串

在开始前，我们要设置好指向将要创建的数据库的连接字符串。我们把数据库连接字符串“NerdDinners”添加到应用程序的web.config文件中，如下所示：

在默认情况下，当你用EF的代码优先类库创建一个DbContext类的时候，它会自动查找和Context类名匹配的连接字符串。因为我们将Context类命名为“NerdDinners”，所以，当ASP.NET应用程序初始化它的时候，默认会找到前面添加好的“NerdDinners”数据库连接字符串。

使用 SQL CE 4

EF 代码优先类库可以支持多个不同的数据库——包括 SQL Server、 SQL Express和 MySQL。

两个星期前，我写了一篇在ASP.NET中使用嵌入式SQL CE 4 数据库引擎的博客。SQL CE 4 是一个轻量级的基于文件的数据库，安装简便，且可以嵌入在ASP.NET应用程序中。它支持低成本的宿主环境，又能够轻松地迁移到SQL Server 数据库当中。

在定义（和重新定义） 你的数据模型层的前期阶段，SQL CE可以是一个很不错的选择——另外，只要你想，还可以快速地创建和重新创建数据库。在开发NerdDinner应用程序时，我们将以SQL CE 4 作为数据库。后面，我们可以选择更改连接字符串去将产品部署到SQL Express或者SQL Server上——无需修改任何一行代码。

我前面设置的数据库连接字符串，指定了NerdDinners.sdf 数据库文件，并使用SQL CE 4 数据库驱动程序。要使它正常工作，你还需要安装SQL CE 4——安装它可以通过标准的SQL CE安装程序或WebMatrix（已内置SQL CE）。SQL CE 4 很小，只要几秒钟就可以安装好。

重要事项：上面的连接字符串中，我们指定将NerdDinners.sdf 文件创建在\DataDirectory\ 文件夹下——在 ASP.NET应用程序中对应的就是其根目录下的\App_Data\文件夹。默认情况下，新建"空 ASP.NET MVC Web 应用程序"项目模板不会创建此目录。所以你需要显式在项目中创建此文件夹（右键单击该项目并选择"添加 ASP.NET 文件夹-> Add_Data->"菜单项）。

自动创建数据库结构（Schema）

EF 代码优先类库支持自动地从数据模型类生成数据库结构和数据库的能力——免除用户必须手动去执行这些步骤。

如果您的连接字符串指定的SQL CE 或 SQL Express 数据库文件在磁盘中不存在，默认就会发生。你根本不需要执行任何手动步骤。

要看到效果，我们可以按 F5 键运行我们的NerdDinner应用程序。它会启动浏览器，并访问我们应用程序的根目录"/"。你应该可以看到下面所示的画面：

访问应用程序的根目录会调用到HomeController.Index()这个函数——它会实例化并查询我们的NerdDinners context类，来从数据库获取即将举办的餐会列表。因为我们在连接字符串中指定的NerdDinners.sdf数据库文件并不存在，所以EF 代码优先类库将自动地为我们创建该数据库。它会根据NerdDinners context类，推断出数据库结构，最后生成数据库。

你可以通过在Visual Studio解决方案管理器上点击“显示所有文件”图标，然后点击“刷新”按钮，展开App_Data文件夹查看那个自动生成的SQL CE数据库文件。

将来我们会发布一个VS 2010的升级包，你将能在“服务器资源管理器”上打开、编辑SQL CE 4数据库（就跟你现在编辑SQL 数据库一样）。这样，你就可以很容易地看到（或许做点调整）数据库结构和数据内容了。到了那时，你也可以在WebMatrix中使用数据库工具去查看SQL CE 4数据库文件的内容。

我们还没有给NerdDinners数据类指定任何自定义的数据持久化映射规则——所以EF 代码优先类库将会根据默认的命名规范作为映射规则自动生成数据库。但是如果我们指定了任何自定义的映射规的话，EF 代码优先类库将会遵守这些规则，生成与它们匹配的数据库。

让我们回顾一下，这里是我们先前定义的两个POCO数据模型类和NerdDinners Context类：

下面是我们运行应用程序后，根据上述模型类自动创建的数据库中的两个表。

“Dinners”表的定义如下图所示。其中，列名和它的数据类型和Dinner类中定义的属性是完全对应的。DinnerID列被自动的设置成了该表的主键和唯一标识列。

“RSVPs”表的定义如下图所示。该表的列名和它的数据类型和我们在RSVP类中定义的属性也是一致的。其中，RsvpID列被设置成了该表的主键和唯一标识列。

在Dinners表和RSVPs表之间，一个一对多的主键/外键关系也同时被创建起来了。EF 代码优先类库自动建立了这种关联，因为Dinner类中有一个类型为ICollection<RSVP>的RSVPs属性，同时，RSVP类中也有一个Dinner的属性。

为数据库填充餐会信息

现在，让我们来新建一些餐会信息并将它们写入数据库。我们可以通过点击我们首页中的“Create New Dinner”链接来跳转到“新建”页面。

当我们点击“Create”按钮时，新餐会将被保存到数据库。我们可以重复数次来新建多个不同的餐会。每条我们新建的餐会都将会保存在数据库中，并会被显示在首页的“Upcoming Dinners”（即将举办的餐会）列表中。

第五步：更改数据模型

随着我们应用程序开发的推进，我们将继续改进和重构我们的模型。EF 代码优先类库包括一些很好的开发功能，这使我们在开发数据库时更容易协调某些改进。

给Dinner（餐会）模型添加一个新的属性

让我们对我们的Dinner类做一个简单的修改，更具体的说，我们将给Dinner类添加一个新的“Country”属性。

做完改动，让我们在Virtual Studio中按下F5按钮，重新编译并运行应用程序。将会看到下面的这些错误信息：

这些错误信息之所以出现，是因为我们修改了Dinner类的结构定义，我们的模型对象现在已经不再和数据库中自动创建的Dinners表一致了。

当EF自动地为你创建数据库时，默认地会增加一个“EdmMetadata”表，这个表用来记录自动创建数据库时使用的模型对象的形状。

当EF发现你修改过模型对象，并且和之前自动创建的数据库不再同步时，就会出现上面的错误消息。

重新同步数据模型类到数据库

我们有很多同步模型对像和数据库的方式：

• 我们可以手动地更新数据库中的结构（Schema）让它们保持一致。
• 我们也可以先删除数据库文件，然后重新运行应用程序，让EF自动重新创建数据库。
• 我们也可以开启EF 代码优先功能，当数据模型发生任何改变时能够自动更新数据库 。

下面，让我们在NerdDinner应用程序中看看如何使用最后一种的自动更新的方式。

当模型对象发生变化时重新创建数据库（RecreateDatabaseIfModelChanges）功能

在EF 代码优先类库的CTP 4版本中包括了一个非常有用的开发时（development-time）功能，它允许你在任意时刻修改数据模型类，自动重建数据库。当你开启这项功能的时候，EF能够识别用来创建数据库的类模型在何时被改动，何时可以重建你的数据库以匹配新的模型类——你不需要做任何手工操作。

这项功能在你刚开发一个应用程序时特别实用，因为它为你快速地重构你的模型代码带来了很大的自由度和灵活性——你根本不用去手动地保持数据库结构的同步。它特别适合SQL CE，因为SQL CE是一个基于文件的数据库而且可以随时在运行时删除和创建。这使得开发流程变得不可思议的流畅。

启用这项功能最简单的方法就是在Global.asax类中的Application_Start()事件处理函数中加上Database.SetInitializer()方法的调用。

这个调用告诉EF当数据模型发生任何变化时，重建NerdDinners.sdf数据库以匹配NerdDinners类。现在当我们重新运行应用程序的时候，再也不会出现提示说类模型和数据库不匹配的错误信息了。反而，EF会自动重建数据库以匹配新的数据模型类，我们的应用程序会正常运行：

为自动创建的数据库产生初始化的数据

在上面的截图上，你可能已经注意到我们之前添加的餐会数据在重建数据库之后就丢失了。这是因为根据模型变化自动重建数据库的功能并不适用于实际场合，此时你想将已经存在的数据从一个数据库移植到另外一个数据库中。相反，它是被设计用来适用于开发场合，我们需要数据库结构能快速地自动更新——而不是通过手动地或指定移植规则来实现。

注意：我们另外正在做的工作，用来提供更好的数据移植服务，支持这种适用于产品数据和数据库结构的版本管理。但我们想这和前面讲的前期开发时（development-time）功能是不同的场景。这种数据移植的功能现在还不会在这个星期的CTP上发布。

其实，EF已经为我们提供了可选的 “种子” 功能，用以在创建或者重建数据库时产生默认或测试数据。我觉得这个功能真的很实用，因为这样一来，在我重构一个数据模型后，马上就可运行应用程序去测试—不用重新手动地输入一堆的测试数据。

我们可以通过实现一个如下所示的“NerdDinnersIntializer”类，将这些“种子”数据到加入到数据库当中。我这里用它创建两个“示例餐会”并把它们加入到数据库中。

然后，我们可以在Global.asax加入Database.Initializer()方法以在启动时使用这个“NerdDinnersInitializer”类。

现在任何时候我们更新NerdDinner模型类，数据库文件都会被删除和重建以匹配我们的模型类，同时，两条默认餐会数据也会被添加到数据库中用以测试。

方便重构

上述的功能使我们非常容易地在开发时改进和重构代码——不需要用到任何工具和脚本去手动地保持数据库结构和代码的同步。

由于我们的模型类、LINQ表达式和“种子”测试数据都是强类型，所以我们也可以很快速地用Visual Studio的重构工具自动在代码文件中应用所有更改。

第六步: 加入验证规则

我们已经创建了一个简单但很好的数据服务应用程序。

但是，这里还是有一个问题，那就是我们还没有任何地方做数据验证以确保我们填入的数据库中的数据都是正确的。让我们来搞定它。

用DataAnnotations实现数据验证

在基于ASP.NET MVC的应用程序中，通常加入验证规则的地方最好是数据模型。这样，可以只在一个地方进行维护，同时也使强制任何与它交互的Controller和View的遵循它。在ASP.NET MVC中，你可以通过很多种机制去实现数据验证，它可以很灵活地支持你想要使用的任何验证机制。

ASP.NET MVC 2内置支持使用.NET类库中System.ComponentModel.DataAnnotations的验证规则库—你可以显式地在模型类中通过验证特性（Attribute）来使用验证规则。你可以在我之前发表的博客中了解这项功能的更多信息。我们将把这种方式的优势应用到我们的NerdDinner应用程序中的输入数据验证上面来。

让我们回过头，将一些数据验证的特性加入到我们之前定义好的Dinner类的属性当中去。（注意：我们同时要加入“using System.ComponentModel.DataAnnotations”命名空间。）

[Required] 验证指明这个属性的数据是必须指定的（非空的）。[StringLength] 指定了该属性允许输入的最大字符串长度。[RegularExpression] 验证指定了用以验证输入匹配的正则表达式（这里我们用以验证邮件地址）。

每一个验证特性都支持“ErrorMessage”属性，这使得我们可以指定验证失败时显示的错误消息。你既可以通过硬编码的方式（像上面一样）指定，也可以通过让它从一个资源文件里取得—可以很容易地实现本地化。

引入一些CSS和JavaScript文件

最后一步，我们将回到Create.aspx视图模板中，加入<link>引用Site.css文件到项目中，同时也加入两个<script>元素引用两个JavaScript文件。我们还在<form>元素呈现之前加入一行代码来调用Html.EnableClientValidation()方法。

这些改动将会确保那些验证错误信息以正确的样式显示出来（让它们更惹眼），而且这些数据模型的验证规则会同时应用在客户端和服务器端。

运行应用程序

让我们重新运行应用程序并尝试注册一个新的餐会。让我们先按一下还没有填写数据时的"创建"按钮。现在我们会发现模型中的验证错误消息在浏览器中已经显示出来：

由于我们在ASP.NET MVC中启用了客户端验证（即我们上面所写的代码中的一行)，我们的错误消息将会实时更新：

注意上面，当我们给”Title”输入的字符串长度大于20的时候，验证错误信息改变的方式。这是因为我们为Dinner.Title设置的验证[StringLength]特性指明了最大允许的长度是20。而当我们开始在“HostedBy”文本框中输入字符串时，错误信息从“[Requred]”（要求你输入电子邮件地址）变成了“[RegularExpression]”（它告诉我们没有输入一个有效的电子邮件地址）。

这些验证规则在浏览器中（通过 JavaScript）和服务器上（即使有人试图绕过JavaScript 验证，也能保护数据的输入有效性）都有效——不用我们对Controller类作任何更改。这种将规则在我们的模型类内指定一次就可以被应用到处任何地方的能力是极其强大的——将使我们能够以一种非常清楚的方式继续改进我们的程序。

你可以通过这里了解更详细的有关这些 ASP.NET MVC 2 模型验证功能和它们的工作方式。

下载

点击这里下载和运行我们在这篇博客里实现的NerdDinnerReloaded示例。你需要安装了VS 2010 (或者免费的Visual Web Developer 2010 Express) 。

重要提示：你必须在你的机子上下载和安装SQL CE 4后才能运行上面的示例程序。你可以从这里下载EF 代码优先类库。这两个下载都不会对你的机器有太大的影响。

.NET Framework 自从 2002 年发展至今，已经历了好几个版本，1.0, 1.1, 2.0, 3.0, 3.5 等不同的版本更替，.NET Framework 的Redistributable Package也愈来愈大，到了 .NET Framework 3.5 SP1 时已经膨胀到 231MB，除非软件本身就很大，不然对于 .NET 软件的Redistribute是相当不利的，除非客户端本身就有安装 .NET Framework，否则几乎都要夹带一个 .NET Framework 的Redistributable Package，如果只是一个小小的应用程序文件 (几十或几百KB) 还要夹一个那 大的 .NET Framework Redistributable Package，大概很多开发人员都会觉得麻烦，就算开发人员接受，但在企业网络的 IT 管理人员就不一定会接受了 … 所以 .NET Framework 的减肥一直都是 .NET 开发人员的愿望与期待，而 .NET Framework Client Profile 就是微软针对这个需要的主要响应。既然 .NET 应用程序不一定会用到所有的 .NET Class Library，那微软就将 .NET Framework 部份不常用的功能由主函数库中抽离出来，让Redistributable Package可以缩小，有利于重新发布应用程序。

.NET Framework Client Profile 在 .NET 3.5 时首次和开发人员见面，但是碍于它只能利用 ClickOnce 部署方式安装，因此使用它的开发人员不多，且也有许多人反应希望将 .NET Framework Client Profile 能够利用光盘或其他储存媒体转散布，微软从善如流，将 .NET Framework 4.0 的 Client Profile 改成Redistributable Package。

The .NET Framework 4 Client Profile 包含下列功能：

• Common Language Runtime (CLR)
• ClickOnce
• Windows Forms
• Windows Presentation Foundation (WPF)
• Windows Communication Foundation (WCF)
• Entity Framework
• Windows Workflow Foundation
• 语音
• XSLT 支援
• LINQ to SQL
• Entity Framework 与 WCF Data Services 执行期设计函式库
• Managed Extensibility Framework (MEF)
• 动态型别
• 并列程序设计功能，例如 Task Parallel Library (TPL), Parallel LINQ (PLINQ), and Coordination Data Structures (CDS)
• 除错客户端应用程序

下列功能不包含，要另外安装 .NET Framework 4.0 的完整版本：

• ASP.NET
• 进阶 Windows Communication Foundation (WCF) 功能
• .NET Framework Data Provider for Oracle
• 编译用 MSBuild
• Visual Studio 2010 的项目中，下列应用程序会默认使用 .NET Framework 4.0 Client Profile，若要使用完整的 .NET Framework 功能，则要自行到项目属性中设定 target framework 至 .NET Framework 4.0：
• Windows Projects (C# and Visual Basic)
• Windows Presentation Foundation
• WPF Application
• WPF Browser Application
• WPF Custom Control Library
• WPF User Control Library
• Windows Forms
• Windows Forms Application
• Windows Forms Control Library
• Console Application
• Empty Project
• Window Service
• Visual F#
• F# Application
• F# Tutorial
• Workflow (C# and Visual Basic)
• Activity Designer Library
• Activity Library
• Workflow Console Application
• Windows Communication Foundation
• WCF Service Library
• Office 2007 and Office 2010
• All projects target the .NET Framework 4 Client Profile

而 .NET Framework 4.0 Client Profile 与原有的 .NET Framework 3.5 Client Profile 不同的地方有：

• 3.5 版本的 Client Profile 只能使用在 Web (ClickOnce)，4.0 版本则因为具有Redistributable Package，所以可同时适用于本机或 Web 安装。
• 3.5 版本只支持 x86 的 Windows XP SP2/SP3，4.0 版本则支持除了 IA64 以外，.NET Framework 4 支持的所有平台。
• 3.5 版本的 Client Profile 与 .NET Framework 3.5 是分开的版本，4.0 版则为 .NET Framework 4.0 完整功能的子集。
• 3.5 版本会受 Windows Update 的影响自动升级到 .NET Framework 3.5，4.0 版则可以在不需要完整 .NET Framework 4.0 下自行运作，也可以分开提供服务。

不过也因为如此，当在 Visual Studio 2010 建立新项目时，如果发现 [添加引用] 中没有列出原本应该列出的组件时，可以先检查是否是项目的 target framework 设成了 .NET 4.0 Client Profile (例如 System.Web.dll 就不在 .NET 4.0 Client Profile 套件中)。

Jack Milunsky将常见的延迟归为以下几类：

• 项目批准过程——开发人员坐等项目得到批准，由此造成时间和金钱的浪费。
• 等待需求的正确优先级——这样工作才能开始推进。
• 等待可用的资源——这常常标志着组织需要反省自己是不是承接了太多工作。
• 变更批准流程——该流程本身就是浪费。如果发生次数太多，就该考虑缩短sprint长度了。
• 在制品增加——在制品越多，开发人员要想将代码发布到生产环境，要等待的时间也就越长。
• 客户签收验收测试时的延迟——不仅在这方面，还包括让客户解决需求问题、提供演示反馈等方面。

Jack提到：在sprint之间也有很多延迟。团队应该认真投入精力，识别并根除这些延迟。他建议：

必须保证backlog得到正确的“看护”。要有一个高效的产品负责人，他能理解市场和客户。你还需要写得很好的用户故事。要尽早从开发人员那里得到估算，这样产品负责人才能在规划会议之前做出决策。这都是为了“防‘延迟’于未然”，保证在所有的转换点上，工作都能得到顺利交接。把这个端到端的过程勾画出来，识别出各个转换点上的延迟，这样做很有价值。

Wouter Baars也提出了IT项目延迟最主要的几个原因，其中包括：

• 画蛇添足——团队花费太多时间去增强客户没有要求的功能。
• 忽略质量控制——时间压力有时会让程序员或项目团队有意跳过测试过程。相对其减少的延迟，这常常会导致更多延迟。
• 同时开发多个项目——任务切换会招致更多问题，而不是解决问题。
• “一劳永逸”症状——试图将一种现有的解决方案用在任何新问题上。
• 平庸的人员素质——人员在技术或流程方面的能力不足会导致多个层面的延迟。
• 客户无法实现承诺——当客户无法在他们必须参与的工作中及时响应时，项目会陷于停滞。
• 客户和开发人员之间的关系紧张——如果项目进展不顺利，“不和谐”会导致更多延迟。这会破坏彼此之间的信任感，影响工作气氛。

Robert Neri提出另一个造成延迟的有趣原因，他指出：企业中敏捷实施的差异可能导致延迟。他提到：

我们常常遇到这种情况：支持部门无法做到项目sprint那么快的速度，因此会造成敏捷项目延迟。类似地，非敏捷项目难以和敏捷项目整合。

因此，如果你的敏捷项目延迟了，看看是不是由于上面这些常见的原因。一旦你识别出了根源，赶紧想办法解决才是明智之道。这会去除项目中最大的一个浪费。

（From InfoQ）

2.      SDemo 我个人比较喜欢用这个工具，可以将操作录成EXE文件，并回放出来。这样就避免了那些偶尔才出现的Bug

• Log on B
• Configure
• Log out
• Log on A
• Test

2. 初级自动化人员（直接把手工case转成自动化）

• Set autologon B
• Set autorun
• Record test status: 0
• Logout
• Check status

if(status==0)
{
Configure
Set autologon A
Record test status:1
Logout
}

if(status==1)
{
Test
}

这个级别的人，需要懂得脚本编程，需要懂得系统设置，autologon and autorun。

3. 有一定经验的自动化人员（改变手工测试case以利于自动化的更简单，可靠的实现）

• 不需要log out and log on

• 利用Windows命令Runas

• 用高级语言调用Runas

• 利用重定向来输入Password

这个级别的人，需要懂得高级语言，重定向，Windows系统命令Runas

4. 中级自动化人员（具有更丰富的开发经验，可以用程序代替UI和系统命令）

• 不需要Runas命令
• 利用.NET的Process对象
• 用B的身份生成一个Process来进行配置工作

这个级别的人，要比较熟悉高级语言，比较熟悉高级语言的类库，懂得操作系统的内核基本概念

5. 高级自动化人员（精通高级语言，精通操作系统内核）

• 不需要多生成一个进程
• 用本线程impersonate用户B
• 利用.NET WindowsIdentity 对象
• 必须要调用Windows API，LogonUser

这个级别的人，要精通C/C++和Java，C#等高级语言，精通Windows内核的知识和Windows API

从以上的例子可以看到，针对同一个test case，不同的测试人员，从手工到高级自动化，由于自己知识面的原因，会设计出非常不同的case出来。越高级的自动化越灵活，稳定，可靠，也更需要掌握更多的开发和内核的知识。因此，我们看到很多人在强烈的否定自动化，你先看看他到底在哪个层次中。越下边层次的自动化人员，由于技术的原因，碰到的问题会越多，能解决的问题却越少，因此对自动化的抱怨也就越大了。这些都是可以理解的，不过以此来否定自动化，我觉得还是不太应该，毕竟自己技术还不过关。

ASP.NET MVC 指南 —— 概述（一）创建一个电影数据库应用程序
http://www.cnblogs.com/ilovesilence/articles/1399795.html

The Will Will Web - ASP.NET MVC
http://blog.miniasp.com/category/ASPNET-MVC.aspx

Scott的ASP.net MVC框架系列文章之二: URL映射
http://blog.csdn.net/drummery/archive/2008/01/03/2022775.aspx

[翻译-ASP.NET MVC]Contact Manager开发之旅系列
http://www.pin5i.com/showtopic-23294.html

ASP.NET MVC 入门8、ModelState与数据验证
http://blog.csdn.net/philiplb/archive/2009/03/24/4020489.aspx

Asp.net MVC中表单验证(Fluent Validation for .NET)
http://space.itpub.net/12639172/viewspace-553431

在ASP.NET MVC Framework 中执行简单验证
http://www.cnblogs.com/darkdawn/archive/2009/03/05/1404201.html

[翻译:ASP.NET MVC 教程]ASP.NET MVC学习之旅——总索引
http://www.cnblogs.com/Kinglee/archive/2009/07/13/1522676.html

Entity Framework系列初、中、高级教程
http://www.cnblogs.com/xray2005/category/189491.html

Cheat Sheets

C# / .NET / LINQ 相關

• .NET Format String Quick Reference [PDF]
• Microsoft .NET Framework 3.5 Commonly Uses Types and Namespaces [PDF]
• LINQ Cheat Sheet
• LINQ Standard Query Operators Cheat Sheet
• LINQ to SQL语句详解：http://kb.cnblogs.com/page/42465/
• Linq to sql 中如何进行 left join：http://www.cnblogs.com/RChen/archive/2008/07/24/1250736.html
• LINQ to Entities 不识别方法,因此该方法无法转换为存储表达式：LINQ to Entities 中,使用lambada或linq时,变量一定要提前转换好,不能到lambada里或linq里再转换。http://bbs.51541.com.cn/showtopic-76.html
• Linq中导航属性为Null的问题和解决方法：取出对象后调用MsgsReference.Load()即可，http://space.cnblogs.com/question/7421/

Visual Studio 相關

• Visual Studio 2005 Built-in Code Snippets (C#) [PDF]
• Visual Studio 2005 Default Keybindings (C#) [PDF]
• Visual C# 2008 Keybinding Reference Poster

ASP.NET 相關

• ASP.NET 2.0 Page Life Cycle & Common Events [PDF]
• ASP.NET Page Life Cycle Diagram [PNG]
• ASP.NET Runtime Cheat Sheet: HttpRequest, HttpRuntime, AppDomain and friends
• Microsoft ASP.NET AJAX Library
• Microsoft ASP.NET AJAX Client Life Cycle & Events [PDF]

SQL Server 相關

• SQL Server Cheat Sheekt

Subversion 相關

• Subversion Cheat Sheet

Reqular Expression 相關

• Regular Expressions Cheat Sheet (V2)

C＃比较两时间大小

1、比较时间大小的实验
    string st1="12:13";
    string st2="14:14";
    DateTime dt1=Convert.ToDateTime(st1);
    DateTime dt2=Convert.ToDateTime(st2);
    DateTime dt3=DateTime.Now;
    if(DateTime.Compare(dt1,dt2)>0)
     msg.Text=st1+">"+st2;
    else
     msg.Text=st1+"<"+st2;
    msg.Text+="\r\n"+dt1.ToString();
    if(DateTime.Compare(dt1,dt3)>0)
     msg.Text+="\r\n"+st1+">"+dt3.ToString();
    else
     msg.Text+="\r\n"+st1+"<"+dt3.ToString();

2、计算两个时间差值的函数，返回时间差的绝对值：
         private string DateDiff(DateTime DateTime1,DateTime DateTime2)
         {
             string dateDiff=null;
             try
             {
                 TimeSpan ts1=new   TimeSpan(DateTime1.Ticks);
                 TimeSpan ts2=new   TimeSpan(DateTime2.Ticks);
                 TimeSpan ts=ts1.Subtract(ts2).Duration();
                 dateDiff=ts.Days.ToString()+"天"
                         +ts.Hours.ToString()+"小时"
                         +ts.Minutes.ToString()+"分钟"
                         +ts.Seconds.ToString()+"秒";
             }
             catch
             {

             }
             return dateDiff;
         }

3、实现计算DateTime1－36天＝DateTime2的功能

    TimeSpan ts=new TimeSpan(40,0,0,0);
    DateTime dt2=DateTime.Now.Subtract(ts);
    msg.Text=DateTime.Now.ToString()+"-"+ts.Days.ToString()+"天\r\n";
    msg.Text+=dt2.ToString();