项目中测试工具的应用(2)

　　除了基本的功能之外，以下的功能需求也可以作为选择测试工具的参考：

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

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

　　3) 操作系统和开发工具的兼容性;测试工具可否跨平台，是否适用于公司目前使用的开发工具，这些问题也是在选择一个测试工具时必须考虑的问题。

　　ii. 价格

　　除了功能之外，价格就应该是最重要的因素了。说句题外话，在论坛上经常看到有人沾沾自喜的说我已经破解了XX测试工具这样的话，对这种态度我十分不赞成。如果作为软件从业者的我们都不能尊重别人的劳动，那有怎么能够指望我们的客户尊重我们的劳动呢?况且，测试工具的价格并不是真的昂贵到不能承受的程度，例如Numega的DevPartner一个固定license是两万多元人民币，对一个中型的公司来说完全可以承受。

　　iii. 测试工具引入的目的是测试自动化，引入工具需要考虑工具引入的连续性和一致性

　　测试工具是测试自动化的一个重要步骤之一，在引入/选择测试工具时，必须考虑测试工具引入的连续性。也就是说，对测试工具的选择必须有一个全盘的考虑，分阶段、逐步的引入测试工具。

　　3、 测试工具在测试过程中的应用

　　前面已经对测试工具的分类、测试工具的选择进行了一些描述，这里，我还想就测试工具在测试过程中的应用说一点自己的看法。

　　对测试工具能够发挥的作用大家都已经了解并认可了，但是很多引入测试软件的公司并没有能够让测试软件发挥应有的作用，其主要原因我总结为三个方面：

　　a) 没有考虑到公司的实际情况，盲目引入测试工具

　　首先我们要明确一点，并不是每种测试工具都适合公司目前的实际情况。我见过一些公司怀着美好的愿望花了不小的代价引入测试工具，半年一年以后，测试工具却成了摆设，成了引入者心头的痛。究其原因，就是没有能够考虑公司的现实情况，不切实际地期望测试工具能够改变公司的现状，从而导致了失败。

　　例如，如果一个公司所开发的软件属于工程性质的软件，在整个开发过程中需求和用户界面变动较大，这种情况下就不适合引入黑盒测试软件，因为黑盒测试软件的基本原理是录制/回放，对于不停变化的需求和界面，可能修改和录制脚本的工作量还大过测试实施，运用测试工具不但不能减轻工作量，反而加重了测试人员的负担。

　　我公司引入测试工具时比较成功的(至少从目前来看)，针对我公司的应用项目都存在需求、界面变动比较频繁的情况，我们暂时没有引入黑盒测试工具，主要依靠白盒测试工具提升代码质量。目前我们引入的测试工具包括Compuware的DevPartner和Telelogic的Logiscope，这两个工具在测试阶段和维护阶段发挥了应有的作用。

　　b) 没有形成一个良好的使用测试工具的环境

　　换句话说，就是没有能够形成一种机制让测试工具真正能够发挥作用。例如，白盒测试工具的一般使用场合是在单元测试阶段，而单元测试是由开发人员完成，如果没有流程来规范开发人员的行为，在项目进度压力比较大的情况下，开发人员很可能就会有意识地不使用测试工具，来逃避问题。在这种情况下，就必须形成一种有约束力的机制来强制对测试工具的使用。

　　将测试工具的使用明确定义进公司的开发流程，我认为是一种比较好的方式。我们目前的做法是在开发流程中明确说明，在项目里程碑提交的文档中必须包括测试工具生成的报告，该报告中的数据是决定项目是否合格的依据。根据我公司的实际情况，在提交集成测试时需要提交DevPartner工具生成的测试覆盖率报告、Logiscope生成的代码质量报告，并且要求单元测试的代码覆盖率必须达到80%以上，代码质量评价必须在Fair以上。

　　c) 没有进行有效的测试工具的培训

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

原文转自：http://www.uml.org.cn/Test/200807232.asp