第03章、编写和管理缺陷报告(理论课)参考教案

2024-06-30

第03章、编写和管理缺陷报告(理论课)参考教案(共1篇)

1.第03章、编写和管理缺陷报告(理论课)参考教案 篇一

 注意事项:

 关于软件测试和软件质量的关系,软件测试和软件工程的关系,以及软件工程和软件质量的关系,学员可能会觉得较难理解,要用通俗的语言和实际的案例进行讲解。 本次课程的内容以介绍测试实践经验为主,需要采用提问、举例和总结的方式进行授课。

 PPT第1~5页:

 回顾上一章内容,可以采用提问的方式;并简要介绍本章的学习目标。

 PPT第6页:

 内容进度页,向学员介绍本次课程的进度安排。

 PPT第7~8页:

 阐述尽早进行软件测试并把测试贯穿整个软件生命周期的原则。 首先提问学员,软件缺陷是在软件生命周期的什么阶段被引入到程序中的?并将学员的回答在白板上记录。然后进行总结,并引申阐述在各阶段都会引入什么样的错误。接下来承上启下地提出,不同阶段引入的缺陷对于软件的整个影响有什么不同?对测试的影响有什么不同?通过幻灯片8中的表格总结出软件测试应该尽早进行的结论。

 通过幻灯片9中的图表,分析软件生命周期的不同阶段引入错误的多少是不同的,但是这些错误需要在后续的测试过程中逐渐发现,所以说软件测试在任何阶段都不能松懈,软件测试应该贯穿于整个软件生命周期。

 PPT第9页:

 说明软件测试应该追溯到需求的原则。首先通过装修房子的案例说明什么是需求,需求是用来约束产品的最终标准,然后阐述如下几个观点:  软件需求过程和需求说明书也是要测试的。

 最终交付的产品必须满足需求说明书中的每一项,如果不能满足,必须以文档的形式列出来请客户方确认并同意。

 如果软件测试过程中发生争议,将需求说明书作为标准来评判。 阐述测试应该由第三方构造的原则。可以从以下几个方面来说明程序设计者不应该测试自己的程序:

 程序设计者一般只熟悉程序结构,不熟悉需求。

 程序设计者不容易发现自己程序中存在的很多隐性问题。

 有些程序设计者淡化自己程序缺陷的严重程度,影响了程序修复。

最后需要强调的是,以上观点只是对测试工作而言,强调测试团队组织的独立性。在实际的工作中,有时也是需要程序员进行测试的,比如单元测试工作,很多公司都是由程序员或系统设计员完成的。而其它测试的话,多数是由测试人员完成的,如果一个项目中实在没有单独的测试队伍的话,也应该让程序员相互进行测试,这样也比不进行测试要好得多,但是在测试之前,首先要进行相关知识的培训(如需求、测试方法和策略等)。

 PPT第10页:

 阐述测试是无法穷举的,测试者需要遵循Good-Enough的原则。首先通过第一堂课中的加法计算器的案例或者教材中电话号码系统的案例,说明对一个非常小的程序,想要进行穷举测试是非常麻烦的,当程序稍微复杂一些,比如Windows计算器中的加法运算,穷举测试几乎是不可能的。接下来讲述测试的“Good-Enough”原则。最后通过测试工作量和发现缺陷数量之间关系的图表说明,找到测试费用和测试量之间的平衡点,是最佳选择。

 PPT第11页:

 阐述测试前必须确定预期的输出结果的原则。通过教材中的四舍五入的例子说明,在测试之前如果不知道输出什么样的结果是正确的,就无法进行测试。提示学员在编写测试用例时,必须给出预期结果。

 阐述测试完成后必须认真检查每个测试结果的原则。主要强调仔细检查缺陷报告的必要性,不能遗漏缺陷,遗漏缺陷会带来很大的危害。重复缺陷或相似缺陷很容易被遗漏,前面已经强调过,测试不是一个人完成的工作,需要测试组共同协作,最终完成产品的检测。但是多人测试就会带来一个问题,那就是重复缺陷报告和相似缺陷报告,测试时需要注意以下问题:

 重复的缺陷描述可能属于不同的模块,要分别处理。 相似的缺陷报告很容易被作为重复的缺陷报告被剔除。

 一个缺陷被两个人提交后,可能都认为是对方跟踪,结果谁都没有跟踪。 讲解必须充分关注测试过程中的群集现象,举例说明测试后发现缺陷最多的模块,其残留的错误也可能是最多(可以举一篮苹果中的坏苹果数目的例子说明群集现象)。

 PPT第12页:

 顺序介绍其他值得注意的规律和经验,时间允许的情况下,可以让学员进行讨论:在测试中,还有哪些规律需要注意?

 PPT第13页:

 根据实际授课情况,对“软件测试的原则”进行小结,回顾前面所讲的内容。

 PPT第14页:

 内容过渡页,做好知识点之间的过渡。

 PPT第15页:

 提问学员什么是软件,以及软件的特点是什么?从问答中引导学员回顾软件和软件程序的区别,接下来提问学员软件测试的对象是什么?根据学生的回答,引出软件测试不仅要测试软件程序是否运行正常,还需要测试软件的文档是否符合要求。然后引出评审的概念。

 简要说明在“关于评审”中要介绍的知识点。

 PPT第16~18页:

 讲解评审的概念,评审主要是针对文档进行评审,但也包含对代码本身的评审。评审的方式是多种多样的,评审的次数和内容也可以根据项目具体制定,但是对开发各关键阶段涉及的一些文档的评审是必不可少的,那么,软件在开发各个阶段都会涉及到哪些文档呢?  提问学员回答后,切换到幻灯片17进行补充介绍:

 对用户来说用户文档包括:用户手册、安装说明等等(如源代码也作为产品的一部分则还包括源代码)

 对企业来说开发文档包括:源代码、需求分析、概要设计、详细设计、其他设计文档、业务建模、技术经验总结等等  对企业来说管理文档包括:开发过程的时间和人员安排计划、便于企业改进开发过程等等

 文档对于软件产品的重要性是不言而喻的,它不仅仅是脑力劳动的输出,更重要的是经验重用和项目管理的手段,是走上工程之路的基础。这里强调文档的重要性是因为文档在测试和开发过程中经常被忽视或推迟完成。 最后通过幻灯片18说明评审工作的意义。

 PPT第19页:

 内容过渡页,做好知识点之间的过渡。

 PPT第20~24页:

 介绍软件测试和软件质量之间的关系。这部分内容从整体上包括层层深入的三个部分:

 软件质量和软件过程:过程决定质量,软件过程决定软件质量。

 软件质量的建立:软件质量是在软件开发过程中逐渐建立起来的。 过程与质量的关系:过程的质量直接影响软件的质量。 决定软件质量的关键因素:人员、技术和过程是决定软件质量的关键因素。 好的产品是怎样生产出来的:高质量的人员和好的过程应该得到好的产品。

 软件测试和软件过程:软件测试是软件过程的一部分。

 强调软件测试过程在整个软件生命周期中占有重要的位置。 软件测试和软件质量:软件测试是有效提高软件质量的技术手段。

 提出问题:那么软件测试是不是软件质量保证的安全网呢?这里可以列举牛奶的生产过程进行说明:

 如果把牛奶的生产过程比作软件生产过程的话,那么软件质量就相当于牛奶质量,软件测试相当于牛奶质量检测。牛奶质量检测只能测试当前的牛奶好坏,要提高牛奶质量必须改善生产牛奶的过程,从精选奶牛开始,每个步骤都要改进。

 最后总结:只有坚持不懈的改进过程中的问题才是提高软件产品质量的根本出路,但是注意过程并不意味着忽视技术。软件质量不是依靠软件测试来保证的,软件质量需要靠不断的提高技术水平和改进软件开发过程来保证,正如牛奶的生产,如果把所有对质量的期望都压在对最后一道工序的质检上,那将是一个什么样的结果。

 PPT第25页:

 内容过渡页,做好知识点之间的过渡。

 PPT第26页:

 阐述“软件质量不是靠测出来的”这一观点。这部分内容在介绍软件测试和软件质量之间的关系时已经进行了详尽的阐述,这里作为正确理解软件测试的一个观点,可以提示学员如下的内容:

 在实际的工作中不要把自己看作质量卫士,要能够明确自己的职责,以较好的心态对待软件测试。

 测试人员作为软件的质量保证人员之一,要积极参与推行软件开发过程改进和软件测试过程改进,从根本上提高软件的质量。

 阐述“软件测试人员需具备很多开发人员不具备的素质”这一观点。

 可以从人们对“测试”这一行业的人员素质的错误认识谈起,比如:某些简单硬件(比如电话)生产厂家的测试人员,在流水线上对组装好的产品进行着简单的检测工作。这使人们心目中形成了一个印象,那就是,测试就是按照固定的流程进行简单操作。这些人相对于产品的设计者,是不需要很高深的知识的。他们只负责检测产品的某些功能是否正常,而不需要告诉设计人员是什么原因造成的。这是无所谓的,因为设计人员基本上可以从现象很快判断出问题出在哪里。

 随着软件行业的发展,软件作为一个产品,也需要进行测试。但是一提起“软件测试”,有些人马上想到了那些流水线上的工人。实际上软件产品和硬件产品完全不同,需要的测试人员也不同。而那些流水线上的工人,连复杂一些的硬件产品(比如程控交换机)测试也是无法完成的。 现代软件的复杂程度的不断增加,对软件测试工作者的要求也越来越高,不是谁都可以做测试,在很多公司,对测试人员的水平要求已经超过了开发人员。 接下来提问学员,关于第一章中“软件测试人员需要具备的素质”的内容,然后对幻灯片中的内容进行详细的阐述,阐述时侧重与测试人员和开发人员所需技能的对比。

 阐述“软件测试需要开发人员和测试人员共同努力”这一观点。我们提倡第三方来测试,提倡测试部门从项目组中独立出来,目的是保证进行客观公正的测试,但是这是否说明,开发和测试是完全独立,互不依赖的呢?可以从以下几个方面进行阐述:

 测试和开发一个是破坏性的,一个是建设性的,正是不断的破坏和建设才能使软件更加稳定更加强大,要更快更好的完成这一过程,需要双方的配合和努力。 测试可以帮助开发人员更快的定位缺陷的位置和产生原因。 开发人员可以帮助测试人员优化缺陷。开发人员通过单步跟踪等方式对程序的检测可以节省很多测试工作量。

 有些测试工作可能需要开发人员完成,如单元测试。

 PPT第27页:

 详细讲解软件测试的V模型,侧重于不同阶段的测试工作的对应,说明软件测试不是软件开发过程中的一个阶段,而是贯穿于整个软件生命周期。

 PPT第28页:

 根据实际授课情况,对“争取理解软件测试”进行小结,回顾前面所讲的内容。

 PPT第29页:

 内容过渡页,做好知识点之间的过渡。

 PPT第30页:  讲解处理缺陷时需要注意的几个问题,包括如下几个观点:

 注意缺陷报告的处理成本

 对于大多数项目来说处理全部缺陷是不可能的。 对缺陷的处理本身也需要成本。 不可重现的缺陷如何处理。 修改缺陷要量力而行。

 修改缺陷是有风险的。 修改缺陷也需要成本。 关注被推迟修改的缺陷

 在一个版本中被推迟的缺陷,到了下一个版本可能优先级会有所变动。 使用缺陷跟踪工具,可能会帮助我们轻松完成这一工作。 如果决定据理力争就一定要赢

 如果自己提交的报告存在争议,应该进行重新测试,如果确认自己的报告是正确的,可以收集更有说服力的资料,必要时采用会议的方式讨论。

 PPT第31页:

 对本次课程进行回顾总结,并利用剩下的时间回答学员的问题

 课堂练习答案

 一.填空题:

1.尽早地进行软件测试,并把软件测试贯穿于整个软件生命周期

软件测试应追溯需求、测试应由第三方来构造 穷举测试是不可能的,要遵循Good-enough原则 必须确定预期输出结果

必须彻底检查每个测试结果 充分注意测试中的群集现象 其他规律和经验:

二八定理

要严格执行测试计划,排除测试的随意性

测试的时候,既要注意合法合理的输入,也要注意非法的非预期的输入 检查程序是否做了应该做的同时,也要检查是否做了不该做的 测试应从“小规模”开始,逐步转向“大规模” 关注缺陷的修复

2.分析

设计

实现

80% 系统测试

发现错误

发现所有的错误 3.早期阶段

中间成果

最终成果  二.选择题:

1.ABC 2.ABCD

上一篇:课程论文写作题目下一篇:狼性的人生励志格言