用户名：王清培
文章数：141
评论数：297
访问量：548227
注册日期：
阅读量：1297
阅读量：3317
阅读量：444653
阅读量：1130434
51CTO推荐博文
分离用例与接口功能(设计模式的使用之地)
1.4.工具、框架
原则对于任何一项技术实现来说都是至关重要的，在设计某一个系统功能的时候我们讲究的是设计原则：
【单一职责原则Single Responsibility Principle、里氏替换原则Liskov Substitution Principle、依赖倒置原则Dependence Inversion Principle、接口隔离原则Interface Segregation Principle、迪米特法则Law Of Demeter、开闭原则Open Close Principle】。
在架构设计的时候我们也讲究架构原则：
【分层原则、避免循环依赖】。
不仅仅在技术领域在做人做事都要讲究原则，违背原则那么等待你的将是无情的惩罚。
对于DDD的设计我们也有相应的原则需要遵守，当然如果不遵守在前期看不出什么区别，但是到开发阶段问题就会暴露出来。
我们来看两个基本的设计原则问题。
【精简聚合】
精简聚合的设计原则无疑是最重要的。一些软件工程方法论书籍经常指导我们进行UML业务建模，&在这个阶段不需要考虑任何技术实现问题&，我按照这样的指导原则进行了UML的设计然后顺利的创建出ER关系图，结果发现那样的数据库结构根本不能作为最终的项目开发数据库。哪里出问题了？我反复查询指导书籍后来在专业的DDD书籍上看到了一句大概这样的话：
【&不以技术实现为前提的设计都是纸上谈兵&】。
我想这句话很真实的描述了方法论与企业应用之间的鸿沟，很多技术思想或者理论确实很好，但是要想用起来需要解决很多问题。DDD也避免不了这个问题，怎么避免在设计UML模型的时候不会导致设计过度的问题，这里我们只需要遵守【精简聚合】原则就不会导致设计过度问题。
在前面的例子当中我们设计一个完整的UML领域模型，但是我们并没有对它进行【精简聚合】重构，所以它存在的问题就是无法进行项目开发。
我们构建出来的领域模型初步版本应该是上图这样的，实体与实体之间是有强联系的，聚合之间的关联太大，导致牵一发而动全身。如果按照这种关系创建数据库那么数据库之间的主\外键肯定很多，对数据库的设计造成了影响。这样的关系如果在程序中使用也会存在很多问题，我们无法进行少数聚合的使用，当我们使用某一个聚合的时候它会接二连三的把相关联的聚合都给拖出来，不仅在查询的时候妨碍而且在Factory创建聚合的时候也会存在无法构造的问题，不管在对聚合Repository进行任何操作的时候都会影响程序逻辑，所以我们需要对一个复杂的庞大的关系进行拆分。
将红线的部分全部断开，聚合之间通过Id进行关联，这样就会变的很清晰。因为很少程序中会在某一个业务逻辑点上需要所有的业务模型参与，这样既方便了程序的开发也方便了数据库的设计，更方便了ORM的使用。ORM的延迟加载其实就是为了聚合之间的依赖，可以在需要的时候在去查询需要的模型。但是这样虽然程序可以说的过去，那么数据库的设计就说不过去了。对于不同的ORM框架的映射原理不同，在构造模型的时候是需要稍微的调整的，比如在EntityFramework中，它能支持的映射方案你保证你的模型能顺利的映射过去，这里就不扯了后面有一个详细的项目做全面实践，到时候在具体问题具体分析。[王清培版权所有，转载请给出署名]
最后我们看一下分解后的类图：
这样一来一块一块很清晰，都能直接使用相关的核心领域模型，也不需要担心ORM框架的延迟加载的问题。
【分离用例与功能接口（设计模式的使用之地）】
分离用例与功能接口其实也是初次接触DDD的朋友都会犯的职业病，因为我们都熟悉面向对象设计。在进行UML建模的时候我们都非常喜欢抽象，会很清楚的把具有泛化关系的用继承来表示，比如【用户类型】，不同的用户具有不同的行为权限，在初步设计的时候我们一般都会建立关于用户的一个继承关系来表达泛化的业务模型。但是在编码阶段会发现很明显的问题就是我们把关于Repository的行为包含到了发起用例的用户聚合当中去了，这样说可能有点抽象。我们还是用例子来分析；
上图中我将【Admin】和【配送】用例分开了，想表达是不能将关于配送的行为放在【Admin】中。在我们对有关权限进行建模的时候经常会潜意识的将各自的行为放在了各自的角色当中，如果后期存在多角色共享行为的就将写在抽象的类中使用虚方法向下传递。问题就出在关于角色行为里，我们知道如果有行为那么就有可能在该行为里面执行有关其他聚合的IRepository操作，这样一来将会把领域模型搞的很乱，无法垂直分析。
DDD讲究领域驱动，在我们看来【Dispatching】、【CheckOrders】都是继承管理员角色，管理员属于后台管理人员，意味着企业的员工。对消费者来说他们就是管理人员。同样消费者也会存在相同的情况，消费者可能存在很多种类型，有VIP系列的(VIP1\VIP2\VIP3&)，有钻石会员之类的。如果这样设计的话并不能说是错的，这也完全符合DDD的思想要求，但是实际情况下却是不理想的。
这里就用到了我们长期使用的设计模式了，我们可以通过设计模式中的很多中模式来将用户与行为分离开来，再将使用的规则条件抽象出来就完全独立了用户，用户在使用的时候不会存在直接的行为归属，但是事实上他们确实是有行为。
用专业的DDD术语讲&规约模式&，将业务规则抽取出来对象化，甚至到最后都可以进行规则的配置化。最让我们兴奋的是，我们苦心学习的设计模式终于可以在系统设计中大面积的使用了，难道不是一件很惊喜的事情吗！
1.4】工具、框架
任何一种架构都是需要框架、工具的支撑才能变的完美。
当我们在某种架构下进行开发的时候，我们必须需要很多工具、框架的支撑才能让开发工作变的很便捷，这也和【敏捷开发】的思想一样。在传统的三层架构下开发我们都需要 &对象映射&、&AOP\IOC& 等等类似的辅助框架，目的是为了架构前行的可能性。在DDD中我们也需要很多目前还没有出现的很多工具、框架，在.NET平台中目前来看只有EntityFramework框架算是为了DDD做了很多工作，如果我们的领域模型无法与数据库进行映射，那么领域模型开发所要付出的代价将是很大。
在设计阶段我们缺乏一个面向特定领域的建模工具，这种工具与UML不同，UML太技术化通用化。DDD中经常会提起【领域专家】一角，他是最具有权威性的领域领头人，我们所创建出来的UML他们未必能看得懂，通过技术人员技术化之后形成UML其实已经变味，【领域专家】是懂非懂的无法做到肯定的保证。如果能把领域模型语言化，那么这个将是一大成就。【领域专家】对领域中的任何事物、人物、环节都很熟悉，但是他无法表达清楚自己的想法，如果能有一个工具辅助他的设计，该工具能将设计后的模型进行平滑等价的技术化变成代码模型或者数据库模型，这一条鸿沟如果能跨越那么对行业来说具有很大影响力。
如果我们能等价的将上图中的真实模型进行技术化，那么真的每个人都会喜欢需求分析、分析设计。
既然是模型驱动设计，我们在给用户分析类似这样一套系统的时候，前提是我们已经对里面的所有细节进行了抽象封装，每一个过程都是可以拆分的，最后能合并在一起形成一个整体的业务模型。当然这里只是一种技术展望，也是我们奋斗和理想的目标。
推荐一本最新Martin Fowler的书：
DDD不是一种纯技术实现，而是一整套开发思想，它贯穿软件开发的所有生命周期。从我们开发接触领域，对领域知识进行深入的消化，这些都是DDD所强调的。那么在我们日常开发过程中，我们该如何处理这些过程，需求不会再像以前那样是一份杂乱无章的草稿，而是一个内容丰富的领域模型草图。这样的要求对团队对部门甚至对公司来说都是一个提升，要想做到完全的DDD过程其实很难。
公司领导如何看待这样的开发方式，我们多数人都是在一些非专业研发类的公司工作，领导希望能尽早的看到东西，这很矛盾，需要好的东西但是不按照好的东西做法来做。如果有幸能有一个面向DDD、敏捷、XP的研发团队工作，那么可以视项目为一件终身的艺术品。[王清培版权所有，转载请给出署名]
这两篇文章主要是一些本人对DDD的感悟，分享给大家。
后面一篇文章将会详细的使用一个DDD架构的小系统作为案例给大家分享，里面将包括从需求的分析建模、设计模式的使用、数据库映射、EntityFramework的使用等等，可以作为真实项目开发的依据。本文出自 “” 博客，请务必保留此出处
了这篇文章
类别：未分类┆阅读(0)┆评论(0)【图片】在ASP.NET MVC4中使用领域驱动设计【c#吧】_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：108,664贴子：
在ASP.NET MVC4中使用领域驱动设计收藏
以前在别的贴吧发过，感觉发在这里更合适，共同学习。
c#培训选择达内的理由1,企业级开发环境2,项目实战教学3,c#课程可选4,金牌讲师授课5,周末/业余班任选.c#培训首选达内--美国上市公司!
在领域驱动设计中，我们首先会为领域设计模型，且在设计的过程中完全不考虑存储和具体的实现细节。也就是说在设计中，我们把数据库放在了一个次要的位置（其实仍然很重要，只是在设计架构时我们不考虑它）。有了模型以后，下一步就是如何持久化（保存数据），且这里就存在着面向对象方式表示的数据和数据库所使用的基于元组的关系模型之间的不一致（对象-关系阻抗失谐）。如果可以选用面向对象数据库，事情就会容易许多，然而面向对象数据库并没有成为IT界的主流，因此关系型数据库就成为你唯一的选择。之所以会出现基于领域的设计是为了处理真实世界中的复杂性。运用领域驱动设计之后，你要么选用面向对像数据库，要么引入一个O/R映射层。然而实现领域驱动设计很复杂，甚至可以说以个人之力完全无法实现。幸好现在有很多框架可用，例如Entity Framework（以下简称EF）。 使用EF有三种方法：1.数据库优先，即先设计数据库，然后做数据库和面向对象模型的映射；2.模型优先，先用EF自带的设计工具设计模型，然后生成sql脚本，创建数据库；3.代码优先，先使用其他UML工具设计模型，根据模型手动编写模型代码，然后生成sql脚本，创建数据库。目前最流行的是代码优先，因为它最灵活，然而代码优先的工作量很大。而数据库优先的方法和领域驱动设计的思想相悖。所以我选择了模型优先的方法，但在EF4中，使用模型优先是有问题的，它生成的模型都继承自一个名为EntityObject的基类，这个基类包含了访问数据库的方法，这就不支持持久化透明了。幸好在EF4.1以后微软引入了DbContext，用EF4.1的模型优先可以生成支持持久化透明的实体类，不继承任何基类，数据访问由DbContext实现。在VS2012中创建一个ASP.NET MVC4项目，VS2012会自动添加EF5.0的引用，并且在设计模型时会自动生成支持持久化透明的实体类，但在VS2010中要麻烦点，这里不做说明了，因为用了VS2012就完全没有问题了。具体建模过程不做介绍，网上一搜一大堆。下图为模型的一部分：
在传统的三层架构设计中，三层架构分为数据访问层、业务逻辑层和表现层。很多人在自己实现三层架构的时候都会明确的定义DAL、BLL和UI，但在实现的过程中总会有一些误解，例如很多人误把用户操作的流程当成业务逻辑，而数据访问层就是大量的sql语句和连接数据库的操作。实际上，用户的操作流程应该称为应用逻辑，应该放在服务层。我看过很多人设计的三层架构，BLL层几乎没有什么代码，只是简单的对DAL层的调用，复杂的数据访问逻辑都在DAL层。可以说，这种三层架构并不是真正意义上的三层架构，只是看起来像三层架构。其实三层架构是一种很复杂的架构模式，个人之力很难实现。在领域驱动设计中，业务逻辑层主要关注于领域的对像模型，每个业务对象都有其数据和行为，即业务逻辑层表示的是领域对象之间的关系逻辑，在你建模完成以后业务逻辑层就已经设计完成了，即使你一行代码都没写。例如上图的模型图，可以很直观的看出来各模型之间的关系，当我们需要时可以从一个模型很容易的导航到另一个模型，然后由EF的DbContext访问数据库，而不需要编写任何sql语句。这样的设计并没有明确定义DAL、BLL，在项目中完全看不到这样的类或类库，这里的三层只是逻辑上的三层。DbContext负责数据访问，领域模型包含业务逻辑。但是在一般情况下，不应该在UI层直接使用DbContext访问数据库，而是要先定义一个仓储层（repository），这是领域驱动设计中最常用的做法，首先定义一个仓储接口，包含CRUD操作。如下图：然后再定义一个Repository类实现这个接口：这个类需要一个泛型参数，该参数的基类是DbContext，在构造方法里直接创建它。构造方法还需要一个IErrorLogger类型的参数，用于记录访问数据库时出现的异常，通过依赖注入（Dependency Injection,DI）的方式传入（控制反转（IoC）原则，后面还将重点介绍。）
表现层使用的是ASP.NET MVC4，这才是本文的重点。新建一个MVC4项目（过程不做介绍），然后新建一个名为ArticleController的控制器，在ArticleController控制器里新建一个名为Articles的控制器操作（action），用来处理用户对文章列表的请求：这个控制器依赖于IRepository接口，通过IRepository访问数据库。这里似乎有个问题，是不是UI层直接调用数据访问层了呢？其实不是，这里的控制器仅依赖于IRepository接口，并非数据访问层，数据访问层由EF实现，而非我们自己实现。当然这里的设计还有点瑕疵，稍后会做改进。下面的问题就是，这个控制器依赖于IRepository接口，那么我们应该在哪里初始化这个接口呢？根据上面在Repository构造方法参数中传入IErrorLogger的经验，我们也可以在控制器的构造方法中传入一个IRepository类型的实例。这是行得通的，并且构造方法参数注入是最常用的依赖注入方法。
下面有必要介绍一下依赖注入。在介绍依赖注入之前，需要先介绍一下依赖倒置原则（DIP），作为一条设计原则，依赖倒置原则强调高层组件应该依赖于抽象而不是某个具体的实现或功能。例如上面的两个例子，Repository类不依赖于IErrorLogger的具体实现，仅依赖于IErrorLogger这个接口，我们只知道这个接口有一个记录日志的功能，但并不知道它具体是怎么实现的（IErrorLogger是个抽象的概念），只有当我们需要某个记录日志的功能时，才会把实现了IErrorLogger接口的类的实例传递给Repository。ArticleController同样只依赖于IRepository这个抽象接口。控制反转（IoC）就是依赖倒置原则的一个应用，用一段泛化的代码控制更加特定的外部组件的执行。在这里的讨论中，控制反转和依赖注入可以认为是同义词。不过在字面上二者并不总是同义词，控制反转有时会指原则，而依赖注入则代表了原则的应用—即模式。实际上，控制反转历史上曾是基于依赖倒置原则的一个模式。依赖注入这个名词由Martin Fowler提出（【企业应用架构模式】），用来专指控制反转的概念。控制反转/依赖注入（IoC/DI）作为一种模式，可以让高层次方法不再需要辅助组件的具体引用。注入的过程可以通过3种方式实现，一种是通过被注入方法所在的类的构造方法，前面两个例子都是采用了这种方法；二是通过在被注入方法所在的类中定义一个方法或属性；最后一种是让被注入方法所在的类实现一个接口，接口中提供了辅助组件的具体实现。IoC/DI的目的就是降低组件之间的耦合度（高内聚，低耦合。）现在IoC/DI通常会有专门的框架提供，这些框架也提供了很多高级功能，下面还会介绍。
介绍完了依赖注入，下面继续看这个例子，虽然在ArticleController的构造方法中定义了传入IRepository的方法，但是直到现在还没有在任何地方创建一个实现了IRepository的实例，也就是说直到现在我们看到的IRepository仍然是抽象的。虽然我们已经知道Repository这个类实现了IRepository接口，并且显而易见我们在控制器中肯定会用到Repository这个类，但是究竟要在哪里创建这个类的实例呢？直接在控制器中创建？那控制器就直接依赖于Repository了，违反依赖倒置原则。这里就要用到一个IoC/DI框架了—Ninject，看起来像个日语词汇，没错，它有忍者的意思，快如闪电！首先需要在项目中安装Ninject，使用NuGet安装，在NuGet命令行中输入：install-package Ninject.MVC3（没错，是MVC3，虽然我用的是MVC4，但这个包同样支持MVC4。）安装完成以后会在App_Start文件夹中生成一个NinjectWebCommon.cs文件，打开这个文件。这里的代码会在应用程序启动之前执行，下面为我们的IRepository接口注册一个IoC容器，在RegisterServices方法中添加代码：这段代码的作用就是为IRepository注册一个具体实例Repository&MainContext&，MainContext是建模时定义的一个上下文，继承自DbContext，同时会为Repository传入一个名为LogErrorToFile的错误日志实例（LogErrorToFile实现了IErrorLogger接口中用于记录日志的方法），用于把错误信息记录到文本中（完全可以重新定义一个LogErrorToDB用于把错误信息记录到数据库，这就是依赖注入的好处，可以根据需要定义任何记录错误日志的方法，而不需要修改Repository的任何代码，即Repository不直接依赖于任何记录日志的具体实现。）当用户向ArticleController发送请求时，Ninject会通过ArticleController的构造方法传入一个IRepository的具体实现（这里是Repository&MainContext&），从而控制器间接依赖于Repository&MainContext&，如果有必要，将来完全可以重新定义一个IRepository的实现，例如不使用EF的数据访问层（NHibernate？），而不需要修改控制器的任何代码，降低了耦合度，提高了代码的复用性。
前面说了，控制器中的设计还有一点瑕疵，现在来改进一下。 上面Articles中的请求逻辑非常简单，从数据库中读取前10条文章，如果有一个很复杂的请求逻辑，可能这里就要写很多代码，那么控制器中的代码就会很长。并且这个请求逻辑可能还会出现在其他地方，那时候就又要写一段重复的代码。所以我们可以考虑把这段代码提出来，单独放到一个类中，这个类就是服务类：这个服务类同样依赖于IRepository接口，并且同样使用了构造方法参数注入的方式传入一个IRepository的实例。服务层同样不直接依赖于特定的仓储层。 那么控制器中的代码就可以修改成这样：但是追求完美的人可能又会提出一个问题，这里的控制器虽然不直接依赖于特定的仓储层，但是却直接依赖于ArticleService这个类，是不是违反了低耦合的原则呢？ 确实是这样，这里是采取了一个折中方案。因为服务层是对表现层应用逻辑的封装，服务层的作用就是向表现层暴露模型对象数据，可以认为服务层是表现层的一部分。当然我们也可以定义一个IArticleService接口，让控制器依赖于这个接口，而不是IRepository，那么在Ninject中也就不为IRepository注册实例，而是为IArticleService注册：IRepository repository=new Repository&MainContext&(new ErrorLogger.LogErrorToFile());kernel.Bind&IArticleService&().To&ArticleService&().WithConstructorArgument("repository", repository); 这同样是不错的设计，如果有一个请求用户数据的控制器UserController，则同样需要依赖于一个IUserService接口，那么也需要在Ninject中注册：kernel.Bind&IUserService&().To&UserService&().WithConstructorArgument("repository", repository); 在应用程序中会针对每一个模型建立一个访问该模型的服务，就会产生大量的服务，那么在应用程序启动之前，就需要为每个服务注册一个IoC容器， 但是服务的数量再多也是有限的，这并不会影响应用程序的效率（几十几百个服务都不是大问题），因此这种设计要更优秀一点。但是这样代码量就会变大，至于偏向哪一种，完全看个人爱好，如果追求完美可以考虑这种设计。可能会有人提出来，难道不能定义一个更高级的接口IService吗？让所有具体的服务接口都继承自这个接口。理论上是可以的，但是前面说了，服务层是对应用逻辑的封装，每个具体服务请求数据的方式都不同，没办法在一个高级接口中涵盖所有情况。
好了，这个项目的架构基本完成了。但别忘了，我们用的是ASP.NET MVC4，MVC4新增了一个很有用的功能—WebAPI。让我们来建一个WebAPI看看：看起来和一般的控制器没什么两样，只是继承自ApiController。执行一下看看会发生什么：竟然有错。原来Ninject不能直接支持WebAPI。该怎么办呢？我们可以手动让它支持。直接贴代码：先建一个NinjectWebApiScope类，实现System.Web.Http.Dependencies.IDependencyScope接口：再建一个NinjectWebApiResolver类，继承自上面的类：然后修改NinjectWebCommon.cs中的RegisterServices方法：设置应用程序默认的依赖解析器为我们自定义的解析器。 这样就可以了。
此贴原创，稍后发源代码。
c#开发会场,一亿元红包继续抢!助力创业者,一站购齐!万名c#开发优质服务商,细分领域专业人士继续为您服务!
好长时间没看到关于MVC4的东西了。并且是驱动部分。。。
先收藏了再说...
大一新生，开始直接上手MVC，发展需要好多东西呀。。
很遗憾的告诉楼主，ef的mysql连接器不能在linux,android,ios下运行
有一点需要注意，不能循环依赖注入
源码来一份，楼主，先谢了。
已收藏谢楼主
楼主，连接过期了，在分享一次么
最近正在学习ioc
云盘链接失效了，来一份，多谢了 ，
登录百度帐号推荐应用您所在的位置： &
2.2 测试领域架构
2.2 测试领域架构
电子工业出版社
《完美测试：软件测试系列最佳实践》本书力求通过一些典型案例告诉大家什么是完美测试，又如何做到完美测试。在给出的例子中，不仅包括功能测试、功能的异常测试、不同平台的功能测试和一些崩溃问题的处理，而且包括国际化测试、性能测试、用户体验测试、Accessibility测试等，并用较大的篇幅讨论了自动化测试。本节为大家介绍测试领域架构。
2.2 测试领域架构
一般在接触测试时，都是从黑盒测试方法开始的，因为其技术相对简单一些，只需要关注外部条件，包括输入、输出结果，而不需要关注系统的内部结构。但随着测试的深入，测试人员将不满足于这种黑盒测试方法，开始关注被测试系统的内部构造，并逐渐深入，比如以下从系统的架构设计到代码实现的思考。
1） 根据系统的内部结构，采取相应的对策实现。例如，数据层和业务逻辑层，都可以采用API 直接调用的测试方法。
2） 在代码层，根据程序结构，分别采用代码覆盖、分支覆盖、条件覆盖等方法来设计测试用例。
从这个演化的过程，可以隐隐约约地看到测试架构的形成。为了真正能解决问题，需要提高测试效率和测试覆盖率。测试不是单纯的，测试的方法也不是一成不变的，而且还要有系统性。
从测试结构来看，不仅要了解全部的测试内容，从单元测试到系统测试、从功能测试到非功能测试，如“附录B 软件测试的详细分类”，而且需要在分析、归纳和总结的基础上，将测试抽象到更高层面；提纲挈领，从整体上更好地把握测试任务。下面，将就功能测试和非功能测试分别讨论，而自动化测试架构，留到下一节讨论。
1. 功能测试
撇开非功能性测试，先谈软件产品的功能测试，以此来分析软件测试的架构。在功能测试中，不仅要完成业务逻辑的验证，还要进行用户界面和输入空间的验证。我们在讨论软件测试方法时，经常谈到的黑盒方法中的等价类划分、边界值分析、决策表、因果分析等方法，实际上都只是功能测试的冰山一角，仅为对输入空间的验证。为了使软件具有更好的质量，包括低缺陷率和高稳定性、可维护性，需要在代码这个层面进行充分的测试，就是人们常提到的单元测试，特别是对代码的评审、通过工具对代码进行静态分析。也就是说，在功能测试中，不光要进行不同层次的测试，还要针对不同空间或领域进行相应的测试，可以用图2-3 简要加以描述。
图2-3 不同视角看功能测试
如果展开讨论，不同的测试领域会侧重采用不同的测试方法，如基于用例的测试，主要用于用户界面测试，但也会用于业务逻辑验证；而基于模型的测试，主要用于语法验证和业务逻辑验证等。图2-4 系统地介绍了不同测试领域的测试方法，其中几个用英文书写的说明如下：
FSM（Finite State Machine，有限状态机）
ForS（Formal Specification，形式规格说明）
FunS（Functional Specification，功能规格说明）
图2-4 功能测试架构示意图
这些测试方法构成了功能测试的架构，即设计一个软件项目的测试功能，就要从用户界面验证、业务逻辑验证、输入空间验证和语法验证4 个方面去考虑。针对不同的方面，根据软件应用系统的技术特点等，选择或决定合适的测试方法、工具等，也是测试架构这个层面需要考虑的。
2. 非功能测试
如果从非功能测试角度来考察测试架构，其和软件开发的架构更为贴近，两者在技术要求上是一致、相通的。非功能测试要追溯到设计阶段，软件设计是前提，设计不好，实现得再好可能也无济于事。所以，非功能测试可以看做由两大部分组成。
1） 设计验证：这是纸上谈兵，针对系统设计说明书进行评审，发现设计的缺陷，因可防患于未然而显得更为重要。这也是和开发人员在思路上的辩论，针锋相对地提问，通过讨论甚至辩论来发现问题。
2） 系统验证：将设计付诸于实施，针对建成后的系统进行验证，以确定系统是否达到设计要求。当然这一步也非常重要，设计得再好，还是要看实际的结果。
对于非功能性测试架构，要在对系统设计和构造理解的基础上来确定测试的具体方法。可以用简单的图来描述，如图2-5 所示。
图2-5 非功能性测试的架构示意图
每一类测试可能需要单独考虑，性能测试和兼容性测试、安全性测试都不一样，不同类型的测试，考虑的着眼点不一样，其方法也不一样，所使用的测试工具也不一样。当然，压力测试、稳定性测试可以和性能测试一起考虑。这里以性能测试为例，其包括如下的关键因素。
1） 测试环境：构造和产品实际运行相当的测试环境。
2） 关键业务：根据系统的设计和实现，判断可能存在性能风险的业务操作点。
3） 负载：根据系统的负载，确定可能受到的最大负载、平均负载等。
4） 监控指标：哪些系统资源是有限的而且会产生瓶颈，需要在测试过程中被监控。
5） 结果分析：通过对测试结果分析，确定性能问题，并分析造成性能缺陷的根本原因。
分析上面这些因素可知，构造一个良好的性能测试解决方案，关键还是要对系统实现全面了解，特别是对被测试的特性（这里指性能）要理解，能把握外部因素对系统的被测试特性的影响，从而确定系统测试的输入和测试的输出。除此之外，我们还得用技术的办法来模拟负载、监控系统的资源或响应，这实际上就是我们经常讲的建模，用逻辑的模型或数学模型来描述实际的物理模型，如图2-6 所示。
图2-6 非功能性测试的建模（系统模拟）
【责任编辑： TEL：（010）】&&&&&&
关于&&&&的更多文章
如何成为一个好的软件测试人员？如何坚持自己的软件测试生涯？软
本书描述了黑客用默默无闻的行动为数字世界照亮了一条道路的故事。
SDN（Software Defined Networking，软件定义网络）是
Web 2.0技术对传统界面设计的创新和变革，直接影响着
每天，Google都要测试和发布数百万个源文件、亿万行的
本书全面深入地介绍网络安全的配置与实现技术，包括系统管理、用户账户、病毒防御、灾难恢复、文件备份、安全策略、注册表等服务
51CTO旗下网站}