软件测试与改错-掌握有效测试的方法与技术课件.ppt
- 【下载声明】
1. 本站全部试题类文档,若标题没写含答案,则无答案;标题注明含答案的文档,主观题也可能无答案。请谨慎下单,一旦售出,不予退换。
2. 本站全部PPT文档均不含视频和音频,PPT中出现的音频或视频标识(或文字)仅表示流程,实际无音频或视频文件。请谨慎下单,一旦售出,不予退换。
3. 本页资料《软件测试与改错-掌握有效测试的方法与技术课件.ppt》由用户(晟晟文业)主动上传,其收益全归该用户。163文库仅提供信息存储空间,仅对该用户上传内容的表现方式做保护处理,对上传内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(点击联系客服),我们立即给予删除!
4. 请根据预览情况,自愿下载本文。本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
5. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007及以上版本和PDF阅读器,压缩文件请下载最新的WinRAR软件解压。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 改错 掌握 有效 方法 技术 课件
- 资源描述:
-
1、软件测试与改错软件测试与改错 掌握有效测试的方法与技术掌握有效测试的方法与技术王晓辉王晓辉maconi126.co 华北电力大学计算机系华北电力大学计算机系第 2 页目录目录1.测试的常识与道理测试的常识与道理 2.测试的分类与比较测试的分类与比较3.测试人员的组织测试人员的组织4.企业的测试策略企业的测试策略5.测试规范测试规范6.软件产品的主要测试内容及技术软件产品的主要测试内容及技术7.改错的方法改错的方法8.小结小结第 3 页1.测试的常识与道理测试的常识与道理1.1 你真的懂测试吗你真的懂测试吗 u编程大师说:没有错误的程序世间难求。编程大师说:没有错误的程序世间难求。(编程之道)(
2、编程之道)u你在学校里学过测试吗?(读到博士可能也不懂测试)你在学校里学过测试吗?(读到博士可能也不懂测试)u你所在的企业重视测试吗?你所在的企业重视测试吗?(小公司程序员的技能更加全面)(小公司程序员的技能更加全面)u临时抱佛脚行吗?临时抱佛脚行吗?你以为有文档模板就会测试了吗你以为有文档模板就会测试了吗?u如果不懂得有效地进行测试,你不仅得不到功劳,也没人欣赏你的如果不懂得有效地进行测试,你不仅得不到功劳,也没人欣赏你的苦劳,你拥有最多的将只是疲劳。苦劳,你拥有最多的将只是疲劳。u职业软件工程师应当掌握需求开发、系统设计、编程、测试、维护职业软件工程师应当掌握需求开发、系统设计、编程、测试
3、、维护 所有技能。所有技能。第 4 页1.2 测试的目的是什么测试的目的是什么u测试的目的是为了发现尽可能多的缺陷测试的目的是为了发现尽可能多的缺陷,不是,不是为了说明软件中没有为了说明软件中没有缺陷。缺陷。u推论:成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员推论:成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员的职责是设计这样的测试用例,它能有效地揭示潜伏在软件里的缺的职责是设计这样的测试用例,它能有效地揭示潜伏在软件里的缺陷。陷。u千万不要将千万不要将“测试测试”与与“演示演示”混为一谈。例如科研鉴定会。混为一谈。例如科研鉴定会。u如果产品通过了严格的测试,大家不要不吭气,应当
4、好好地宣传一如果产品通过了严格的测试,大家不要不吭气,应当好好地宣传一把把。第 5 页1.测试的常识与道理测试的常识与道理1.3 一些常识和经验之谈一些常识和经验之谈u测试能提高软件的质量,但是提高质量不能依赖测试。测试能提高软件的质量,但是提高质量不能依赖测试。u测试只能证明缺陷存在,不能证明缺陷不存在。测试只能证明缺陷存在,不能证明缺陷不存在。“彻底地测试彻底地测试”难难以成为现实,要考虑时间、费用等限制,不允许无休止地测试。我以成为现实,要考虑时间、费用等限制,不允许无休止地测试。我们应当祈祷:软件的缺陷在产品被淘汰之前一直没有机会发作。们应当祈祷:软件的缺陷在产品被淘汰之前一直没有机会
5、发作。u测试的主要困难是不知道如何进行有效地测试,也不知道什么时候测试的主要困难是不知道如何进行有效地测试,也不知道什么时候可以放心地结束测试。可以放心地结束测试。u每个开发人员应当测试自己的程序(份内之事),但是不能作为该每个开发人员应当测试自己的程序(份内之事),但是不能作为该程序已经通过测试的依据(所以项目需要独立测试人员)。程序已经通过测试的依据(所以项目需要独立测试人员)。u80-2080-20原则:原则:8080的缺陷聚集在的缺陷聚集在2020的模块中,经常出错的模块改错的模块中,经常出错的模块改错后还会经常出错后还会经常出错u测试应当循序渐进,不要企图一次性干完,注意测试应当循序
6、渐进,不要企图一次性干完,注意“欲速则不达欲速则不达”。第 6 页2.测试的分类与比较测试的分类与比较2.1 测试方式测试方式u白盒测试:关心软件内部设计和程序实现,主要测试依据是设计文档白盒测试:关心软件内部设计和程序实现,主要测试依据是设计文档u黑盒测试:不关心软件内部,只关心输入输出,主要测试依据是需求文档黑盒测试:不关心软件内部,只关心输入输出,主要测试依据是需求文档2.2 测试阶段测试阶段u单元测试、集成测试、单元测试、集成测试、系统测试、系统测试、验收测试。是验收测试。是“从小到大从小到大”、“由内至由内至外外”、“循序渐进循序渐进”的测试过程,体现了的测试过程,体现了“分而治之分
7、而治之”的思想。的思想。u单元测试的粒度最小,一般由开发小组采用白盒方式来测试,主要测试单单元测试的粒度最小,一般由开发小组采用白盒方式来测试,主要测试单元是否符合元是否符合“设计设计”。u集成测试界于单元测试和系统测试之间,起到集成测试界于单元测试和系统测试之间,起到“桥梁作用桥梁作用”,一般由开发,一般由开发小组采用白盒加黑盒的方式来测试,既要验证小组采用白盒加黑盒的方式来测试,既要验证“设计设计”又要验证又要验证“需求需求”。u系统测试的粒度最大,一般由独立测试小组采用黑盒方式来测试,主要测系统测试的粒度最大,一般由独立测试小组采用黑盒方式来测试,主要测试系统是否符合试系统是否符合“需求
8、规格说明书需求规格说明书”。u验收测试与系统测试非常相似,主要区别是测试人员不同,验收测试由用验收测试与系统测试非常相似,主要区别是测试人员不同,验收测试由用户执行。户执行。第 7 页2.测试的分类与比较测试的分类与比较2.3 开发与测试的开发与测试的 V 型关系型关系u如果软件开发过程采用严格的瀑布模型,那么开发与测试有如果软件开发过程采用严格的瀑布模型,那么开发与测试有“V”型的对应关系型的对应关系。需求开发需求开发 高层设计高层设计详细设计详细设计编程编程单元测试单元测试集成测试集成测试系统测试系统测试验收测试验收测试第 8 页2.测试的分类与比较测试的分类与比较2.4 测试内容测试内容
9、u接口与路径测试。接口与路径测试。u功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装性测试、安装/反安装测试反安装测试 测试阶段测试阶段 主要依据主要依据 测试人员、测试方式测试人员、测试方式 主要测试内容主要测试内容 单元测试单元测试系统设计文档系统设计文档由开发小组执行白盒测试由开发小组执行白盒测试 接口测试、路径测试接口测试、路径测试 集成测试集成测试系统设计文档系统设计文档需求文档需求文档由开发小组执行白盒测试和黑盒由开发小组执行白盒测试和黑盒测试测试 接口测试、路径测试接口测试
10、、路径测试功能测试、性能测试功能测试、性能测试 系统测试系统测试需求文档需求文档由独立测试小组执行黑盒测试由独立测试小组执行黑盒测试 功能测试、健壮性测试、性能测试功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压、用户界面测试、安全性测试、压力测试、可靠性测试、安装力测试、可靠性测试、安装/反安装反安装测试测试 验收测试验收测试需求文档需求文档由用户执行黑盒测试由用户执行黑盒测试 第 9 页2.测试的分类与比较测试的分类与比较2.5 问题问题u问题问题1 1:有了:有了“黑盒黑盒”测试为什么还要测试为什么还要“白盒白盒”测试?测试?黑盒测试只能观察软件的外部表现,即使软件的输入输出
11、都是正确的黑盒测试只能观察软件的外部表现,即使软件的输入输出都是正确的,却并不能说明软件就是正确的。因为程序有可能用错误的运算方式,却并不能说明软件就是正确的。因为程序有可能用错误的运算方式得出正确的结果,例如得出正确的结果,例如“负负得正,错错得对负负得正,错错得对”,只有白盒测试才能,只有白盒测试才能发现真正的原因。发现真正的原因。(举一个学生作业的例子举一个学生作业的例子)白盒测试能发现程序里的隐患,象内存泄漏、误差累计问题。在这方白盒测试能发现程序里的隐患,象内存泄漏、误差累计问题。在这方面,黑盒测试存在严重的不足。面,黑盒测试存在严重的不足。u问题问题2 2:由于单元测试要写测试驱动
12、程序,非常麻烦,能否等到整个:由于单元测试要写测试驱动程序,非常麻烦,能否等到整个系统全部开发完后,再集中精力进行一次性地单元测试呢?系统全部开发完后,再集中精力进行一次性地单元测试呢?如果这样做,在开发过程中,缺陷会越积越多并且分布得更广、隐藏如果这样做,在开发过程中,缺陷会越积越多并且分布得更广、隐藏得更深,反而导致测试与改错的代价大大增加。最糟糕的是无法估计得更深,反而导致测试与改错的代价大大增加。最糟糕的是无法估计测试与改错的工作量,使进度失去控制。因此为图眼前省事而省略单测试与改错的工作量,使进度失去控制。因此为图眼前省事而省略单元测试或者元测试或者“偷工减料偷工减料”,是,是“得不
13、偿失得不偿失”的做法。的做法。第 10 页u问题问题3 3:如果每个单元都通过了测试,把它们集成一起难道会有什么不妥吗:如果每个单元都通过了测试,把它们集成一起难道会有什么不妥吗?集成测试是否多此一举?集成测试是否多此一举?要把要把N N个单元集成一起肯定靠接口耦合,这时可能会产生在单元测试中个单元集成一起肯定靠接口耦合,这时可能会产生在单元测试中无法发现的问题。例如:数据通过不同的接口时可能出错;几个函数无法发现的问题。例如:数据通过不同的接口时可能出错;几个函数关联在一起时可能达不到预期的功能;在某个单元里可以接受的误差关联在一起时可能达不到预期的功能;在某个单元里可以接受的误差可能在集成
14、后被扩大到无法接受的程度。所以集成测试是必要的,不可能在集成后被扩大到无法接受的程度。所以集成测试是必要的,不是多此一举。是多此一举。u问题问题4 4:在集成测试的时候,已经对一些子系统进行了功能测试、性能测试:在集成测试的时候,已经对一些子系统进行了功能测试、性能测试等等,那么在系统测试时能否跳过相同内容的测试等等,那么在系统测试时能否跳过相同内容的测试?不能!因为集成测试是在仿真环境中开展的,那不是真正的目标系统不能!因为集成测试是在仿真环境中开展的,那不是真正的目标系统。再者,单元测试和集成测试通常由开发小组执行。根据测试心理学。再者,单元测试和集成测试通常由开发小组执行。根据测试心理学
15、的分析,开发人员测试自己的工作成果虽然是必要的,但不能作为成的分析,开发人员测试自己的工作成果虽然是必要的,但不能作为成果已经通过测试的依据。果已经通过测试的依据。第 11 页2.测试的分类与比较测试的分类与比较2.5 问题问题u问题问题5 5:既然系统测试与验收测试的内容几乎是相同的,为什么还要验收测:既然系统测试与验收测试的内容几乎是相同的,为什么还要验收测试?试?首先是首先是“信任信任”问题。对于合同项目而言,如果测试小组是开发方的人员,客问题。对于合同项目而言,如果测试小组是开发方的人员,客户怎么能够轻易相信户怎么能够轻易相信“别人别人”呢呢?所以当项目进行系统测试之后,客户再进行所以
16、当项目进行系统测试之后,客户再进行验收测试是情理之中的事。否则,那是客户失职。验收测试是情理之中的事。否则,那是客户失职。不论是合同项目还是非合同项目,软件的最终用户各色各样(如受教育程度不不论是合同项目还是非合同项目,软件的最终用户各色各样(如受教育程度不同、使用习惯不同等等)。测试小组至多能够模仿小部分用户的行为,但并不同、使用习惯不同等等)。测试小组至多能够模仿小部分用户的行为,但并不具有普遍的代表性。具有普遍的代表性。u问题问题6 6:能否将系统测试和验收测试:能否将系统测试和验收测试“合二为一合二为一”?系统测试不是一会儿就能做完的,比较长时间的用户测试很难组织。用户还有系统测试不是
17、一会儿就能做完的,比较长时间的用户测试很难组织。用户还有自己的事情要做,他们为什么要为别人测试呢?即使用户愿意做系统测试,他自己的事情要做,他们为什么要为别人测试呢?即使用户愿意做系统测试,他们消耗的时间、花费的金钱大多比测试小组的高。们消耗的时间、花费的金钱大多比测试小组的高。系统测试时会找出相当多的软件缺陷,软件需要反反复复地改错。如果让用户系统测试时会找出相当多的软件缺陷,软件需要反反复复地改错。如果让用户发现发现“内幕内幕”,一是丢脸,二是会吓跑买主。所以还是关起门来,先让测试小,一是丢脸,二是会吓跑买主。所以还是关起门来,先让测试小组做完系统测试的好。组做完系统测试的好。第 12 页
18、3.测试人员的组织测试人员的组织3.1 了解开发人员的测试心理了解开发人员的测试心理u测试的目的是找出尽可能多的缺陷。所以测试是测试的目的是找出尽可能多的缺陷。所以测试是“破坏性破坏性”的,而开发却的,而开发却是是“建设性建设性”的。开发人员总是喜欢欣赏程序的成功之处,而不愿看到失的。开发人员总是喜欢欣赏程序的成功之处,而不愿看到失败之处。让开发者去做败之处。让开发者去做“蓄意破坏蓄意破坏”的测试,就象杀自己的孩子一样难以的测试,就象杀自己的孩子一样难以接受。接受。u开发者对自己的程序印象深刻,并总以为是正确的(自信是应该的)。倘开发者对自己的程序印象深刻,并总以为是正确的(自信是应该的)。倘
19、若在设计时就存在理解错误,或因不良的编程习惯而流下了隐患,他本人若在设计时就存在理解错误,或因不良的编程习惯而流下了隐患,他本人很难发现这类错误很难发现这类错误.u开发者对自己的程序的功能、接口十分熟悉,他自己几乎不可能因为使用开发者对自己的程序的功能、接口十分熟悉,他自己几乎不可能因为使用不当而引发错误,这与大众用户的情况不太相似,所以测试自己的程序不不当而引发错误,这与大众用户的情况不太相似,所以测试自己的程序不具备典型性。具备典型性。u结论:开发人员应当测试自己的程序,这是他分内的工作。但是开发人员结论:开发人员应当测试自己的程序,这是他分内的工作。但是开发人员在测试自己的程序时,很难做
20、到客观、公正,所以自我测试不具有说服力在测试自己的程序时,很难做到客观、公正,所以自我测试不具有说服力。第 13 页3.2 如何组织测试人员:应当视企业的人力资源而如何组织测试人员:应当视企业的人力资源而定定u条件特别好的公司条件特别好的公司,可以为每一个开发人员分配一名独立的测试人员。这可以为每一个开发人员分配一名独立的测试人员。这样的测试人员职业化程度很高,可以完成单元测试、集成测试和系统测试样的测试人员职业化程度很高,可以完成单元测试、集成测试和系统测试工作,能够实现开发与测试同步进行。工作,能够实现开发与测试同步进行。u条件比较好的公司,可以设置一个独立的测试小组,该测试小组轮流参加条
21、件比较好的公司,可以设置一个独立的测试小组,该测试小组轮流参加各个项目的系统测试。而单元测试、集成测试工作由项目的开发小组承担各个项目的系统测试。而单元测试、集成测试工作由项目的开发小组承担。u条件一般的公司,养不起独立的测试小组。单元测试、集成测试工作由项条件一般的公司,养不起独立的测试小组。单元测试、集成测试工作由项目开发小组承担。当项目进展到系统测试阶段,可以从项目外抽调一些人目开发小组承担。当项目进展到系统测试阶段,可以从项目外抽调一些人员,加上开发人员,临时组织系统测试小组。员,加上开发人员,临时组织系统测试小组。u条件比较差的公司,也许只有一个项目和为数不多的一些开发人员。那么条件
22、比较差的公司,也许只有一个项目和为数不多的一些开发人员。那么就让开发人员一直兼任测试人员的角色,相互测试对方的程序。如果人员就让开发人员一直兼任测试人员的角色,相互测试对方的程序。如果人员实在太少了,只好让开发者测试自己的程序,有测试总比没有测试好吧!实在太少了,只好让开发者测试自己的程序,有测试总比没有测试好吧!第 14 页3.测试人员的组织测试人员的组织3.3 避免开发人员与测试人员产生矛盾避免开发人员与测试人员产生矛盾u开发人员的注意事项:开发人员的注意事项:不要敌视测试人员。要理解测试的目的就是发现缺陷,是测试人员的不要敌视测试人员。要理解测试的目的就是发现缺陷,是测试人员的工作职责。
23、不要以为测试人员吃饱了没事干,存心找茬。工作职责。不要以为测试人员吃饱了没事干,存心找茬。不要轻视测试人员,别说人家技术水平差,不配搞开发只好搞测试。不要轻视测试人员,别说人家技术水平差,不配搞开发只好搞测试。u测试人员的注意事项:测试人员的注意事项:发现缺陷时不要嘲笑开发人员,别说他的程序真臭、到处是发现缺陷时不要嘲笑开发人员,别说他的程序真臭、到处是BugBug。在开发人员压力太大时或心情不好时不要火上浇油,发现缺陷时别大在开发人员压力太大时或心情不好时不要火上浇油,发现缺陷时别大声嚷嚷。声嚷嚷。u请留意另一种极端:如果测试人员与开发人员的关系非常好,可能请留意另一种极端:如果测试人员与开
24、发人员的关系非常好,可能会导致在测试的时候会导致在测试的时候“手下留情手下留情”,这对项目也是一种伤害。,这对项目也是一种伤害。第 15 页4.企业的测试策略企业的测试策略4.1 理念:理念:u企业的主要目的是获取利润,降低测试成本也是盈利的一种方式。企业的主要目的是获取利润,降低测试成本也是盈利的一种方式。u用较低的代价实现有效的测试,不应为了追求完美的测试而不失一切代价用较低的代价实现有效的测试,不应为了追求完美的测试而不失一切代价。第 16 页4.2 如何合理地减少测试工作量如何合理地减少测试工作量u减少冗余的测试减少冗余的测试 白盒测试与黑盒测试的方式虽然不同,但往往有白盒测试与黑盒测
25、试的方式虽然不同,但往往有“异曲同工异曲同工”之妙。在很多地之妙。在很多地方,白盒测试与黑盒测试会产生一模一样的效果(或者能推理出来),这样的方,白盒测试与黑盒测试会产生一模一样的效果(或者能推理出来),这样的测试是冗余的。测试是冗余的。在集成测试、系统测试阶段,可能要执行多次在集成测试、系统测试阶段,可能要执行多次“回归测试回归测试”。每一次。每一次“回归测回归测试试”都会存在不少的冗余,应当设法剔除不必要的重复测试工作。都会存在不少的冗余,应当设法剔除不必要的重复测试工作。u减少无价值的测试减少无价值的测试 无价值的测试通常是由于不懂得测试技术引起的。例如功能测试,在等价区间无价值的测试通
展开阅读全文