1、第二章第二章 软件测试流程软件测试流程n概述n测试计划n测试设计n单元测试n集成测试n确认测试n系统测试n验收测试n评估测试n测试计划 根据用户需求报告中关于功能要求和性能指标的规格说明书，定义相应的测试需求报告，使得随后所有的测试工作都将围绕着测试需求来进行。同时，适当选择测试内容，合理安排测试人员、测试时间及测试资源等。n测试设计 测试设计是指将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程，并为每个测试过程选择适当的测试用例，保证测试结果的有效性。测试执行 执行测试开发阶段建立的自动测试过程，并对所发现的缺陷进行跟踪管理。测试执行一般由单元测试、组合测试、集成测试以及回归测
2、试等步骤组成。测试评估 结合量化的测试覆盖域及缺陷跟踪报告，对于应用软件的质量和开发团队的工作进度及工作效率进行综合评价。测试计划的依据主要是项目开发计划和测试需求分析结果而制定。测试计划一般包括测试背景、测试依据、测试资源、测试策略和测试日程等内容。根据测试计划设计测试方案，测试设计过程输出的是各测试阶段使用的测试用例，为每一个测试需求确定测试用例集，并且确定执行测试用例的测试过程。根据软件测试计划、软件需求、软件构架设计、软件详细设计等文档内容，具体如下：n对每一个测试需求，确定其需要的测试用例。n对每一个测试用例，确定其输入及预期结果。n确定测试用例的环境配置、驱动程序。n编写测试用例文
3、档n对测试用例进行同行评审 测试人员需要搭建测试环境，应尽可能的模拟被测系统的实际应用工作所必需的软件、硬件系统、网络设备、历史数据和支持条件等，测试执行过程又分为以下测试阶段：单元测试、集成测试、确认测试、验收测试等。n软件开发是一个自顶向下，逐步细化的过程。n软件测试则是依相反顺序的自底向上，逐步集成的过程。低一级的测试为上一级的测试准备条件。集成测试确认测试系统测试单元测试单元测试单元测试单元测试模块模块模块模块已测模块设计信息集成的软件确认的软件软件需求其它系统元素集成测试确认测试系统测试单元测试单元测试单元测试单元测试模块模块模块模块模块模块模块已测模设计信息设计信息集成的软件确认的
4、软软件需求软件需求 单元测试是在软件开发过程中进行的最低级别的测试活动，其测试的对象是软件设计的最小单位。例如：传统的结构化编程语言中，比如C语言，单元测试的对象一般是函数或子过程。在像C+这样的面向对象的语言中，单元测试的对象可以是类，或类的成员函数。对Ada语言，单元测试可以在独立的过程和函数上进行，也可以在Ada包的级别上进行。单元测试的原则同样也可以扩展到第四代语言(4GL)中，这时单元被典型地定义为一个菜单或显示界面。单元测试又称为模块测试，什么是模块？并没有严格的定义，不过按照一般的理解，模块应该具有以下的一些基本属性：名字；明确规定的功能；内部使用的数据，或称局部数据；与其它模块
5、或外界的数据联系；实现其特定功能的算法；可被其上层模块调用，也可调用其下属模块进行协同工作。单元测试过程n模块接口测试对被测模块，检测数据能否正确无误地进入和流出模块；n模块局部数据结构测试检测模块在工作过程中，其内部数据能否保持其完整性，包括内部数据的内容、形式以及相互之间关系；n模块边界条件测试检测在数据边界处，模块能否正常工作；n覆盖测试检测模块运行能否满足特定的逻辑覆盖；n出错处理检测检测模块出错处理是否有效。由于每个模块在整个软件中并不是孤立的，在对每个模块进行单元测试时，需要考虑它和周围模块的相互联系。为模拟这一联系，在进行单元测试时，必须设置若干个辅助测试模块。这些辅助模块分为两
6、种：驱动模块（driver）:用以模拟被测模块上级模块，相当于被测模块的主程序。桩模块（stub）:用以模拟被测模块的下级模块，相当于被测模块调用的子模块。被测模块与其相关的驱动模块和桩模块共被测模块与其相关的驱动模块和桩模块共同构成了一个同构成了一个“测试环境测试环境”。1999年9月，火星气象人造卫星在经过41周416亿英里的成功飞行之后，在就要进入火星轨道时失败了。美国投资5万美元调查事故原因，发现：太空科学家使用的是英制(磅)加速度数据，而喷气推进实验室采用公制(牛顿)加速度数据进行计算。模块相互调用时引入了新的问题；几个子功能组合起来不能实现主功能；误差不断积累达到不可接受的程度；全
7、局数据结构出现错误等。集成测试集成测试非增式测试非增式测试 增式测试增式测试 自顶向下测试自顶向下测试自底向上测试自底向上测试独立地测试程序的每个模块，然后再把它们组合成整个程序的集成测试方法。把下一个待测试的模块组合到已经测试过的那些模块上去，再进行测试。从主控模块开始，按照软件的控制层次结构，逐步把各个模块集成在一起。从最下层的模块开始，按照程序的层次结构，逐渐形成完整的整体。n非增式集成测试法：独立地测试该程序的每个模块，然后再把它们组合成整个程序的方法。n增式集成测试法：把下一个待测试的模块组合到已经测试过的那些模块上去，再进行测试的方法。测试每一个模块都需要驱动模块和桩模块。n驱动模
8、块用以模拟被测模块的上级模块，用来驱动或传送测试用例给被测模块，还须向测试者显示执行被模块所产生的结果。n桩模块由被测模块调用，以便检验被测模块与其下级模块之间的接口。非增式集成测试M1S1S2S3M2M3M4M5d1d2d3d4S4S5M6d5S6M7d6图图 6-2 非增式测试非增式测试M1S1S2S3M2M3M4M5d1d2d3d4S4S5M6d5S6M7d6M2M3M4M5d1d2d3d4S4S5M6d5M6d5S6M7d6图图 6-2 非增式测试非增式测试M1M2M3M4M5M7M6图图6-1 七模块的程序简图七模块的程序简图M1M2M3M4M5M7M6M1M2M3M4M5M7M6图
9、图6-1 在进行单元测试时，对模块M2和M4配备了驱动模块和桩模块，对模块M3，M5，M6和M7只配备了驱动模块，对主模块M1配备了3个桩模块，以模拟被它调用的3个模块M2、M3和M4。分别进行单元测试以后，再联接起来，进行集成测试。增式集成测试是另一种集成测试方法，它不是孤立地测试每一个模块，而是一开始就把待测试的模块与已测试过的模块联接起来。增式集成测试的过程，就是不断地把待测试的模块联接到已测试过的模块集(或其子集)上，对待测试模块进行测试，直到最后一个模块测试完毕。M1M2M3M4M5M7M6图图6-1 七模块的程序简图七模块的程序简图M1M2M3M4M5M7M6M1M2M3M4M5M
10、7M6图图6-1 七模块的程序简图七模块的程序简图增量测试方法的种类很多，比如从程序底部开始（自底向上）测试。先由4个人并行或顺序地测试模块M3，M5，M6和M7。这时，需为每个模块准备一个驱动模块，但不需要准备桩模块。然后测试模块M2和M4，它们不是孤立地测试，而是把M2联在模块M5和M6上，模块M4联在模块M7上，也就是如果要测试模块M2，先要设计一个驱动模块，再对模块对M2M5，M2M6进行测试。n非增式集成测试方法工作量大。n增式集成测试中，能够较早地检查出模块之间接口的错误。n增式集成测试，查找故障比较容易。n增式集成测试可以更彻底地对程序进行测试。n非增式集成测试方法需要的机器时间
11、较少。n采用非增式集成测试，所有模块可以同时进行并行测试。非增式与增式的比较 增式集成是构造程序结构的一种方式，按照不同的模块集成方式，又分为自顶向下增式测试和自底向上增式测试两种。l自顶向下集成从主控模块开始，按照软件的控制层次结构，逐步把各个模块集成在一起。l自底向上集成则从最下层的模块开始，按照程序的层次结构，逐渐形成完整的整体。原则：下一次要测试的模块，至少有一个调用它的模块已经测试过。自顶向下增式测试的具体步骤为：1）对主控模块进行测试，然后以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块逐渐用实际模块替代；2）依据所选的集成策略，每次只替代一个桩模块；3）每集
12、成一个模块立即测试一遍；4）只有每组测试完成后，才着手替换下一个桩模块；5）为避免引入新故障，需不断地进行回归测试（即全部或部分地重复已做过的测试）。从第二步开始，循环执行上述步骤，直至整个程序结构构造完毕。先测试模块M1。要测试模块M1，必须先编写出表示模块M2、M3和M4的各个桩模块s1,s2和s3，以模拟被M1调用的模块。测试完M1后，将由下一个要测试的模块来代替其中一个桩模块，并加入这个模块所需要的桩模块。M1S1S2S3图图6-4（a）自顶向下集成测试自顶向下集成测试M1S1S2S3图图6-4（a）自顶向下集成测试自顶向下集成测试M1M2S2S3图图6-4（b）自顶向下集成测试自顶向
13、下集成测试 S4S5 测试了主模块之后，有几种可能的测试顺序：nM1，M2，M3，M4，M5，M6，M7，M8，M9，M10，M11，M12nM1，M2，M5，M6，M10，M3，M7，M11，M4，M8，M12，M9nM1，M4，M8，M9，M11，M12，M3，M7，M2，M6，M10，M5nM1，M2，M6，M10，M4，M9，M5，M3，M7，M11，M8，M12下面两点是应该考虑的：下面两点是应该考虑的：1 1）如果程序中有关键性的部分，设计次序就）如果程序中有关键性的部分，设计次序就应该尽早地把这些模块加入进程序。所谓应该尽早地把这些模块加入进程序。所谓“关键关键部分部分”可能是一
14、个复杂的模块，一个具有新算法可能是一个复杂的模块，一个具有新算法的模块，或怀疑容易出错的模块。的模块，或怀疑容易出错的模块。2 2）设计次序时，要让）设计次序时，要让输入输入/输出模块输出模块尽早尽早地加入测试。地加入测试。如果模块如果模块M10，和，和M9是是输入输出模块并且输入输出模块并且M7执行一些关键性的功能，执行一些关键性的功能，那么增量顺序最好是：那么增量顺序最好是：M1，M2，M6，M10，M4，M9，M3，M7，M5，M11，M8，M12 并且第并且第6次增量测试后的次增量测试后的程序形式程序形式M 1M 2S2M 4S4M 6S7M 9M 10图 6-5自 顶 向 下 测 试
15、 的 中 间 状 态M 1M 2S2M 4S4M 6S7M 9M 10图 6-5自 顶 向 下 测 试 的 中 间 状 态 自顶向下测试可以自然地做到逐步求精，让测试人自顶向下测试可以自然地做到逐步求精，让测试人员看到系统的雏型，有助于对程序的主要控制和决策员看到系统的雏型，有助于对程序的主要控制和决策模块进行检验，增强测试人员的信心。模块进行检验，增强测试人员的信心。不足之处不足之处在于：测试较高层模块时，由于低层处理在于：测试较高层模块时，由于低层处理用桩模块替代，不能反映真实情况，重要数据不能及用桩模块替代，不能反映真实情况，重要数据不能及时回送到上层模块，观察和解释测试输出往往比较困时
16、回送到上层模块，观察和解释测试输出往往比较困难的。难的。为了解决这个问题，可以采用几种办法：为了解决这个问题，可以采用几种办法：把某些模块测试推迟到用真实模块替代桩模块之把某些模块测试推迟到用真实模块替代桩模块之后进行；后进行；开发出能模拟真实模块的桩模块；开发出能模拟真实模块的桩模块；采用自底向上集成测试方法。采用自底向上集成测试方法。2.自底向上增式集成测试自底向上增式集成测试 自底向上增式集成测试是从软件结构的最下层模自底向上增式集成测试是从软件结构的最下层模块开始测试的，测试较高层模块时，所需的下层块开始测试的，测试较高层模块时，所需的下层模块功能都已具备，所以不再需要桩模块。模块功能
17、都已具备，所以不再需要桩模块。自底向上增式集成测试的步骤为：自底向上增式集成测试的步骤为：1）把低层模块组织成实现某个子功能的模块群;2）开发一个测试驱动模块，控制测试数据的输入和测试结果的输出；3）对每个模块群进行测试；4）删除测试使用的驱动模块，用较高层模块把模块群组织成为完成更大功能的新模块群。从第一步开始循环执行上述各步骤，直至整个程序构造完毕。自底向上集成测试自底向上测试自底向上测试 d6M5d1d2d3M11d5d4d6M5d1M5d1d2d2d3d3d5(a)(b)(c)(d)(e)(f)d4d4M7M9M10M12第一步顺序地或并行地测试M5，M7，M9，M10，M11和M12
18、中的部分模块或全部模块。每一模块都需要专门的驱动模块：这个驱动模块可以接受测试输入，可以调用正在测试的模块，并且可以显示结果或将实际输出与期望输出进行比较。图6-7自底向上测试的中间状态M6M10d7M4M8M9M11M12d7(a)(b)图6-7自底向上测试的中间状态M6M10d7M6M10d7M4M8M9M11M12d7M4M8M9M11M12M4M8M9M11M12d7(a)(b)影响测试顺序的因素是模块的关键性质。影响测试顺序的因素是模块的关键性质。如果可以确定模块如果可以确定模块M4M4和和M6M6是关键的，那么自底是关键的，那么自底向上增式测试的中间状态可能如图所示。向上增式测试的
19、中间状态可能如图所示。优点：优点：自底向上测试方法不需要桩模块，测试用自底向上测试方法不需要桩模块，测试用例的设计亦相对比较简单例的设计亦相对比较简单,也不存在还没把前面的也不存在还没把前面的模块完全测试却又开始测试另一模块的问题。如模块完全测试却又开始测试另一模块的问题。如果关键的模块是在结构图的底部，自底向上测试果关键的模块是在结构图的底部，自底向上测试具有一定的优越性。具有一定的优越性。缺点：缺点：在测试初期不能呈现出被测软件系统的轮在测试初期不能呈现出被测软件系统的轮廓。实际上，直到最后一个模块廓。实际上，直到最后一个模块(模块模块M1)M1)加入时加入时才具有整体形象，才能形成完整的
20、程序。才具有整体形象，才能形成完整的程序。集成方法集成方法 优点优点缺点缺点自顶向下自顶向下测试测试1.如果主要故障发生在程序的顶端时，有利于查出故障。2.一旦加入I/O功能，测试用例易于形成。3.初期的程序轮廓可以让人们看到程序的功能，增强信心1.需要桩模块。2.在I/O功能加入以前，很难描述测试用例。3.很难观察测试输出。4.使人想推迟完成某些模块的测试。自底向上自底向上测试测试1.如果主要故障发生在程序的底端时，有利于查出故障。2.测试用例生成容易。3.观察测试结果容易。1.需要驱动程序。2.在加入最后一个每卡之前，程序不能作为一个整体存在。系统测试实际上是针对系统中各个组成部进系统测试
21、实际上是针对系统中各个组成部进行的综合性检验，很接近我们的日常测试实践。行的综合性检验，很接近我们的日常测试实践。系统测试的目标不是要找出软件故障，而是系统测试的目标不是要找出软件故障，而是要证明系统的性能要证明系统的性能 系统开发人员不能进行系统测试。系统开发人员不能进行系统测试。系统开发组织不能负责系统测试。系统开发组织不能负责系统测试。系统测试最好由独立的测试机构完成。系统测试最好由独立的测试机构完成。验收测试是将最终产品与最终用户的当前需求验收测试是将最终产品与最终用户的当前需求进行比较的过程，是软件开发结束后，软件产品向进行比较的过程，是软件开发结束后，软件产品向用户交付之前进行的最
22、后一次质量检验活动，回答用户交付之前进行的最后一次质量检验活动，回答开发的软件产品是否符合预期的各项要求，用户是开发的软件产品是否符合预期的各项要求，用户是否接受等问题。否接受等问题。验收测试不只检验软件某方面的质量，还要进验收测试不只检验软件某方面的质量，还要进行全面的质量检验并决定软件是否合格。因此验收行全面的质量检验并决定软件是否合格。因此验收测试是一项严格的正规的测试活动，并且应该在生测试是一项严格的正规的测试活动，并且应该在生产环境中而不是开发环境中进行。产环境中而不是开发环境中进行。明确规定验收测试通过的标准；明确规定验收测试通过的标准；确定验收测试方法；确定验收测试方法；确定验收
23、测试的组织和可利用的资源；确定验收测试的组织和可利用的资源；确定测试结果的分析方法；确定测试结果的分析方法；制定验收测试计划并进行评审；制定验收测试计划并进行评审；设计验收测试的测试用例；设计验收测试的测试用例；审查验收测试的准备工作；审查验收测试的准备工作；执行验收测试；执行验收测试；分析测试结果，决定是否通过验收。分析测试结果，决定是否通过验收。n 验证是对软件产品进行人工检查或评审。验证是对软件产品进行人工检查或评审。n验证的基本方法有：软件审查、走查、伙伴检查等。验证的基本方法有：软件审查、走查、伙伴检查等。软件审查走 查伙伴检查主持人非该软件的编制人员 任何人没有参与人员36人小组多
24、一些人12人准备有只有主持人无数据收集有不要求无输出报告有不要求口头评论优点有效能使更多人熟悉产品 费用低缺点短期成本高查出的故障较少查出的故障较少n 正式正式评审、技术评审以及软件审查会是审查的评审、技术评审以及软件审查会是审查的几种不同说法。几种不同说法。n 软件审查以会议的形式进行，利用集体的智慧软件审查以会议的形式进行，利用集体的智慧查找软件产品中存在的问题，从而保证软件产品查找软件产品中存在的问题，从而保证软件产品的质量。的质量。n 软件审查的对象可以是任何重要的工作产品，软件审查的对象可以是任何重要的工作产品，例如：需求分析、概要设例如：需求分析、概要设计、详细设计等阶段的计、详细
25、设计等阶段的成果以及源程序代码、测试计划和测试用例等。成果以及源程序代码、测试计划和测试用例等。n软件软件审查的目标是：审查的目标是：收集数据，发现软件故障。收集数据，发现软件故障。交流。信息。交流。信息。n软件审查的基本要素：软件审查的基本要素：确定问题。遵守规则。准备。编写报告。n软件软件审查的输入：审查的输入：被审查的文档；被审查的文档；有关的原始资料：有关的原始资料：审查单审查单n软件审查的输出：软件审查的输出：审查汇总审查汇总/报告报告 有关故障类型的数据。有关故障类型的数据。软件软件审查的步骤：审查的步骤：制定计划；准备；审查会；返工；终审。n 走查不像软件审查那么正式，准备工作一
26、般由走查不像软件审查那么正式，准备工作一般由主持者负责，参加人员只是简单地参加会议，在主持者负责，参加人员只是简单地参加会议，在会议前不需要做更多的准备工作。会议前不需要做更多的准备工作。n 走查走查的目标是：熟悉材料、发现软件故障。的目标是：熟悉材料、发现软件故障。n 走查的主要元素有：走查的主要元素有：l定期的会议，只有主持人必须事先准备：定期的会议，只有主持人必须事先准备：l2-7人，软件开发人员或材料编写者；人，软件开发人员或材料编写者；l主持人通常是软件开发者。主持人通常是软件开发者。n 走查的输入是被检查的材料以及可使用的标准走查的输入是被检查的材料以及可使用的标准n 走查的输出是
27、走查报走查的输出是走查报告。告。n 伙伴检查常常只在编写代码的程序员和充当审伙伴检查常常只在编写代码的程序员和充当审查者的其他一二个程序员或测试员之间进行，这查者的其他一二个程序员或测试员之间进行，这个小团体只是在一起审查代码，寻找问题和失误。个小团体只是在一起审查代码，寻找问题和失误。n 聚集起来讨论问题也能找出一些软件缺陷，发聚集起来讨论问题也能找出一些软件缺陷，发现产品中的缺陷而不是人的错误，伙伴检查不失现产品中的缺陷而不是人的错误，伙伴检查不失为一种极好的训练。为一种极好的训练。验证活动是测试生存周期中的一个阶段，包括需求验证、功能设验证活动是测试生存周期中的一个阶段，包括需求验证、功
28、能设计验证、详细设计验证和代码验证。在每个验证活动中，测试的目的计验证、详细设计验证和代码验证。在每个验证活动中，测试的目的都是为了发现尽可能多的故障，测试人员应积极参与软件审查和走查都是为了发现尽可能多的故障，测试人员应积极参与软件审查和走查工作，并开展验证工作。工作，并开展验证工作。在每一类的验证活动中，都要考虑以下问题：在每一类的验证活动中，都要考虑以下问题：使用的验证方法(审查、走查、伙伴检查等)产品中要验证的和不要验证的范围 没有验证的部分所承担的风险。需要优先进行验证的范围 资源、进度、工具和责任等。n 审查单是验证测试的重要工具，尤其是对于像审查单是验证测试的重要工具，尤其是对于
29、像软件审查这一类比较正式的验证方法。软件审查这一类比较正式的验证方法。n 针对各种类型的验证活动都有相应的审查单，针对各种类型的验证活动都有相应的审查单，例如，需求验证审查单，功能设计验证审查单，例如，需求验证审查单，功能设计验证审查单，详细设计验证审查单，代码验证审查单、一般文详细设计验证审查单，代码验证审查单、一般文档验证审查单等等。对于一切要进行检查的项目档验证审查单等等。对于一切要进行检查的项目都可以开发相应的审查单。都可以开发相应的审查单。n 进行验证测试时，最重要的是利用一般的审查进行验证测试时，最重要的是利用一般的审查单，针对特殊目的和特别项目开发属于自己组织单，针对特殊目的和特
30、别项目开发属于自己组织的审查单，这些审查单应该有明确的目的，并能的审查单，这些审查单应该有明确的目的，并能充分反应组织在验证测试方面现有的成熟水平。充分反应组织在验证测试方面现有的成熟水平。完整性；每一条款必须详细说明所列问题的解决方案。准确、清楚；每一条款只有一种解释。前后一致；规格说明中的前后条款不能自相矛盾。相关性；每一条款都与问题和解决方案相关。可测试性；项目开发及验收测试期间，能确定该项目是否得到满足。可跟踪性；每一条款都能追踪到它的起源。可行性；每一条款在规定的时间和开销下，在现有的人力和物力支持下，都可以实现。n 功能设计是将用户需求转化为一组外部接口的过功能设计是将用户需求转化
31、为一组外部接口的过程。功能设计规格说明从功能角度对产品行为进行程。功能设计规格说明从功能角度对产品行为进行描述。描述。n 对功能设计进行验证测试，就是要确定用户需求对功能设计进行验证测试，就是要确定用户需求是如何在功能设计中得以具体体现的，需求中的每是如何在功能设计中得以具体体现的，需求中的每一项都要在功能设计规格说明中得到体现，如果不一项都要在功能设计规格说明中得到体现，如果不是这样的话，它是被遗漏了还是被删掉了？是这样的话，它是被遗漏了还是被删掉了？n 功能设计规格说明不完整是一种最常见的缺陷。功能设计规格说明不完整是一种最常见的缺陷。一份通用的功能设计验证审查单包含以下几方面的内容：一份
32、通用的功能设计验证审查单包含以下几方面的内容：如果术语已被明确定义，则尽可能用定义代替术语。如果术语已被明确定义，则尽可能用定义代替术语。如果对一个结构进行了描述，则试着勾画被描述结构如果对一个结构进行了描述，则试着勾画被描述结构的结构图。的结构图。如果指定了一项计算，则至少手工计算两个例子并作如果指定了一项计算，则至少手工计算两个例子并作为范例包含在规格说明内。为范例包含在规格说明内。查找确定性语句时，应根据需要一层层次进行搜索，查找确定性语句时，应根据需要一层层次进行搜索，直到满足计算机所需要的确定性。直到满足计算机所需要的确定性。注意含义不明确的词。注意含义不明确的词。查找功能清单，找出
33、没有例子或例子雷同的功能，修查找功能清单，找出没有例子或例子雷同的功能，修改例子并包含在规格说明内。改例子并包含在规格说明内。n 详细设计是将功能设计转化为详细的数据结构、数据流和算法的过程，它表明了软件产品具体是如何构造的。n 详细设计规格说明对测试人员来说十分宝贵。从测试的角度出发，对详细设计规格说明进行仔细地审查，可以利用审查获得的信息，了解产品将如何构造，系统将如何集成，可以使测试者更加深入和全面地认识软件产品。n 使用详细设计验证审查单对详细设计规格说明使用详细设计验证审查单对详细设计规格说明进行验证测试，发现问题可以追踪到功能设计和进行验证测试，发现问题可以追踪到功能设计和需求阶段
34、，看看所用的算法及组合方式是否合适。需求阶段，看看所用的算法及组合方式是否合适。n 一个典型的详细设计验证审查单中包括：一个典型的详细设计验证审查单中包括：设计文档是否包含了详细设计的步骤描述或说明。设计文档是否包含了详细设计的步骤描述或说明。是否有计算机系统的用户界面模型。是否有计算机系统的用户界面模型。是否有计算机系统其它接口的模型或描述。是否有计算机系统其它接口的模型或描述。是否有被推荐的计算机系统高层功能模型。是否有被推荐的计算机系统高层功能模型。主要实施及评估方案在详细设计规格说明中是否得主要实施及评估方案在详细设计规格说明中是否得到了反映。到了反映。n 对代码进行验证测试可以采用审
35、查、走查或伙对代码进行验证测试可以采用审查、走查或伙伴检查的方式。伴检查的方式。n 代码验证测试包括以下几方面的内容：代码验证测试包括以下几方面的内容：将代码与详细设计规格说明进行比较。将代码与详细设计规格说明进行比较。对照特定语言的审查单检查代码。对照特定语言的审查单检查代码。使用静态分析工具对句法规则进行检查。使用静态分析工具对句法规则进行检查。检查代码中的标识符是否与在数据字典和详细设计检查代码中的标识符是否与在数据字典和详细设计规格说明中的一致。规格说明中的一致。寻找边界条件、可能的性能瓶颈、以及其他可能需寻找边界条件、可能的性能瓶颈、以及其他可能需要进行测试的内部条件。要进行测试的内
36、部条件。在代码验证测试时，测试人员还应检查代码编写是否符合某种标在代码验证测试时，测试人员还应检查代码编写是否符合某种标准或规范。准或规范。坚持标准或规范的原因有：坚持标准或规范的原因有：可靠性。事实证明按照某种标准或规范编写的代码比不按标准可靠性。事实证明按照某种标准或规范编写的代码比不按标准编写的代码更可靠，软件故障更少。编写的代码更可靠，软件故障更少。可读性维护性。符合标准和规范的代码易于阅读、理解和维可读性维护性。符合标准和规范的代码易于阅读、理解和维护。护。移植性。如果代码符合标准，移植到另一个平台就会轻而易举，移植性。如果代码符合标准，移植到另一个平台就会轻而易举，甚至完全没有障碍
37、。甚至完全没有障碍。n 数据引用错误数据引用错误n 数据声明错误数据声明错误n 计算错误计算错误 n 比较错误比较错误 n 控制流错误控制流错误 n 接口错误接口错误n 输入输出错误输入输出错误 n 其他检查其他检查 是否引用了未初始化或未说明的变量。数组和字符串的下标是否是整数值，下标是否在维数定义的范围之内。使用字符串时，是否超过了字符串的边界，使用数组时，是否出现“差一个”这样的潜在错误。是否在应该使用常量的地方使用了变量。是否变量被赋予了不同类型的值。是否为引用的指针分配了内存。如果一个数据结构在多个函数或者子程序中被引用，每个引用对该数据结构的定义是否一致。变量是否都赋予了正确的长度
38、、类型和存储类型 变量是否在声明的同时被初始化了，是否正确初始化并与其存储类型相匹配。变量是否有相似的名称。是否存在存在声明过、但从未引用或者只引用过一次的变量。模块中所有变量都显式声明了吗，如果没有，是否该变量为更高级别的模块所共享。计算中是否使用了不同数据类型的变量；计算中是否使用了不同数据类型的变量；计算中是否使用了数据类型相同但长度不同的变量；计算中是否使用了数据类型相同但长度不同的变量；计算时是否了解或考虑了编译器对类型或长度不一变量的计算时是否了解或考虑了编译器对类型或长度不一变量的转换规则；转换规则；目标变量的分配空间是否小于右边的表达式；目标变量的分配空间是否小于右边的表达式；
39、在数值计算过程中是否可能出现溢出；在数值计算过程中是否可能出现溢出；除数模是否可能为零；除数模是否可能为零；对于算术运算，代码处理是否可能丢失精度；对于算术运算，代码处理是否可能丢失精度；变量的值是否会超过合理的范围；变量的值是否会超过合理的范围；对于包含多个操作数的表达式，求值的次序是否混乱，对于包含多个操作数的表达式，求值的次序是否混乱，运算优先级是否正确，是否需要加括号使其清晰。运算优先级是否正确，是否需要加括号使其清晰。比较运算符正确吗，比较应该是小于还是小于或等于；是否存在分数或者浮点值之间的比较，如果有，精度问题是否会影响比较结果；每一个逻辑表达式是否都表示正确，求值次序是否有问题
40、；逻辑表达式的操作数是否是逻辑值，是否将整型变量用于逻辑计算中。如果程序包含beginend和dowhile等语句组，结尾与其相应的语句组是否匹配；程序、模块、子程序或循环能否终止，如果不能，是否可以接受；是否有死循环，是否会过早地退出循环；是否有这种可能，由于入口条件的原因，某个循环永远不会被执行到；如果程序包含有多个分支，是否能执行到每个分支；是否存在“差一个”错误，导致意外地进入或退出循环。被调用模块接收的参数类型和数量与调用模块传送的参数是否匹配，次序是否正确；如果某模块有多个入口点，引用的参数是否与当前入口点无关；常量是否被当作形参传递；子程序是否更改了只能作为输入的参数；每个参数的
41、使用单位与形参匹配吗，例如，度与弧度。如果文件被显式地声明，它们的属性是否正确；是否处理了文件、外设不存在或未准备好等错误的情况；所有文件在使用之前是否都被打开了；软件是否以预期方式处理预计的错误；是否检查了错误提示信息的准确性、正确性、语法和拼写错误。集成测试完成以后，分散开发的模块被联接集成测试完成以后，分散开发的模块被联接起来，构成一个完整的程序。其中各模块之间接起来，构成一个完整的程序。其中各模块之间接口存在的种种问题都已消除。于是进入了确认测口存在的种种问题都已消除。于是进入了确认测试阶段。试阶段。所谓确认测试，是对照软件需求规格说明书，所谓确认测试，是对照软件需求规格说明书，对软件
42、产品进行评估以确定其是否满足需求规格对软件产品进行评估以确定其是否满足需求规格的过程的过程。（1）经过检验，软件功能、性能及其它要求都已满足需求规格说明书的规定，是一个合格的软件。（2）经过检验，发现与需求说明书有相当的偏离，我们得到一个缺陷清单，这就需要开发部门和顾客进行协商，找出解决的办法。确认是指决定最后的软件产品是否正确无误。确认是指决定最后的软件产品是否正确无误。比如，开发的软件是否符合软件需求规格说明和比如，开发的软件是否符合软件需求规格说明和用户要求，输出的信息是否是用户想要的信息，用户要求，输出的信息是否是用户想要的信息，在将来的实际使用环境中能否正确稳定地运行，在将来的实际使
43、用环境中能否正确稳定地运行，是否存在隐患等，这自然包含了对它在功能、性是否存在隐患等，这自然包含了对它在功能、性能、接口以及限制条件等方面满足需求程度的评能、接口以及限制条件等方面满足需求程度的评价。价。测试覆盖用来衡量软件产品的被测程度测试覆盖用来衡量软件产品的被测程度n测试覆盖分为：需求覆盖、功能覆盖和逻辑测试覆盖分为：需求覆盖、功能覆盖和逻辑覆盖。覆盖。n逻辑覆盖很重要，因为：逻辑覆盖很重要，因为：1 1）逻辑覆盖可以间接地提高功能覆盖；）逻辑覆盖可以间接地提高功能覆盖；2 2）对逻辑路径的测试是必要的，而逻辑路径）对逻辑路径的测试是必要的，而逻辑路径一般无法从外部功能看出来。一般无法从
44、外部功能看出来。n逻辑覆盖包括：语句覆盖、判定覆盖、条件逻辑覆盖包括：语句覆盖、判定覆盖、条件覆盖、判定覆盖、判定/条件覆盖和路径覆盖，最常用、条件覆盖和路径覆盖，最常用、最简单的形式是语句覆盖，即覆盖被测程序最简单的形式是语句覆盖，即覆盖被测程序中语句的百分比。中语句的百分比。n 基于需求的测试：采用黑盒测试策略，在不知基于需求的测试：采用黑盒测试策略，在不知道详细设计规格说明或代码的情况下对用户需求道详细设计规格说明或代码的情况下对用户需求进行测试。基于需求的测试根据功能设计规格说进行测试。基于需求的测试根据功能设计规格说明设计测试用例。明设计测试用例。n 基于功能的测试：采用黑盒策略，根
45、据功能设基于功能的测试：采用黑盒策略，根据功能设计规格说明，采用等价类划分、边界值分析和故计规格说明，采用等价类划分、边界值分析和故障猜测等方法设计测试用例。障猜测等方法设计测试用例。n 基于内部的测试：只能采用白盒测试策略，但基于内部的测试：只能采用白盒测试策略，但可采用功能设计规格说明制订测试计划。一但采可采用功能设计规格说明制订测试计划。一但采用白盒测试，便可通过一系列的技术确保系统的用白盒测试，便可通过一系列的技术确保系统的内部各部分获得充分的测试并且达到足够的逻辑内部各部分获得充分的测试并且达到足够的逻辑覆盖。覆盖。测试是为了发现故障，测试是为了发现故障，而不是为了显示故障不存在。而
46、不是为了显示故障不存在。测试最困难的问题之一是不知道何时终止测试。测试最困难的问题之一是不知道何时终止测试。避免使用未经计划、不能重复使用且用后即扔的测试用避免使用未经计划、不能重复使用且用后即扔的测试用例。例。测试用例的一个重要组成部分是预期输出或结果，仔细测试用例的一个重要组成部分是预期输出或结果，仔细比较每一次测试执行的实际结果和预期结果。比较每一次测试执行的实际结果和预期结果。测试用例必须考虑有效、无效、预期和非预期的输入条测试用例必须考虑有效、无效、预期和非预期的输入条件。件。经验较少的测试人员倾向于只从输入角度设计测试用例。经验较少的测试人员倾向于只从输入角度设计测试用例。经验丰富
47、的测试人员能够生成预期输出所要求的输入。经验丰富的测试人员能够生成预期输出所要求的输入。1.低层测试 低层测试涉及对程序的各个单元或模块进行测试，包括单元测试和集成测试。l单元测试l集成测试 l综合测试策略 高层测试涉及对整个产品的测试。为保证测试的客观性，测试最好在开发组织之外由独立的测试机构进行。高层测试的形式包括：l可用性测试l功能测试试l系统测试l验收测试高层测试n回归测试则是对程序进行测试以确定是否回归测试则是对程序进行测试以确定是否因故障修复而引入了新的故障。因故障修复而引入了新的故障。n回归测试不是一种新的测试活动，它是为回归测试不是一种新的测试活动，它是为检查是否因修复故障引入
48、了新的故障而重检查是否因修复故障引入了新的故障而重新执行某些或所有测试用例的过程。新执行某些或所有测试用例的过程。软件测试的主要评测方法有测试覆盖、质量评测和性能评测。测试覆盖是对测试完全程度的评测，由测试需求和测试用例的覆盖或已执行代码的覆盖表示。质量评测是对软件系统的可靠性、稳定性以及性能的评测，对测试结果的评估和对测试过程中确定的变更请求进行分析。性能评测检测软件运行时的性能，如传输的最长时间限制、传输的错误率、计算的精度、相应的时限和恢复时限等。5类常用终止测试的标准和依据。n标准1：测试超过了预定时间，则终止测试。n标准2：执行了所有的测试用例，但并没有发现故障，则终止测试。n标准3：使用特定的测试用例设计方法作为判断测试停止的基础。n标准4：给出测试停止的要求，例如发现并修改了100个软件故障。n标准5：根据单位时内查出故障的数量决定是否停止测试。
