第01章 软件测试概述.docx
- 文档编号:4374307
- 上传时间:2022-12-01
- 格式:DOCX
- 页数:20
- 大小:266.70KB
第01章 软件测试概述.docx
《第01章 软件测试概述.docx》由会员分享,可在线阅读,更多相关《第01章 软件测试概述.docx(20页珍藏版)》请在冰豆网上搜索。
第01章软件测试概述
第1章软件测试概述
随着计算机技术的飞速发展,人们对计算机的需求和依赖与日俱增。
随之而来的是计算机系统的规模和复杂性急剧增加,其软件开发成本以及由于软件故障而造成的经济损失也正在增加,软件质量问题已成为人们共同关注的焦点。
因此,许多科学家在展望21世纪计算机科学发展方向和策略时,把软件质量放在优先于提高软件功能和性能的地位。
软件测试是对软件需求分析、设计规格说明和编码的最终复审,是软件质量保证的关键步骤。
随着软件系统规模和复杂性的增加,进行专业化高效软件测试的要求越来越严格,软件测试职业的价值逐步得到了认可,软件测试从业人员急剧增加,软件测试评测中心如雨后春笋般成长起来。
可以预测,在未来3~5年内,软件测试技术将作为一门新兴产业而快速发展起来。
1.1计算机系统的软件可靠性问题
随着对计算机需求和依赖的与日俱增,计算机系统的规模和复杂性急剧增加,使得计算机软件的数量以惊人的速度急剧膨胀。
与此同时,计算机出现故障引起系统失效的可能性也逐渐增加。
由于计算机硬件技术的进步,元器件可靠性的提高,硬件设计和验证技术的成熟,硬件故障相对显得次要了,软件故障正逐渐成为导致计算机系统失效和停机的主要因素。
下面介绍几个实例,以说明软件故障可能造成的损失和灾难,
1.千年虫问题
千年虫问题是一个众所周知的软件故障。
上世纪70年代,所使用的计算机存储空间很小,这就迫使程序员在开发工资系统时尽量节省存储空间,一个简单的方法是在存储日期时,只存储2位,如1974存储为74。
工资系统常依赖于日期的处理,因此他们节省了大量的存储空间。
他们知道在2000年到来时,问题会出现,比如银行在计算利息时,是用现在的日期如“2000年1月1日”减去客户当时的存款日期如“1974年1月1日”,如果年利息为3%,那么每100元银行应付给客户78元的利息。
如果年份存储问题没有得到纠正,其存款年数就变为-74年,客户反应付给银行利息了,这显然是不合理的。
但他们认为在20多年内程序肯定会更新或升级,而且眼前的任务比计划遥不可及的未来更加重要。
为此,全世界付出了数亿美元的代价来更换或升级类似程序以解决千年虫问题,特别是金融、保险、军事、科学、商务等领域,花费大量的人力、物力对现有的各种各样程序进行检查、修改和更新。
2.爱国者导弹防御系统
1991年,美国爱国者导弹防御系统首次应用在海湾战争中对抗伊拉克飞毛腿导弹的防御战争中。
尽管对该系统的赞誉不绝于耳,但是它确实在几次对抗导弹战役中失利,其中一枚在沙特阿拉伯的多哈击毙28名美国士兵。
分析专家发现症结在于一个软件故障。
一个很小的系统时钟错误积累起来就可能拖延14小时,造成跟踪系统失去准确度。
在多哈袭击战中,这样一个小故障造成系统被拖延100多个小时。
3.美国火星登陆事故
1999年美国宇航局火星极地登陆飞船在试图登陆火星表面时突然坠毁失踪。
故障评测委员会调查分析了这一故障,认定出现该故障的原因可能是由于某一数据位被更改,并认为该问题在内部测试时应该能够解决。
为什么会这样呢?
简单而言,火星登陆过程计划是:
飞船在火星表面降落时,着陆伞自动打开以减缓飞船的下降速度。
当飞船距离火星表面1800米时,丢弃着陆伞,点燃登陆推进器,缓缓降落到地面。
然而,美国宇航局为了节省开销,简化了关闭着陆推进器的装置,在飞船的支撑脚部安装了一个触点开关,在计算机中设置一个数据位来控制触点,以关闭飞船燃料。
显然,飞船没着陆以前,推进器就应该一直处于着火工作状态。
不幸的是,在许多情况下,当飞船的支撑脚迅速打开准备着陆时,机械震动也会触发触点开关,导致设置了错误的数据位,关闭了登陆推进器的燃料,使火星加速下降1800米后撞向地面,撞成碎片。
结果是灾难性的,但原因很简单。
事实上,飞船发射之前,经过了多个小组的测试,其中一个小组负责测试飞船支撑脚的落地打开过程,另一个小组负责测试此后的着陆过程。
其前一个小组没有检测触点开关数据位,那不是他们的职责;后一个小组总是在测试之前重置计算机,清除数据位。
两个小组工作的都很好,但从未在一起进行过集成/系统测试,接口错误没有被检测出,从而导致了这一灾难性的事故。
4.Intel奔腾芯片缺陷
在PC机的“计算器”中输入以下算式:
(41958353145727)3145727-4195835
如果答案不为0,就说明该计算机使用的是带有浮点除法软件缺陷的老式Intel奔腾处理器。
1994年,美国弗吉利亚州Lynchburg学院的一位博士在用奔腾PC机解决一个除法问题时,发现了这个问题。
他将发现的问题放在互联网上,引发了一场风暴,成千上万的人发现了同样的问题,以及其它得出错误结果的情形。
万幸的是,这种情况很少出现,仅在精度要求很高的数学、科学和工程计算中才会出现。
这个事件引起人们关注的原因并不是这个软件缺陷,而是Intel公司解决问题的态度。
●Intel的测试工程师在芯片分布之前已经发现了这个问题,但管理层认为还没严重到一定要修正,甚至公开的程度。
●当这个软件缺陷被发现时,Intel公司通过新闻发布和公开声明试图弱化问题的严重性。
●当压力增大时,Intel承诺可以更换有问题的芯片,但要求用户必须证明自己受到缺陷的影响。
结果舆论大哗。
互联网上充斥着愤怒客户要求Intel解决问题的呼声,新闻报道将Intel公司描绘成不诚信者。
最后,Intel公司为自己处理软件缺陷的行为道歉并拿出4亿多美元来支付更换芯片的费用。
由此可见,这个小小软件缺陷造成的损失有多大。
5.Windows2000安全漏洞
微软曾经承认,Windows2000操作系统远程服务软件中存在有安全漏洞,这里漏洞可能导致3种不同的安全隐患——拒绝服务、权限滥用和信息泄漏,并发布了相应的补丁软件进行修补。
拒绝服务隐患可能导致DOS受到攻击,使得合法用户无法远程登录系统;而权限滥用和信息泄漏隐患则涉及系统权限管理,有可能使攻击者控制Windows2000系统,从而在计算机上添加用户,删除或安装组件,破坏数据,或执行其它操作。
据美国军方证实,一名联机攻击者则利用微软网络软件中一个缺陷控制了其国防部的一个服务器接口。
尽管美国陆军网络技术事业部称受到攻击的军事网站不属于军方,但他们强调陆军很认真地对待这事。
这个缺陷也使微软的安全团队大吃一惊,因为没有一名安全研究人员发现这个问题,造成了很坏的影响。
巨额的财产损失和多条生命的代价让人们开始重视软件质量。
类似的例子,国内也可举出很多。
大大小小的软件故障几乎每天甚至每时每刻都在发生,只不过有些问题不那么严重罢了。
随着信息技术的飞速发展,软件产品已应用到社会的各个领域,软件质量问题已成为人们共同关注的焦点。
软件开发商为了占有市场,必须把软件质量作为企业的重要目标之一,以免在激烈的竞争中被淘汰出局。
用户为了保证自己业务的顺利完成,当然希望选用优质的软件。
质量欠佳的软件产品不仅会使开发商的维护费用和用户的使用成本大幅增加,还可能产生其他的责任风险,造成公司信誉下降。
在一些关键领域的应用系统,如民航订票系统、银行结算系统、证券交易系统、自动飞行控制软件、军事防御和核电站安全控制系统中,对软件质量提出了更高的要求。
使用质量欠佳的软件,还可能造成灾难性的后果。
勿庸置疑,提高软件质量,如同如何提高软件生产率一样,已成为整个软件开发过程中必须始终关心和设法解决的问题。
1.2软件测试的目的和意义
由于人的主观认识常常难以完全符合客观现实,与工程密切相关的各类人员之间的通信和配合也不可能完美无缺。
因此对于软件来讲,不论采用什么样的技术和方法,软件中都会有故障存在。
即使标准商业软件里也有故障存在,只是严重程度不同而已。
采用新的编程语言、先进的开发方式、完善的开发过程,可以减少故障的引入,但是我们无法完全杜绝软件中的故障。
这些软件故障就需要用测试来发现,软件中的故障密度也需要用测试来估计。
软件测试是对软件需求分析、设计规格说明和编码的终审,是软件质量保证的关键步骤。
但对于什么是软件测试,一直未达成共识,根据侧重点不同,主要有三种描述:
定义1:
1983年IEEE(国际电子电气工程师协会)提出的软件工程标准术语中给软件测试下的定义是:
“使用人工或自动手段来运行或测定某个系统的过程,其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别”。
该定义包含了两方面的含义:
1)是否满足规定的需求。
2)是否有差别。
如果有差别,说明设计或实现中存在故障,自然不满足规定的需求。
因此,这一定义非常明确地提出了软件测试以检验软件是否满足需求为目标。
定义2:
软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例,并利用这些测试用例去执行程序,以发现软件故障的过程。
该定义强调寻找故障是测试的目的。
定义3:
软件测试是一种软件质量保证活动,其动机是通过一些经济有效的方法,发现软件中存在的缺陷,从而保证软件质量。
上述三种观点实际上是从不同角度理解软件测试,但不论从哪种观点出发,都可以认为软件测试是在一个可控的环境中分析或执行程序的过程,其根本目的是以尽可能少的时间和人力发现并改正软件中潜在的各种故障及缺陷,提高软件的质量。
测试目的决定了测试方案的设计,如果我们的目的是要证明程序中没有隐藏的故障存在,那就会不自觉地回避可能出现故障的地方,设计出一些不易暴露故障的测试方案,从而使程序的可靠性受到极大的影响。
相反,如果测试的目标是要证明程序中有故障存在,那就会力求设计出最能暴露故障的测试方案。
软件测试是一项花费昂贵的活动,测试者希望通过软件测试来提高软件的质量或可靠性。
这就意味着要发现并改正程序中的错误。
所以,进行测试时不应该为了显示程序是好的,而应该从软件中含有故障这个假定出发去测试程序,从中发现尽可能多的软件故障。
因此,“一个好的测试用例在于发现至今尚未被发现的故障”,“一个成功的测试是发现了至今未被发现的故障的测试”。
1.3软件测试过程
软件测试是软件开发过程的一个重要环节,是在软件投入运行前,对软件需求分析、设计规格说明和编码实现的最终审定,贯穿于软件定义与开发的整个期间。
软件项目一开始,软件测试随之开始。
从软件需求分析到最终的验收测试,其整个测试过程如图1.1所示。
从测试过程可以看出,软件测试主要由一系列不同的测试阶段组成,即单元测试、集成测试、确认测试、系统测试和验收测试。
软件开发是一个自顶向下逐步细化的过程。
软件测试则是依相反顺序的自底向上逐步集成的过程。
低一级的测试为上一级的测试准备条件。
单元测试是测试执行的开始阶段,即首先对每一个程序模块进行单元测试,以确保每个模块能正常工作。
单元测试大多采用白盒测试方法,尽可能发现并消除模块内部在逻辑和功能上的故障及缺陷。
然后,把已测试过的模块组装起来,形成一个完整的软件后进行集成测试,以检测和排除与软件设计相关的程序结构问题。
集成测试大多采用黑盒测试方法来设计测试用例。
确认测试以规格说明书规定的需求为尺度,检验开发的软件能否满足所有的功能和性能要求。
确认测试完成以后,给出的应该是合格的软件产品。
但为了检验开发的软件是否与系统的其它部分(如硬件、数据库及操作人员)协调工作,还需进行系统测试。
最后进行验收测试,以解决开发的软件产品是否符合预期要求,用户是否接受等问题。
1.单元测试
单元测试是在软件开发过程中进行的最低级别的测试活动,其目的是要检测程序模块中有无故障存在。
也就是说,一开始不是把程序作为一个整体来测试,而是首先集中注意力来测试程序中较小的结构块,以便于发现并纠正模块内部的故障。
单元测试又称为模块测试,模块并没有严格的定义,按照一般的理解,模块应具有一些基本属性:
如名字,明确规定的功能,内部使用的数据或称局部数据,与其它模块或外界的数据联系,实现其特定功能的算法,可被其上层模块调用,也可调用其下属模块进行协同工作等。
在传统的结构化编程语言中(比如C语言),单元测试的对象一般是函数或子过程。
在像C++这样的面向对象的语言中,单元测试的对象可以是类,也可以是类的成员函数。
对Ada语言而言,单元测试可以在独立的过程和函数上进行,也可以在Ada包的级别上进行。
单元测试的原则同样也可以扩展到第四代语言(4GL)中,这时单元被典型地定义为一个菜单或显示界面。
单元测试的对象是软件设计的最小单位,与程序设计和编程实现关系密切,因此,单元测试一般由测试人员和编程人员共同完成。
测试人员可通过模块详细设计说明书和源程序代码清楚地了解模块的内部逻辑结构和I/O条件,常采用白盒测试方法设计测试用例。
在实际软件开发工作中,单元测试和代码编写所花费的精力大致相同。
经验表明:
单元测试可以发现很多的软件故障,并且修改它们的成本也很低。
在软件开发的后期阶段,发现并修复故障将变得更加困难,将花费大量的时间和费用。
因此,有效的单元测试是保证全局质量的一个重要部分。
在经过测试单元后,系统集成过程将会大大地简化,开发人员可以将精力集中在单元之间的交互作用和全局的功能实现上,而不是陷入充满故障的单元之中不能自拔。
2.集成测试
集成测试,又称组装测试、子系统测试,是在单元测试基础之上,将各个模块组装起来进行的测试,其主要目的是发现与接口有关的模块之间的问题。
这是因为时常有这样的情况发生,每个模块都能单独工作,但这些模块组装起来之后却不能正常工作。
程序在某些局部反映不出的问题,在全局上很可能就暴露出来,影响功能的正常发挥。
可能的原因有:
●模块相互调用时引入了新的问题,例如数据可能丢失;一个模块对另一模块可能有不良影响等;
●几个子功能组合起来不能实现主功能;
●误差不断积累达到不可接受的程度;
●全局数据结构出现错误等。
因此,在每个模块完成单元测试以后,需要按照设计的程序结构图,将它们组合起来,进行集成测试。
集成测试是按设计要求把通过单元测试的各个模块组装在一起,检测与接口有关的各种故障。
那么,如何组织集成测试呢?
是独立地测试程序的每个模块,然后再把它们组合成一个整体进行测试好呢?
还是先把下一个待测模块组合到已经测试过的那些模块上去,再进行测试,逐步完成集成好呢?
前一种方法称为非增式集成测试法。
后一种方法叫做增式集成测试法。
非增式测试法的集成过程是:
先对每—个模块进行单元测试,我们可以同时测试或是逐个地测试各个模块,这主要由测试环境(如所用计算机是交互式的还是批处理式的)和参加测试的人数等情况来决定。
然后,在此基础上按程序结构图将各模块连接起来,把连接后的程序当作一个整体进行测试。
这种集成测试方法容易出现混乱。
因为测试时可能发现一大堆错误,为每个故障定位和纠正非常困难,并且在修复一个故障的同时又可能引入新的故障,新旧故障混杂,很难断定出错的原因和位置。
与之相反的另一种集成方法是增量式集成测试方法。
增式集成测试不是孤立地测试每一个模块,而是将待测模块与已测过的模块集合连接起来进行测试。
增式集成测试过程,就是不断地把待测模块连接到已测模块集(或其子集)上,对待测模块进行测试,直到最后一个模块测试完毕。
在软件集成阶段,测试的复杂程度远远超过单元测试的复杂程度。
可以类比一下,假设要清洗一台已经完全装配好的食物加工机器,无论你喷了多少水和清洁剂,一些食物的小碎片还是会粘在机器的一些死角上,只有任其腐烂并等待以后再想办法。
但如果这台机器是拆开的,这些死角也许就不存在或者更容易接触到,并且每一部分都可以毫不费力地进行清洗。
3.确认测试
确认测试是对照软件需求规格说明,对软件产品进行评估以确定其是否满足软件需求的过程。
比如,编写出的程序相对于软件需求规格说明是否符合要求?
程序输出的信息是否是用户所要求的信息?
程序在整个系统的环境中能够正确稳定地运行?
等等,自然包含了对软件需求满足程度的评价。
集成测试完成以后,分散开发的模块已经按照设计要求组装成一个完整的软件系统,各模块之间存在的种种问题都已基本排除。
为进一步验证软件的有效性,对它在功能、性能、接口以及限制条件等方面做出更切实的评价,就应进行确认测试。
在开发的初期,软件需求规格说明中可能明确地规定了确认标准,但在测试阶段需要更详细、更具体地在测试规格说明中加以体现。
除了考虑功能、性能以外,还需检验其它方面的要求。
例如,可移植性、兼容性、可维护性、人机接口以及开发的文档资料是否符合要求等。
经过确认测试,应该为已开发的软件做出结论性的评价。
这无非存在两种情况:
(1)经过检验,软件功能、性能及其它方面的要求都已满足需求规格说明的规定,是一个合格的软件。
(2)经过检验,发现与软件需求规格说明有相当的偏离,得到一个缺陷清单,这就需要开发部门和用户进行协商,找出解决的办法。
4.系统测试
软件只是计算机系统的一个重要组成部分,软件开发完成以后,还应与系统中其它部分配合起来,进行一系列系统集成和测试,以保证系统各组成部分能够协调地工作。
这里所说的系统组成部分除软件外,还包括计算机硬件以及相关的外围设备、数据及采集和传输机构、计算机系统操作人员等。
系统测试实际上是针对系统中各个组成部分进行的综合性检验,很接近日常测试实践。
例如,在购买二手车时要进行系统测试,在订购在线网络时要进行系统测试等。
系统测试的目标不是要找出软件故障,而是要证明系统的性能。
比如,确定系统是否满足其性能需求;确定系统的峰值负载条件及在此条件下程序能否在要求的时间间隔内处理要求的负载;确定系统使用资源(存储器、磁盘空间等)是否会超界;确定安装过程中是否会导致不正确的方式;确定系统或程序出现故障之后能否满足恢复性需求;确定系统是否满足可靠性要求等。
系统测试很困难,需要很多的创造性。
那么,系统测试应该由谁来进行测试。
可以肯定以下人员、机构不能进行系统测试:
●系统开发人员不能进行系统测试。
●系统开发组织不能负责系统测试。
之所以如此,第一个原因是,进行系统测试的人必须善于从用户的角度考虑问题。
他最好他能彻底地了解用户的看法和环境,了解软件的使用。
显然,最好的人选就是一个或多个用户。
然而,一般的用户没有前面所说的各类测试的能力和专业知识,所以理想的系统测试小组应由这样一些人组成:
几个职业的系统测试专家、一到两个用户代表,一到两个软件设计者或分析者等。
第二个原因是系统测试没有清规戒律的约束、灵活性很强。
而开发机构对自己程序的心理状态往往与这类测试活动不相适应。
大部分开发软件机构最关心的是让系统测试能按时圆满地完成,并不真正想说明系统与其目标是否一致。
一般认为:
独立测试机构在测试过程中查错积极性高并且有解决问题的专业知识。
因此,系统测试最好由独立的测试机构完成。
关于系统测试,有很多种类型,我们将在第6章进—步讨论。
5.验收测试
验收测试的目的是向用户表明所开发的软件系统能够像用户所预定的那样工作,可以类比为建筑的使用者来对建筑进行的检测。
首先,他认为这个建筑是满足规定的工程质量的,这是有建筑的质检人员来保证。
使用者关注的重点是住在这个建筑的中的感受。
包括建筑的外观是否美观、各个房间的大小是否合适,窗户的位置是否合适,是否能够满足家庭的需要等。
这里,建筑的使用者执行的就是验收测试。
验收测试是将最终产品与最终用户的当前需求进行比较的过程,是软件开发结束后软件产品向用户交付之前进行的最后一次质量检验活动,它解决开发的软件产品是否符合预期的各项要求,用户是否接受等问题。
验收测试不只检验软件某方面的质量,还要进行全面的质量检验并决定软件是否合格。
因此,验收测试是一项严格的、正规的测试活动,并且应该在生产环境中而不是开发环境中进行。
验收测试的主要任务包括:
●明确规定验收测试通过的标准;
●确定验收测试方法;
●确定验收测试的组织和可利用的资源;
●确定测试结果的分析方法;
●制定验收测试计划并进行评审;
●设计验收测试的测试用例;
●审查验收测试的准备工作;
●执行验收测试;
●分析测试结果,决定是否通过验收。
验收测试关系到软件产品的命运,因此应对软件产品做出负责任的、符合实际情况的客观评价。
制定验收测试计划是做好验收测试的关键一步。
验收测试计划应为验收测试的设计、执行、监督、检查和分析提供全面而充分的说明,规定验收测试的责任者、管理方式、评审机构以及所用资源、进度安排、对测试数据的要求、所需的软件工具、人员培训以及其他的特殊要求等。
总之,在进行验收测试时,应尽可能去掉一些人为的模拟条件,去掉一些开发者的主观因素,使得验收测试能够得到真实、客观的结论。
1.4软件测试与软件开发的关系
软件开发过程是软件工程的重要内容,也是进行软件测试的基础。
近年来,软件工程界普遍认为,软件生命周期的每一阶段都应进行测试,以检查本阶段的工作成果是否接近预期的目标,尽可能早地发现并改正错误。
软件测试贯穿于软件开发的整个期间。
1.4.1软件开发过程
一个软件产品的开发可能需要几十、几百甚至几千人的协同工作,例如,开发Windows2000Server大约有6000人参与。
显然,一个软件产品的开发过程与计算机程序爱好者编写个小程序的过程是完全不同的。
正规的软件开发过程一般包括制定计划、需求分析、设计、程序编码、测试及运行维护六个阶段,即:
第一阶段计划
第二阶段需求分析
第三阶段设计
第四阶段程序编写
第五阶段测试
第六阶段运行和/维护
这六个阶段构成了软件的生存周期。
以下给出各阶段的主要任务:
(1)计划(第一阶段)
确定软件开发的总目标。
设想软件的功能、性能、可靠性以及接口等方面的要求。
研究完成该项软件任务的可行性,探讨解决问题的方案;对可供开发使用的资源(如计算机软/硬件、人力等)、成本、可取得的效益和开发的进度做出估计;制定完成开发任务的实施计划(ImplementationPlan)。
(2)需求分析(第二阶段)
对开发的软件进行详细的定义,由软件开发人员和用户共同讨论决定哪些需求是可以满足的并且给予确切的描述;写出软件需求说明或称软件规格说明书以及初步的用户手册,提交管理机构审查。
(3)软件设计(第三阶段)
设计是软件工程的技术核心。
在设计阶段应把已确定的各项需求转换成相应的体系结构,在结构中每一组成部分都是功能明确的模块。
每个模块都能体现相应的需求。
这一步称为概要设计。
在概要设计的基础上进行详细设计,即对每个模块要完成的工作进行具体的描述,包括确定使用的数据结构等,为程序编写打下基础。
上述两步设计工作均应写出设计说明,以供后继工作使用并提交审查。
(4)程序编写(第四阶段)
把软件设计转换成计算机可以接受的程序,即编写以某种程序设计语言表示的源程序。
当然,编写出的程序应该是结构良好、清晰易读并且与设计相一致。
(5)测试(第五阶段)
测试检验开发的软件是否符合规格说明的要求,它是保证软件质量的重要手段。
通常测试工作分为4步,即:
①单元测试:
检验各单元模块能否正常工作。
②集成测试:
将已测试的模块组装起来进行测试,检验与软件设计相关的程序结构问题。
③确认测试:
对照软件规格说明,检验开发的软件能否满足所有功能和性能的要求,以决定开发的软件是否合格,能否提交用户使用。
④系统测试:
检验开发的软件能否与系统的其他部分(如硬件、数据库、操作人员等)协调工作。
(6)运行和维护
已交付给用户的软件投入正式使用以后便进入运行阶段。
这阶段可能持续若干年,甚至几十年。
在运行中可能有多种原因需要对软件进行修改。
比如:
运行中发现了软件故障;为适应变化了的软件工作环境,为进一步增强软件的功能,提高它的性能等。
1.4.2软件测试在软件开发中的作用
软件开发经过制定计划、需求分析、设计阶段之后,才能进人编写程序阶段。
显然,表现在程序中的故障,并不一定是编码所引起的。
很可能是详细设计、概要设计阶段,甚至是需求分析阶段的问题引起的。
即使针对源程序进行测试,所发现故障的根源也可能在开发前期的各个阶段。
解决问题、排除故障也必须追溯到前
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 第01章 软件测试概述 01 软件 测试 概述