第八章软件测试与软件开发过程

1、软件测试与软件开发过程8.1.1 软件开发生命周期模型 1.软件开发过程概述 2. 各种软件测试在软件开发生命周期中的位置内容提要内容提要定义：定义： 软件测试软件测试是软件工程（是软件工程（software engineering）的一个重要分支，随着软件工）的一个重要分支，随着软件工程学科的发展，现在的软件测试与传统的软件测试相比有了很大的发展，它与软件程学科的发展，现在的软件测试与传统的软件测试相比有了很大的发展，它与软件开发过程和软件质量保证（开发过程和软件质量保证（quality assurance，qa）密切相关。）密切相关。 软件开发过程软件开发过程是生产软件产品所用的工具、方法

2、和实践过程的集合。在商业上是生产软件产品所用的工具、方法和实践过程的集合。在商业上软件开发通常是由一组协同工作的人来完成的，我们把这组人称为开发团队。开发软件开发通常是由一组协同工作的人来完成的，我们把这组人称为开发团队。开发团队里有各种角色，一个人可以充当不止一个角色，特别是在许多小公司，有时一团队里有各种角色，一个人可以充当不止一个角色，特别是在许多小公司，有时一个人身上集中了几个角色。个人身上集中了几个角色。 生命周期 一个软件产品是由上述多种角色的团队协同工作而完成的。从策划、定义、开发、使用与维护直到最后废，要经过一个漫长的时期，通常把这个时期称为软件的生命周期（software l

3、ife cycle），很多人也把它称为软件开发生命周期（software development life cycle）。8.1 软件开发过程概述软件开发过程概述各种角色及主要职责l 项目经理（程序经理）：负责管理产品的质量，以及项目的进度和预算。l 商业分析师（软件分析师）：分析客户的真正需求，用能被程序员或其他设计人员理解的术语来定义客户的需求。l 架构师（系统工程师）：是产品小组的专家，负责系统的总体内部设计（定义代码，数据结构，数据通信和开发策略等）。l 程序员（开发人员）：设计、编写程序并编写内部设计规格说明。l 测试员（质量保证员）：负责找出并报告软件产品的问题。l 产品经理（产品

4、营销经理）：负责符合公司长期战略和形象的产品的交付，并在产品发布后负责市场营销活动。对产品的盈利负责。l 技术支持代表：负责处理客户投诉和服务的小组的成员。在产品开发期间他们会尽力对产品的设计和手册的内容施加影响，以减少客户的投诉。l 技术文档编写员：制作用户手册和在线帮助。瀑布模型（waterfall model） 几个特征：几个特征：（1）阶段间的顺序性和依赖性）阶段间的顺序性和依赖性（2）推迟实现的观点）推迟实现的观点（3）质量保证的观点）质量保证的观点缺点：缺点：（1）不适应需求经常发生变更的环境。）不适应需求经常发生变更的环境。（2）瀑布模型也经常不能接受项目开始）瀑布模型也经常不能

5、接受项目开始阶段自然存在的不确定性。阶段自然存在的不确定性。（3）线性顺序模型种特征导致工作中发）线性顺序模型种特征导致工作中发生生“阻塞阻塞”状态。状态。8.1.1 软件开发生命周期模型 模型种类种类有瀑布模型、原型模型、快速应用开发模型、增量模型、螺旋模型、v模型、形式方法模型、rup（rational unified process）模型、敏捷过程模型、构件组装模型、并发开发模型等。 几种比较流行的模型 1传统的瀑布模型（waterfall model） 2原型模型（prototyping model） 3螺旋模型（spiral model）原型模型（prototyping model）

6、 在项目开发的初始阶段，人们对软件的需求认识常常不够清在项目开发的初始阶段，人们对软件的需求认识常常不够清晰，使得开发项目难以做到一次开发成功，出现返工再开发在所晰，使得开发项目难以做到一次开发成功，出现返工再开发在所难免。因此，可以先做试验开发，其目标只是探索可行性，弄清难免。因此，可以先做试验开发，其目标只是探索可行性，弄清软件需求；然后在此基础上获得较为满意的软件产品。通常把第软件需求；然后在此基础上获得较为满意的软件产品。通常把第一次得到的试验性产品称为一次得到的试验性产品称为“原型原型”。螺旋模型（spiral model）优点：优点： 1.瀑布模型与原型的迭代特征结合起来，加入两种

7、模型均忽略了的风险分析。 2.能够快速开发软件的增量版本。 3.不要求每一个增量都是可以运行的程序。4.划分为若干个框架活动，活动也称划分为若干个框架活动，活动也称为任务区域。为任务区域。包括包括制定计划 风险分析 实施工程 客户评估8.1.2 软件测试与软件开发过程的关系狭义定义测试： 比如“程序设计”与“测试”之间的关系，传统上总以为程序设计在先，测试在后。这种专指测试程序代码，定义在编码之后的“测试”是一种狭义定义的测试。广义定义定义测试： 这种测试活动可以在软件开发生命周期的任何阶段进行。但是，随着开发不断地进行，越到后续阶段，找出错误并改正它的代价会越大全新的软件开发模式： 以测试驱

8、动软件开发。软件测试贯穿了整个软件开发过程，软件开发生命周期的各个阶段中都少不了相应的测试，这种思想与软件质量保证的出发点是一致的。8.2 各种软件测试在软件开发生命周期中的位置适用于所有的软件生命周期的三个阶段适用于所有的软件生命周期的三个阶段软件规划软件规划软件开发软件开发运行与维护运行与维护在软件规划阶段中，在软件规划阶段中，主要进行软件目标的策划、主要进行软件目标的策划、可行性研究和软件的需求分析工作。可行性研究和软件的需求分析工作。软件被定义之后，软件被定义之后，进入开发阶段，主要对软件的体系架构、进入开发阶段，主要对软件的体系架构、数据结构和主要算法进行设计；数据结构和主要算法进行

9、设计；将设计用程序语言编码实现，并进行测试。将设计用程序语言编码实现，并进行测试。软件的运行与维护阶段在软件生命周期中软件的运行与维护阶段在软件生命周期中占据的比例最大。针对不同的需求，维护工作占据的比例最大。针对不同的需求，维护工作一般可以分为纠错性维护、适应性维护、一般可以分为纠错性维护、适应性维护、扩充性维护和预防性维护等不同类型。扩充性维护和预防性维护等不同类型。软件开发阶段还可细分为软件设计、编码和测试阶段软件开发阶段还可细分为软件设计、编码和测试阶段8.2.1 软件规划阶段的测试 产品策划 由项目经理确定进度计划、项目范围和开发产品所需的资源规划阶段 需求分析 由产品市场开发团队根

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

11、）的方式对测试计划进行评审。评审人员应该包括项目以外的测试或质量保证人员、项目经理和开发人员（非必需）。8.2.2 软件设计阶段的测试定义软件设计阶段是设计人员将软件需求转换为语言文字和图表的集合，用来描述系统结构、数据结构、算法和用户界面。根据不同的设计方法和模式，设计分为外部设计和内部设计，或者分为高层设计（或概要设计）和低层设计（或详细设计）。设计描述 外部设计主要从用户的角度对产品进行描述，内部设计则描述产品的内部工作机制。它们是并行展开，相互制约，相互要求。概要设计描述了总体上系统架构应该包含的组成元素，各个模块之间的关联。详细设计主要描述各个模块如何实现以及所用的算法和数据结构。8

12、.2.2 软件设计阶段的测试由于设计依赖于需求文档，如果文档不存在、不完善或者始终处于变更之中，设计人员就需要与需求分析人员沟通，以确定软件产品应该具备什么能力。因此设计阶段也是对软件需求的深化理解和完善阶段。设计文档进行评设计文档进行评审审设计是否满足需求：设计是否满足需求：如果需求规格说明文档是非正式的，可变的如果需求规格说明文档是非正式的，可变的或是有歧义的，那么设计文档就是对产品需求的第一份正式说明。或是有歧义的，那么设计文档就是对产品需求的第一份正式说明。管理人员和市场营销人员应该从这个角度来评审文档，而不仅仅局管理人员和市场营销人员应该从这个角度来评审文档，而不仅仅局限于设计本身。

13、同时还需要建立需求和设计之间的映射关系，可以限于设计本身。同时还需要建立需求和设计之间的映射关系，可以很好地追踪软件设计和需求的关系，从而避免设计上的遗漏。很好地追踪软件设计和需求的关系，从而避免设计上的遗漏。设计是否完备：设计是否完备：它是否规定了模块间的关系，模块如何传递数据，它是否规定了模块间的关系，模块如何传递数据，异常条件下会发生什么，每个模块是否赋予了初始状态等。异常条件下会发生什么，每个模块是否赋予了初始状态等。设计是否良好：设计是否良好：能否产出高效、简洁、可测试、可维护的软件产能否产出高效、简洁、可测试、可维护的软件产品。品。设计是否可行：设计是否可行：计算机能运行这么快吗？

14、内存够吗？数据库中的计算机能运行这么快吗？内存够吗？数据库中的数据检索速度能达到这么快吗？数据检索速度能达到这么快吗？设计的错误处理程度如何。设计的错误处理程度如何。同时还要评审文档编写是否规范，描述是否正确、完整和一致。同时还要评审文档编写是否规范，描述是否正确、完整和一致。评审会议通评审会议通常由会议管理者（也是召集者）主持，会议的目的在评审会议通常由会议管理者（也是召集者）主持，会议的目的在于识别出设计中存在的问题，而如何修改和设计不是会议的内容。评审人于识别出设计中存在的问题，而如何修改和设计不是会议的内容。评审人员把一系列问题带入到会议中，评审的目的在于生成一个问题列表，并确员把一系

15、列问题带入到会议中，评审的目的在于生成一个问题列表，并确认设计人员是否理解了其中的歧义或者容易混淆的问题。会议记录人员记认设计人员是否理解了其中的歧义或者容易混淆的问题。会议记录人员记录下所有达成共识的意见和遗留到下次要解决的问题。录下所有达成共识的意见和遗留到下次要解决的问题。在概要设计和详细设计评审通过后，测试或质量保证人员就可以在概要设计和详细设计评审通过后，测试或质量保证人员就可以以该文档为依据编写测试用例，并以同行评审的方式对测试用例进行评审。以该文档为依据编写测试用例，并以同行评审的方式对测试用例进行评审。评审人员应该包括项目以外的测试或质量保证人员、项目经理和开发人员评审人员应该

16、包括项目以外的测试或质量保证人员、项目经理和开发人员（非必需）。（非必需）。8.2.3 软件开发编码阶段的测试在编码阶段程序员编写代码并对程序进在编码阶段程序员编写代码并对程序进行测试。这里的测试我们称之为白盒测试，它是行测试。这里的测试我们称之为白盒测试，它是编码期间可供程序员使用的测试类型。白盒测试编码期间可供程序员使用的测试类型。白盒测试有别于黑盒测试，后者将程序视为一个黑盒子，有别于黑盒测试，后者将程序视为一个黑盒子，你无法看到里面的内容。而白盒测试需要程序员你无法看到里面的内容。而白盒测试需要程序员运用自己的理解能力，深入到源程序中以开发测运用自己的理解能力，深入到源程序中以开发测试

17、用例。试用例。 通常认为白盒测试是编程过程的一部分，这是因为当模块与系统其他部分集成之前或之后，程序员常规地都会对模块进行白盒测试。尽管大多数测试方面的书籍都会花很多篇幅来介绍白盒测试技术，作者们希望测试人员和程序员都进行白盒测试，但是在实际的软件开发项目中通常都是由程序员完成白盒测试。8.2.3 软件开发编码阶段的测试 白盒测试又可以分为静态测试和动态测试。静态测试只要求提供程序的源代码，代码被检查而不执行。动态测试则执行代码，代码被测试而不被检查。静态测试可以人工完成也可以借助专门的工具。人工静态测试方法:（1）个人的代码走查（walk through）（2）小组的代码检查（inspect

18、ion）（3）代码评审（review）其目的是由人阅读代码以确定以下内容。代码是否能够满足功能需求代码是否与初期开发的设计一致是否遗漏功能代码代码是否恰当地处理了错误8.2.3 软件开发编码阶段的测试结构测试属于动态白盒测试，它主要考虑代码、代码的结构测试属于动态白盒测试，它主要考虑代码、代码的结构、内部设计以及设计是如何转化为代码的。结构测试又可以结构、内部设计以及设计是如何转化为代码的。结构测试又可以分为单元测试和覆盖测试。分为单元测试和覆盖测试。单元测试是结构测试的基本部分，它是对过程或程序的单元测试是结构测试的基本部分，它是对过程或程序的单个小部分进行测试。单元测试有很多种方法。单个小

19、部分进行测试。单元测试有很多种方法。由于程序员了解输入变量和对应的预期输出变量，可以由于程序员了解输入变量和对应的预期输出变量，可以执行一些容易的快速测试，以检查所有明显的错误。执行一些容易的快速测试，以检查所有明显的错误。对包含复杂逻辑和条件的模块，程序员可以构建一种调对包含复杂逻辑和条件的模块，程序员可以构建一种调试版本，加入一些中间打印语句，监测循环或迭代次数。重要的试版本，加入一些中间打印语句，监测循环或迭代次数。重要的是一定要在修改了缺陷后删除这些语句。是一定要在修改了缺陷后删除这些语句。在调试器或集成开发环境中运行被测产品，设置断点并在调试器或集成开发环境中运行被测产品，设置断点并

20、观察各种系统参数或变量。观察各种系统参数或变量。这些方法更像这些方法更像“调试调试”而不是而不是“测试测试”，它与代码的结，它与代码的结构知识密切相关。构知识密切相关。覆盖测试覆盖测试覆盖测试覆盖测试要求覆盖测试要求 contents contents 了解代码和逻辑,了解如何编写能够覆盖更多代码的有效的测试用例 测试也可以叫做“灰盒测试”，因为它为了提高有效性综合使用了白盒和黑盒测试方法功能覆盖功能覆盖语句覆盖语句覆盖 路径覆盖路径覆盖条件覆盖条件覆盖 覆盖测试时运行测试用例考察代码的不同部分，包括设计和执行测试用例，并确定测试覆盖的代码百分比。覆盖测试有以下几类覆盖。集成测试定义定义 由于

21、系统是逐步开发出来的，是过程与模块的集合。一由于系统是逐步开发出来的，是过程与模块的集合。一旦单个部件能够运行，就将一些部件放在一起测试。将产品旦单个部件能够运行，就将一些部件放在一起测试。将产品的各个部分组装起来测试称为集成测试。的各个部分组装起来测试称为集成测试。目标目标 发现与接口有关的问题发现与接口有关的问题列子：列子：如数据穿过接口时有可能丢失；一个模块对另一个模块可能如数据穿过接口时有可能丢失；一个模块对另一个模块可能由于疏忽的问题而造成有害的影响；把子功能组合起来可能由于疏忽的问题而造成有害的影响；把子功能组合起来可能不产生预期的主功能；全程数据结构有可能有错误等不产生预期的主功

22、能；全程数据结构有可能有错误等集成测试集成测试更多采用灰盒测试，即白盒加黑盒测试的方法。集成测试更多采用灰盒测试，即白盒加黑盒测试的方法。 主要几种集成测试的策略：主要几种集成测试的策略： （1）增量测试（）增量测试（incremental test）：又分为自顶向下（）：又分为自顶向下（top-down）、自底向上（）、自底向上（bottom-up）和混合式集成的策略。）和混合式集成的策略。（2）大爆炸测试（）大爆炸测试（big bang test）：是一种非增量集成策略，）：是一种非增量集成策略，也称为一次性组装或整体拼装。也称为一次性组装或整体拼装。（3）冒烟测试（）冒烟测试（smoke

23、 test）：当项目开发的时间比较紧的）：当项目开发的时间比较紧的时候可以考虑冒烟测试的方法，软件团队的人员可以定期地操作这个软时候可以考虑冒烟测试的方法，软件团队的人员可以定期地操作这个软件系统。件系统。冒烟测试包括如下的活动。冒烟测试包括如下的活动。将已经完成编码的模块集成为一个将已经完成编码的模块集成为一个build系统，包括数据文件、系统，包括数据文件、库文件、重用模块和实现部分功能的组件。库文件、重用模块和实现部分功能的组件。对这个对这个build系统做一系列的测试，发现错误，使得该系统可以系统做一系列的测试，发现错误，使得该系统可以正确运行功能。正确运行功能。将一个将一个build

24、系统与另外的系统与另外的build系统不断地组合，最后整合为系统不断地组合，最后整合为一个产品，这个产品可以每天进行测试。一个产品，这个产品可以每天进行测试。集成测试从单元测试到集成测试，直到系统测试之从单元测试到集成测试，直到系统测试之前，通常都是由程序员完成。由于集成测试的复前，通常都是由程序员完成。由于集成测试的复杂程度取决于具体的软件系统，有的软件项目会杂程度取决于具体的软件系统，有的软件项目会让测试人员共同参与集成测试。在测试人员不参让测试人员共同参与集成测试。在测试人员不参与集成测试的情况下，在本阶段测试人员应该根与集成测试的情况下，在本阶段测试人员应该根据概要设计和详细设计编写测

25、试用例。而对于需据概要设计和详细设计编写测试用例。而对于需要采用自动化测试的部分要进行自动化测试设计要采用自动化测试的部分要进行自动化测试设计和脚本编写。和脚本编写。8.2.4 软件测试阶段的测试 when? 当程序员完成编码将系统提交给测试小组做进一步测试，就进入软件测试阶段。测试人员在测试阶段进行系统测试。定义：定义： 系统测试是将集成测试的软件系统，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等元素结合在一起，对计算机系统进行一系列的组装测试和确认测试。系统测试可以是将产品提交给用户之前的最后一个测试，除非有用户接收测试（user acceptance test）。系统测试多采用黑盒测试技术，它的依据是需求规格，也就是说系统测试应该覆盖需求规格。由于需求规格主要包括功能性和非功能性需求（如性能需求），系统测试也主要包括功能测