第08章软件测试与软件开发过程课件

《第08章软件测试与软件开发过程课件》由会员分享，可在线阅读，更多相关《第08章软件测试与软件开发过程课件（28页珍藏版）》请在金锄头文库上搜索。

1、软件测试与软件开发过程,第8章,8.1.1 软件开发生命周期模型,1.软件开发过程概述 2. 各种软件测试在软件开发生命周期中的位置,内容提要,定义：,软件测试是软件工程（Software Engineering）的一个重要分支，随着软件工程学科的发展，现在的软件测试与传统的软件测试相比有了很大的发展，它与软件开发过程和软件质量保证（Quality Assurance，QA）密切相关。 软件开发过程是生产软件产品所用的工具、方法和实践过程的集合。在商业上软件开发通常是由一组协同工作的人来完成的，我们把这组人称为开发团队。开发团队里有各种角色，一个人可以充当不止一个角色，特别是在许多小公司，有时

2、一个人身上集中了几个角色。 生命周期 一个软件产品是由上述多种角色的团队协同工作而完成的。从策划、定义、开发、使用与维护直到最后废，要经过一个漫长的时期，通常把这个时期称为软件的生命周期（Software Life Cycle），很多人也把它称为软件开发生命周期（Software Development Life Cycle）。,8.1 软件开发过程概述,各种角色及主要职责,项目经理（程序经理）：负责管理产品的质量，以及项目的进度和预算。 商业分析师（软件分析师）：分析客户的真正需求，用能被程序员或其他设计人员理解的术语来定义客户的需求。 架构师（系统工程师）：是产品小组的专家，负责系统的总体

3、内部设计（定义代码，数据结构，数据通信和开发策略等）。 程序员（开发人员）：设计、编写程序并编写内部设计规格说明。 测试员（质量保证员）：负责找出并报告软件产品的问题。 产品经理（产品营销经理）：负责符合公司长期战略和形象的产品的交付，并在产品发布后负责市场营销活动。对产品的盈利负责。 技术支持代表：负责处理客户投诉和服务的小组的成员。在产品开发期间他们会尽力对产品的设计和手册的内容施加影响，以减少客户的投诉。 技术文档编写员：制作用户手册和在线帮助。,瀑布模型（Waterfall Model）,几个特征： （1）阶段间的顺序性和依赖性 （2）推迟实现的观点 （3）质量保证的观点 缺点： （1

4、）不适应需求经常发生变更的环境。 （2）瀑布模型也经常不能接受项目开始阶段自然存在的不确定性。 （3）线性顺序模型种特征导致工作中发生“阻塞”状态。,8.1.1 软件开发生命周期模型,模型种类 有瀑布模型、原型模型、快速应用开发模型、增量模型、螺旋模型、V模型、形式方法模型、RUP（Rational Unified Process）模型、敏捷过程模型、构件组装模型、并发开发模型等。 几种比较流行的模型 1传统的瀑布模型（Waterfall Model） 2原型模型（Prototyping Model） 3螺旋模型（Spiral Model）,原型模型（Prototyping Model）,在项

5、目开发的初始阶段，人们对软件的需求认识常常不够清晰，使得开发项目难以做到一次开发成功，出现返工再开发在所难免。因此，可以先做试验开发，其目标只是探索可行性，弄清软件需求；然后在此基础上获得较为满意的软件产品。通常把第一次得到的试验性产品称为“原型”。,螺旋模型（Spiral Model）,优点： 1.瀑布模型与原型的迭代特征结合起来，加入两种模型均忽略了的风险分析。 2.能够快速开发软件的增量版本。 3.不要求每一个增量都是可以运行的程序。 4.划分为若干个框架活动，活动也称 为任务区域。 包括,制定计划 风险分析 实施工程 客户评估,8.1.2 软件测试与软件开发过程的关系,狭义定义测试：,

6、比如“程序设计”与“测试”之间的关系，传统上总以为程序设计在先，测试在后。这种专指测试程序代码，定义在编码之后的“测试”是一种狭义定义的测试。,广义定义测试：,这种测试活动可以在软件开发生命周期的任何阶段进行。但是，随着开发不断地进行，越到后续阶段，找出错误并改正它的代价会越大,全新的软件开发模式：,以测试驱动软件开发。软件测试贯穿了整个软件开发过程，软件开发生命周期的各个阶段中都少不了相应的测试，这种思想与软件质量保证的出发点是一致的。,8.2 各种软件测试在软件开发生命周期中的位置,适用于所有的软件生命周期的三个阶段,在软件规划阶段中， 主要进行软件目标的策划、 可行性研究和软件的需求分析

7、工作。,软件被定义之后， 进入开发阶段，主要对软件的体系架构、 数据结构和主要算法进行设计； 将设计用程序语言编码实现，并进行测试。,软件的运行与维护阶段在软件生命周期中 占据的比例最大。针对不同的需求，维护工作 一般可以分为纠错性维护、适应性维护、 扩充性维护和预防性维护等不同类型。,软件开发阶段还可细分为软件设计、编码和测试阶段,8.2.1 软件规划阶段的测试,产品策划 由项目经理确定进度计划、项目范围和开发产品所需的资源 规 划 阶 段 需求分析 由产品市场开发团队根据客户提出的要求来描述产品的需求,需求规格说明文档评审,这是否是真正的需求：描述的产品是否就是要开发的产品？ 需求是否完备

8、：第一个发布的版本是否需要更多的功能？ 需求是否兼容：在逻辑上是否矛盾？需求是否可实现？ 需求是否可实现？ 需求是否合理：在开发进度、费用、产品性能、可靠性之间存在平衡关系，这些都考虑到了吗？是否认识到应该根据实际安排一个优先级计划？ 需求是否可测试：从测试的角度出发，判断这 样的需 求实现的产品是否可以进行测试。 文档编写是否规范，描述是否正确、完整和一致。,需求规格说明文档评审,在需求规格说明评审通过后，测试或质量保证人员就可以以该文档为依据编写测试计划。并以同行评审（Peer Review）的方式对测试计划进行评审。评审人员应该包括项目以外的测试或质量保证人员、项目经理和开发人员（非必需

9、）。,8.2.2 软件设计阶段的测试,定义 软件设计阶段是设计人员将软件需求转换为语言文字和图表的集合，用来描述系统结构、数据结构、算法和用户界面。根据不同的设计方法和模式，设计分为外部设计和内部设计，或者分为高层设计（或概要设计）和低层设计（或详细设计）。 设计描述 外部设计主要从用户的角度对产品进行描述，内部设计则描述产品的内部工作机制。它们是并行展开，相互制约，相互要求。概要设计描述了总体上系统架构应该包含的组成元素，各个模块之间的关联。详细设计主要描述各个模块如何实现以及所用的算法和数据结构。,8.2.2 软件设计阶段的测试,由于设计依赖于需求文档，如果文档不存在、不完善或者始终处于变

10、更之中，设计人员就需要与需求分析人员沟通，以确定软件产品应该具备什么能力。因此设计阶段也是对软件需求的深化理解和完善阶段。,设计文档进行评审,设计是否满足需求：如果需求规格说明文档是非正式的，可变的或是有歧义的，那么设计文档就是对产品需求的第一份正式说明。管理人员和市场营销人员应该从这个角度来评审文档，而不仅仅局限于设计本身。同时还需要建立需求和设计之间的映射关系，可以很好地追踪软件设计和需求的关系，从而避免设计上的遗漏。 设计是否完备：它是否规定了模块间的关系，模块如何传递数据，异常条件下会发生什么，每个模块是否赋予了初始状态等。 设计是否良好：能否产出高效、简洁、可测试、可维护的软件产品。

11、 设计是否可行：计算机能运行这么快吗？内存够吗？数据库中的数据检索速度能达到这么快吗？ 设计的错误处理程度如何。 同时还要评审文档编写是否规范，描述是否正确、完整和一致。,评审会议：,评审会议通常由 会议管理者（也是召集者）主持，会议的目的在于识别出设计中存在的 问题，而如何修改和设计不是会议的内容。 评审人员把一系列问题带入到会议中，评审的目的在于生成一个问题列 表，并确认设计人员是否理解了其中的歧义或者容易混淆的问题。 会议记录人员记录下所有达成共识的意见和遗留到下次要解决的问题。 在概要设计和详细设计评审通过后，测试或质量保证人员就可以以该文档为依据编写测试用例，并以同行评审的方式对测试

12、用例进行评审。评审人员应该包括项目以外的测试或质量保证人员、项目经理和开发人员（非必需）。,8.2.3 软件开发编码阶段的测试,在编码阶段程序员编写代码并对程序进行测试。这里的测试我们称之为白盒测试，它是编码期间可供程序员使用的测试类型。白盒测试有别于黑盒测试，后者将程序视为一个黑盒子，你无法看到里面的内容。而白盒测试需要程序员运用自己的理解能力，深入到源程序中以开发测试用例。,通常认为白盒测试是编程过程的一部分，这是因为当模块与系统其他部分集成之前或之后，程序员常规地都会对模块进行白盒测试。,8.2.3 软件开发编码阶段的测试,白盒测试又可以分为静态测试和动态测试。静态测试只要求提供程序的源

13、代码，代码被检查而不执行。动态测试则执行代码，代码被测试而不被检查。静态测试可以人工完成也可以借助专门的工具。 人工静态测试方法: （1）个人的代码走查（Walk Through） （2）小组的代码检查（Inspection） （3）代码评审（Review） 人工静态测试目的：由人阅读代码，以确定以下内容： 代码是否能够满足功能需求 代码是否与初期开发的设计一致 是否遗漏功能代码 代码是否恰当地处理了错误,8.2.3 软件开发编码阶段的测试,结构测试：属于动态白盒测试 主要考虑：代码 代码的结构 内部设计以及设计是如何转化为代码的。 结构测试可分为： 1.单元测试 2.覆盖测试。 单元测试是结

14、构测试的基本部分，它是对过程或程序的单个小部分 进行测试。 单元测试有很多种方法。 由于程序员了解输入变量和对应的预期输出变量，可以执行一些容易的快速测试，以检查所有明显的错误。 对包含复杂逻辑和条件的模块，程序员可以构建一种调试版本，加入一些中间打印语句，监测循环或迭代次数。重要的是一定要在修改了缺陷后删除这些语句。 在调试器或集成开发环境中运行被测产品，设置断点并观察各种系统参数或变量。 总结：这些方法更像“调试”而不是“测试”，它与代码的结构知识密切相关。,覆盖测试,覆盖测试,覆盖测试要求,Contents,Contents,了解代码和逻辑,了解如何编写能够覆盖更多代码的有效的测试用例,

15、测试也可以叫做“灰盒测试”，因为它为了提高有效性综合使用了白盒和黑盒测试方法,功能覆盖,语句覆盖,路径覆盖,条件覆盖,覆盖测试时运行测试用例考察代码的不同部分，包括设计和执行测试用例，并确定测试覆盖的代码百分比。覆盖测试有以下几类覆盖。,集成测试,定义 由于系统是逐步开发出来的，是过程与模块的集合。一旦单个部件能够运行，就将一些部件放在一起测试。将产品的各个部分组装起来测试称为集成测试。 目标 发现与接口有关的问题 列子： 如数据穿过接口时有可能丢失；一个模块对另一个模块可能由于疏忽的问题而造成有害的影响；把子功能组合起来可能不产生预期的主功能；全程数据结构有可能有错误等,集成测试,集成测试更

16、多采用灰盒测试，即白盒加黑盒测试的方法。 主要几种集成测试的策略： （1）增量测试（incremental test）：又分为自顶向下（Top-Down）、自底向上（Bottom-Up）和混合式集成的策略。 （2）大爆炸测试（big bang test）：是一种非增量集成策略，也称为一次性组装或整体拼装。 （3）冒烟测试（smoke test）：当项目开发的时间比较紧的时候可以考虑冒烟测试的方法，软件团队的人员可以定期地操作这个软件系统。 冒烟测试包括如下的活动。 将已经完成编码的模块集成为一个build系统，包括数据文件、库文件、重用模块和实现部分功能的组件。 对这个build系统做一系列的测试，发现错误，使得该系统可以正确运行功能。 将一个build系统与另外的build系统不断地组合，最后整合为一个产品，这个产品可以每天进行测试。,集成测试,从单元测试到集成测试，直到系统