（7）、覆盖测试 C-Cover C-Cover是一个测试工具软件，用来找出没有被测到的代码，并报告测试的覆盖率。C-Cover 只支持C/C++的代码覆盖率分析，其它语言不支持。但不受OS的限制 单元测试方面：（对开发人员比较有用）J-Unit工具。 功能测试方面：E-test是个不错的选择，功能很强大，由于不是采用PostURL的方式回放脚本，所以可以支持多内码的测试数据（当然要程序支持）。基本上可以应付大部分的WebSite。 如果只是利用脚本回放代替手工劳动，或者做对页面响应数的性能测试，MicrosoftWebApplicationStressTool是个不错的选择。 另外，在性能测试方面，PureLoad也是一个不错的工具，完全用Java写成，可以测试各种C/S程序，如SMTPServer等。这两个工具都是使用PostURL的方法测试WebApplication的。对大量使用JavaScript的页面不太适合。当然，如果程序在Unix，linux下面运行的话，可以直接编写Shell脚本程序，更加方便。 另外，还有很多专门的工具，比如说Linkbot是专门作页面链接测试的。 另外，测试流程管理工具也有不少，个人用过也一直在用的是TestPlanControl，短小精悍，不错。至于WinRunner和LoadRunner之类，因为没有License，所以都没怎么用过，惭愧。不过我看过一篇英国人评价英国测试市场上最流行的五个软件的文章。WinRunner得分最高。 测试工具从测试的方法上可以分为两种：白盒测试和黑盒测试白盒测试工具主要有： 内存资源泄漏检查：Numega中的bouncechecker，Rational的Purify等 代码覆盖率检查：Numega中的truecoverage，Rational的Purecoverage，Telelogic公司的logiscope，Macabe公司的Macabe等代码性能检查：Numega中的truetime，Rational的Quantify等 代码静态度量分析质量检查工具：logiscope和Macabe等 黑盒测试工具主要有：客户端功能测试：MI公司的winrunner，compuware的qarun，Rational的SQArobot等等 服务器端压力性能测试：MI公司的winload，compuware的qaload，Rational的SQAload等等 Web测试工具：MI公司的Astra系列，rsw公司的e-testsuite等等 测试管理工具：rational的testmanager，compuware的qadirector等等，此外还有缺陷跟踪工具trackrecord等。 数据库测试工具：TestBytes 黑盒测试工具：QACenter、SQATeamTest，RationalViaualTest。 回归测试工具：RationalTeamTest，WinRunner（MI公司） WEB系统测试工具：TEST，Workberch，WebAppicationStressTool（WAS） 白盒测试工具：Numega、PuRe、软件纠错工具（RationalPurity）。 嵌入式测试工具：Logiscope（静态测试工具）、CodeTest。 系统负荷测试工具：RationalPerformance 涵盖测试工具范围评估工具 软件性能测试工具：LoadRunner（MI产品）、RationalVisualQantify 测试管理工具：TestDirector（MI产品支持整个生命周期中测试流程管理） 测试基于Web的应用程序 测试web应用程序和测试桌面系统用很多共同点：例如你需要和执行所有标准测试类型一样测试常见的功能点，配置及兼容性。但是由于与应用程序交互的所有分布式系统组件的复杂性成倍的增加的原因，导致web应用程序测试更加的困难。当我们在web环境中看到一个错误时，通常很难指出错误发生的地方，并且由于我们看到的行为或我们接受到的错误信息可能是发生在Web系统中不同部分的错误的结果。错误可能是很难重现的。那么我们如何在web系统中分析错误呢，并且为了重现那些错误又应该做哪些考虑呢？ 4．哪个层真正的引起了那个问题？ 在Web系统中的错误通常是很难一直重现因为许多由C/S架构的分布式特性而引入的许多变量。（例如，服务器，客户端和网络组件）。在一个web环境中至少由3个常见的怀疑部分：客户端，服务器和网络。客户端和服务器都会携带诶之和兼容性问题，那些和PC环境相似，所有的组件都在一个盒子里。在C/S系统里，问题成倍的增长，然而，由于可能有很多的客户端和服务器链接在一个网络中。典型的C/S配置和兼容性问题涉及到硬件和操作系统的混合（例如，基于UNIX的vs基于windows的盒子）以及在服务器端的软件组合（Web服务器包，数据库服务器包，防火墙，COM对象，CORBA对象等等）。问题也可能涉及客户端的软件组合（TCP/IP堆栈，拨号软件，帮助组件，浏览器带宽和浏览器版本）。另外，浏览器设置，例如一些常见的设置，连接设置，安全设置（包括ActiveX空间，插件，Java，脚本，下载，用户认证等等），内容设置，程序设置，和其他高级设置（包括浏览器选项，多媒体选项，JVM选项，打印选项和HTTP选项）引入很多可以被测试并分析的变量。 网络提供了另一套变量。网络用几个方式影响着Web应用程序，包括由于带宽和响应时间引起的分时相关的问题（竞态条件，性能，超时等等），由于硬件设备例如网关和路由器导致的潜在的配置和兼容性问题，以及和安全实现相关的端问题。 5．静态和动态操作环境是不同的 一般来说，有两类操作环境－每个都有自己独一无二的测试牵连： 静态环境（例如配置和兼容性错误）不兼容性问题可能存在其中，不管可变的条件，例如处理速度和可用的内存 动态环境（例如资源及时间相关的错误）其他方面可兼容的组件可能出现错误在其中，由于内存相关的错误和反应时间条件（我们将在这一节中更详尽的探讨动态环境） 静态操作环境：配置和兼容性变量 配置和兼容性问题可能会出现在web系统中的任何一个点上：客户端，服务器端，或网络中。配置问题包括不同的服务器软件和硬件设置，浏览器设置，网络连接，和TCP/IP堆栈设置。浏览器设置/前面提到的JavaScript例子说明了配置问题的一种类型。 我们用来示范的所测试应用程序有一些制图的功能，可以让用户生成度量报告，例如条形图和直线图。当用户请求一个度量报告时，应用程序服务器执行的伪码如下： 1．连接服务器并运行查询， 2．编写查询结果到一个名为c：\temp\chart.val的文件中， 3．执行Chart的JavaApplet。从c：\temp\chart.val文件中读取数据以生成一个图表 4．发送JavaApplet到浏览器 在测试这个应用程序过程中，我发现图表功能可以在以上的配置上运行，但是却不能在其他配置上工作。在我更进一步的研究之后，我认识到问题可能出现在two-box配置中。在检查代码之后，我认识到问题在步骤2和3中。在步骤2中，查询结果被写到数据库服务器本地驱动器中c：\temp\chart.val。在步骤3里，ChartJavaApplet是运行在应用服务器上而不是和数据库服务器在一个相同的盒中。当它试图在应用服务器本地驱动器中打开c：\temp\chart.val文件时，文件并不存在。 在这个用例中，我不建议在遇到问题时就阅读代码，我把调试的工作留给开发人员。我只不过想指出识别哪个服务器配置是有问题的，并且在bug报告中含括这些信息。我也会在测试下的应用程序支持的全部的分别式配置下运行一个粗略的测试用例包。 配置问题在静态操作环境中也是很终于的。 这个例子并不是要说IE比NetscapeNavigator更好，它只不过意味着在浏览器之间有不兼容性问题－并且代码应该假设相对路径在所有的浏览器中都可以工作。更重要的是，它建议当你在一个环境中发现一个错误时，如果它是一个环境相关的错误的话，同样的错误可能不会出现在不同的环境中。 动态的操作环境：事情不会保持一样 当特定环境的属性值不是每次都在测试过程中保持常量时，它会引起操作环境变为动态。属性可以从资源特定（可用的RAM，磁盘空间等）转变为时间特定的（网络反应时间，用户要提交的交易顺序等）。 当一个测试用例取决于步骤集和操作环境的准确复制，然而（由于它的动态本质）操作环境不可能被复制，错误变得不可重现或很难重现。 顺便说一下，这也是内存相关错误通常较难重现的原因。当一个内存覆盖的错误出现在代码中时，例如，它常常会引起一个内存覆盖的问题。然而，从一个黑盒测试的角度看，我们永远没有机会看到这个错误的症状直到执行或读取特定的代码或数据溢出字节。在这个例子中，步骤集代表了黑盒测试的准确集合。内存覆盖错误代表了在代码中的真实的错误。被执行或读取的被覆盖的字节的条件代表了动态的操作环境或需要揭露（重现）错误的条件。 |
