测试工具引入的误区

ivanland

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

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

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

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

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

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

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

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

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

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

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