软件测试的重要性讲解
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
软件测试的重要性
前言:软件迅猛发展凸现软件测试问题
随着软件业蓬勃发展,各种软件需求纷繁而来,在潮起潮落的IT洪流中,软件项目越来越凸现大型化、复杂化的发展趋势。几十人上百人的开发团队、成千上万的模块与接口、跨地域、跨系统的使用用户等情况早已屡见不鲜,所有这些,对项目质量管理提出了更高要求,如何满足各方需求,做出更好的软件系统?测试管理逐渐成了大家目光的焦点。
软件的质量靠什么,靠管理、靠各个软件过程的严密配合。但勿庸置疑,质量的守护是靠测试。它就象一只看门狗,认真守护着软件质量这个“家”。
软件测试的重要性
测试是什么?测试就是对项目开发过程的产品(编码、文档等)进行差错审查,保证其质量的一种过程。
软件业的迅猛发展也就是近几十年的过程,时间虽短,但许多误解似乎已根深蒂固,对测试的偏见也是如此。“软件的重点在于需求、在于分析、在于设计、在于开发,而测试,容易,没什么技术含量,找一些用户,对照需求尽力去测就行了;有时间多测点,没时间就少测点。”这种看法在许多项目经理、软件负责人的心中固守着,难以改变。
这种观念的结果有目共睹,是什么?很简单,是大量软件BUG、缺陷的“流失”,从测试人员手中悄然而过,流失到用户手中,流失进项目维护阶段。随之而来的,便是用户无休止的抱怨、维护人员无休止的“救火”、维护成本无休止的增加。这是软件人员的梦魇!
恶梦总有醒来时,经过无数教训的重击,在不堪回首而不得回首的经历中,软件业的管理者
发现:是他们错了,软件测试是不可忽视的。
“所有这些问题,假如在项目中测试到的话,便不会有造成不可收拾的结果了。”――人们终于意识到测试简单而纯真的真谛。
软件测试
软件测试从直观上来讲是对测试对象进行检查、验证,似乎很简单,但实际不然,它是由许多处理环节构成的。根据测试目标、质量控制的要求,它被划分为以下各类环节(如下图),并被设置了不同的准入、准出标准。
测试的主要过程及活动如上图所示,容一目了然,在此就不一一详述了,只希望通过对测试重点问题、关注热点的介绍,帮助大家对测试管理有一个总体的把握。
测试方式中普遍存在的问题与点评
谈到测试,我们无法回避的是当前软件过程普遍存在的测试问题:
1、手工过多,缺少测试工具,自动化测试方式缺失。
传统的项目测试还是以手工为主,测试人员根据需求规格说明书的要求,与测试对象进行“人机对话”。随着软件业的不断发展及软件规模的扩大,这种测试的弊端日益明显:·大量的手工使项目人力成本、沟通成本居高不下;
·人工操作的低效率使项目耗时增加,带来进度风险;
·人员素质及其他不确定因素会影响手工测试的结果,导致差错率的增加。
·在测试过程中,需要对测试案例库进行统一配置管理,项目规模的激增使手工管理案例库的难度日益加大,尤其是在需求变更、回归测试频繁发生的时候。
从古到今,当生产率阻碍了生产力的发展的时候,必然会引入更高级的生产工具及方式。项目测试也是这个道理,引入工具,引入自动化测试及管理,是项目测试的一大趋势。
2、缺乏文档测试、检查。
文档是项目的重要产品之一,产品需求、功能分析、架构设计、详细设计、用户手册、维护手册等等,对于项目的测试、上线、维护等过程起到至关重要的参考、指导作用,所以它们的质量应该是项目重点关注点之一。令人遗憾的是,许多软件项目对于文档的重视只停留在口头上,“编码第一”的观念似乎根深蒂固。
随着需求不断变更、补充,业务、技术人员忙于应付,无法腾出精力来进行文档容的修改及完善,往往是将包含需求变更容的工作联系单往需求文档后一附了事,而不去更新需求与其他相关文档;另一方面,项目变更管理还不够完善,管理重点往往集中于开发,而轻视文档
质量管理,未留出充分的文档更新时间,导致文档更新严重滞后于编码进度。为保证文档质量,必须定期进行文档测试,但测试要花成本,项目高层不愿意付此代价。
文档若可读性低,便会影响用户的理解;若与编码不一致,便起不到参考作用,编码测试就没有可靠的测试依据。路都看不清楚,怎么往前走呀?所以,强烈建议进行文档测试,并将其置于测试管理的首位。
当前文档测试的方法没有什么特别的形式,还缺乏测试工具支持,通常是通过静态审查方式――“走查”来进行的,主要查看文档的可读性,容真实性、可靠性、全面性。另外,在项目里程碑时期召集相关领域专家对重要文档进行集中审核,也是一种检查方式。
3、单元测试应引入交叉测试方法;
单元测试是对软件基本组成单元进行的测试,测试对象是软件模块。通常,单元测试是由开发人员来完成,而且往往是各人测各人的。这存在问题隐患。
为什么呢,技术人员是软件模块的制造者,自己来测自己的软件的话,角色便从制造者变成了审查者,而前一个角色的目的是为了保证软件正确,后一个角色的目的是为了发现更多的缺陷,让一个人同时来扮演两种目的不同的角色,好比让他既当裁判员又当运动员,怎么能做好呢?
解决方法通常有两种,一种是:由测试人员来进行单元测试,这种方式要求测试人员要有较高的软件技术知识;另一种是:将软件人员分组,在模块开发告一段落时进行交叉测试,这种方法只需要测试者了解被测方的软件需求,不需要另外的知识培训,而且测试出发点较为客观,所以被较普遍的推广使用。
4、测试在开发基本完成才启动;
在传统的瀑布型开发模式中,软件测试位于编码阶段之后,是作为一个独立阶段存在的,许多人便一刀切地认为应该将所有的测试工作在编码完成后再开始。这个观点要不得,原因有二:
首先,若将测试工作细分,有许多工作是可以提前先期执行的,如:需求书与设计书的学习、测试计划的制定、测试人员的培训、测试脚本的建立、测试资源的搭建、测试模板的创建、测试工具的选择等等,都是可以与其他阶段并行处理的,这将大大缩短项目开发时间,为测试提供充分的时间保障,提高测试质量。