测试工具应用之我见/压力测试实例

随着软件测试的地位逐步提高，测试的重要性逐步显现，测试工具的应用已经成为了普遍的趋势。目前用于测试的工具已经比较多了，这些测试工具一般可分为白盒测试工具、黑盒测试工具、性能测试工具，另外还有用于测试管理（测试流程管理、缺陷跟踪管理、测试用例管理）的工具。
总的来说，测试工具的应用可以提高测试的质量、测试的效率。但是在选择和使用测试工具的时候，我们也应该看到，在测试过程中，并不是所有的测试工具都适合我们使用，同时，有了测试工具、会使用测试工具并不等于测试工具真正能在测试中发挥作用。因此，本文拟从测试工具的选择和使用方面着手，讲述一点本人的心得。

1、 应用测试工具的目的
应用测试工具的目的很明确，一般而言，在测试过程中应用测试工具主要为了以下几个目的：

a) 提高测试质量；
b) 减少测试过程中的重复劳动
c) 实现测试自动化

在测试中应用测试工具，可以发现正常测试中很难发现的缺陷（例如，Numega的DevPartner工具就可以发现软件中的内存方面的问题）

2、 测试工具的分类和选择
一般而言，我们将测试工具分为白盒测试工具、黑盒测试工具、性能测试工具、测试管理工具几个大类。

a) 白盒测试工具
白盒测试工具一般是针对代码进行测试，测试中发现的缺陷可以定位到代码级，根据测试工具原理的不同，又可以分为静态测试工具和动态测试工具。
i. 静态测试工具
静态测试工具直接对代码进行分析，不需要运行代码，也不需要对代码编译链接，生成可执行文件。静态测试工具一般是对代码进行语法扫描，找出不符合编码规范的地方，根据某种质量模型评价代码的质量，生成系统的调用关系图等。
静态测试工具的代表有Telelogic公司的Logiscope软件、PR公司的PRQA软件。
ii. 动态测试工具
动态测试工具与静态测试工具不同，动态测试工具的一般采用“插桩”的方式，向代码生成的可执行文件中插入一些监测代码，用来统计程序运行时的数据。其与静态测试工具最大的不同就是动态测试工具要求被测系统实际运行。
动态测试工具的代表有Compuware公司的DevPartner软件、Rational公司的Purify系列。

b) 黑盒测试工具
黑盒测试工具适用于黑盒测试的场合，黑盒测试工具包括功能测试工具和性能测试工具。黑盒测试工具的一般原理是利用脚本的录制(Record)/回放(Playback)，模拟用户的操作，然后将被测系统的输出记录下来同预先给定的标准结果比较。黑盒测试工具可以大大减轻黑盒测试的工作量，在迭代开发的过程中，能够很好地进行回归测试。
黑盒测试工具的代表有Rational公司的TeamTest、Robot，Compuware公司的QACenter，另外，专用于性能测试的工具包括有Radview公司的WebLoad、

Microsoft公司的WebStress等工具。

c) 测试管理工具
测试管理工具用于对测试进行管理。一般而言，测试管理工具对测试计划、测试用例、测试实施进行管理，并且，测试管理工具还包括对缺陷的跟踪管理。
测试管理工具的代表有Rational公司的Test Manager、Compureware公司的TrackRecord等软件。

d) 其他测试工具
除了上述的测试工具外，还有一些专用的测试工具，例如，针对数据库测试的TestBytes，对应用性能进行优化的EcoScope等工具。

e) 测试工具的选择
面对如此多的测试工具，对工具的选择就成了一个比较重要的问题。我们在考虑选用工具的时候，建议从以下几个方面来权衡和选择：
i. 功能

功能当然是我们最关注的内容，选择一个测试工具首先就是看它提供的功能。当然，这并不是说测试工具提供的功能越多就约好，在实际的选择过程中，适用才是根本。“钱要花在刀刃上”，为不需要的功能花费金钱实在不是明智的行为。事实上，目前市面上同类的软件测试工具之间的基本功能都是大同小异，各种软件提供的功能也大致相同，只不过有不同的侧重点。例如，同为白盒测试工具的Logiscope和PRQA软件，他们提供的基本功能大致相同，只是在编码规则、编码规则的定制、采用的代码质量标准方面有不同。
除了基本的功能之外，以下的功能需求也可以作为选择测试工具的参考：

1) 报表功能；测试工具生成的结果最终要由人进行解释，而且，查看最终报告的人员不一定对测试很熟悉，因此，测试工具能否生成结果报表，能够以什么形势提供报表是需要考虑的因素。

2) 测试工具的集成能力；测试工具的引入是一个长期的过程，应该是伴随着测试过程改进而进行的一个持续的过程。因此，测试工具的集成能力也是必须考虑的因素，这里的集成包括两个方面的意思，首先，测试工具能否和开发工具进行良好的集成；其次，测试工具能够和其他测试工具进行良好的集成。

3) 操作系统和开发工具的兼容性；测试工具可否跨平台，是否适用于公司目前使用的开发工具，这些问题也是在选择一个测试工具时必须考虑的问题。
ii. 价格
除了功能之外，价格就应该是最重要的因素了。说句题外话，在论坛上经常看到有人沾沾自喜的说我已经破解了XX测试工具这样的话，对这种态度我十分不赞成。如果作为软件从业者的我们都不能尊重别人的劳动，那有怎么能够指望我们的客户尊重我们的劳动呢？况且，测试工具的价格并不是真的昂贵到不能承受的程度，例如Numega的DevPartner一个固定license是两万多元人民币，对一个中型的公司来说完全可以承受。
iii. 测试工具引入的目的是测试自动化，引入工具需要考虑工具引入的连续性和一致性
测试工具是测试自动化的一个重要步骤之一，在引入/选择测试工具时，必须考虑测试工具引入的连续性。也就是说，对测试工具的选择必须有一个全盘的考虑，分阶段、逐步的引入测试工具。

3、 测试工具在测试过程中的应用
前面已经对测试工具的分类、测试工具的选择进行了一些描述，这里，我还想就测试工具在测试过程中的应用说一点自己的看法。
对测试工具能够发挥的作用大家都已经了解并认可了，但是很多引入测试软件的公司并没有能够让测试软件发挥应有的作用，其主要原因我总结为三个方面：

a) 没有考虑到公司的实际情况，盲目引入测试工具
首先我们要明确一点，并不是每种测试工具都适合公司目前的实际情况。我见过一些公司怀着美好的愿望花了不小的代价引入测试工具，半年一年以后，测试工具却成了摆设，成了引入者心头的痛。究其原因，就是没有能够考虑公司的现实情况，不切实际地期望测试工具能够改变公司的现状，从而导致了失败。
例如，如果一个公司所开发的软件属于工程性质的软件，在整个开发过程中需求和用户界面变动较大，这种情况下就不适合引入黑盒测试软件，因为黑盒测试软件的基本原理是录制/回放，对于不停变化的需求和界面，可能修改和录制脚本的工作量还大过测试实施，运用测试工具不但不能减轻工作量，反而加重了测试人员的负担。
我公司引入测试工具时比较成功的（至少从目前来看），针对我公司的应用项目都存在需求、界面变动比较频繁的情况，我们暂时没有引入黑盒测试工具，主要依靠白盒测试工具提升代码质量。目前我们引入的测试工具包括Compuware的DevPartner和Telelogic的Logiscope，这两个工具在测试阶段和维护阶段发挥了应有的作用。

b) 没有形成一个良好的使用测试工具的环境
换句话说，就是没有能够形成一种机制让测试工具真正能够发挥作用。例如，白盒测试工具的一般使用场合是在单元测试阶段，而单元测试是由开发人员完成，如果没有流程来规范开发人员的行为，在项目进度压力比较大的情况下，开发人员很可能就会有意识地不使用测试工具，来逃避问题。在这种情况下，就必须形成一种有约束力的机制来强制对测试工具的使用。
将测试工具的使用明确定义进公司的开发流程，我认为是一种比较好的方式。我们目前的做法是在开发流程中明确说明，在项目里程碑提交的文档中必须包括测试工具生成的报告，该报告中的数据是决定项目是否合格的依据。根据我公司的实际情况，在提交集成测试时需要提交DevPartner工具生成的测试覆盖率报告、Logiscope生成的代码质量报告，并且要求单元测试的代码覆盖率必须达到80%以上，代码质量评价必须在Fair以上。

c) 没有进行有效的测试工具的培训
测试工具的使用者必须对测试工具非常了解，在这方面，有效的培训是必不可少的。测试工具的培训是一个长期的过程，不是通过一两次讲课的形式就能达到良好的效果。而且，在实际的使用测试工具的过程中，测试工具的使用者可能还存在着这样那样的问题，这也需要有专人负责解决，否则的话，对于测试工具使用者的积极性是很大的打击。
我公司在进行测试工具的培训时，进行了一个系列的培训和交流，从针对开发高层的《测试工具基本概念培训》到针对测试工具实际使用者的《测试工具使用培训》，再到交流性质的《测试工具应用交流研讨会》，再到定期发出的《测试工具应用问答》，在这方面下了很大的功夫，目前测试工具的应用已经成为了开发人员和测试人员的基本功。

以上是我对测试工具应用的一点个人见解，不当之处，欢迎各位同行的批评指正。
>>>---------我想分页！--这么长的文章，在这里来个分页多好啊！哈哈----------<<<
压力测试实例
作者:李明艳 时间:2005-08-12 21:00 出处:互连网
摘要：压力测试实例

　　利用现代的设计技术和正式的技术复审可以减少代码中存在的初始错误，但是错误总是存在的，如果开发者找不到错误，那么，客户就会找到它们。越来越多的软件组织认识到软件测试是软件质量保证的重要元素之一，很多软件开发组织将30%—40%甚至更多的项目资源用在测试上，软件测试技术和软件测试策略受到了高度的重视和广泛的应用。
　　本文不想就软件测试技术和软件测试策略作深入的理论分析，而是列举一个在软件系统测试阶段进行的压力测试实例，希望能通过这个实例与从事软件测试相关工作的朋友进行交流。
　　首先介绍一下实例中软件的项目背景，该软件是一个典型的三层C/S架构的MIS系统（客户端/应用服务器/数据库管），中间层是业务逻辑层，应用服务器处理所有的业务逻辑，但应用服务器本身不提供负载均衡的能力，而是利用开发工具提供的ORB（对象请求代理）软件保证多个应用服务器间的负载均衡。本次测试的目的是：进行单个应用服务器的压力测试，找出单个应用服务器能够支持的最大客户端数。测试压力估算的依据是：假定在实际环中，用户只启用一个应用服务器进行所有的业务处理。方法是：按照正常业务压力估算值的1~10倍进行测试，考察应用服务器的运行情况。
压力测试的详细计划如下：

《压力测试计划》

1、测试计划名称
　　河北省公安交通管理信息系统压力测试计划。
2、测试内容
2.1背景
　　本次测试中的压力测试是指模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时 间运行测试软件来测试被测系统的可靠性，同时还要测试被测系统的响应时间。

用户的实际使用环境：
◇由两台IBM XSeries250 PC Server组成的

Microsoft Cluster；
◇数据库管理系统采用Oracle8.1.6；
◇应用服务器程序和数据库管理系统同时运行在

Microsoft Cluster上。
◇有200个用户使用客户端软件进行业务处理，每年通过软件进行处理的总业务量为：150万笔业务/年。

2.2测试项
应用服务器的压力测试；
2.3不被测试的特性
◇系统的客户端应用程序的内部功能；
◇数据库中的数据量对程序性能的影响。
3、测试计划
3.1测试强度估算
测试压力估算时采用如下原则：
◇全年的业务量集中在8个月完成，每个月20个工作日，每个工作日8个小时；
◇采用80—20原理，每个工作日中80%的业务在20%的时间内完成，即每天80%的业务在1.6小时内完成；
测试压力的估算结果：
　去年全年处理业务约100万笔，其中15%的业务处理每笔业务需对应用服务器提交7次请求；
70%的业务处理每笔业务需对应用服务器提交5次请求；其余15%的业务每笔业务向应用服务器
提交3次请求。根据以往统计结果，每年的业务增量为15%，考虑到今后三年业务发展的需
要，测试需按现有业务量的2倍进行。
每年总的请求数量为：（100*15%*7+100*70%*5+100*15%*3）*2=300万次/年。
每天的请求数量为：300/160=1.875万次/天。
每秒的请求数量为：（18750*80%）/（8*20%*3600）=2.60次/秒。
正常情况下，应用服务器处理请求的能力应达到：3次/秒。
3.2测试环境准备
3.2.1基本硬件及软件环境的准备
1)网络环境：公司内部的以太网，与服务器的连接速率为100M，与客户端的连接速率为10/100M自适应。
2)使用两台IBM XSeries250（1G内存）PC Server作

Microsoft Cluster，安装系统软件 Windows 2000 Advance Server及

Microsoft Cluster Server（MSCS）。
3)数据库管理系统的安装及配置：在测试用的IBM XSeries服务器上安装Oracle8.1.6，数据 库采用Oracle Fail Safe（ofs）的Active/Passive配置。 安装数据库管理系统及支撑软件（包括VisiBroker和BDE Administrator）。
4)安装被测的应用服务器程序。
5)客户端的PC机：10台（PⅢ600/128M RAM）。
3.2.2系统客户端测试程序的编写系统客户端测试程序使用Delphi编写，要求测试程序实现如下功能：
1)模拟一个主要的向应用服务器发送请求并接收响应信息的功能。要求交替模拟两种情况：第一种，发送的请求至少包括10个参数，参数类型涵盖字符、日期、数字种类型；接收的 响应信息不少于1个参数；第二种，发送的请求不少于1个参数；接收的响应信息至少包括10个参数，参数类型涵盖字符、日期、数字种类型。
2)必须能够通过参数设定在每台PC机上运行的客户端测试程序个数、请求的时间间隔（单位：毫秒）、运行时间（单位：小时）。
3)在数据库中建立测试记录表，生成测试记录，向数据库写入测试记录的功能不通过被测的应用服务器实现。日志内容包括：发送测试请求的机器名、客户端测试程序序号、发出请求时间、收到响应时间、处理是否成功。表名：TEST_LOG，字段名：MACHINE、ID、START_TIME、END_TIME、FLAG。
3.2.3系统本底数据的准备
为考察系统运行一段时间后系统的响应性能，参照实际运行情况及发展进行系统的本底数据准备。业务处理中涉及到的业务表中都要求按设计规模进行本底数据的准备。要求准备的数据记录的有效性符合系统要求，数据有效性的具体要求参见数据库设计及系统设计文档。
3.3破坏性测试
按照设计连接的客户端连接数量进行测试，把应用服务器处理请求的设计频度增加1－10倍，分别测试出现错误的状态和和出现错误的比率，考察是否出现不可恢复错误，系统设计要考 虑出现严重错误情况下负荷减轻错误自动恢复的实现方法。
计划时间：2天；这个时间包括破坏性的修复和自动恢复的实现需要的时间。
在测试过程中每10分钟记录一次IBM Xseries PC Server的内存及CPU使用情况，包括被测程序的内存占用百分比、数据库管理系统的内存占用百分比、操作系统的内存占用百分比。
3.4强度稳定性测试
选择一种负荷比设计负荷重的情况（应用服务器处理请求的频度为应用服务器处理请求的
设计频度的1.5倍），进行24小时稳定性测试。
3.5测试方法和工具
黑盒测试
测试工具：无外购的测试工具，自己编制的测试工具。
3.6测试时间计划
3.6.1环境准备：2天。
其中：基本硬件、软件环境及系统本底数据的准备：1天，
系统客户端测试程序的编写及测试：1天。
3.6.2破环性测试：2天。
3.6.3强度稳定性测试：1天。
3.7测试中的问题及处理
3.7.1暂停标准和再启动要求
暂停标准：被测试软件在强度稳定性测试中频繁出现异常（每小时出现1次以上）时。用户或公司要求暂停测试时。
再启动要求：通过调试后，预计被测试软件的可靠性有所提高时，可再次启动测试。
3.7.2不可预见问题
不可预见问题包括：
◇测试环境被破坏而导致测试无法进行；
◇当出现上述不可预见问题时，测试终止，就已完成的测试内容编制测试总结报告，并在报告中说明测试终止的原因。
3.8测试报告 2002.06.21
测试总结报告提交日期：2002.06.21。
3.8.1应生成的测试文件
测试记录（测试负责人和参与测试的人员签字）；
测试总结报告。
3.8.2测试总结报告中必须包含的内容
被测试软件名称、测试项、测试环境；
被测试软件的压力测试结论：响应时间、最大/最小并发数、失败的次数、正常连续运行的最长/最短时间，并发数与失败的关系。
4、人员和职责
4.1职责
测试工程师：负责编写测试计划，组织测试，对测试过程进行记录，收集、整理测试记录数据，对测试结果进行分析，编写测试总结报告。
软件工程师：负责编写、调试客户端测试软件；数据库管理系统的安装、ofs配置及系统的本底数据准备。
系统工程师：负责测试用的硬件维护及操作系统安装、MSCS配置。
总工程师：负责对测试计划及测试总结报告进行批准。
用户：必要时可参加测试，并提出具体的测试要求；可要求暂停测试。
4.2人员和训练要求
本次测试无特别的人员及培训要求。
5、批准