《目前市场主流的测试工具和管理软件(开源).doc》由会员分享，可在线阅读，更多相关《目前市场主流的测试工具和管理软件(开源).doc（7页珍藏版）》请在金锄头文库上搜索。
1、目前市场主流的测试工具和管理软件，如Rational和Mercury的系列产品，大多比较昂贵。 商业软件的优势主要表现在其售后服务和工具本身的强大和易用性上，而作为技术基础相对较好的测试人员，也可考虑使用开源的软件，这将为公司节省一大笔开支，必要时也有更好的扩展自由度。 开源测试工具功能测试工具 Linux Test Project http:/ 工具描述: Linux Test Project是一个测试Linux内核和内核相关特性的工具集合。该工具的目的是通过把测试自动化引入到Linux内核测试，提高Linux的内核质量。 使用环境: Linux MaxQ http:/maxq.tigris
2、.org/ 工具描述: MaxQ是一个免费的功能测试工具。它包括一个HTTP代理工具，可以录制测试脚本，并提供回放测试过程的命令行工具。测试结果的统计图表类似于商用测试工具，比如Astra QuickTest和Empirix e-Test，这些商用工具都很昂贵。MaxQ希望能够提供一些关键的功能，比如HTTP测试录制回放功能，并支持脚本。 使用环境: Java 1.2以上版本 WebInject http:/www.webinject.org/ 工具描述: WebInject是一个针对Web应用程序和服务的免费测试工具。 它可以通过HTTP接口测试任意一个单独的系统组件。可以作为测试框架管理功
3、能自动化测试和回归自动化测试的测试套。 使用环境: Windows, OS Independent, Linux 开源测试工具性能测试工具 Apache JMeter http:/jakarta.apache.org/jmeter/ 工具描述: Apache JMeter是100的Java桌面应用程序，它被设计用来加载被测试软件功能特性、度量被测试软件的性能。设计Jmeter的初衷是测试Web应用，后来又扩充了其它的功能。Jmeter可以完成针对静态资源和动态资源（讹误女监, Servlets, Perl脚本, Java对象, 数据查询s, FTP服务等）的性能测试。 Jmeter可以模拟大量
4、的服务器负载、网络负载、软件对象负载，通过不同的加载类型全面测试软件的性能。Jmeter提供图形化的性能分析。 使用环境: Solaris, Linux, Windows (98, NT, 2000). JDK1.4以上. DBMonster http:/dbmonster.kernelpanic.pl/ 工具描述: DBMonster是一个生成随机数据，用来测试SQL数据库的压力测试工具。 使用环境: OS Independent OpenSTA (Open System Testing Architecture) http:/portal.opensta.org/index.php 工具描
5、述: 基于CORBA的分布式软件测试构架。使用OpenSTA，测试人员可以模拟大量的虚拟用户。 OpenSTA的结果分析包括虚拟用户响应时间、web服务器的资源使用情况、数据库服务器的使用情况，可以精确的度量负载测试的结果。 使用环境: OS Independent TPTEST http:/ 工具描述: TPTest的提供测试Internet连接速度的简单方法。 使用环境: MacOS/Carbon、 Win32 Web Application Load Simulator http:/www.openware.org/loadsim/index.html 工具描述: LoadSim是一个网
6、络应用程序的负载模拟器。 使用环境: JDK 1.3以上 开源测试工具缺陷管理工具 Mantis http:/ 工具描述: Mantis是一款基于WEB的软件缺陷管理工具，配置和使用都很简单，适合中小型软件开发团队，关于Mantis的介绍文章参见51testing软件测试网顾问蔡琰的文章 使用开源软件 Mantis 实施缺陷跟踪的成功实践 使用环境: MySQL, PHP Bugzilla http:/www.mozilla.org/projects/bugzilla/ 工具描述: 一款不错的软件缺陷管理工具。 使用环境: TBC 开源测试工具测试管理工具 TestLink http:/ 工具
7、描述: 基于WEB的测试管理和执行系统。测试小组在系统中可以创建、管理、执行、跟踪测试用例，并且提供在测试计划中安排测试用例的方法。 使用环境: Apache, MySQL, PHP Bugzilla Test Runner http:/ 工具描述: Bugzilla Test Runner基于Bugzilla缺陷管理系统的测试用例管理系统。 使用环境: Bugzilla 2.16.3 or above代码实践下图展示了两段相同功能的代码，在重构前后的结构示意图。ProfileConf直接使用了第三方SNMP协议包，而ProfileConfNew则使用了封装后的SNMP协议软件包。进行协议封装
8、的目的一是为了隔离第三方软件包，另一个目的是为了简化客户端使用SNMP协议栈的操作。改造完成后，我们使用Together自带的软件测量工具进行了数据测量。选择Together菜单中toolsmetrics，里面提供了大量的测量指标。我们选择了几个比较关注的指标，对新旧代码进行了测量，下面是测量结果。下表对测量指标做简单说明。 通过数据可以看出，改进以后，编写的代码有所减少，大约节省三分之一的代码；耦合度有所降低，但并不是特别明显，因为我们把对第三方协议包的依赖转为对自己编织的协议包的依赖了；代码复杂度大大降低，这是因为我们自己编写的协议包更符合实际使用情况，因而使代码编写难度大大降低，非常容易
9、学习，修改和维护。数据说明了一切。总结软件度量最终的目标是要提供统一衡量软件质量的标准，并促使软件质量的不断提高，这项任务被人称为是“寻找圣杯的任务”。但是，无数的科学事实都说明，如果因为目标太难达到就不作任何工作，就不可能有任何进步。在达到最终目标之前的过程中，会有很多有益的小发现，这些发现又在不断促进新的发现，最后使不可能变成可能。软件度量科学的发展同样在追求最终目标的过程中为我们带来了众多的有益发现，让我们用更加科学和严谨的态度来看待软件质量问题；让我们对代码的认识从定性描述阶段，进入到定量描述阶段；让我们感受到科学和美学的统一所展现出的巨大魅力。三、CheckStyle的最佳实践 3.
10、1. Suns Code Conventions的修改 在CheckStyle的最新发布版本中，有一个对于Sun的Java编码规范的配置文件信息。但是，其中有很多条目并不一定符合项目开发的需要。就算是对于很多优秀的开源项目，按照这个规范来进行检查，也会出现成千上万的错误。 下面提出的一些修改意见，是从实际项目执行过程中总结出来的，可以作为大家的参考。我们以CheckStyle3.0配置文件的顺序来介绍： 1. 去除对于每个包都有一个package.html文件的限制； !-module name=PackageHtml/- 2. 修改对于JavaDoc Comments的限定：对于很多使用Co
11、de Generator的项目来说，需要将手写代码与生成代码、单元测试代码的检查分开进行； 3. 修改对于体积大小的限制：目前，很多显示器都是17寸，而且打印方面的限制也比以前有所改善，同时，由于代码中Factory等模式的运用，以及有意义的方法名称等约定，默认每行代码的长度（80）是远远不能满足要求；对于方法长度等等，也应该根据项目情况自行决定： module name=FileLength/ module name=LineLength property name=max value=120/ /module module name=MethodLength property name=m
12、ax value=300/ /module module name=ParameterNumber/ 4. 修改对于Throws的的限制：允许Throws Unchecked Exception以及Throws Subclass Of Another Declared Exception。 module name=RedundantThrows property name=allowUnchecked value=true/ property name=allowSubclasses value=true/ /module 5. 修改成员变量的可视性：一般情况下，应该允许Protected M
13、embers以及Package Visible Members。 module name=VisibilityModifier property name=protectedAllowed value=true/ property name=packageAllowed value=true/ /module 3.2. CheckStyle应用的最佳实践 采用CheckStyle以后，编码规范的检查就变得及其简单，可以作为一项切实可行的实践加以执行。 一般情况下，在项目小组中引入CheckStyle可以按照下面的步骤进行： 1 强调Code Review与Code Conventions的重要作用； 2 介绍CheckStyle； 3 初步应用CheckStyle：参照CheckStyle附带的配置文件，酌情加以剪裁，在项目的Ant配置文件中，添加CheckStyle任务，可以单独执行； 4 修改、定型CheckStyle的配置文件：按照基本配置文件执行一段时间（23周），听取开发人员的反馈意见，修改配置信息； 5 作为开发过程的日常实践，强制执行CheckStyle：稳定CheckStyle的配置信息，同时将CheckStyle任务作为Build的依赖任务或者配置源码控制系统（目前，CheckStyle可以与CVS有效集成
