软件测试工具的分类和选择

 测试工具的分类和选择

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

　　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) 没有进行有效的测试工具的培训

　　测试工具的使用者必须对测试工具非常了解，在这方面，有效的培训是必不可少的。测试工具的培训是一个长期的过程，不是通过一两次讲课的形式就能达到良好的效果。而且，在实际的使用测试工具的过程中，测试工具的使用者可能还存在着这样那样的问题，这也需要有专人负责解决，否则的话，对于测试工具使用者的积极性是很大的打击。

　　我公司在进行测试工具的培训时，进行了一个系列的培训和交流，从针对开发高层的《测试工具基本概念培训》到针对测试工具实际使用者的《测试工具使用培训》，再到交流性质的《测试工具应用交流研讨会》，再到定期发出的《测试工具应用问答》，在这方面下了很大的功夫，目前测试工具的应用已经成为了开发人员和测试人员的基本功