软件测试工具

软件测试工具 软件测试工具LoadRunner的安装、脚 本录制及加压(1) 发布: 2011-3-08 10:48 | 作者: admin | 来源: www.test8848.net | 查看: 631次 字号: 小中大 | 推荐给好友 软件测试工具LoadRunner的安装、脚本录制及加压(1) 指正。 1.Loadrunner的简介 LoadRunner通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，是 一种预测系统行为和性能的工业级负载测试工具。 LoadRunner能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。目前企业的网络应用环境都必须支持大量用户，网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢，系统崩溃等问题。这些都不可避免 地导致公司收益的损失。 Mercury Interactive的LoadRunner能让企业保护自己的收入来源，无需购置额外硬件而最大限度地利用现有的IT资源，并确保终端用户在应用系统的各个环节中对其测试应用的质量，可靠性 和可扩展性都有良好的评价。 1.1轻松创建虚拟用户 LoadRunner中的Virtual User Generator，提供了这样一种功能，您可以很简便地创立起系统负载。 该引擎能够生成虚拟用户，以虚拟用户的方式模拟真实用户的业务操作行为。它先记录下业务流程(如下订单或机票预定)，然后将其转化为测试脚本。利用虚拟用户，您可以在Windows，UNIX或Linux机器上同时产生成千上万个用户访问。所以LoadRunner能极大的减少负载测试所需的 硬件和人力资源。 另外，LoadRunner的TurboLoad专利技术能提供很高的适应性。TurboLoad使您可以产生每天几十万名在线用户和数以百万计的点击数的负载。用Virtual User Generator建立测试脚本后，您可以对其进行参数化操作，这一操作能让您利用几套不同的实际发生数据来测试您的应用程序，从而反映出本系统的负载能力。以一个订单输入过程为例，参数化操作可将记录中的固定数据，如订单号和客户名称，由可变值来代替。在这些变量内随意输入可能的订单号和客户名，来匹配多个实际用户的操作行为。LoadRunner通过它的Data Wizard来自动实现其测试数据的参数化。Data Wizard直接连于数据库服务器，从中您可以获取所需的数据(如定单号和用户名)并直接将其输入到测试脚本。这样避免了人工处理数据的需要，Data Wizard为您节省了大量的时间。为了进一步确定您的Virtual user能够模拟真实用户，您可利用LoadRunner控制某些行为特性。例如，只需要点击一下鼠标，您就能轻易控制交易的数量，交易频率，用户的思考时间和连接速度等。 1.2创建真实的负载 Virtual users建立起后，您需要设定您的负载，业务流程组合和虚拟用户数量。用 LoadRunner的Controller，您能很快组织起多用户的测试方案。Controller的Rendezvous功能提供一个互动的环境，在其中您既能建立起持续且循环的负载，又能管理和驱动负载测试方案。而且，您可以利用它的日程计划服务来定义用户在什么时候访问系统以产生负载。这样，您就能将测试过程自 动化。同样您还可以用Controller来限定您的负载方案，在这个方案中所有的用户同时执行一个动作---如登陆到一个库存应用程序----来模拟峰值负载的情况。另外，您还能监测系统架构中各个组件的性能----包括服务器，数据库，网络设备等----来帮助客户决定系统的配置。LoadRunner通过它的AutoLoad技术，为您提供更多的测试灵活性。使用AutoLoad，您可以根据目前的用户人数事先设定测试目标，优化测试流程。例如，您的目标可以是确定您的应用系统承受的每秒点 击数或每秒的交易量。 1.3实时监测器 LoadRunner内含集成的实时监测器，在负载测试过程的任何时候，您都可以观察到应用系统的运行性能。这些性能监测器为您实时显示交易性能数据(如响应时间)和其它系统组件包括application server, web server，网路设备和数据库等的实时性能。这样，您就可以在测试过程中 从客户和服务器的双方面评估这些系统组件的运行性能，从而更快地发现问题。 再者，利用LoadRunner的ContentCheck TM，您可以判断负载下的应用程序功能正常与否。ContentCheck在Virtual users运行时，检测应用程序的网络数据包内容，从中确定是否有错误内 容传送出去。它的实时浏览器帮助您从终端用户角度观察程序性能状况。 1.4分析结果以精确定位问题所在 一旦测试完毕后，LoadRunner收集汇总所有的测试数据，并为您提供高级的分析和报告工具，以便迅速查找到性能问题并追溯原由。使用LoadRunner的Web交易细节监测器，您可以了解到将所有的图象、框架和文本下载到每一网页上所需的时间。例如，这个交易细节分析机制能够分析是否因为一个大尺寸的图形文件或是第三方的数据组件造成应用系统运行速度减慢。另外，Web交易细节监测器分解用于客户端、网络和服务器上端到端的反LoadRunner支持广泛的协议， 可以测试各种IT基础架构。 软件测试中测试自动化与软件测试工具 的使用 发布: 2011-3-08 10:50 | 作者: admin | 来源: www.test8848.net | 查看: 177次 字号: 小中大 | 推荐给好友 软件测试中测试自动化与软件测试工具的使用 首先，我们来看一下目前办铢萌芽测试工具使用的现状。目前，软件测试方面的工具很多，主要有MercuryInteractive(MI)、Segue、Rational、Compuware和Empirix等公司的产品，而 MI公司的产品占了主流。以下就各种常用测试工具进行简要对比: 主要厂商及其软件测试工具如下表: Mercury Interactive Winrunner、loadrunner、TestDirector、Astra QuickTest Rational Rational Purify(测试时用，检查运行时内存错误) Rational Quantify(性能检测工具，查出系统瓶颈以便改进运行速度) Rational TestManager(测试管理) Robot(软件测试用，通过Script自动模拟输入输出) LoadTest TestFactory(软件测试用) Compuware QACenter、Perfromance Edition、EcoScope、TrackRecord Segue SilkTest Empirix eTest Suite 以下从常见软件测试工具功能、使用范围、目前市场情况、应用前景等方面做简要比较: 工具名称功能范围 WinRunner-----功能: 1.插入检查点; 2.检验数据; 3.增强测试; 4.分析结果; 5.维护测试; 6.为无线应用作准备。 范围:功能测试、生成测试用例、分析测试结果、维护测试用例、回归测试。 LoadRunner-----功能: 1.松创建虚拟用户; 2.创建真实的负载; 3.定位性能问题; 4.分析结果以精确定位问题所在; 5.重复测试保证系统发布的高性能; 6.Enterprise Java Beans的测试; 7.支持无线应用协议; 8.支持Media Stream应用; 9.完整的企业应用环境的支持。 范围:性能测试、压力测试、模拟多用户、定位性能瓶颈。 软件测试自动化的程度再高都不可能取代手工测试，即软件测试工具不可能取代软件测试人员;一般来讲，测试自动化在整个软件测试过程中只能占到30%左右;实现、运用自动化的程度还取决于各方面的资源，特别是软件的行业规范性和软件开发的稳定性;对于部分白盒测试可以 使用软件测试工具，如对代码性能分析等. 那么如何实现软件测试自动化的计划呢,首先将测试的基本管理形成自动化，如BUG管理等，然后利用软件测试自动化工具来实现一些手工无法进行的测试活动，如:压力，并发，强度测试，接着利用测试自动化工具来完成回归测试中的缺陷跟踪测试，再往后就可以利用测试自动化工具来记录两个版本的异同，以找出缺陷。最后将整个回归测试都用自动化脚本保存，以完成 每次的回归测试。而对于白盒测试则可以引入测试工具进行代码分析; 软件测试中写QTP(软件测试工具)中 代码的一些技巧 发布: 2011-3-10 10:29 | 作者: admin | 来源: 本站原创 | 查看: 332次 字号: 小中大 | 推荐给好友 软件测试中写QTP(软件测试工具)中代码的一些技巧 这几年，我所从事的一些大型项目中，越来越多的管理者采用QTP。在这个过程中，明显发现验证效率的提高。在实际工作中也整理出一些语法和技巧，现在写出来，供大家备用。 QTP不同数据库检查点手动SQL写法 QTP插入数据库检查点，手动指定SQL语句的写法。 一、SQL Server格式(本地无需安装SQL Server) connectionstring(连接字符串): 1.本地没有创建数据源的方式 DRIVER=SQL Server;SERVER=数据库IP地址;UID=用户名; PWD=密码;APP=Microsoft Office 2003;WSID=本地主机名;DATABASE=数据库名 实例: DRIVER=SQL Server;SERVER=10.160.11.10;UID=sa; PWD=sa;APP=Microsoft Office 2003;WSID=RJHLJUN;DATABASE=dcwork 2.本地已创建数据源的方式 DSN=数据源名称;UID=用户名; PWD=密码;APP=Microsoft Office 2003;WSID=数据库的主机 名;DATABASE=数据库名 实例: DSN=LocalServer;UID=sa; PWD=sa;APP=Microsoft Office 2003;WSID=RJDCWORKTEST;DATABASE=dcwork 3.SQL语句实例(从数据库表HR_LANGUAGE_TYPE中，查询字段语言名称LANGUAGE_NAME， 条件语言名称,中文，按语言名称升序排序结果) source(SQL语句): SELECT HR_LANGUAGE_TYPE.LANGUAGE_NAME FROM dcwork.dbo.HR_LANGUAGE_TYPE HR_LANGUAGE_TYPE WHERE (HR_LANGUAGE_TYPE.LANGUAGE_NAME=„中文?) ORDER BY HR_LANGUAGE_TYPE.LANGUAGE_NAME 二、DB2格式:(本地至少安装DB2 Run-Time Client Lite) connectionstring(连接字符串): 1.本地没有创建数据源的方式 DRIVER={IBM DB2 ODBC DRIVER};UID=用户名; PWD=密码;MODE=SHARE;DBALIAS=数据库名; 实例: DRIVER={IBM DB2 ODBC DRIVER};UID=db2admin; PWD=db2admin;MODE=SHARE;DBALIAS=DCWORK; 2.本地已创建数据源的方式 DSN=数据源名称;UID=用户名; PWD=密码;MODE=SHARE;DBALIAS=DCWORK; 实例: DSN=DWCORKDB2;UID=db2admin; PWD=db2admin;MODE=SHARE;DBALIAS=DCWORK; 3.SQL语句实例 source:SQL语句 SELECT HR_LANGUAGE_TYPE.LANGUAGE_NAME FROM DB2ADMIN.HR_LANGUAGE_TYPE HR_LANGUAGE_TYPE WHERE (HR_LANGUAGE_TYPE.LANGUAGE_NAME=„中文?) ORDER BY HR_LANGUAGE_TYPE.LANGUAGE_NAME 三、Oracle格式:(本地需要安装Oracle ODBC DRIVER) connectionstring(连接字符串): 1.本地没有创建数据源的方式 DRIVER={Oracle in OraHome92};SERVER=数据库服务名;UID=用户名; PWD=密码;DBQ= 数据库 名;DBA=W;APA=T;EXC=F;XSM=Default;FEN=T;QTO=T;FRC=10;FDL=10;LOB=T;RST=T;G DE=F;FRL=Lo;BA M=IfAllSuccessful;MTS=F;MDI=Me;CSR=F;FWC=F; PFC=10;TLO=O; 实例: DRIVER={Oracle in OraHome92};SERVER=DCWORK;UID=DCWORK; PWD=DCWORK;DBQ=DCWORK;DBA=W;APA=T;EXC=F;XSM=Default;FEN=T;QTO=T;FRC=10;FDL=10;LOB=T;RST=T;GDE=F;FRL=Lo;BAM=IfAllSuccessful;MTS=F;MDI=Me;CS R=F;FWC=F; PFC=10;TLO=O; 2.本地已创建数据源的方式 DSN=数据源名称;UID=用户名; PWD=密码;DBQ=数据库 名;DBA=W;APA=T;EXC=F;FEN=T;QTO=T;FRC=10;FDL=10;LOB=T;RST=T;GDE=F;FRL=F;BAM=IfAllSuccess ful;MTS=F;MDI=F;CSR=F;FWC=F; PFC=10;TLO=0; 实例: DSN=dcworkoracle;UID=DCWORK;DBQ=DCWORK;DBA=W;APA=T;EXC=F;FEN=T;QTO=T;FRC=10;FDL=10;LOB=T;RST=T;GDE=F;FRL=F;BAM=IfAllSuccessful;MTS=F;MDI=F;CS R=F;FWC=F; PFC=10;TLO=0; 3.SQL语句实例 source:SQL语句 SELECT HR_LANGUAGE_TYPE.LANGUAGE_NAME FROM DCWORK.HR_LANGUAGE_TYPE HR_LANGUAGE_TYPE WHERE (HR_LANGUAGE_TYPE.LANGUAGE_NAME=„中文?) ORDER BY HR_LANGUAGE_TYPE.LANGUAGE_NAME 目前最流行的十大软件测试工具 发布: 2011-3-10 10:31 | 作者: admin | 来源: 本站原创 | 查看: 1062次 字号: 小中大 | 推荐给好友 目前最流行的十大软件测试工具 目前由于软件测试工作在软件的生产过程中越来越重要，很多软件测试工具应运而生，这 里介绍一下目前最流行的一些软件测试工具，一个十个，介绍如下: 一、企业级自动化测试工具WinRunner 这款软件是Mercury Interactive公司的。 WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂 的企业级应用无故障发布及长期稳定运行。 二、工业标准级负载测试工具Loadrunner 这款软件是惠普公司开发的。 LoadRunner是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。 三、功能测试工具Rational Robot IBM Rational Robot是业界最顶尖的功能测试工具，它甚至可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。它集成在测试人员的桌面IBM Rational TestManager上，在这里测试人员可以计划、组织、执行、管理和报告所有测试活动，包括手动测试报告。这种测试和管 理的双重功能是自动化测试的理想开始。 四、功能测试工具SilkTest Borland SilkTest 2006属于软件功能测试工具，是Borland公司所提出软件质量管理解决方案的套件之一。这个工具采用精灵设定与自动化执行测试，无论是程序新手或资深的专家都能 快速建立功能测试，并分析功能错误。 五、功能和性能测试的工具JMeter JMeter是Apache组织的开放源代码项目，它是功能和性能测试的工具，100%的用java实 现。 六、单元测试工具xUnit系列 目前的最流行的单元测试工具是xUnit系列框架，常用的根据语言不同分为JUnit(java)，CppUnit(C++)，DUnit(Delphi)，NUnit(.net)，PhpUnit(Php)等等。该测试框架的第一个和最杰出的应用就是由Erich Gamma(《设计模式》的作者)和Kent Beck(XP(Extreme Programming) 的创始人)提供的开放源代码的JUnit. 七、全球测试管理系统testdirector TestDirector是业界第一个基于Web的测试管理系统，它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分，包括需求管理， 测试计划，测试执行以及错误跟踪等功能，TestDirector极大地加速了测试过程。 八、自动化白盒测试工具Jtest Jtest是parasoft公司推出的一款针对java语言的自动化白盒测试工具，它通过自动实现java的单元测试和代码标准校验，来提高代码的可靠性。parasoft同时出品的还有C++ test，是一款 C/C++白盒测试工具。 九、性能测试工具WAS Microsoft Web Application Stress Tool是由微软的网站测试人员所开发，专门用来进行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具，您可以使用少量的Client端计算机 仿真大量用户上线对网站服务所可能造成的影响。 十、性能测试和分析工具WEBLODE webload是RadView公司推出的一个性能测试和分析工具，它让web应用程序开发者自动执行压力测试;webload通过模拟真实用户的操作，生成压力负载来测试web的性能。 软件测试工具发展展望 发布: 2011-6-04 15:13 | 作者: 网络转载 | 来源: 网络转载 | 查看: 214次 字号: 小中大 | 推荐给好友 软件测试是软件工程中的一个重要过程，也是保证软件质量的重要手段。随着软件测试的地位在软件开发过程中逐步提高，重要性逐步显现，测试工具的应用也已经成为了普遍的趋势。目前用于测试的工具比较多，基本上覆盖了整个测试周期。其中国际主流的HP系列测试工具、IBM系列测试工具、Segue系列测试工具及Compuware系列测试工具占据了市场的90%以上。按照测试及测试目的，我们可以将测试工 具分为白盒测试工具、黑盒测试工具、测试管理工具等。 白盒测试工具一般是针对被测源程序进行的测试，测试所发现的故障可以定位到代码级。根据测试工 具工作原理不同，白盒测试的自动化工具可分为静态测试工具和动态测试工具。 目前普遍使用的该类测试工具主要有Parasoft公司的Jtest、Jcontract、C++ Test，Compuware公司的BoundsChecker、TrueTime、FailSafe等，这类工具可以对C/ C + +、Java等语言的软件源代码进行静 态分析，内置标准的编码规则检查，以及功能确认、接口测试、覆盖率分析、性能分析等。 黑盒测试工具适用于黑盒测试的场合，黑盒测试工具包括功能测试工具和系统测试工具。黑盒测试工具的一般原理是利用脚本的录制和回放，模拟用户的操作，然后将被测系统的输出记录下来同预先给定的标准结果比较。黑盒测试工具可以大大减轻黑盒测试的工作量，在迭代开发的过程中，能够很好地进行回 归测试。 目前常见的功能测试工具有HP公司的Winrunner、QuickTest Professional，IBM公司的 Rational Functional Tester，Segue公司的SilkTest，Compuware公司的QARun等，这类工具主要为用户提供了符合所有主要应用软件环境的功能测试和回归测试的自动化测试功能。常见的性能测试工具有HP公司的LoadRunner，IBM公司的Rational Performance Tester，Segue公司的SilkPerformer，Compuware公司的QALoad等，这类工具主要通过模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题， 帮助测试人员和性能工程师验证系统的性能。 测试管理工具主要用于对测试进行管理。一般而言，测试管理工具对测试计划、测试用例、测试实施 进行管理，并且，测试管理工具还包括对缺陷的跟踪管理。 常用的测试管理工具主要有HP公司的Quality Center、IBM公司的Rational Test Manager，Segue公 司的SilkCentral Test Manager等。 除了上述测试工具外，还有一些专用的测试工具，例如，针对数据库测试的TestBytes，对应用性能进 行优化的EcoScope等。 近年来，随着测试技术的逐步发展，加上测试工作者及测试厂商的努力，测试工具在软件行业中得到了较为广泛的应用。在2009年下半年由工业和信息化部组织的全国范围 云测试工具:云测试是基于云计算的一种新型测试方案，云计算通过网络以按需、易扩展的方式向用户交付所需的资源，包括基础设施、应用平台、软件功能等服务。作为软件测试工具(包括功能测试工具、性能测试工具等)服务商提供的测试平台，软件开发企业在其平台上进行相关自动化测试、不再在本地计算机上安装和使用这些工具。这种无须本地安装和配置测试环境，在远程测试平台上进行测试的方式被称作云测试。目前云测试平台还处于实验阶段，随着云计算技术的逐步发展，云测试技术也将不断发展完善。 安全性测试工具:安全性测试工具以自动化或半自动化的方式验证系统安全功能运行是否正确、安全机制是否有效和查找潜在的安全漏洞。随着计算机网络的迅速发展和软件的广泛应用，软件的安全性己经成为备受关注的一个方面，渐渐融入我们的生活，成为关系到金融、电力、交通、医疗、政府以及军事等各个领域的关键问题。软件安全漏洞造成的重大损失以及还在不断增长的漏洞数量使人们已经开始深刻认识到软件安全的重要性。随着安全性测试技术的深入研究，安全性测试工具也将是测试工具的重点发展方 向。 Web服务器性能/压力测试工具 发布: 2011-6-22 17:03 | 作者: 网络转载 | 来源: 本站原创 | 查看: 26次 字号: 小中大 | 推荐给好友 一、http_load 程序非常小，解压后也不到100K http_load以并行复用的方式运行，用以测试web服务器的吞吐量与负载。但是它不同于大多数压力测试 工 具，它可以以一个单一的进程运行，一般不会把客户机搞死。还可以测试HTTPS类的网站请求。 下载地址: 安装很简单 #tar zxvf http_load-12mar2006.tar.gz #cd http_load-12mar2006 #make && make install 命令格式:http_load -p 并发访问进程数 -s 访问时间需要访问的URL文件 参数其实可以自由组合，参数之间的选择并没有什么限制。比如你写成http_load -parallel 5 -seconds 300 urls.txt也是可以的。我们把参数给大家简单说明一下。 -parallel 简写-p :含义是并发的用户进程数。 -fetches 简写-f :含义是总计的访问次数 -rate 简写-p :含义是每秒的访问频率 -seconds简写-s :含义是总计的访问时间 准备URL文件:urllist.txt，文件格式是每行一个URL，URL最好超过50-100个测试效果 比较好.文件格式 如下: 例如: http_load -p 30 -s 60 urllist.txt 参数了解了，我们来看运行一条命令来看看它的返回结果 命令:% ./http_load -rate 5 -seconds 10 urls说明执行了一个持续时间10秒的测试，每秒的 频率为5。 49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds5916 mean bytes/connection4.89274 fetches/sec, 28945.5 bytes/secmsecs/connect: 28.8932 mean, 44.243 max, 24.488 minmsecs/first -response: 63.5362 mean, 81.624 max, 57.803 minHTTP response codes: code 200 -- 49 结果分析: 1.49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds 说明在上面的测试中运行了49个请求，最大的并发进程数是2，总计传输的数据是 289884bytes，运行的 时间是10.0148秒 2.5916 mean bytes/connection说明每一连接平均传输的数据量289884/49=5916 3.4.89274 fetches/sec, 28945.5 bytes/sec 说明每秒的响应请求为4.89274，每秒传递的数据为28945.5 bytes/sec 4.msecs/connect: 28.8932 mean, 44.243 max, 24.488 min说明每连接的平均响应时间是 28.8932 msecs ，最大的响应时间44.243 msecs，最小的响应时间24.488 msecs 5.msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min 6、HTTP response codes: code 200 -- 49 说明打开响应页面的类型，如果403的类型过多， 那可能 要注意是否系统遇到了瓶颈。 特殊说明: 测试结果中主要的指标是 fetches/sec、msecs/connect 这个选项，即服务器每秒能够响应的查询次数， 用这个指标来衡量性能。似乎比 apache的ab准确率要高一些，也更有说服力一些。 Qpt-每秒响应用户数和response time，每连接响应用户时间。 测试的结果主要也是看这两个值。当然仅有这两个指标并不能完成对性能的分析，我们还需要对服务器的 cpu、men进行分析，才能得出结论 二、webbench webbench是Linux下的一个网站压力测试工具，最多可以模拟3万个并发连接去测试网站的负载能力。 下载 地址可以到google搜，我这里给出一个 下载地址: 这个程序更小，解压后不到50K，呵呵 安装非常简单 #tar zxvf webbench-1.5.tar.gz #cd webbench-1.5 #make && make install 会在当前目录生成webbench可执行文件，直接可以使用了 用法: webbench -c 并发数 -t 运行测试时间 URL 如: webbench -c 5000 -t 120 这个表示同时处理1000个请求并运行100次index.php文件. 四、Siege 一款开源的压力测试工具，可以根据配置对一个WEB站点进行多用户的并发访问，记录每个用户所有请求 过程的相应时间，并在一定数量的并发访问下重复进行。 官方: Siege下载: 解压: # tar -zxf siege-2.67.tar.gz 进入解压目录: # cd siege-2.67/ 安装: #./configure ; make #make install 使用 siege -c 200 -r 10 -f example.url -c是并发量，-r是重复次数。 url文件就是一个文本，每行都是一个url，它会从里面随机访问的。 example.url内容: 结果说明 Lifting the server siege… done. Transactions: 3419263 hits //完成419263次处理 Availability: 100.00 % //100.00 % 成功率 Elapsed time: 5999.69 secs //总共用时 Data transferred: 84273.91 MB //共数据传输84273.91 MB Response time: 0.37 secs //相应用时1.65秒:显示网络连接的速度 Transaction rate: 569.91 trans/sec //均每秒完成 569.91 次处理:表示服务器后 Throughput: 14.05 MB/sec //平均每秒传送数据 Concurrency: 213.42 //实际最高并发数 Successful transactions: 2564081 //成功处理次数 Failed transactions: 11 //失败处理次数 Longest transaction: 29.04 //每次传输所花最长时间 Shortest transaction: 0.00 //每次传输所花最短时间 软件测试工作中解析StressMark压力 测试工具 发布: 2012-2-17 10:00 | 作者: 网络转载 | 来源: 测试时代采编 | 查看: 91次 字号: 小中大 | 推荐给好友 简介 StressMark测试软件是一个使用Visual C++编写的，开放源代码的测试工具，可以完成服务程序及重 要算法的功能和性能测试，其最主要的功能是模拟多线程或多客户端的自动化压力测试。 我们可以利用StressMark软件完成的典型测试任务包括: 1. 在多线程环境下测试一个软件模块、一段关键算法是否可以正确运行，即代码是否是多线程安全的。 2. 测试一个软件模块、一段关键算法在并发执行时的效率，如每个线程的平均执行时间等。 3. 模拟一个服务程序的多个客户端，测试该服务程序对并发请求的响应是否正确。 4. 模拟一个服务程序的多个客户端，测试该服务程序在并发请求的情况下，对每个客户请求的响应效 率。 5. 使用一台或多台高配置的测试计算机(多CPU，大内存)，每台计算机上运行一套StressMark，每套StressMark模拟多个客户线程，以此测试服务程序在大压力情况下的响应能力，这一方法甚至可以测出服 务程序支持的并发数上限。 因为StressMark软件的源代码是完全开放的，基于这套源代码，你完全可以改造出符合你的特定需求 的自动测试程序，使StressMark可以完成更多的测试任务。 基本概念 测试包:用户根据特定测试需求制订的，包含一个或多个不同测试用例及其配置方式的描述性大纲。 测试用例:指对一项特定的测试任务的描述，包括测试目标，输入数据，测试方法，实现代码等。在 StressMark 中，测试用例对应于一段具体的待测试代码，该测试代码由测试者提供，并被嵌入到 StressMark 工程中。测试时，可以对一个测试用例起多个测试客户(线程)同时运行，也就是说，一个测试用例同时可以有多个运行实例。还可以对特定的测试用例指定测试次数，即指定在该测试用例的每个实例中，重复执 行多少次测试代码。根据需要，用户也可以指定每两次重复之间的时间间隔。 测试客户:或称测试线程。指测试时某特定测试用例的一个具体的实例。该实例以线程方式运行，并与该测试用例的其他实例同时启动。用户可以在测试包中为每个测试用例配置测试客户(线程)的数目。 测试次数:某特定测试用例的每一个测试客户(线程)中，待测试代码的重复执行次数。用户可以在测 试包中为每个测试用例配置测试次数。 间隔时间:某特定测试用例的每一个测试客户(线程)中，待测试代码两次重复执行之间的间隔时间。 单位是毫秒。间隔时间可以在测试包中指定。 软件测试工具WinRunner的规则 发布: 2012-3-01 09:25 | 作者: 网络转载 | 来源: 测试时代采编 | 查看: 251次 字号: 小中大 | 推荐给好友 1.1 脚本录制规范: 基本原则是录制脚本要分开、gui文件要合并、批调用回放验证、可移植回放验证。 1.1.1 录制脚本要分开: 脚本太大，不仅不利于以后的维护，并且会导致WinRunner的不可预测的错误产生(具体可以参考WinRunner 的Readme文档)。录制时，可以根据测试用例的流程，拆分为几个小流程，对每个小流程分 别录制成不同的脚本。 1.1.2 gui文件要合并: 首先，要在系统参数中，设置gui的录制模式为“Global GUI Map File 录制过程中，WinRunner会自动产生gui文件，一个测试用例要确保生成一个公用gui文件。用一个gui文件主要是为了以后gui对象的维护，脚本回放时gui对象的查找。但是由于我们的测试用例是分开录制的，每个小流程录制时都会产生一个gui临时文件，因此录制完脚本后要把临时gui文件合并到该测试用例的公用gui文件中。但是也要注意，开始新的录制前，一定要先手工加载测试用例的公用gui文件。 如果划分的子流程超过20个，则按每20个子流程录制一个gui文件的方式。Gui文件太大，会影响 WinRunner的回放效率。 1.1.3 批调用回放验证: 为了提高脚本的正确性，每录制完成一个子流程后，都要恢复数据库，其他初始环境进行回放，以近 早发现脚本错误。 单个测试用例脚本录制完成后，要专门写一个主脚本，进行各子脚本的主次调用处理，然后恢复数据 库和其他初始环境进行回放，以验证整个脚本是否可以正确回放。 1.1.4 可移植回放验证: 由于WinRunner 工具的限制，在本机回放成功后，如果把脚本移植到其他机器上，往往无法成功。这 其中既有自己编写的脚本问题，又有WinRunner录制自动生成的脚本问题。 自己编写脚本问题:往往是编写的可移植性较差，如加载gui文件时用的是绝对地址，如 gui_load(“c:\\aa\\aa.gui”)，这样的脚本换到其他机器必然出错。 WinRunner录制自动生成的脚本问题: WinRunner的录制脚本往往和机器的环境有关，如果换了其 他机器环境，往往回放不成功，这就需要手工修改脚本。 因此，可移植性回放是非常必要的。 1.1.5 脚本中使用的ODBC数据源名称统一命名为WR。 1.1.6 录入中文数据时统一使用简体。 1.1.7 数据表列名称规定 录入数据驱动的脚本时，数据表列名称统一采用英文，使用PB数据窗口中列对象的名称。数据表列名称下的第一行用中文对英文列名称做注释，使用PB数据窗口中列对象的中文标签，这一行不作为有效的录入数据。与数据表相关的循环语句请修改脚本从数据表的第二行开始读取数据。典型的例子是将数据驱动 脚本中For循环的第一个表达式改为table_Row = 2。 1.1.8 脚本成功回放判定规定 一个子测试录制完成后，一定要及时回放测试，直到测试报告显示测试结果为OK，且子测试明细报告中没有红色的出错提示。如果是回放主测试，回放成功的标准是:主测试的结果报告显示为OK，同时所有 子测试的结果报告也为OK,且子测试明细报告中没有红色的出错提示。 1.1.9 WinRuner主脚本中关于设置系统日期时间设置的规定，以保证脚本所描述的业务过程按业务逻 辑在时间上有序。 因为脚本回放与脚本录制时的系统日期时间不一致，会导致与系统时间关系密切的测试脚本回放时失 败。 为了消除时间差导致的回放错误,要求每一个测试用例的主测试在第一个子测试前加上 date_set_system_date(年,月,日,时,分,秒)函数,以修改本地机器的日期时间等于这个主测试在接力式验收回放成功执行后的日期时间.这样再次回放时系统的日期时间就和上一次成功回放时的日期时间一致。 1.2 测试脚本存放规范: 各子测试脚本必须放到同一目录下，即环境目录下的scrīpt目录下。这样便于批调用时引用。 1.3 Gui文件的存放: Gui 文件，必须和测试脚本放到同一目录下，即环境目录下的scrīpt目录下。 1.4 WinRunner使用规范: (1) 必须写上清楚的注释:编写测试脚本，要进行详细的标注，每测试一小段，就要写一段备注，以 便于将来修改，格式可以参考如下: 功能描述:描述脚本的功能 前置条件:该脚本在满足什么条件下才可以被执行 步骤描述:描述脚本录制的动作 检查点描述:描述作了对什么的检查，检查条件。 录入人:录制人 录入时间: 备注: (2) gui文件的加载保存: 每次开始测试用例的录制脚本前，如果该测试用例已经存在gui文件，一定要手工打开gui文件，再开始录制。如果不想手工打开，可以写段自动加载gui的脚本，每次录制前运行一下该脚本。录入脚本后，要注意保存GUI文件，如果测试用例已经存在gui文件，一定要把临时的gui文件合并到该用例的公用gui 文件中，然后保存。 (3) 如果机器数据较慢，或者网络较慢、或者数据库运行较慢，需要把等待打开窗口的时间设长。或 者在脚本中插入同步点来处理。 (4) WinRunner不支持Fomular One，目前不可以用wr测试Fomular One 使用WinRunner录制时不可以切换不同输入法录制，仅可以用一种输入法。 (5) WinRunner 对shift 键无法纪录，需要特殊处理，可以加入如下处理 obj_type "dw_1.fslipbugno","-";(告诉WinRunner按下Shift键) 中间是选择行的脚本 obj_type ("dw_1.FBugNo","+";(告诉WinRunner释放Shift键) (6) 保证录制的脚本干净性: 在录制过程中，不可避免的要进行其他动作，如打开邮件、打开非录制程序等，这些动作也会被 WinRunner录制下来，这些动作会严重影响测试脚本的回放(除非作这些动作前停止录制)。 因此，为了保证脚本的干净，在WinRunner的参数中进行如下设置:设置Recode 的“Selected Applications” 为要录制的程序。 (7) 录制脚本时，不允许同时打开两个运行程序(指进行wr测试的程序) (8) 变量的声明:WinRunner有auto \public \static \extern 四个类型的变量作用域声明，其中public为默认的类型。由于public 是全局的，只要在一个脚本中声明了，在任何其他脚本都可以引用，这就带来一个问题，如果其他的脚本修改了这个public 变量的值，将会引发问题。因此变量声明时必须明确的加上 类型(auto \public \static \extern)，public 的一般不要使用，推荐使用static \auto 。 2. 异常处理规范: 在录制或者编写测试脚本时，必须进行异常的错误处理。以提高程序的错误检查能力。 2.1 函数异常检测: 对于一些常用函数，必须进行函数执行异常的处理。至少进行如下函数的异常检测:et_window、 win_activate、menu_select_item、ddt_open。 发现异常后，要终止程序的执行，并发邮件相关人员。 2.2 返回值规范: 模块、函数的返回值约定如下，0 表示成功，其他失败。 对于一些函数的返回值，需要进行判断处理: (1) 每一个call语句都应该检查它的返回值是否为0, 如果不为0则报错退出。 所有GUI检查点、数据库检查点都应做返回值检查。如果不为0则报错退出。 DNS 服务器的概念和原理 发布: 2010-2-22 13:56 | 作者: alexander | 来源: www.test8848.net | 查看: 214次 字号: 小中大 | 推荐给好友 DNS是域名系统的缩写, 它是嵌套在阶层式域结构中的主机名称解析和网络服务的系统。当用户提出利用 计算机的主机名称查询相应的 IP 地址请求的时候， DNS 服务器从其数据库提供所需的数据。 ? DNS 域名称空间:指定了一个用于组织名称的结构化的阶层式域空间 ? 资源记录:当在域名空间中注册或解析名称时，它将 DNS 域名称与指定的资源信息对应起来 ? DNS 名称服务器:用于保存和回答对资源记录的名称查询 ? DNS 客户:向服务器提出查询请求，要求服务器查找并将名称解析为查询中指定的资源记录类型 DNS 域名空间 DNS 域名空间是一种树状结构如下图。 目前由InterNIC管理全世界的 IP 地址，在 InterNIC 之下的 DNS 结构分为多个Domain,如图 5.1中 root domain下的七个 top-level domain 都归 InterNIC 管理，上图中还显示了由 InterNIC 分配给微软的域名空间。Top-level domain 可以再细分为 second-level domain 如 "Microsoft" 为公司名称,而 second-level domain 又可以分成多级的 subdomain 如 "example、www" ,在最下面一层被称为 hostname(主机名称)如 "host-a" ,一般用户使用完整的名称来表示 (FQDN)，如 "host-a.example.Microsoft.com"。 DNS 域名 DNS 利用完整的名称方式来记录和说明 DNS 域名，就象用户在命令行显示一个文件或目录的路径，如 "C:\Winnt\System32\Drivers\Etc\Services.txt"。同样在在一个完整的 DNS 域名中包含着多级域名。 如 "host-a.example.microsoft.com." 其中 "host-a" 是最基本的信息(一台计算机的主机名称)"example"表示主机名称为host-a的计算机在这个子域中注册和使用它的主机名称，"microsoft" 是 "example" 的父域或相对的根域 (即 second-level domain)，"com"是用于表示商业机构的top-level domain，最后的句点表示域名空间的根 (root)。 区域(zone) 区域 (zone) 是一个用于存储单个 DNS 域名的数据库，它是域名称空间树状结构的一部 分， DNS 服务器是以 zone 为单位来管理域名空间的，zone 中的数据保存在管理它的 DNS 服务器中。当在现有的域中添加子域时，该子域既可以包含在现有的 zone 中，也可以为它创建一个新 zone 或包含在其它的 zone 中。一个 DNS 服务器可以管理一个或多个 zone ,同时一个 zone 可以由多个 DNS 服务器来管理。 用户可以将一个 domain 划分成多个 zone 分别进行管理以减轻网络管理的负荷，如图 所示，microsoft.com 是一个域，用户可以将它划分为两个 zone:microsoft.com 和 example.Microsoft.com,zone 的数据分别保存在单独的 DNS 服务器中。因为 zone"example.Microsoft.com" 是从"domain" 延伸而来，所以用户可以将 domain"microsoft.com" 称为 zone"example.Microsoft.com" 的 zone root domain。 DNS 查询的工作方式 当 DNS 客户机向 DNS 服务器提出查询请求时，每个查询信息都包括两部分信息: ? 一个指定的 DNS 域名，要求使用完整名称(FQDN) ? 指定查询类型，既可以指定资源记录类型又可以指定查询操作的类型 如指定的名称为一台计算机的完整主机名称"host-a.example.microsoft.com.", 指定的查询类型为名称的A (address) 资源记录。可以理解为客户机询问服务器"你有关于计算机的主机名称为 „hostname.example.microsoft.com.?的地址记录吗,当客户机收到服务器的回答信息时，它解读该信息，从中获得查询名称的 IP 地址。 DNS 的查询解析可以通过多种方式实现。客户机利用缓存中记录的以前的查询信息直接回答查询请求， DNS 服务器利用缓存中的记录信息回答查询请求， DNS 服务器通过查询其它服务器获得查询信息并将它发送给客户机。这种查询方式称为递归查询。 另外, 客户机通过 DNS 服务器提供的地址直接尝试向其它 DNS 服务器提出查询请求。这种查询方式称为反复查询。 当 DNS 客户机利用 IP 地址查询其名称时，被称为反向查询。 测试用例设计方法的综合运用 发布: 2010-2-16 12:51 | 作者: 网络转载 | 来源: 网络转载 | 查看: 91次 字号: 小中大 | 推荐给好友 测试用例是按一定的顺序执行的与测试目标相关的测试活动的描述，是确定“怎样”测试。测试 用例被看作是有效发现软件缺陷 的最小测试执行单元，也被视为软件的测试规格#说明书#。在测试工作中，测试用例的设计是非常重要的，是测试执行的正确性、有效性的基础。如何有效地设计测试用例，一直是测试人员所关 注的问题;设计好测试用例，也是保证测试工作的最关键的因素之一。 设计测试用例，也分为白盒设计方法和黑盒设计方法。白盒设计方法又分为逻辑覆盖法和基本路径覆盖法，或者分为语句覆盖、判定覆盖、条件覆盖方法，而黑盒设计方法分为等价类划分法、边界值划分法、错误推测法、因果图法等。在实际测试用例设计过程中，不仅根据需要、场合单 独使用这些方法，常常综合运用多个方法，使测试用例的设计更为有效。 1(判定-条件覆盖方法 判定-条件覆盖方法就是将两种白盒设计方法“判定覆盖”和“条件覆盖”结合起来的一种设计方法，它所设计的测试用例是判定覆盖的设计的测试用例和条件覆盖设计的设计的测试用例的交集，即设计足够精巧的测试用例，使得判断条件中的所有条件可能取值至少执行一次，同时，所 有判断的可能结果也至少执行一次。 举个例子，源程序是: Dim a,b as Integer Dim c as Double If(a > 0 and b > 0)Then c = c/ a End If If(a>1 or c>1)Then c=c+1 End If c=b+c 则用两个测试用例(如表1)来覆盖了两个判定“P1=(a > 0 and b > 0)”和“P2 =(a>1 or c>1)” 和四个条件“C1= a > 0”、“C2= b > 0”、“C3= a>1”和“C4= c>1”。 表1判定-条件覆盖的测试用例 2(条件组合覆盖 条件组合覆盖的基本思想是:设计足够的测试用例，使得判断中每个条件的所有可能至少出现一次，并且每个判断本身的判定结果也至少出现一次，条件覆盖是简单地要求每个条件出现“真” 与“假”两种结果，而条件组合覆盖是让这些结果的所有可能组合都至少出现一次。 按照条件组合覆盖的基本思想，针对8种组合条件，来设计所有能覆盖这些组合的设计用例，如表2所示。即使我们用四个测试用例覆盖了所有8种组合条件，但还不能保证所有的路径被 执行，如这个例子少了一种路径，即P1= True, P2= false。 表2条件组合覆盖的测试用例 3.等价类划分法和边界值分析法的组合 数据测试是功能测试的主要内容，或者说功能测试最主要手段之一就是借助数据的输入/输出来判断功能能否正常运行。所以在测试用例的黑盒设计方法中，最常用的方法是等价类划分法、边 界值分析法。 等价类划分方法的基本思想是设想用一组有限的数据去代表近似无限的数据，就是基于对输入或输出数据的评估将数据划分为两个或更多子集(如有效的和无效的数据集)，从每个等价类中选 择一定的代表值进行测试，来代表整个数据集的输入/输出。 边界值分析法就是在某个变量范围的边界上，验证独立的输入/输出是否正确的测试方法。因为实践证明，程序往往在输入/输出数据边界更容易发生错误，所以检查边界情况的测试用例是比 较高效的，可以更快地查出错误。 但是，仅仅测试边界数据是不够的，正常区域 有效数据的等价输入值 Ni, 如75 无效数据的等价输入值两个:NLm1和NLm2, 如 -999和 999 为了得到更好的覆盖率，可以在最靠近边界取一些值，共四个，即: Nmin+1，Nmin-1，NMax+1，NMax-1，如-1，1，99，101 所以一个有效的测试数据集合是{-1，0，1，99，100，101};更完整的测试数据集合是{-999， -1，0，1，75，99，100，101，999}。 4(因果图法和组合分析法 因果图法和组合分析可以看作测试用例黑盒设计方法的综合方法。因果图法就是一种利用图解法分析输入的各种组合情况，生成判定表，从而设计测试用例的方法，它适合于检查程序输入条件的各种情况的组合。我们知道，即使各种单个输入条件可能出错的情况已经被排除了，但多个输入情况组合起来还是可能会出错。检验各种输入条件的组合并非一件很容易的事情，因为即使将所有的输入条件划分成等价类，它们之间的组合情况也相当多，因此，必须需要考虑采用一种适合于多种条件的组合，相应能产生多个动作的形式来进行测试用例的设计，这就是因果图法。 而组合分析是一种基于每对参数组合的测试技术，主要考虑参数之间的影响是主要的错误来源和 大多数的错误起源于简单的参数组合。 5(功能图法 功能图法是一种黑盒和白盒混合用例设计方法，在功能图方法中，要用到逻辑覆盖和路径测试的概念和方法，这属于白盒设计方法;而确定输入数据序列以及相应的输出数据，则是 黑盒设 计方法。 我们知道，每个程序的功能通常由静态说明和动态说明组成，动态说明描述了输入数据的次序或者转移的次序;静态说明描述了输入条件和输出条件之间的对应关系。对于比较复杂的程序，由于大量的组合情况的存在，如果我们仅仅使用静态说明来组织测试往往是不够的，必须还要动 态说明来补充。功能图法就是因此而产生的一种测试用例设计方法。 功能图法就是使用功能图形式化地表示程序地功能说明，并机械地生成功能图的测试用例。功能图模型由状态迁移图和逻辑功能模型组成。其中，状态迁移图用于表示输入数据序列以及相应的输出数据，由输入和当前的状态决定输出数据和后续状态;逻辑功能模型用于表示再状态输入条件和输出条件之间的对应关系。逻辑功能模型只适合于描述静态说明，输出数据仅仅由输入数据决定。测试用例测试由测试中经过的一系列的状态以及在每个状态中必须依靠输入/输出数 据满足的一对条件组成。 软件测试中经常遗漏的点 发布: 2009-12-23 14:54 | 作者: 未知 | 来源: 中国IT实验室 | 查看: 204次 字号: 小中大 | 推荐给好友 1、认知问题 由于测试工程师大多没做过开发或做过短暂的开发，开发知识和产品知识都有一定的局限，造成某些功 能没有测试到 2、前后台测试 对于一些运行于Linux环境下的产品，为了定位问题的方便，往往采用前台启动服务，而交付给客户后 却是后台启动。前台启动测试OK并不能能保证后台启动也是OK的。 3、安装部分 在测试的时候只是按照开发提供的文档去安装和配置，却并没有对安装进行测试(能够安装成功就认为 是OK)，忽略了可安装和易用性的测试; 4、输入框的以及输入法(ctrl+c/ctrl+v) 在我们的测试中，某个输入法输入会造成客户端退出，后来次问题一直存在，我问其他同事，他们都没 做过相应的测试，所幸只有我负责的一块出现这个问题; 5、软件版本 测试任务下达后，我们会按照测试申请中的提到的软件版本和路径去下载相应的软件，核对安装，一般不会在系统中敲命令去查看版本。事实上开发可能由于疏忽或其他原因把版本搞错的，即实际的软件跟测试申请中的不一样。虽然这不是我们的责任，但是试想一个版本测试下来，却发现时徒劳功岂不郁闷，更 危险的是我们的报告没问题，但发出的软件不是我们测试的，却出了大问题。 测试过程中进行Bug描述 发布: 2009-12-23 14:41 | 作者: 未知 | 来源: 中国IT实验室 | 查看: 109次 字号: 小中大 | 推荐给好友 1、术语解释 测试程序:提供给测试组测试的程序; 测试计划:对测试程序(构件、应用程序、系统等)及其目标进行简要说明; 测试bug:不符合测试需求的错误，也就是缺陷; 错误跟踪系统:是某个程序或应用系统，使得项目组可以报告、管理以及分析错误报告和错误趋势，如 RationalClearQuest就是一个错误跟踪系统 2、为什么要提交bug 在得到一个详尽的测试程序后，剩下的工作就是执行测试计划了。但是由于任何由人编写的程序都不可避免的存在着不符合测试需求的错误，也就是bug。因此需要一个方法来跟踪、分析和展示那些测试活动， 避免偏离最小。这种方法称之为错误跟踪系统。它主要是有效的管理缺陷，实现以下作用: 1)减少由于缺陷报告不明确而被开发组驳回的情况; 2)加快缺陷的处理速度; 3)提高测试的可信度; 4)加强测试组与开发组在整个项目过程中的团队合作 3、如何才能提交好的测试bug 在有些组织里，程序员几乎会把一半的测试bug返回给测试组，因为那些错误不可再现、没有发现错误、同设计要求一致，或者错误报告根本无法操作。如果错误报告有如此高的返回率，基本可以认为是过程崩溃，需要立即解决:因为编写这些报告浪费了时间;会影响程序员和测试人员之间的团队凝聚力;最糟糕 的是失去改进产品质量的机会。 有些错误总是不可再现的或提出质疑的。有些错误只是间断地在模糊的或极端的条件下表现出来。有时候，测试环境和程序员之间的不一致会导致“在我的系统上工作良好”的反应。在需求不清楚的项目中，在一定的测试条件下，对“正确”行为的观点可以存在合理的不同。有时候，当真正的问题在于糟糕的测试过 程、测试数据或不正确的测试用例时，测试人员可能错误解释测试测试结果和报告错误。 为了防止这类问题，要提交好的测试bug，作为一个好的测试人员，必须遵循以下八个步骤: 1) 结构:无论你是做探索性的或是描述性的、手工的或自动的测试，都要认真仔细的测试; 2)再现:尽量三次再现故障。如果问题是间断的，那么最好报告问题发生的概率;例如，每3次出现一 次，每3次出现2次等; 3) 推广:确定系统其他部分是否可能出现这种错误，以及使用不同的数据是否可能出现这种问题，特 别是那些存在严重影响的问题。 4)总结:简要描述客户或用户的质量体验和观察到的一些特征。 5)压缩:精简任何不必要的信息，特别是冗余的测试步骤。 6)去除歧义:使用清晰的语言，尤其要避免使用那些有多个不同或相反含义的词汇。 7)中立:公正地表达自己的意思，对错误及其特征的事实进行描述，避免夸张或忽略的语句，引起过度 的注意力或忽视。 8)评审:至少有一个同行，最好是一个有经验的测试工程师或测试经理，在你提交测试报告或测试评估 报告之前先自己读一遍。 好的测试bug描述是告诉读者测试人员发现了什么，而不是测试人员做了什么。因此只需要根据上述八 个步骤写下最少的必需重现步骤 4、如何提交bug 一个好的错误跟踪系统包括了错误的必要信息，如果做得不好，会造成迷惑，并误导读者。 好的故障描述应该包括十个基本部分:标题、项目、所属模块、优先级、重要性、异常等级、可重复性、 现象、操作过程和附件。 ?标题 使用一两句话来描述错误，告诉经理、开发人员以及其他读者为什么应该关心该问题。好的标题应该着重于出现的bug现象。但是过于简洁易引起误导，使得原本重要的问题被忽视。因此必须应该采用简洁、切中要害的概要，这样才能引起读者的重视。不重要的就描述比较轻微，例如:“联系人的email没有检查合法性”;重要的就要体现比较严重，例如:“填了运营商仍然提示运营商不能为空，使得无法进行下一步 的操作”，会更容易让开发人员理解究竟是什么问题及其重要性，并及时处理。 ?项目 是指该错误属于哪一个项目，归哪个项目组解决，使不同的项目组看到和及时定位自己项目的错误。 ?所属模块 是指准确说明发异常等级生错误的模块，切忌发生错误指派模块，导致后续流程错误; ?优先级 分为以下4级:1级:“马上解决”，表示问题必须马上解决，否则系统根本无法达到预定的需求;2级:“高度重视”，表示有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现;3级:“正常处理”，即进入个人计划解决，表示问题不影响需求的实现，但是影响其他使用方面，比如页面调用出错，调用了错误的数据库等;4级:“低优先级”，即问题在系统发布以前必须确认解决或确认可以不予解决。 ?重要性 分为以下5级:1级:“非常严重”，表示缺陷不修改整个系统流程不能继续;2级:“比较严重”，表示缺陷不修改不影响系统其他流程，但是本模块流程不能继续;3级:“一般”，表示缺陷不影响流程;4级: “轻微”，表示缺陷可以延期解决;5级:“优化”，表示修改以后流程会更好。 LoadRunner性能测试业务模型设计 发布: 2009-9-27 21:28 | 作者: 网络转载 | 来源: 网络转载 | 查看: 306次 字号: 小中大 | 推荐给好友 一个访问量达到百万级别的门户网站及奥运会订票系统等这中用户数较多的系统，进行性能测试是必须的。要不就和产品演示会上出现的笑话一样，风险投资商提出的问题是这个网站能支持多少用户同时上 线，项目经理居然说没有进行这方面的测试。全场哗然。。。。 对于性能测试的第一步是怎么去根据业务的实际模型分析出具体的测试场景及性能测试的指标。 一、 性能测试业务逻辑理解的一些基本概念 1、负载测试和压力测试的区别:负载测试在于确定最终满足系统指标的前提下，系统所能承受的最大 负载测试，压力测试的目标则在确定什么条件下系统性能处于失效状态。 2、吞吐量(Throughput):指单位时间内处理的客户段请求数量，直接体现软件系统的性能承载能 力。 3、并发(Concurrency):多个同时发生的业务操作。例如100个用户同时点登录21CN邮箱和同时在线人数不一样。比如说21CN通行证用户登录的有1万个可能只有20%的人在看博客，10%的人在看相册， 30%的人在查看邮件，10%的人在查看播客，10%的人在看视频点播，10%的人在逛论坛等等 但是同时在线人数就是1万，并发用户就是针对每个系统的具体人数。 二、几种常见的业务模型设计 1、e家广告系统: (1)具体的业务参数要求: 系统要达到4000万日均PV，则需要平台可以处理4000并发/秒。根据选中的服务器的性能，处理能力约为2000个HTTP并发/秒或1000个流媒体并发/秒。假设这4000万PV中有图片的PV占3000万，流 媒体的PV占1000万，则需要WEB服务器及流媒体服务器各两台。 (2)具体的测试设计方法: (a)平台的处理能力与要达到的日均PV的能力的计算关系为: 参数说明: X:表示整个系统的日均PV值，单位为:万PV/天 m:平台最大有效并发数(即用来服务于广告物料显示的并发数)，单位为:并发/秒，每小时是3600 秒，即每个小时处理的并发数为3600m并发，即0.36m万并发/小时。 y:非高峰时期的平均并发数与平台最大并发数的比例，0<y<1 Y:高峰期(平台达到最大并发数的70%，平台负载超过70%以后，将变得不稳定)小时数,0<Y<24,即 高峰期并发数为70%*0.36m 那么: 日均PV,高峰期并发数,高峰期小时数，非高峰期平均并发数,(24,高峰期小时数) 即: X=0.7*0.36mY+y*0.36m*(24-Y) 即最后结论: X=(0.252Y+8.64y-0.36yY)*m 根据经验值，Y,3，y=30%时，m/X=0.33。而m是平台最大有效并发数，即用来服务于广告物料显示的并发数，而对于每次广告物料的显示，客户端还有访问其它资源如JS代码等，假设每一次广告物料的访 问会有伴随另外2个资源的访问。 那么平台支撑的总的并发数与需要达到的日均PV的比大约为0.33*3=1。 (b)实际测试模型设计中结果: 对广告链接页面的并发用户数只需要达到N1=0.33*40000000*0.7/24*0.3*3600=356个 对于流媒体服务器并发用户数:N2=10000000*0.7/24*0.3*3600/2=135个 对于图片服务器并发用户数:N3=30000000*0.7/24*0.3*3600/2=405个 2、集团邮箱: (1)具体的业务参数要求:集团邮箱支持支持2000万用户，对性能有要求的操作有邮箱登录，读信，翻页，发邮件(分别是8秒内，2秒内，2秒内，5秒内)。所有的操作均返回HTTP200的状态代码。其中服务器资源分别是登录5台机器(连接PASSPORT)，收发邮件5台(不包括POP收发信)，其它邮件 处理服务器5台，pop/smtp服务器5台。 (2)具体的测试设计方法:具体的设计2000万个用户登录时间大概在会在8点到下午18点前操作，而该类业务模型满足80~20原则，比如80%的业务会在20%的时间内处理。则登录的并发用户数设计成多 少好呢, VUlogin=20000000*80%/(10*20%*3600*5) 其它事物可以以此类推。 (3)当然如果业务在要求吞吐量的时候，就要更根据吞吐量来设计性能瓶颈所需要的并发用户数这在我们21CN网站和电子商务网站中经常出现。这里引进一个公式VU=F /R*T(VU并发虚拟用户数,F吞吐量,T性能测试时间,R每个VU的请求数量)举例说明(某网站的吞吐量为90亿KB，每个用户每秒50万kb，运 行时间30分钟设计出来的每秒用户数VU=9000000000/(500000*30*30)) (4)如办公系统(业务比较频繁的系统):每天内的一些典型用户固定可以考虑采用一种更准确的计算并发用户数的的方法。公式引进:C=N*L/T,C1=C+ (C是平均并发用户数，N是login session的数量，L是login session的时长，T是考察的时间长度，C1是最高峰值)(*这里的用户是指明确每天都要使用的系统的大概数量来自需求，而这里的用户都是当做一个典型的用户来分析就是登录后会进行正常的流程操作) 如21CNEIP每天有320个典型用户访问，系统平均时间为4小时，在一天内用户使用该系统的时间都在8小时内。得出C=320*4/8,C1=C+3 (5)针对这几种模式做一些归纳无论那种模型都是来源于需求根据需求的实际模型是最真实的也是最有效的性能测试模型，在没有典型用户的前提下选择2-8原则(在测试环境中要考虑到等价这个概念就是测试环境服务器数量没有实际环境哪么多的时候要折算过来)，有典型用户的情况下选择最大并发数的计算方法，在要求有吞吐量的情况下用吞吐量的计算方法(但是吞吐量的数据要采用上一次测试或者经验值中没有突破系统瓶颈的部分数据要不结果不准确，其中每秒事物数取的是平均 值) 三、其它值得注意部分 1、设置测试场景中并发用户为每隔一段时间增加X个虚拟用户(预热，RAMP UP设置)，与同时加载所有的并发用户的测试结果不同，实际的测试中要根据具体业务情况设计。另外实际的数据库记录数和 网络环境等都会影响到测试结果。 2、建议在实际的测试过程中能多次测试取平均值。 3、性能测试的”拐点论”:产生拐点的情况是性能测试产生某种瓶颈，主要原因是某种资源达到了极限。 此时表现为随着压力的增大，系统性能出现急剧下降。 4、性能测试的系统能力验证: (a)是系统稳定性的一个基本要求，通常表现为系统在要求的平均并发用户下服务器的CPU平均使用率不高于75%，内存的使用率不高于75%。(b)系统在要求的并发用户数达到峰值情况下服务器的CPU平均使用率不高于95%，内存的使用率不高于90%。(c)系统能在高于实 际系统运行压力1倍的情况下，稳定的运行72小时。 5、为分清各个不同事物的响应时间请务必在多事物的脚本中添加事物以便区分，请在要用到多个帐户或者多个用户的迭代或者循环操作的时候请务必进行参数化(很多系统都限制了同一帐户在多长时间的操 作，或者防止数据冲突)。 LoadRunner登录脚本认证失败 发布: 2009-8-29 09:24 | 作者: 网络转载 | 来源: 网络转载 | 查看: 342次 字号: 小中大 | 推荐给好友 测试对象:某Web即时通讯系统(以下称WebIM) 开发语言:XML 数据通讯协议:Web(HTTP/HTML)协议、Windows Sockets协议 底层数据库:Mysql 服务器操作系统:Redhad 4 脚本实现功能:登入系统后，再退出系统。 问题1:录制开发的脚本可以成功回放，但是数据库的logout表里却查不到“登出”的用户? 分析:录制的时候只选用了单协议:Web(HTTP/HTML)协议，而WebIM的实现不只用到了 Web(HTTP/HTML)协议，也用到了 Windows Sockets协议。在定位了问题的"原因"之后，笔者尝试录制多协议的脚本，结果回放失败。回放失败是因为Webim在登录的过程中有个加密验证的过程。脚本回放时提交了上一次的经过Sha1加密后的密文，而此时服务器端的Sha1密文已经发生了改变。从而导致了失败。 解决方法: a、使用双协议录制脚本 b、开发Sha1算法的DLL文件并在脚本中调用。 问题2:录制的脚本中并没有捕获到服务器返回的Session ID? 分析和方案:Webim的开发用到了XML和Windows Sockets协议，因此按照正常的思路，Loadrunner在录制脚本时，也应该采用XML和Windows Sockets协议，但实际情况是这样的，录制的脚本中并没有捕获到服务器返回的Session ID。既然公司内网的Jabberd服务器有专门的测试客户端，笔者决定通过这个客户端录制脚本，由于这个客户端和服务器的通信协议是Windows Sockets，因此录制协议也采用了这个最底层的协议。这一次，录制的脚本中捕获到了服务器返回的Session ID。为了保证脚本回放时能够动态的获取到这个Session ID，需要做“关联”操作，笔者使用了lrs_save_searched_string()函数，对脚本做了 处理。 问题3:如何调用Dll来对服务器返回的序列和Password加密，以产生Sha1的密文? 分析和方案:脚本中加载了Dll库文件后，在调用库文件中的加密函数对Session ID+Password字符序列加密时，必须采用如下格式endes(a，b)，其中的a代表源序列，b代 表密文。经过这样的步骤处理后， 调试脚本，就可以看到密文了。 问题4:Buf中参数化密文后，脚本还是不能编译通过，存在语法错误? 分析和方案:发现Loadrunner参数化，是按照它内置的机制执行的，符合这个机制，编译就能通过。后来在Gen中的Tools—>general option中找到了可以更改这个机制的地方，修改完了之后，脚本再次编 译，这次OK了。 问题5:错误提示:没有足够的虚拟用户分配给这个NewPara? 分析和方案:loadrunner中在对用户名和密码或其他数据参数化了以后，不要将参数删除后，重新参数化，否则就会出现上述问题。笔者决定重新录制脚本，重新参数化，重新修改脚本。事实证明这样做是 正确的，编译运行后，5个虚拟用户的脚本正确无误的通过。 LoadRunner的Apache的监控 发布: 2009-10-13 09:50 | 作者: webmaster | 来源: 本站原创 | 查看: 78次 字号: 小中大 | 推荐给好友 LoadRunner的Apache的监控 具体配置如下: 配置LoadRunner监控Apache,LoadRunner监控Apache服务器是调用的Apache自身的模块进行监控的， 所以需要配置Apache和LoadRunner 一.配置LoadRunner 1.在图树中单击 Apache 图，并将该图拖进“运行”视图的右窗格中。 2.右键单击该图，然后选择“添加度量”，或选择“监视器”>“添加联机度量”。 3.在“Apache”对话框的“监视的服务器计算机”部分，单击“添加”输入要监 视计算机的服务器名或 IP 地址。选择计算机运行的平台，单击“确定”。 4.在“Apache”对话框的“资源度量”部分中，单击“添加”选择要监视的度量。 将打开“Apache - 添加度量”对话框，显示可用的度量和服务器属性。 5.在“服务器属性”部分，输入端口号和不带服务器名的 URL，并单击“确定”。 默认的 URL 是 /server-status?auto。 6.在“Apache”对话框中单击“确定”，激活监视器。 二.配置Apache 1.修改Apache中Httpd.conf文件，添加如下代码(该文件中都有，只要取消注释就好了) <Location /server-status> SetHandler server-status Order deny,allow # Deny from all Allow from .localhost </Location> 2.添加 ExtendedStatus 设置 ExtendedStatus On 3.取消注释LoadModule status_module modules/mod_status.so 加载该模块。 4.重新启动Apache Quality Center 发布: 2009-12-22 10:14 | 作者: 网络转载 | 来源: 本站原创 | 查看: 166次 字号: 小中大 | 推荐给好友 首先介绍什么是QC,QC的前身就是大名鼎鼎的TD,改进后现在可以叫QualityCenter,网上有试用版，可以免费试用6个月，但是自带的SQL数据库只支持5个人用，建议大家可以连接一个正版的SQL数据库或者Access数据库。QC比TD改进在把TD转移到了j2ee平台上，支持weblogic,jboss，支持 QTP/WinRunner，不过BPT只在QC8.2可用。但个人认为QC9.0其极耗资源。 其次让我们了解一下QC的功能: 1.Quality Center 有助于维护测试的项目数据库，这个数据库涵盖了应用程序功能的各个方面。设计了项目中的每个测试，以满足应用程序的某个特定的测试需求。要达到项目的各个目标，可将项目中的测试组织成各种特定的组。Quality Center 提供了一种直观、高效的方法，用于计划和执行测试集、收集测试结果以及分析相关数据。Quality Center 还具有一套完善的系统，用于跟踪应用程序缺陷，通过它，您可 以在从初期检测到最后解决的整个过程中严密监视缺陷。将 Quality Center 链接到电子邮件系统，所有应 用程序开发、质量保证、客户支持和信息系统人员可以共享缺陷跟踪信息。 2.Quality Center 可以集成 Mercury 测试工具(WinRunner、QuickTest Professional、QuickTest Professional for MySAP.com Windows Client、LoadRunner和 Visual API-XP)以及第三方和自定义测试工具、需求和配置管理工具。Quality Center 可以无缝地与您选择的测试工具通信，提供一种完整的解决 方案，使应用程序测试完全自动化。 3.Quality Center 可指导您完成测试流程的需求指定、测试计划、测试执行和缺陷跟踪阶段。它把应用程 序测试中所涉及的全部任务集成起来，有助于确保客户能够得到最高质量的应用程序。 总之个人认为在测试中合理的使用QC，能起到事半功倍的效率，所以现在一些公司都在使用QC为了管理 整个测试流程。 关于QA与QC的概念 发布: 2010-3-16 17:31 | 作者: webmaster | 来源: www.test8848.net | 查看: 225次 字号: 小中大 | 推荐给好友 什么是QC, QC 是 Quality Control 指检验，在质量管理发展史上先出现了“QC”，产品经过检验后再出货是质量管理最基本的要求。QC的工作主要是产成品，原辅材料等的检验，QA是对整个公司的一个质量保证， 包括成品，原辅料等的放行， 质量管理体系正常运行等. QC最重要的职责在于对制成品(主要包括Raw material,in-process goods,finish goods，In-process audit)的监控，侧重于通过Sample Inspection来Detect defect. 什么是QA, QA 是 Quality Assurance QA最重要的职责在于系统层面的完善，侧重于问题的防范及对已发生之问题之Root Cause探究及其 Permament C/A之实施，从而降低不良的产生。 随着QA的出现，企业的质量管理范围进一步推广，包括了整个品质保证题写的范围，质量管理人员的权限也进一步增大。有些企业QA还包括了CS(顾客满意)的业务，就是处理顾客的投诉:分析、对策、 顾客满意度调查等业务。 高效的测试用例设计方法 发布: 2010-1-11 19:03 | 作者: 网络转载 | 来源: 网络转载 | 查看: 248次 字号: 小中大 | 推荐给好友 1、最少用例，提供最大的测试覆盖率。 如果两位工程师用两个不同的测试过程来测试同一个功能，那么这种做法就不是高效的，除非是为了 达到要求的功能路径覆盖，否则这种做法是没有必要的。 2、明确需求和功能路径之间的关系。 功能性测试目的是为了发现与最终用户需求不一致的地方，而功能性测试阶段最重要的目标是评估系统的行为是否和需求指定的行为一致。实际工作中，测试人员拿到完美需求的情况是非常罕见的。为了创建有效的功能测试过程，测试人员必须理解应用程序的细节和实质。当这些细节和实质在需求文档中没有充分体现时，测试人员就必须对文档进行分析。而大多数情况下需求文档都没有详细到明确地定义了需求 和功能路径之间的关系，所以测试人员需要重点关注两方面: 完善一条需求的流程。 设计测试过程的过程中，测试人员会用测试数据集合为输入仔细地走查系统的每个交互操作。会把各 种情况下的需求描述成一条有交互操作组成的清晰路径。 明晰一条需求对其他需求的依赖。 分析每一部分应用测试用例程序的改变对应程序其他部分的影响，并且这种变化所影响的其他部分。 3、确定特定事务的测试顺序或者序列。 为了满足执行的测试过程所需的前置条件(例如:数据库配置以及控制流或梦八流所产生的其他需求)， 必须确定特定事务的测试顺序或者序列。 如何确定事务的测试顺序呢,创建一个测试过程关系矩阵，或者关系图。矩阵根据执行一个测试过程所需要的前置条件和后置条件组成了测试过程的流程。关系图表示了各种测试过 程之间的交互作用，可以 显著地改进测试过程。 为了在开发时间表中尽早地安排对最重要的功能的测试以及对它们进行更深入的测试，建立有效测试 过程，另外需要考虑的问题是确定和评审关键和高风险的需求，划分需求的优先级。 4、明确需求用例场景(使用情况、可先路径、异常路径)。 要设计高效的测试用例，就需要对系统的变化、流程和场景有较深的了解。为了理解各种联系、流程 和相互关系，就需要借助系统开发过程中形成的各种文档，深入分析思考和关注细节。 那为什么引入用例场景呢,主要由于现在的软件几乎都是由事件触发来控制流程的，事件触发时的情 景便形成了场景;同一事件不同的触发顺序和处理结果形成事件流。 什么是用例场景呢,用例场景是指通过描述流经用例的路径来的确定的过程，这个流经过要从用例开始到结束遍历其中所有的基本流和备选流。基软件测试用例场景本流是指流经用例的最简单路径;备选流 是指自基本流开始，之后会在某特定条件下执行。 模型驱动测试用例设计方法 发布: 2010-1-14 13:34 | 作者: 网络转载 | 来源: 网络转载 | 查看: 282次 字号: 小中大 | 推荐给好友 根据统计分析，一个基本功能，使用手工测试，需要达到测试用例:测试功能点=5:1以上，才比较有意义。 使用更多的测试用例，才能够发现更多的问题，这是根据经验归纳来的。 设计测试用例，是整个测试工作的最核心部分。目前绝大多数的测试设计方法，都属于测试设计“技巧”，如:等价类划分、边界值、因果图等，都是在具体设计测试数据时候来考虑如何根据测试数据的不同来设 计测试用例。 基于这些具体测试技巧，对整体测试用例设计水平的提升，帮助不是很大。目前，基于这些方法，真正影响测试用例质量的，是测试设计人员对被测试系统需求的理解、业务层面的理解。 MDV的方法，是想通过建立一套设计测试用例的流程，通过标准化的输入、标准化的处理，生成更可 靠的测试用例。 MDV，就是基于测试模型的测试设计方法，MDV把的基本方法，就是把需求作为测试用例设计的输入， 通过测试需求分析，转换为测试模型，在根据测试模型生成测试用例。 我们的方法论，更进一步: 需求模型——>测试模型——>测试用例——>测试场景 测试场景，更多的体现了测试过程的流程，体现了需求对流程的描述，对需求中各个业务流程、业务 功能的测试。 通过这个方法，我们能够覆盖到应用系统的各个流程和不同的测试数据分支。 下面，我们简要的介绍一些各个阶段的转换: ? 从需求模型到测试模型 在进行功能测试的时候，输入是需求。如果需要进行MDV ，则需要对需求进行约束，也就是我们需 要对需求进行形式化。需求的形式化，便于我们很方便的转换何曾为测试模型。 需求的形式化，就是需要对需求的表述，从自然语言转换成为UML的形式。在测试中，主要采用UML 的usecase图和活动图来表述。 解决了需求的形式化，就要求在需求导入的时候，必须导入活动图，否则就需要测试需求分性做更多的工作，自己来解决没有必要需求，自己来表述的问题了。这样会导致理解的偏差和测试的不足。 很多时候，不是没有UML图的问题，而是发现需求本身不全面。因此建立需求UML的过程，也是对需求 进行补充的过程。 需求建立之后，我们需要把需求转换为测试需求。转换的基础是:定义测试项。也就是，需要在本需求中，定义那些测试场景建立完成，就需要进行测试用例设计。从MDV的角度，测试用 例就是给测试场景增加了测试数据来形成的:测试场景+测试数据=测试用例’s 因此，这个阶段的重点工作就是设计测试数据，或者添加测试数据给测试场景，形成测试用例(很多 个测试用例)。 这个方法，我们叫做面向测试模型驱动的测试设计方法。 基于测试概念进行代码设计的七条基本 原则 发布: 2010-2-16 12:53 | 作者: 网络转载 | 来源: 网络转载 | 查看: 174次 字号: 小中大 | 推荐给好友 当设计大型程序的时候，您必须时刻留心不同设计选项对诸如性能和可扩展性这样的特征的影响。随着软 件产品的日渐复杂及其无所不在的部署，软件的“可测试性”也成了更重要的考虑事项。 彻底测试代码的重要性是显然的。花在编写测试和测试代码上的时间和精力给您带来的回报是维护成本的 大幅降低。 然而，除非您很小心，否则您花在测试代码上的精力可能会首先达到花在编写代码上的精力的几倍～我曾看到程序员们齐心协力地对他们的全部代码进行单元测试，结果花在上面的时间使大多数人都以沮丧而告 终。 幸运的是，没有必要这样。在您设计软件的时候应用一些基本原则，编写易于测试、甚至使测试成为乐趣 的代码是可能的。 跟其它编码原则一样，这些原则也不是不容置疑或不可改变的教条。有时候打破这些规则也是必要的。因此，理解每条原则背后的动机和判断何时这些动机不适用(或应让位给更关心的问题)的能力是很重要的。 原则1:到GUI视图的外面去 尽可能把代码移到GUI视图的外面。然后各种GUI动作就能成了模型上的简单方法调用。为什么您需要这 样做呢, 对GUI测试者来说，通过方法调用测试功能比间接地测试功能容易的多。 另一个好处是它使修改程序功能而不影响视图变的更容易。 当然，视图中也可能存在错误。在理想情况下，对程序的测试将同时检查模型和视图。 原则2:使用类型进行错误检查 类型是您的朋友 — 尽可能多地用类型系统自动检查错误。 类型能在程序运行之前自动捕捉程序中的错误。没有静态类型检查的话，类型错误将作为破坏者逗留在您 的程序中，直到恰当的执行路径碰巧把它揭露出来为止。 最大限度地发挥使用类型的长处是棘手的。通常，一组数据结构可以在一个抽象级别上一起使用，或者被 分出，成为一个单一的、更高抽象级别的一个新的相关数据类型。 事实上，编程语言自身的历史可以看成是可以编程的抽象级别的逐渐提高。汇编语言提供了比特到整数和 浮点数的抽象。接下来是记录和函数抽象，然后又是诸如对象、类、线程以及异常这样的抽象。 在每一抽象级别上，达到与更高级别抽象一致的功能是可能的，但那实质上仅仅是耗费更多精力，冒更多 的错误风险。 在面向对象语言(其它现代语言也一样)中，一个程序员在设计抽象上有很大的灵活性。在哪个抽象级别上设计程序就成了基于折衷的决定，比如由抽象级别提供的更多的健壮性和由于不能在更低抽象级别上工 作而带来的表达性(有时是性能)的损失。 通常，高级别抽象带来的健壮性和简单性的价值很少被其它考虑事项超过。 原则3:使用调节器避免“故障线路”(fault line) 我用“故障线路”来指独立组件之间的接口，独立组件之间和组件与其相应子组件之间相比，很少有交互。这种故障线路的一个典型示例是 GUI 视图和它的模型之间的接口。其它示例包括在编译器中处理的不同阶 段之间的接口或操作系统的内核和用户界面之间的接口。 找出程序的故障线路，然后用具有转发功能的调节器快速访问聚合组件。 沿着故障线路隔离测试每个组件通常更容易。但如果每个组件暴露的对象有很多，或者组件中您想测试的 一些对象只有通过多个嵌套引用才能访问，那么测试就会变的很乏味。 不用隔离测试，而是拥有您在它上面调用您想测试的各种方法的单个调节器对象通常是有帮助的。这个对 象然后能把这些方法调用转发到适当的地方。 沿着相同线路，设计和自己的测试代码串联在一起的程序组件接口是有益的。这将使您把注意力集中在使 这些接口尽可能简单上。 原则4:方法:小型签名和缺省参数 使用小型方法说明和重载带缺省方法参数的方法将使您在测试中调用这些方法变的愉快 的多。否则，在测试这些方法时您将不得不构造额外参数。如果参数很大，那么将很快导致代码膨胀。更糟的是，它会诱使 您编写比在其它情况下更少的测试。 原则5:访问器不应修改内存状态 请在您的测试中使用不修改内存状态的访问器来检查对象状态。 在某些方面，测试和实验室试验相似。它们都想证明特定假设有效。如果特定检查动作改变了该领域的状 态，那么要这样做会变得困难的多。 与量子力学领域不同，计算机进程的状态可以不修改就被检查。使用这种原则对您有好处。 原则6:用接口说明外部程序组件 用接口说明外部程序组件使得我们可以容易地在测试案例中模拟这些组件。 这条原则能节省大量时间，特别是当外部组件的实现还未完成时。通常，大多数基本组件都不能准时可用。如果这些组件不在适当位置您就不能测试您自己的代码的话，那么您就在朝灾难走去。您的客户不会关心 您只有两个小时来集成迟到了两周的组件。他们知道的全部就是整套产品被延期了和这是违约的。 原则7:优先编写测试代码 优先编写测试代码。这是标准的XP方法，但却总有一种忽视它的诱惑。 每次我屈服于这种诱惑时，我都感到后悔。假设您正努力生产正确的代码，那么您好象能从推迟编写测试 代码中节省的时间其实只是一个幻想。 注意:这不是说您应该一次性编写全部测试代码后，再一次性全部实现。编写一些测试代码，实现它们，再编写一些测试代码，再实现它们等等是个更好的办法。设计以这种方式得以进展;在实现阶段捕捉错误 并在下一组测试中改正它。以这种方式编写测试也更少会使人畏缩。 代码比您需要的还多, 只需一点点努力，就可能容易地对任何程序进行彻底的测试。当然，不可避免存在这些原则不适用的情况; 于是，看起来好像不可能对功能进行测试。 当出现这些情况时，我尽力退一步地看这个问题，“我怎样才可能测试这种代码,”相反地，我问自己，“我怎样才能以可测试方式编写这些代码呢,”这种想法上的改变的结果经常是增加了大量仅仅服务于简化测 试的功能。 什么,别担心～出现这种情况完全正常。 就象很多现有的设计模式，它们只是为了增加程序的可扩展性就往程序中添加很多类(例如 visitor、decorator 等等)，开发简化测试的新模式是可以接受的。实际上，面向对象语言的很多特征都是为了简 化扩展而包含进去的;为什么语言的未来版本(或全新的语言)不应包含简化测试的特征。 对Java语言来说，这已经开始。人们计划在未来版本中包含很多更强大的类型系统、断言(assertion)等等。就象面向对象的语言已经增加了我们重用和扩展现有代码的程度，将来，面向测试的设计和特征将 帮助我们增强新老代码的健壮性。 那如何做性能测试那? 1) 性能测试应该早期就积极介入。介入代码审查和分析性能目标，多提出疑问，早期发现潜在的性能 问题 2) 性能测试考虑全局，他是一个系统的测试。需要在产品的每个部件都做了一个测试，并全部成功后 才开始系统测试执行。需要考虑多种因素:环境的、硬件的、软件的等等。 3) 测试前一定要检查确认配置。参数一定要配置对，否则测试无效。最好对于每个测试都有一个 checklist，每次检查前都一一检查。这一步骤一定不可以省略，并需要被开发review。 4) 数据预热和数据准备很关键。一开始系统并不是一个干净的环境。我们需要在性能测试开始前预存 一定的数据，并且让其有个增量。而且也要考虑到哪些方面数据多少(要更具实际情况)。 5) 准备测试脚本和工具要考虑实际情况。比如人的思考时间，场景的设计，不同操作的比例，数据的 随机性等都要仔细设计，最和可以开发以及应用方进行讨论和确认。 6) 测试执行前一定要确保服务器独占，执行中如果是5-7天的测试，最好拿出一天先跑一个一天压力 不高的测试，潜在一天发现可发现的问题。 7) 多种测试结果的分析发现问题。 a) Log日志的分析 b) 系统状态的分析 c) 数据一致性的分析 性能测试需要长时间的经验积累，我知道的只是些皮毛，后面还会继续探索，喜欢性能测试并将会在 实践中不断积累和成长。