JMeter 聚合报告之 90% Line 参数说明 Posted on  2013-02-26 22:06  虫师 阅读( 1262) 评论( 3)  编辑  收藏  其实要说明这个参数的含义非常简单，可能你早就知道他的含义，但我对这个参数一直有误解，而且还一直以为是“真理”，原于一次面试，被问到了这个问题，所以引起我这个参数的重新认识。   先说说我错误的认识：       我一直把90%Li

单一职责原则：就一个类而言，应该仅有一个引起它变化的原因。   如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。   软件设计时要发现职责并把那些职责相互分离。如何判断是否应该分离呢？如果你能够想到多于一个动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类

UML的构造快包含3种：  (1) 事物（4种）：结构事物，行为事物，分组事物，注释事物 (2) 关系（4种）：泛化关系，实现关系，依赖关系，关联关系 (3) 图（10种）：用例图，类图，对象图，包图，组件图，部署图，状态图，活动图，序列图，协作图 事物是对模型中最具代表性的成分的抽象；关系把事物结合在一起；图聚集了相关的事物。     (2) 关系（4种） UML 中类与类, 类与接口, 接口与

依赖倒置原则（Dependence Inversion Principle），简称DIP 定义 High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details

里氏置换原则（Liskov Substitution Principle），简称LSP 定义： Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. 所有引用基类的地方必须能够透明的使用其子类对象。 也就

单一职责原则（Single Responsibility Principle），简称SRP。 定义： There should never be more than one reason for a class to change. 应该有且仅有一个原因引起类的变更。   有时候，开发人员设计接口的时候会有些问题，比如用户的属性和用户的行为被放在一个接口中声明。这就造成了业务对象和业务逻辑被放在了

定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。 问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。 解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会

肯定有不少人跟我刚看到这项原则的时候一样，对这个原则的名字充满疑惑。其实原因就是这项原则最早是在1988年，由麻省理工学院的一位姓里的女士（Barbara Liskov）提出来的。 定义1：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。 问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。 解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类

Spring 能有效地组织J2EE应用各层的对象。不管 是控制层的Action对象，还是业务层的Service对象，还是持久层的DAO对象，都可在Spring的 管理下有机地协调、运行。Spring将各层的对象以松耦合的方式组织在一起，Action对象无须关心Service对象的具体实现，Service对 象无须关心持久层对象的具体实现，各层对象的调用完全面向接口。当系统需要重构时，代码的改写量将

UML的构造快包含3种： (1) 事物（4种）：结构事物，行为事物，分组事物，注释事物 (2) 关系（4种）：泛化关系，实现关系，依赖关系，关联关系 (3) 图（10种）：用例图，类图，对象图，包图，组件图，部署图，状态图，活动图，序列图，协作图 事物是对模型中最具代表性的成分的抽象；关系把事物结合在一起；图聚集了相关的事物。 (2) 关系（4种） UML 中类与类, 类与接口, 接口与接口这间的

依赖倒置原则又称依赖倒置原则： 抽象不应该依赖细节，细节应该依赖于抽象。说白了，就是针对接口编程，不要针对实现编程。 依赖倒置原则包含三层含义： 1)高层模块不应该依赖低层模块，两者都应该依赖其抽象； 2)抽象不应该依赖细节; 3)细节应该依赖抽象。 看了上面的解释相信大家会和我一样会有一些疑问在脑海里(你存在我深深的脑海里)下面来详细说一说吧： 1)为什么要针对接口编程，而不是针对实现编程呢？

关于控制反转和依赖注入的文章和书籍很多，对其定义也解释的也仁者见仁，这里就不赘述了，这是本人（只代表个人观点）理解之后用通俗的例子和平淡的话词为您解释，希望对您有所帮助： 控制反转（IoC/Inverse Of Control）:   调用者不再创建被调用者的实例，由spring框架实现（容器创建）所以称为控制反转。 依赖注入(DI/Dependence injection) :   容器创建好实

IOC 和DI，这两个在Java中指的是控制反转和依赖注入；熟悉struts2 , spring的人对于这两个名词都很不陌生； 最近在学习的过程中，又不断的碰到这两个词；而网络上，更多的是对依赖注入的方式进行了说明；而很少提到具体什么是IOC和DI；在此蛮说一下自己对这两个的理解； 依赖注入、控制反转；提到这两个概念，必须首先了解什么是依赖； 依赖："依赖描述了两个模型元素之间的关系，如果被依赖的

http://justsee.iteye.com/blog/808799 UML的构造快包含3种：  (1) 事物（4种）：结构事物，行为事物，分组事物，注释事物 (2) 关系（4种）：泛化关系，实现关系，依赖关系，关联关系 (3) 图（10种）：用例图，类图，对象图，包图，组件图，部署图，状态图，活动图，序列图，协作图 事物是对模型中最具代表性的成分的抽象；关系把事物结合在一起；图聚集了相关的事

问题由来 　　类A直接依赖于类B，加入要将类A修改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑。类B和C是底层模块，负责基本的原子操作。假如修改类A，将会给程序带来不必要的风险。而遵循依赖倒置原则的程序设计可以解决这一问题。 什么是依赖倒置原则 　　英文缩写DIP（Dependence Inversion Principle）。 　　原始定义：Hi

一，说在前面的话 大概在半年前，看见一到信息竞赛题：在任意方格阵中设置障碍物，确定起始点后，求这两点之间路径。当时觉得蛮有意思的，但是没有时间去做，今天花了两个小时来实现它。据说有一个更高级的寻路算法叫做a*, 那我就把我的算法叫做W*。 这个算法主要用于解迷宫和实现战棋游戏(SLG)的寻路。 首先讲一讲我的算法的思路： 我们先确定起始点，然后从起点出发，按一定顺序判断这个位置上下左右是否有可走的

compile（编译范围） compile是默认的范围；如果没有提供一个范围，那该依赖的范围就是编译范 围。编译范围依赖在所有的classpath中可用，同时它们也会被打包。   provided（已提供范围） provided依赖只有在当JDK或者一个容器已提供该依赖之后才使用。例如，如果 你开发了一个web应用，你可能在编译classpath中需要可用的Servlet API来编 译一个ser

类之间的关系 种类： Generalization(泛化)，Dependency(依赖关系)、Association(关联关系)、Aggregation(聚合关系)、Composition(合成关系)。 其中Aggregation(聚合关系)、Composition(合成关系)属于Association(关联关系)，是特殊的Association关联关系。 Generalization(泛化)表现

“我的TDD实践”系列之CI持续集成   写在前面： 我的TDD实践这几篇文章主要是围绕测试驱动开发所展开的，其中涵盖了一小部分测试理论，更多的则是关注工具的使用及环境的搭建，做到简单实践先行，后理论专精的目的。   TDD实践系列文章： 1.TDD概念篇 2.CI持续集成 3.SVN架设篇 4.NUint测试框架 5.Mock模拟框架 6.Inject注入框架 7.TestCoverage代码覆

今天帮忙同事调试一个自定义Panel的问题， 很奇怪， 利用Binding可以通过ItemSource来添加控件，但是在Listbox的xaml里添加几个ListboxItem却报异常： VisualTree of ItemsPanelTemplate must be a single element. 原因有2： 1）ListBox的ItemPanelTemplate使用自定义Panel时， 需

摘要：测试可以帮助项目团队找出代码中存在的问题，TDD方式更是将测试放在了开发工作的首位。那么在团队中该如何应用单元测试和TDD呢？开发者Paulo Ortins结合自身经历给出了本文中的12个经验教训。 测试可以帮助项目团队找出代码中存在的问题，TDD方式更是将测试放在了开发工作的首位。那么在团队中该如何应用单元测试和TDD呢？开发者Paulo Ortins结合自身经历给出了本文中的12个经验教

“我的TDD实践”系列之SVN架设   写在前面： 我的TDD实践这几篇文章主要是围绕测试驱动开发所展开的，其中涵盖了一小部分测试理论，更多的则是关注工具的使用及环境的搭建，做到简单实践先行，后理论专精的目的。    TDD实践系列文章： 1.TDD概念篇 2.CI持续集成 3.SVN架设篇 4.NUint测试框架 5.Mock模拟框架 6.Inject注入框架 7.TestCoverage代码覆

两年前，我在一个Web项目开发组中，项目的目标是编写一个类似Excel的、用来计算产品/服务价格的Web应用程序。项目团队被分成3部分——开发团队、需求团队和QA团队。随着项目越做越大，而我们没有使用任何形式的自动化测试（QA团队使用手工测试），结果导致项目的测试时间比开发时间还要多。每进行一次小的改动，QA团队都要花费几个小时来做测试。 有一天，我参加了一个开发者会议，并与其他程序员谈到了这些问

前面的话：提到依赖注入，大家都会想到老马那篇经典的文章。其实，本文就是相当于对那篇文章的解读。所以，如果您对原文已经有了非常深刻的理解，完全不需要再看此文；但是，如果您和笔者一样，以前曾经看过，似乎看懂了，但似乎又没抓到什么要领，不妨看看笔者这个解读，也许对您理解原文有一定帮助。 1.依赖在哪里    老马举了一个小例子，是开发一个电影列举器（MovieList），这个电影列举器需要使用一个电影查

一. 摘要 　　首先圣殿骑士很高兴这个系列能得到大家的关注和支持，这个系列从七月份开始到现在才第七篇，上一篇发布是在8月2日，掐指一算有二十多天没有继续更新了，最主要原因一来是想把它写好，二来是因为最近几个月在筹备“云计算之旅”系列，所以一再推迟了发布进度。之前一直都没有想过要录制视频，主要的原因还是怕自己知识有限，从而误导他人，所以前几次浪曦和51CTO邀请录制视频，我都以工作忙、公司内部培训需

UML的构造快包含3种：  (1) 事物（4种）：结构事物，行为事物，分组事物，注释事物 (2) 关系（4种）：泛化关系，实现关系，依赖关系，关联关系 (3) 图（10种）：用例图，类图，对象图，包图，组件图，部署图，状态图，活动图，序列图，协作图 事物是对模型中最具代表性的成分的抽象；关系把事物结合在一起；图聚集了相关的事物。     (2) 关系（4种） UML 中类与类, 类与接口, 接口与

转自http://justsee.iteye.com/blog/808799   UML的构造快包含3种：  (1) 事物（4种）：结构事物，行为事物，分组事物，注释事物 (2) 关系（4种）：泛化关系，实现关系，依赖关系，关联关系 (3) 图（10种）：用例图，类图，对象图，包图，组件图，部署图，状态图，活动图，序列图，协作图 事物是对模型中最具代表性的成分的抽象；关系把事物结合在一起；图聚集了

前言 　 此文译自CodeProject上<How I explained OOD to my wife>一文，该文章在Top Articles上排名第3，读了之后觉得非常好，就翻译出来，供不想读英文的同学参考学习。 作者(Shubho)的妻子(Farhana)打算重新做一名软件工程师(她本来是，后来因为他们孩子出生放弃了)，于是作者就试图根据自己在软件开发设计方面的经验帮助她学习面向对象设计(O

端口聚合又称作链路聚合，即将几个链路作聚合处理以达到增加交换机之间的连接带宽，避免网络瓶颈的目的。 链路聚合控制协议实现了如何将两个以上的以太网链路组合起来成为高带宽通道。其实现方法是在交换机上把多个物理端口的链路连接捆绑在一起形成一个简单的逻辑连接　这个逻辑连接被称为聚合端口。 冗余链路和流量负载平衡是端口聚合的根本目的。 一、二层端口上的链路聚合 端口的聚合有两种方式，一种是手动的方式，一个是