第07章、正确理解软件测试(理论课)参考教案.docVIP

注意事项： 关于软件测试和软件质量的关系，软件测试和软件工程的关系，以及软件工程和软件质量的关系，学员可能会觉得较难理解，要用通俗的语言和实际的案例进行讲解。 本次课程的内容以介绍测试实践经验为主，需要采用提问、举例和总结的方式进行授课。 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页： 讲解评审的概念，评审主要是针对文档进行评审，但也包含对代码本身的评审。评审的方式是多种多样的，评审的次数和内容也可以根据项目具体制定，但是对开发各关键阶段涉及的一些文档的评审是必不可少的，那么，软件在开发各个阶段都会涉及