工具却成了摆设。究其原因,就是没有能够考虑公司的现实情况,不切实际地期望测试工具能够改变公司的现状,从而导致了失败。
例如,国内多数软件公司是针对最终用户进行项目开发--工程性质的软件,而不是产品开发。项目开发周期短,不同的用户需求不一样,而且在整个开发过程中需求和用户界面变动较大,这种情况下就不适合引入黑盒测试软件,因为黑盒测试软件的基本原理是录制/回放(虽然通过修改,形成结构化测试脚本),对于不停变化的需求和界面,可能修改和录制脚本的工作量大大超过测试实施的工作量,运用测试工具不但不能减轻工作量,反而加重了测试人员的负担。这种情况下可以考虑引入白盒测试工具,以提升代码质量。
6. 没有形成一个良好的使用测试工具的环境
建立良好的测试工具应用环境,需要测试流程和管理机制做相适应的变化,也只有这样,测试工具才能真正发挥其作用。例如,对于基于 GUI 录制/回放的自动测试来说,产品界面的改变对脚本的正常运行影响较大。再者,白盒测试工具的一般在单元测试阶段使用,而单元测试在多数公司是由开发人员自己完成,如果没有流程来规范开发人员的行为,在项目进度压力比较大的情况下,开发人员很可能就会有意识地不使用测试工具,来逃避问题。所以,有必要将测试工具的使用在开发和测试的流程中明确起来,如在项目各个里程碑所提交的文档中,必须包含某些测试工具生成的报告,如集成测试时DevPartner工具生成的测试覆盖率报告、Logiscope生成的代码质量报告等。
<!--[if !supportLineBreakNewLine]-->
<!--[endif]-->
7.其它技术问题和组织问题
软件测试自动化所需要的测试脚本其维护量很大,而且软件产品本身代码的改变也需要遵守一定的规则,从而保证良好的测试脚本使用重复性,也就是说测试自动化和软件产品本身不能分离。
其次,提供软件测试工具的第三方厂家,对客户的应用缺乏足够理解,很难提供强有力的技术支持和具体问题的解决能力。也就是说,软件测试工具和被测试对象—软件产品或系统的互操作性会存在或多或少问题,加之技术环境的不断变化,所有这些对测试自动化的应用推广和深入,都带来很大的影响。
还有安全性的错觉,如果软件测试工具没有发现被测软件的缺陷,并不能说明软件中不存在问题,可能测试工具本身不够全面的问题或测试的预期结果设置不对。
来源: http://tb.blog.csdn.net/TrackBack.aspx?PostId=801381