为此我还特地去注册了一个腾讯微博开放平台的开发者，当我开始阅读开发文档的时候，才发现，他妹的，腾讯官方已经推出一个相同功能的应用，叫作
“Q-Share”，再翻阅了一下其他资料，原来已经有前辈写出了 js
页面文字选中后分享到新浪微博的方法，那我就省力多了，两者结合一下，把新浪微博和腾讯微博两个按钮都加上了，然后闲的蛋疼的我又把它翻译成了 jQuery
的方法。

效果的话就可以看本站了，选中任何文字，就会在右上角显示两个微博按钮，点击试试吧。

实现的方法也很简单，只需要两步：

1、引入 jQuery，相信大多数 WordPress 博客都已经引入了 jQuery，那就可以直接进行第二步了。

2、在页面底部，或者更确切的说，在引入 jQuery 库的后面加上这样一段 JS，你就可以看到和本站一样的效果了。

是不是很简单呀？

赶紧选中本文的标题，在微博上通知你的好友来围观吧，哈哈~

    融资，固然能促进小范围产业链的深化扩张，实现资本快速积累。但是，领测国际凭借什么优势能够吸引“带着资源”的投资呢？

    完整的产业链，环环递进

 
    据贺炘介绍，领测国际最大的优势在于，在七年的时间中打造了一个小范围的软件测试产业链，实现了软件测试相关产业的关联和互促。
    目前，这个产业链的基本模式是：软件测试技能培训——软件测试求职招聘——软件测试工作提供——软件测试技能提升（领测软件测试网，领测软件测试论坛）——软件测试企业培训——软件测试国际认证——软件测试工具服务——软件测试服务外包。以上各个环节之间，均保持着相互递进的关系，共同促进企业和产业的发展。

 
    独特商业模式，凸显优势

 
    领测国际经过多年的发展，已经小范围内形成了一个完整的软件测试产业链。那么，其具体的商业模式究竟是怎么的呢？

 
    贺炘说：“大部分的IT培训机构，都是靠网络广告支撑，但是，过度的依赖广告投放，会进入一个恶性循环。而领测国际，旗下有一个专业的软件测试门户网站，这个网站作为软件测试行业的主流媒体，吸引了大批的软件测试工程师、软件研发工程师、软件质量工程师聚集于此，就连IBM、微软等企业也有广告投放。另外，网站还通过BBS、技术博客、技术培训、人才交流等多项服务，促进软件测试专业人员的交流。这样，我们的商业模式就凸显出来了。”
    “与此同时，在专业教学团队的带领下，100%的就业率和良好口碑也为我们带来了大量学员，让我们逐渐摆脱了以广告为主的生存模式，实现了体系内良性发展。” 贺炘说。

        技术背景的领导+专业团队
    核心团队的能力和潜力，是投资人在选择投资对象时最看重的一个要素。对于领测国际来说，这个团队的优势在于：第一，企业领导者具有雄厚的技术背景，能亲自参与到教学细节中，挑选师资把控教学，促进软件测试产业链各个环节间的递进发展。

    据了解，贺炘现任北京市软件行业协会测试工作委员会副秘书长、中国软件服务外包标准评审委员会评审专家，有多年软件测试和项目管理经验，主持过朗讯、佳能、神州数码、用友、上海贝尔等众多企业的内训和公开课。在贺炘的把关下，领测国际的师资团队，全部具有5年以上软件测试经理经验，给上百家等企业做过培训，技术能力业内领先。

 
    除了专业的教学团队外，领测国际的咨询部和渠道部负责人，也具有深厚的资历和专业背景。其中，招生咨询负责人，具有IT培训机构6年以上咨询经验；渠道负责人，具有十余年从业历史，能同时抓好就业合作和院校合作两条路线。

    标准化模式，可迅速复制

    标准化，一直是培训机构探讨的热点话题。而领测国际，目前已经初步形成了一个标准化的教学管理模式，贯穿咨询、教学、就业和就业后的提升服务等各个环节，这一模式无疑为将来快速复制产业链提供了良好的根基和土壤。

    其中，非常值得一提的是，由领测国际主编的软件测试培训教材，于2008年经过国家工信部评审认证，到目前为止，国内仅领测一家软件测试培训机构受此认证。课程的高度权威性，也极大的促进了领测国际标准化工作的开展。

    不过，贺炘直言，只有在保证师资水平的前提下，课程标准化才能起到作用，商业模式才能复制。有些培训机构，包括高等院校，虽然也有一套标准化的教材，但是因为师资水平参差不齐，导致教学和就业效果不佳。而相比之下，领测国际的就业率却达到100%，平均就业薪水也达到3500元。

 
    专注软件测试，坚持理想

 
    “所有的优势，都来源于我们对软件测试行业的理想和专注。贺炘说。

    据了解，现在很多培训机构都是发现做软件测试培训比较挣钱后，才涉足其中的，他们仅仅是把软件测试当成一个挣钱的方式。对于这部分培训机构来说，做软件测试和做JAVA、.NET没有什么区别，只要渠道好了，就可以附以其他产品。而领测国际则是认准了这个行业，只做软件测试，目前培训过的企业已经达到几百家，包括建行、工行等。

  贺炘表示，未来将继续坚持这份理想和专注，把软件测试当成一个产业去做，进一步促进已有的产业链的完善和发展。
    资本市场，更有责任在肩

 
    凭借独特的商业模式和打造软件测试产业链的战略目标，领测国际在7年中不断发展壮大。贺炘经理说：“经过多年的管理和磨合，我们已经有了一套可复制的体系。未来能拿到投资的话，会从两方面考虑：第一，如果带着资源，会将相关资源的产业部分做大做强；第二，如果不带资源，会将可复制的模式尽快在优势城市复制商业模式。”

    贺炘还表示，软件测试行业有很大的发展空间，但是受诸多因素影响，目前还是小众市场，没有被更多的人知道。所以，领测国际也肩负着培育市场的责任，希望利用电子期刊、论坛、门户网站等优势，促进软件测试培训市场的进一步深化发展

转自:领测软件测试网[http://www.ltesting.net]
原文链接:http://www.ltesting.net/ceshi/news/ltestingnews/2011/1031/203424_2.html

　　【关键字】性能测试　　并发测试　　负载测试

　　? 软件测试中的性能测试

　　软件测试是保证软件质量的重要手段，也是软件过程中一个必不可少的环节。而性能测试则隶属于软件测试中的系统级测试，它对软件在集成系统中运行的性能行为进行测试，旨在及早确定和消除软件中与构架有关的性能瓶颈。

　　? 性能测试的含义

　　目前对性能测试没有明确的定义，一般地，它主要是针对系统的性能指标制定性能测试方案，执行测试用例，得出测试结果来验证系统的性能指标是否满足既定值。性能指标里可能包括系统各个方面的能力，如系统并发处理能力，批量业务处理能力等。

　　? 性能测试的分解

　　在性能测试的执行中，可以根据具体的性能指标，分解为几种测试，根据其关系，可以在不同的时间和空间内执行。这些子测试通常包括以下几种：

　　并发测试：验证系统的并发处理能力。一般是和服务器端建立大量的并发连接，通过客户端的响应时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。

　　负载测试：验证系统的负载工作能力。系统配置不变的条件下，在一定时间内，服务器端在高负载情况下的性能行为表现。这里的负载可以是用户数，交易数，事务数等。

　　配置测试：核实在操作条件保持不变的情况下，系统在使用不同配置时其性能行为的可接受性。

　　健壮性测试：核实被测系统的性能行为在异常或极端条件之下的可接受性。这里的异常或极端条件指的是资源过少，用户数过多，突发故障等。

　　随着软件系统的规模日益庞大，结构日趋复杂，对软件系统的性能测试已经成为必须和趋势。尤其大型的分布式软件系统更要在正式运行前进行性能测试，因为这样的系统在投入生产之后，往往要接受大批量的业务量，这对应用程序本身，操作系统, 中心数据库服务器，中间件服务器，网络设备的承受力都是一个严峻的考验。在其中任意一个环节出现的问题都可能给用户带来巨大的商业损失。预见软件系统的并发承受能力以避免商业风险，这是在软件测试阶段就应该解决的。例如中国人民银行的现代化支付系统和上海外汇交易中心的本币交易系统都在投入生产之前进行了多轮的第三方性能测试，起到了很好的作用。

　　下面我就介绍一个性能测试案例。

　　?一个性能测试实例

　　? 被测系统

　　1)被测系统介绍

　　本系统应我国金融信息化发展设计，采用当今比较先进和流行的技术，是运行在城域网上的大型分布式应用系统。

　　本系统遵循J2EE规范，采用B/S体系结构进行设计和开发。业务主要分为交易业务和查询业务，查询业务采用J2EE规范，交易业务以J2EE体系架构为基础，进行进一步的处理，采用了TCP的四层结构。系统体系结构图如下：

　　图表 1被测系统体系结构设计图

　　表示层：

　　运行在终端上。运行java applet程序，提供协议控制和用户界面，与系统最终用户实现直接交互，通过TCP/HTTP与前置系统通讯。向前置系统发送请求报文，并接收前置系统返回的回应报文。

　　商业逻辑层：

　　作为中间层实现核心业务逻辑服务。

　　交易应用服务：运行在交易主机上。在tuxedo中间件上运行业务处理程序，按交易规则处理前置机发来的交易指令，通过tuxedo jolt与前置机连接，通过DB2 C API与数据库连接。

　　交易前置服务和查询前置服务：运行在前置机上。交易前置服务运行服务程序接收终端请求报文并通过tuxedo jolt客户端将其转发给交易主机，再通过轮询和同步反馈接收交易主机返回的报文，将其转发给业务终端;查询前置服务运行在weblogic应用服务器上并调用Jreport组件，通过JDBC完成对查询流指令的发送并接受数据库返回的结果给业务终端。

　　数据层：

　　运行在数据库主机上。负责整个系统中数据信息的存储、访问及其优化。运行DB2数据库服务程序。通过DB2 C API与交易主机通讯，JDBC与查询前置服务通讯。数据库主机和交易主机运行在交易中心城市，前置机运行在各个分中心城市，终端是各个城市参加交易的单位，整个系统覆盖城域网。

　　2) 被测系统的性能要求和性能指标

　　金融系统是业务处理十分频繁、数据交换吞吐量很大的系统，业务处理的速度直接关系到公司的经济效益和客户对公司的评价。在客观条件下，整个广域网系统必须在大业务量的情况下同时保持快速的实时响应能力，以保证整个业务系统的通畅运行。用户对此提出如下性能指标：

　　表格1用户要求性能指标表

　　下面我们会根据此系统和给定的性能指标来进行性能测试：

　　?

　　性能测试的目的是最大程度地模拟真实业务场景，来验证系统的性能指标，并发现可能存在的性能瓶颈。

　　1)对被测系统进行系统分析

　　我们可以看到本系统大体上由终端、前置机、交易主机、数据库主机节点组成。

　　在整个业务流程中，业务终端→前置机→交易主机→数据库主机形成了一个压力流串，每个节点在压力下能够正常工作是整个系统正常运转的基础。也就是说，如果其中任意一个节点在业务压力下发生了拥塞、处理不力等不正常情况，那整个系统都无法正常运转。

　　近期我跟踪了2个外协人员参与的性能测试项目，沟通中发现大家在制定测试策略时对如何确定负载目标、计算并发用户数量等方面有很多不同方法，本文希望能对各种方法进行探讨，并根据已有经验对策略制定方面给出一些自己的建议。本文被测应用以银行系统为主，压力发起工具以LoadRunner为例。

　　二、术语

　　单位时间：本文中以1秒为单位时间。

　　在线用户数量：访问被测应用的用户数量，但单位时间内用户不会同时对被测服务器发送请求，产生压力。

　　并发用户数量：部分书中分狭义和广义两种，狭义指单位时间内同时执行一种操作的用户数量，广义指单位时间内同时执行多种不同操作的用户数量，广义的并发用户操作更接近实际业务环境。但本文中的并发用户数量仅指狭义而言，因为广义是多种狭义的组合。

　　TPS：Transaction per Second，每秒事务数量，单位是事务/秒。

　　TRT：Transaction Response Time，事务响应时间，指TPS稳定时的平均事务响应时间，单位是秒。

　　三、负载目标

　　1. 负载视角

　　制定测试策略是性能测试的重点，包括测试范围、场景提取、负载目标、发起方式、通过标准等。而负载目标关系整个测试的场景设计、并发配比、结果评判，因此确定负载目标也决定了测试的总体方向。通过了解业务需求，负载目标都会转化为一系列具体的数值，一般可从两方面来划分：

　　前端：业务人员更关注前端并发用户数量或在线用户数量，以人数衡量;

　　后端：技术人员更关注后端应用服务器和数据库服务器的负载能力，以TPS衡量;

　　前端并发用户数量的计算在业界中有很多公式和原则，如2/8原则、10%在线用户数量估算、(在线用户数量*session时间)/监控时间等，但各公式和原则计算出的并发用户数量并不精确，如有10万在线用户的系统不能说仅测试10万*10%=1万并发用户即可。

　　后端TPS反应被测应用的实际负载能力，对已有具体业务量的应用可以计算精确，如银行系统中某省行对公交易量日均10万笔，则可精确计算出TPS均值=10万/(6*3600)=4.63笔/秒(对公业务按6小时计算)，若被测应用达不到TPS要求则完成不了当日业务。

　　同一个被测应用以不同视角估算负载目标，得到的数值可能会有很大差异，因此如何正确选择负载目标，将会直接影响之后的测试方法和场景设计。

　　2. 负载指标

　　抛开视角的选择，单从最终测试指标来说，对于一个软硬件环境固定的应用程序，只有一个负载指标是固定的，那就是最大事务处理能力 – 通常以TPS衡量。随着负载的增加，被测应用将会逐渐达到最大事务处理能力，若应用足够健壮，则负载继续增加，应用的事务处理能力也不会骤然下降。因此性能测试的目标就是确定被测应用的最大事务处理能力。以事务处理能力反推，将逐渐捋清TPS、TRT、并发用户数量、在线用户数量等负载目标的关系和估算。

　　1、TPS

　　Transaction的粒度会直接影响TPS的计算，因此Transaction定义时要保证粒度适当：

　　C/S架构联机类应用中一笔交易往往会流经多层前置应用，需要确定压力发起工具所在位置，建议跨过前端直压被测应用，此时一个Transaction代表一支后台交易。

　　B/S架构经管类应用中一个页面操作可能会和后台有多次交互，建议以页面上的操作为Transaction划分基准，但要保证Transaction内的交互操作在前端是不可再拆分的。

　　LoadRunner发起压力时Action内的语句是反复迭代的，而LR计算TPS仅看1秒内执行了几次Transaction，如果Action内有多个Transaction则各事务的TPS都一样，反应不出各事务的真实处理能力，因此建议Action内只定义一个或尽量精简的Transaction。

　　由此TPS才可以准确表示被测应用的事务处理能力。

　　通过获取生产日志、参考相似系统等方式能够得到具体交易(事务)数量的被测应用程序，以TPS为负载目标是直接也最准确的。但要注意，若以TPS为目标，则前端配置的并发数量就不再代表并发人数，而是并发提交事务的数量。TPS和TRT的计算关系将在下面详述。

　　2、TRT

　　TRT指TPS稳定时(不一定是最大时)的平均事务响应时间，不关注个别事务，它和TPS关系紧密，随TPS的变化而变化。当负载增加时TRT会逐渐增大，直至事务阻塞，交易超时。

　　TPS × TRT = 并发提交事务的数量。如果以TPS=20为目标，且此时TRT=2秒，则并发提交事务的数量=20×2=40笔。如果1个用户单位时间内提交1笔事务，则可等于有40个并发用户数量。

　　设定好目标TPS后要同时兼顾TRT的表现，若TRT明显超出业务要求，即使达到负载目标也是无效的。TRT无固定的好坏标准，一般来说对OLTP的联机应用，从前端提交到返回不应高于3秒，后台应用程序和数据库的处理应在1秒左右。对OLAP的在线分析系统或一般网站可遵循3/5/8原则，或更长。

　　3、并发用户数量

　　通常理解并发用户数量就是LoadRunner里设置的VUser数量，通过梯度增加VUser，对比TPS变化即可找到被测应用的最大并发用户。但我却认为并发用户数量不等于LoadRunner中设置的VUser数量。受交易响应时间、thinktime、pacing和集合点等因素影响，VUser数量不能直接体现被测应用负载能力。假设同样10个VUser并发一次，如果A程序的响应时间是1秒，则A程序的TPS=10/1=10。而B程序的响应时间是5秒，则B程序的TPS=10/5=2。同样在混合场景中用VUser比例体现不同应用的负载比例也是错误的，混合场景下由于各交易相互影响，单交易负载时响应快的很可能现在出现阻塞，前端VUser的比例根本无法准确控制后端应用的压力。

　　因此我更愿意将“并发用户数量”和“并发提交事务数量”挂钩，体现被测应用实际负载：单位时间内n个用户并发向被测应用提交n个事务请求(n是相同的)。VUser的数量和发起设置只是实现并发用户数量的一种手段。

　　4、在线用户数量

　　在线用户数量与并发用户数量、TPS、TRT间没有固定的换算公式，我不提倡10%这样的粗糙比例，对联机类应用在线用户就是每天签到的柜员数量，对经管类应用就是月末、季末时所有登录系统的用户数量。在线用户数量可以从需求人员或生产管理员处获得大概数值，但不能通过性能测试倒推出在线数量。

　　1、使用statement插入100000条记录

　　public void exec(Connection conn){

　　try {

　　Long beginTime = System.currentTimeMillis();

　　conn.setAutoCommit(false);//设置手动提交

　　Statement st = conn.createStatement();

　　for(int i=0;i<100000;i++){

　　String sql="insert into t1(id) values ("+i+")";

　　st.executeUpdate(sql);

　　}

　　Long endTime = System.currentTimeMillis();

　　System.out.println("st："+(endTime-beginTime)/1000+"秒");//计算时间

　　st.close();

　　conn.close();

　　} catch (SQLException e) {

　　// TODO Auto-generated catch block

　　e.printStackTrace();

　　}

　　}

　　2、使用PreparedStatement对象

　　public void exec2(Connection conn){

　　try {

　　Long beginTime = System.currentTimeMillis();

　　conn.setAutoCommit(false);//手动提交

　　PreparedStatement pst = conn.prepareStatement("insert into t1(id) values (?)");

　　for(int i=0;i<100000;i++){

　　pst.setInt(1, i);

　　pst.execute();

　　}

　　conn.commit();

　　Long endTime = System.currentTimeMillis();

　　System.out.println("pst:"+(endTime-beginTime)/1000+"秒");//计算时间

　　pst.close();

　　conn.close();

　　} catch (SQLException e) {

　　// TODO Auto-generated catch block

　　e.printStackTrace();

　　}

　　}

　　3、使用PreparedStatement + 批处理

　　public void exec3(Connection conn){

　　try {

　　conn.setAutoCommit(false);

　　Long beginTime = System.currentTimeMillis();

　　PreparedStatement pst = conn.prepareStatement("insert into t1(id) values (?)");

　　for(int i=1;i<=100000;i++){

　　pst.setInt(1, i);

　　pst.addBatch();

　　if(i%1000==0){//可以设置不同的大小;如50，100，500，1000等等

　　pst.executeBatch();

　　conn.commit();

　　pst.clearBatch();

　　}

　　}

　　Long endTime = System.currentTimeMillis();

　　System.out.println("pst+batch："+(endTime-beginTime)/1000+"秒");

　　pst.close();

　　conn.close();

　　} catch (SQLException e) {

　　// TODO Auto-generated catch block

　　e.printStackTrace();

　　}

　　}

　　在Oracle 10g中测试，结果：

　　1、使用statement耗时142秒;

　　2、使用PreparedStatement耗时56秒;

　　3、使用PreparedStatement + 批处理耗时：

　　a.50条插入一次，耗时5秒;

　　b.100条插入一次，耗时2秒;

　　c.1000条以上插入一次，耗时1秒;

　　通过以上可以得出结论，在使用jdbc大批量插入数据时，明显使用第三种方式(PreparedStatement + 批处理)性能更优。

　　当使用sqlserver 2000进行测试时，第三种方式最少耗时5秒，从这方面可以看出Oracle在处理大量数据时，明显性能更强。

　　您可能感兴趣的文章

　　性能测试工具在测试工作中的重要性

　　性能测试总结之内存泄露和内存溢出

　　性能测试负载目标探讨

　　性能测试原理及性能测试实例分析

　　性能测试在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。

　　应用在客户端性能的测试

　　应用在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能测试是重点。

　　并发性能测试是重点

　　并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试(Load Testing)是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。压力测试(Stress Testing)是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

　　并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能;当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能;通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。

　　当一家企业自己组织力量或委托软件公司代为开发一套应用系统的时候,尤其是以后在生产环境中实际使用起来,用户往往会产生疑问,这套系统能不能承受大量的并发用户同时访问? 这类问题最常见于采用联机事务处理(OLTP)方式数据库应用、Web浏览和视频点播等系统。这种问题的解决要借助于科学的软件测试手段和先进的测试工具。

　　举例说明：电信计费软件

　　众所周知,每月20日左右是市话交费的高峰期，全市几千个收费网点同时启动。收费过程一般分为两步,首先要根据用户提出的电话号码来查询出其当月产生费用,然后收取现金并将此用户修改为已交费状态。一个用户看起来简单的两个步骤,但当成百上千的终端，同时执行这样的操作时，情况就大不一样了,如此众多的交易同时发生,对应用程序本身、操作系统、中心数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。决策者不可能在发生问题后才考虑系统的承受力, 预见软件的并发承受力, 这是在软件测试阶段就应该解决的问题。

　　目前，大多数公司企业需要支持成百上千名用户，各类应用环境以及由不同供应商提供的元件组装起来的复杂产品，难以预知的用户负载和愈来愈复杂的应用程序，使公司担忧会发生投放性能差、用户遭受反应慢、系统失灵等问题。其结果就是导致公司收益的损失。

　　如何模拟实际情况呢? 找若干台电脑和同样数目的操作人员在同一时刻进行操作,然后拿秒表记录下反应时间? 这样的手工作坊式的测试方法不切实际，且无法捕捉程序内部变化情况,这样就需要压力测试工具的辅助。

　　测试的基本策略是自动负载测试，通过在一台或几台PC机上模拟成百或上千的虚拟用户同时执行业务的情景，对应用程序进行测试，同时记录下每一事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能，确定问题所在以及优化系统性能。预先知道了系统的承受力,就为最终用户规划整个运行环境的配置提供了有力的依据。

　　并发性能测试前的准备工作

　　测试环境：配置测试环境是测试实施的一个重要阶段，测试环境的适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备以及打印机/扫描仪等辅助硬件设备所构成的环境;软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。

　　一个充分准备好的测试环境有三个优点：一个稳定、可重复的测试环境，能够保证测试结果的正确;保证达到测试执行的技术需求;保证得到正确的、可重复的以及易理解的测试结果。

　　测试工具：并发性能测试是在客户端执行的黑盒测试，一般不采用手工方式，而是利用工具采用自动化方式进行。目前，成熟的并发性能测试工具有很多，选择的依据主要是测试需求和性能价格比。着名的并发性能测试工具有QALoad、LoadRunner、Benchmark Factory和Webstress等。这些测试工具都是自动化负载测试工具，通过可重复的、真实的测试，能够彻底地度量应用的可扩展性和性能，可以在整个开发生命周期、跨越多种平台、自动执行测试任务，可以模拟成百上千的用户并发执行关键业务而完成对应用程序的测试。

　　测试数据：在初始的测试环境中需要输入一些适当的测试数据，目的是识别数据状态并且验证用于测试的测试案例，在正式的测试开始以前对测试案例进行调试，将正式测试开始时的错误降到最低。在测试进行到关键过程环节时，非常有必要进行数据状态的备份。制造初始数据意味着将合适的数据存储下来，需要的时候恢复它，初始数据提供了一个基线用来评估测试执行的结果。

　　在测试正式执行时，还需要准备业务测试数据，比如测试并发查询业务，那么要求对应的数据库和表中有相当的数据量以及数据的种类应能覆盖全部业务。

　　模拟真实环境测试，有些软件，特别是面向大众的商品化软件，在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的数据才有实际意义。

　　并发性能测试的种类与指标

　　并发性能测试的种类取决于并发性能测试工具监控的对象，以QALoad自动化负载测试工具为例。软件针对各种测试目标提供了DB2、DCOM、ODBC、ORACLE、NETLoad、Corba、QARun、SAP、SQLServer、Sybase、Telnet、TUXEDO、UNIFACE、WinSock、WWW、Java Script等不同的监控对象，支持Windows和UNIX测试环境。

　　转自:领测软件测试网[http://www.ltesting.net]

　　原文链接:http://www.ltesting.net/ceshi/ceshijishu/xncs/2011/0923/203263.html

　　主要从以下几部分来说明，关于内存和内存泄露、溢出的概念，区分内存泄露和内存溢出;内存的区域划分，了解GC回收机制;重点关注如何去监控和发现内存问题;此外分析出问题还要如何解决内存问题。

　　下面就开始本篇的内容：

　　第一部分 概念

　　众所周知，java中的内存java虚拟机自己去管理的，他不想C++需要自己去释放。笼统地去讲，java的内存分配分为两个部分，一个是数据堆，一个是栈。程序在运行的时候一般分配数据堆，把局部的临时的变量都放进去，生命周期和进程有关系。但是如果程序员声明了static的变量，就直接在栈中运行的，进程销毁了，不一定会销毁static变量。

　　另外为了保证java内存不会溢出，java中有垃圾回收机制。 System.gc()即垃圾收集机制是指jvm用于释放那些不再使用的对象所占用的内存。java语言并不要求jvm有gc，也没有规定gc如何工作。垃圾收集的目的在于清除不再使用的对象。gc通过确定对象是否被活动对象引用来确定是否收集该对象。

　　而其中，内存溢出就是你要求分配的java虚拟机内存超出了系统能给你的，系统不能满足需求，于是产生溢出。

　　内存泄漏是指你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问,该块已分配出来的内存也无法再使用，随着服务器内存的不断消耗，而无法使用的内存越来越多，系统也不能再次将它分配给需要的程序，产生泄露。一直下去，程序也逐渐无内存使用，就会溢出。

　　第二部分 原理

　　JAVA垃圾回收及对内存区划分

　　在Java虚拟机规范中，提及了如下几种类型的内存空间：

　　◇ 栈内存(Stack)：每个线程私有的。

　　◇ 堆内存(Heap)：所有线程公用的。

　　◇ 方法区(Method Area)：有点像以前常说的“进程代码段”，这里面存放了每个加载类的反射信息、类函数的代码、编译时常量等信息。

　　◇ 原生方法栈(Native Method Stack)：主要用于JNI中的原生代码，平时很少涉及。

　　而Java的使用的是堆内存，java堆是一个运行时数据区，类的实例(对象)从中分配空间。Java虚拟机(JVM)的堆中储存着正在运行的应用程序所建立的所有对象，“垃圾回收”也是主要是和堆内存(Heap)有关。

　　垃圾回收的概念就是JAVA虚拟机(JVM)回收那些不再被引用的对象内存的过程。一般我们认为正在被引用的对象状态为“alive”,而没有被应用或者取不到引用属性的对象状态为“dead”。垃圾回收是一个释放处于”dead”状态的对象的内存的过程。而垃圾回收的规则和算法被动态的作用于应用运行当中，自动回收。

　　JVM的垃圾回收器采用的是一种分代(generational )回收策略，用较高的频率对年轻的对象(young generation)进行扫描和回收，这种叫做minor collection，而对老对象(old generation)的检查回收频率要低很多，称为major collection。这样就不需要每次GC都将内存中所有对象都检查一遍，这种策略有利于实时观察和回收。

　　(Sun JVM 1.3 有两种最基本的内存收集方式：一种称为copying或scavenge，将所有仍然生存的对象搬到另外一块内存后，整块内存就可回收。这种方法有效率，但需要有一定的空闲内存，拷贝也有开销。这种方法用于minor collection。另外一种称为mark-compact，将活着的对象标记出来，然后搬迁到一起连成大块的内存，其他内存就可以回收了。这种方法不需要占用额外的空间，但速度相对慢一些。这种方法用于major collection. )

　　一些对象被创建出来只是拥有短暂的生命周期，比如 iterators 和本地变量。

　　另外一些对象被创建是拥有很长的生命周期，比如 高持久化对象等。

　　垃圾回收器的分代策略是把内存区划分为几个代，然后为每个代分配一到多个内存区块。当其中一个代用完了分配给他的内存后，JVM会在分配的内存区内执行一个局部的GC(也可以叫minor collection)操作，为了回收处于“dead”状态的对象所占用的内存。局部GC通常要不Full GC要快很多。

　　JVM定义了两个代，年轻代(yong generation)(有时称为“nursery”托儿所)和老年代(old generation)。年轻代包括 “Eden space(伊甸园)”和两个“survivor spaces”。虚拟内存初始化的时候会把所有对象都分配到 Eden space，并且大部分对象也会在该区域被释放。 当进行 minor GC的时候，VM会把剩下的没有释放的对象从Eden space移动到其中一个survivor spaces当中。此外，VM也会把那些长期存活在survivor spaces 里的对象移动到 老生代的“tenured” space中。当 tenured generation 被填满后，就会产生Full GC，Full GC会相对比较慢因为回收的内容包括了所有的 live状态的对象。pemanet generation这个代包括了所有java虚拟机自身使用的相对比较稳定的数据对象，比如类和对象方法等。

　　关于代的划分，可以从下图中获得一个概况：

　　如果垃圾回收器影响了系统的性能，或者成为系统的瓶颈，你可以通过自定义各个代的大小来优化它的性能。使用JConsole，可以方便的查看到当前应用所配置的垃圾回收器的各个参数。想要获得更详细的参数，可以参考以下调优介绍：

　　Tuning Garbage collection with the 5.0 HotSpot VM

　　http://java.sun.com/docs/hotspot/gc/index.html

　　最后，总结一下各区内存：

　　Eden Space (heap)： 内存最初从这个线程池分配给大部分对象。

　　Survivor Space (heap)：用于保存在eden space内存池中经过垃圾回收后没有被回收的对象。

　　Tenured Generation (heap)：用于保持已经在 survivor space内存池中存在了一段时间的对象。

　　Permanent Generation (non-heap): 保存虚拟机自己的静态(refective)数据，例如类(class)和方法(method)对象。Java虚拟机共享这些类数据。这个区域被分割为只读的和只写的，

　　转自:领测软件测试网[http://www.ltesting.net]

　　原文链接:http://www.ltesting.net/ceshi/ceshijishu/xncs/2011/0923/203260.html

　　故障模型是软件测试的基础，也是一个判断测试方法是否成熟的重要标志。在测试的过程中，要确保每一个目标状态都被测试，那么测试必须是系统的;为了最终定位软件缺陷，所以测试必须是集中的;测试需要使用大量的测试用例和重复性测试，因此测试必须是自动的。若要满足上述三个测试条件，我们必须建立故障模型。

　　故障模型是将测试人员的经验和直觉尽量归纳和固化，使得可以重复使用。测试人员通过理解软件在做什么，来猜测可能出错的地方，并应用故障模型有目的地使它暴露缺陷。它具有一定的形式和足够的信息对错误进行预测，因此对测试人员来说，构造一个准确的故障模型，是选择测试策略、设计测试用例和测试执行的基础。在建立故障模型时，希望故障模型在框架上是通用的，但是建立具体的故障模型时一定要针对具体的软件类型、应用环境、甚至开发工具才有意义。一个成熟的故障模型必须具备下列条件：

　　1)该模型是符合实际的：大多数系统中存在的故障都可以用该模型来表示;

　　2)模型下的故障个数是可容忍的：模型下的故障个数一般和系统的规模是成线性关系;

　　3)模型下的故障是可以测试的：存在一个算法，利用该算法可以检测模型中的每一个故障。

　　本文将从软件的功能和技术特点出发，如软件的输入、输出、数据以及处理等，分析在软件功能测试过程中，我们通常应建立的故障模型及按照故障模型所提供的缺陷类型寻找尽量多的缺陷。

　　2. 输入型故障模型

　　主要是对用户的各种输入进行建模，因为用户的输入是无法预期的，可能的组合状态也是千变万化。软件功能除了能让正确的输入得到正确的输出之外，还必须对非法和不合逻辑的输入进行处理，防止因数据异常造成不可挽回的错误。典型的建模方法有：

　　1)使用非法数据：从输入数据的类型、长度、边界值等方面考虑，测试软件是否允许不正确的输入进入系统并进行处理，是否有错误处理代码，代码是否正确。

　　2)使用默认值输入：检测软件中所使用的变量是否初始化，是否将非法数据默认为合法边界内的某个合理值。

　　3)使用特殊字：检测软件是否正确处理了特殊字符和数据类型。

　　4)使用使缓冲区溢出的合法输入：输入超过允许的最大长度的数据，检测软件是否检查字符串/缓冲区的边界。

　　5)使用可能产生错误的合法输入组合：测试多个输入值的组合，确认这些值的组合是否会互相影响而引起软件失效。

　　6)重复输入相同的合法输入序列：检测软件是否考虑了循环处理的边界。

　　3. 输出型故障模型

　　软件的输出通常是最直观也是用户最关注的，输出型故障模型就是从软件输出角度出发，分析造成故障的可能原因。例如通过一个正确的输入在不同情况下产生不同输出的情况可以对输入和输出的关系进行进一步验证;可采用列举等方法，强制软件产生不符合业务背景知识的无效的输出，从而进行处理，规避不必要的错误;强制修改输出的属性、查看输出结果，测试初始化代码和修改代码是否同步;检查用户界面刷新情况，在不同的操作下测试界面刷新时间是否正确、界面刷新区域计算是否正确。

　　在大多数的软件中，功能输出的正确与否直接决定了软件实现的好坏，输出型故障模型所覆盖的故障也占有相当大的比例。因此，我们在测试过程中应建立这种故障模型，从故障结果进行分析，判断造成故障的影响因素。

　　4. 计算型故障模型

　　对于部分软件程序，常需要进行大量的计算，因此该模型应该尽可能包括关于计算方面的各种错误。包括变量的定义与使用方面的错误;数据的冗余;数组变量的越界错误;数据类型不匹配的错误;还有数据操作方面错误，包括函数调用参数传递错误、赋值语句错误等。在建立计算型故障模型的时候，要定义数据并且对这些数据执行各种故障操作，尽可能使模型比较完善。体现在功能层面上，可以使用非法的操作数和操作符组合来验证计算要求的合法性、强制使计算结果溢出考虑数据结构存储的正确性、同时对数据进行操作检测数据共享性等方法来建立故障模型。

　　5. 流程型故障模型

　　这是一种程序控制流的故障模型，是对在程序中同样占很大比例的循环结构和分支结构建立的模型。循环故障主要包括永不循环故障和死循环故障，这主要是由循环条件错误引起的。循环条件的错误中包括变量错误和运算符错误，在未执行循环之前，循环变量的初值设置出错以致永不循环;进入循环以后，循环变量的值不作修改以致发生死循环。而分支故障则包括判定条件故障和谓词结构故障，由于判定条件的出错或者变量初值设置错误而导致不执行分支结构;对于进入了分支结构的执行，可能因为谓词的错误而提前退出分支结构。

　　由此可知，流程型故障模型很可能是由一串连续的故障所组成的。因此在软件功能测试中，我们可以通过判断软件流程是否正确执行、功能分支是否覆盖全面、循环操作是否正常结束等方法来检测软件流程的正确性。

　　6. 资源型故障模型

　　资源型故障模型是在文件系统超载、系统介质忙或不可用、介质损坏等情况下，运行被测程序进行测试。此类故障模型的建立通常需要辅助测试工具进行环境的模拟。当磁盘负荷到达一定程度或可用物理资源十分有限时，系统进程十分容易进入“死锁”状态或出现不可恢复的错误。产生死锁的根本原因在于系统提供的资源个数少于并发进程所要求的该类资源数。显然，由于资源有限，不可能为所有要求资源的进程无限制地提供资源。但是，可以采用适当的方法，以达到消除或规避“死锁”的目的。因此判断软件在何种操作下会导致“死锁”以及软件对介质损坏的纠错能力也就变得极其重要。所以我们应该建立这种故障模型，并给出相应的测试用例。

　　7. 结论

　　故障模型的建立对于故障定位、故障分析以及生成相应的测试用例是非常有用的。本文在前人研究的基础上，仅仅从软件功能层面出发，提出了五种常用的故障模型。而在实际的软件测试工程中，由于软件故障原因的多样性，还有很多故障模型有待于进一步细化和探讨。

　　故障模型是软件测试的基础，也是一个判断测试方法是否成熟的重要标志。在测试的过程中，要确保每一个目标状态都被测试，那么测试必须是系统的;为了最终定位软件缺陷，所以测试必须是集中的;测试需要使用大量的测试用例和重复性测试，因此测试必须是自动的。若要满足上述三个测试条件，我们必须建立故障模型。

　　故障模型是将测试人员的经验和直觉尽量归纳和固化，使得可以重复使用。测试人员通过理解软件在做什么，来猜测可能出错的地方，并应用故障模型有目的地使它暴露缺陷。它具有一定的形式和足够的信息对错误进行预测，因此对测试人员来说，构造一个准确的故障模型，是选择测试策略、设计测试用例和测试执行的基础。在建立故障模型时，希望故障模型在框架上是通用的，但是建立具体的故障模型时一定要针对具体的软件类型、应用环境、甚至开发工具才有意义。一个成熟的故障模型必须具备下列条件：

　　1)该模型是符合实际的：大多数系统中存在的故障都可以用该模型来表示;

　　2)模型下的故障个数是可容忍的：模型下的故障个数一般和系统的规模是成线性关系;

　　3)模型下的故障是可以测试的：存在一个算法，利用该算法可以检测模型中的每一个故障。

　　本文将从软件的功能和技术特点出发，如软件的输入、输出、数据以及处理等，分析在软件功能测试过程中，我们通常应建立的故障模型及按照故障模型所提供的缺陷类型寻找尽量多的缺陷。

　　2. 输入型故障模型

　　主要是对用户的各种输入进行建模，因为用户的输入是无法预期的，可能的组合状态也是千变万化。软件功能除了能让正确的输入得到正确的输出之外，还必须对非法和不合逻辑的输入进行处理，防止因数据异常造成不可挽回的错误。典型的建模方法有：

　　1)使用非法数据：从输入数据的类型、长度、边界值等方面考虑，测试软件是否允许不正确的输入进入系统并进行处理，是否有错误处理代码，代码是否正确。

　　2)使用默认值输入：检测软件中所使用的变量是否初始化，是否将非法数据默认为合法边界内的某个合理值。

　　3)使用特殊字：检测软件是否正确处理了特殊字符和数据类型。

　　4)使用使缓冲区溢出的合法输入：输入超过允许的最大长度的数据，检测软件是否检查字符串/缓冲区的边界。

　　5)使用可能产生错误的合法输入组合：测试多个输入值的组合，确认这些值的组合是否会互相影响而引起软件失效。

　　6)重复输入相同的合法输入序列：检测软件是否考虑了循环处理的边界。

　　3. 输出型故障模型

　　软件的输出通常是最直观也是用户最关注的，输出型故障模型就是从软件输出角度出发，分析造成故障的可能原因。例如通过一个正确的输入在不同情况下产生不同输出的情况可以对输入和输出的关系进行进一步验证;可采用列举等方法，强制软件产生不符合业务背景知识的无效的输出，从而进行处理，规避不必要的错误;强制修改输出的属性、查看输出结果，测试初始化代码和修改代码是否同步;检查用户界面刷新情况，在不同的操作下测试界面刷新时间是否正确、界面刷新区域计算是否正确。

　　在大多数的软件中，功能输出的正确与否直接决定了软件实现的好坏，输出型故障模型所覆盖的故障也占有相当大的比例。因此，我们在测试过程中应建立这种故障模型，从故障结果进行分析，判断造成故障的影响因素。

　　4. 计算型故障模型

　　对于部分软件程序，常需要进行大量的计算，因此该模型应该尽可能包括关于计算方面的各种错误。包括变量的定义与使用方面的错误;数据的冗余;数组变量的越界错误;数据类型不匹配的错误;还有数据操作方面错误，包括函数调用参数传递错误、赋值语句错误等。在建立计算型故障模型的时候，要定义数据并且对这些数据执行各种故障操作，尽可能使模型比较完善。体现在功能层面上，可以使用非法的操作数和操作符组合来验证计算要求的合法性、强制使计算结果溢出考虑数据结构存储的正确性、同时对数据进行操作检测数据共享性等方法来建立故障模型。

　　5. 流程型故障模型

　　这是一种程序控制流的故障模型，是对在程序中同样占很大比例的循环结构和分支结构建立的模型。循环故障主要包括永不循环故障和死循环故障，这主要是由循环条件错误引起的。循环条件的错误中包括变量错误和运算符错误，在未执行循环之前，循环变量的初值设置出错以致永不循环;进入循环以后，循环变量的值不作修改以致发生死循环。而分支故障则包括判定条件故障和谓词结构故障，由于判定条件的出错或者变量初值设置错误而导致不执行分支结构;对于进入了分支结构的执行，可能因为谓词的错误而提前退出分支结构。

　　由此可知，流程型故障模型很可能是由一串连续的故障所组成的。因此在软件功能测试中，我们可以通过判断软件流程是否正确执行、功能分支是否覆盖全面、循环操作是否正常结束等方法来检测软件流程的正确性。

　　6. 资源型故障模型

　　资源型故障模型是在文件系统超载、系统介质忙或不可用、介质损坏等情况下，运行被测程序进行测试。此类故障模型的建立通常需要辅助测试工具进行环境的模拟。当磁盘负荷到达一定程度或可用物理资源十分有限时，系统进程十分容易进入“死锁”状态或出现不可恢复的错误。产生死锁的根本原因在于系统提供的资源个数少于并发进程所要求的该类资源数。显然，由于资源有限，不可能为所有要求资源的进程无限制地提供资源。但是，可以采用适当的方法，以达到消除或规避“死锁”的目的。因此判断软件在何种操作下会导致“死锁”以及软件对介质损坏的纠错能力也就变得极其重要。所以我们应该建立这种故障模型，并给出相应的测试用例。

　　7. 结论

　　故障模型的建立对于故障定位、故障分析以及生成相应的测试用例是非常有用的。本文在前人研究的基础上，仅仅从软件功能层面出发，提出了五种常用的故障模型。而在实际的软件测试工程中，由于软件故障原因的多样性，还有很多故障模型有待于进一步细化和探讨。

　　转自:领测软件测试网[http://www.ltesting.net]

　　原文链接:http://www.ltesting.net/ceshi/ceshijishu/gncs/2011/0819/203096.html

　　Spoon Browser Sandbox

　　点击你需要测试的浏览器环境，安装插件就可以进行测试了。帮助你测试网页在Safari、Chrome、Firefox和Opera浏览器中是否正常，IE以前也有的，网站上说应微软的要求去掉了。

　　Superpreview

　　这是为微软自己发布的跨浏览器测试工具，您可以同时查看您的网页在多个浏览器的呈现情况，对页面排版进行直观的比较。

　　IETester

　　专门用于测试网页在IE浏览器各个版本中兼容性的工具，版本包含IE5.5至IE9的各个版本，很不错的一款工具，推荐。

　　BrowserShots

　　BrowserShots 是一款免费的跨浏览器测试工具，捕捉网站在不同浏览器中的截图。这是最有名，也是最古老的浏览器兼容性测试工具。

　　Multiple IEs

　　这款工具同样用于测试网页在IE浏览器各个版本的兼容性。

　　IE netrenderer

　　Netrenderer 也是用于检查你的网站在IE浏览器中的呈现情况，包括各个常用版本的检测。

　　Viewlike.Us!

　　Viewlike 是一款新推出的工具，帮助你检查浏览器在不同分辨率下得呈现情况。

　　BrowserSeal

　　这款工具的两个主要特色是独立的浏览器支持和带有自动化脚本的命令行界面。

　　Browsera

　　Browsera 是一个可测试您的网站的跨浏览器布局的工具，您会看到您网站上存在的兼容性错误。

　　WebDevLab

　　这款工具专门用于测试你的网站在苹果Safari浏览器中是什么样子的。

　　Litmus

　　这个工具可以帮助你检查你的网站在多个浏览器中的呈现情况，跟踪Bug并创建报告。

　　Browsercam

　　最后这款工具是要付费的，可以帮助你检查 Javascript 和 DHTML，提供不同的测试环境平台。

　　转自:领测软件测试网[http://www.ltesting.net]

　　原文链接:http://www.ltesting.net/ceshi/ceshijishu/gncs/jrxcs/2011/0825/203126.html