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