1. 不正确的观念或不现实的期望 没有建立一个正确的软件测试自动化的观念,或操之过急,或认为测试自动化可以代替手工测试,或认为测试自动化可以发现大量新缺陷,或不够重视而不愿在初期投入比较大的开支等。多数情况下,对软件测试自动化存在过于乐观的态度、过高的期望,人们都期望通过这种测试自动化的方案能解决目前遇到的所有问题。而同时测试工具的软件厂商自然会强调其工具的优势、有利的或成功的一面,可能对要取得这种成功所要做出持久不懈的努力和困难却只字不提。结果,最初的期望,便得不到实现。
2.缺乏具有良好素质、经验的测试人才 有些软件公司舍得花几十万元去买测试工具软件,但缺乏具有良好素质、经验的测试人才。软件测试自动化并不是简简单单地使用测试工具,还需要有良好的测试流程、全面的测试用例(Test case)等来配合脚本的编写,这就要求测试人员不仅熟悉产品的特性和应用领域、熟悉测试流程,而且很好地掌握测试技术和编程技术。
3.测试工具本身的问题影响测试的质量
一般不会对自动测试脚本再做大规模的测试,所以自动测试脚本的质量往往依赖于TA工程师的经验和工作态度,如果自动测试工具不能提供一种机制来保证脚本的的质量,那将直接影响到测试结果的正确性。
通过自动测试工具测试的Test Case是不需要再进行手工测试的,将自动测试与手工测试有效的结合,并在最终的测试报告中也体现自动测试的结果,是比较正确的做法。
4.没有进行有效的、充分的培训 人员和培训是相辅相成的,如果没有良好的、有效的、充分的培训,测试人员对测试工具了解缺乏深度和广度,从而导致其使用效率低下,应用结果不理想。这种培训是一个长期的过程,不是通过一两次讲课的形式就能达到效果。而且,在实际的使用测试工具的过程中,测试工具的使用者可能还存在着这样那样的问题,这也需要有专人负责解决,否则的话,会严重影响测试工具的使用积极性。
5. 没有考虑到公司的实际情况,盲目引入测试工具
有一点很明确,不同的测试工具面向不同的测试目的、具有各自的特点和适用范围,所以不是任何一个优秀的测试工具都能适应不同公司的需求。某个公司怀着美好的愿望花了不小的代价引入测试工具,半年一年以后,测试工具却成了摆设。究其原因,就是没有能够考虑公司的现实情况,不切实际地期望测试工具能够改变公司的现状,从而导致了失败。
例如,国内多数软件公司是针对最终用户进行项目开发--工程性质的软件,而不是产品开发。项目开发周期短,不同的用户需求不一样,而且在整个开发过程中需求和用户界面变动较大,这种情况下就不适合引入黑盒测试软件,因为黑盒测试软件的基本原理是录制/回放(虽然通过修改,形成结构化测试脚本),对于不停变化的需求和界面,可能修改和录制脚本的工作量大大超过测试实施的工作量,运用测试工具不但不能减轻工作量,反而加重了测试人员的负担。这种情况下可以考虑引入白盒测试工具,以提升代码质量。
6. 没有形成一个良好的使用测试工具的环境 建立良好的测试工具应用环境,需要测试流程和管理机制做相适应的变化,也只有这样,测试工具才能真正发挥其作用。例如,对于基于 GUI 录制/回放的自动测试来说,产品界面的改变对脚本的正常运行影响较大。再者,白盒测试工具的一般在单元测试阶段使用,而单元测试在多数公司是由开发人员自己完成,如果没有流程来规范开发人员的行为,在项目进度压力比较大的情况下,开发人员很可能就会有意识地不使用测试工具,来逃避问题。所以,有必要将测试工具的使用在开发和测试的流程中明确起来,如在项目各个里程碑所提交的文档中,必须包含某些测试工具生成的报告,如集成测试时DevPartner工具生成的测试覆盖率报告、Logiscope生成的代码质量报告等。
7.其它技术问题和组织问题 软件测试自动化所需要的测试脚本其维护量很大,而且软件产品本身代码的改变也需要遵守一定的规则,从而保证良好的测试脚本使用重复性,也就是说测试自动化和软件产品本身不能分离。
其次,提供软件测试工具的第三方厂家,对客户的应用缺乏足够理解,很难提供强有力的技术支持和具体问题的解决能力。也就是说,软件测试工具和被测试对象—软件产品或系统的互操作性会存在或多或少问题,加之技术环境的不断变化,所有这些对测试自动化的应用推广和深入,都带来很大的影响。
还有安全性的错觉,如果软件测试工具没有发现被测软件的缺陷,并不能说明软件中不存在问题,可能测试工具本身不够全面的问题或测试的预期结果设置不对。
|