湘潭大学软件测试

慎²º²¹

已于 2023-11-11 01:30:02 修改

阅读量179

点赞数

文章标签：单元测试 junit

于 2023-05-27 16:12:02 首次发布

本文链接：https://blog.csdn.net/qq_65326651/article/details/130902237

版权

第一章 软件测试基础

1.软件测试的定义

（1）在特定的条件下运行系统或构件，观察或记录结果，对系统的某方面做出评价。

（2）分析某个软件项已发现和现存的，以及要求的条件之别（即错误）并评价此软件项的特性。

2.软件测试的目的

（1）以最少的人力、物力、时间找出软件中潜在的各种错误和缺陷，全面评估和提高软件质量，以及揭示质量风险，控制项目风险

（2）通过分析测试过程中发现的问题可以帮助发现当前开发工作所采用的软件过程的缺陷，以便进行软件过程改进；同时通过对测试结果的分析整理，可修正软件开发规则，并为软件可靠性分析提供相关的依据。

（3）评价程序或系统的属性，对软件质量进行度量和评估，以验证软件的质量满足用户的需求，为用户选择、接受软件提供有力的依据。

3.软件测试与软件质量保证

评价、度量和测试在技术内容上有着非常重要的关系。可以说评价依据度量，而度量依据测试。也可以说评价指导度量，度量指导测试。

测试可以查找错误并进行修改，从而提高软件产品的质量。软件质量保证测试避免错误以求高质量并且还有其他方面的措施以保证质量问题。

（1）共同点

目的都是尽力确保软件产品满足需求，从而开发出高质量的软件产品；都是贯穿软件开发生命周期

（2）不同点

软件测试系统主要包括：制定测试计划、测试设计、实施测试、建立和更新测试文档。

软件质量保证主要工作：制定软件质量要求、组织正式度量、软件测试管理、对软件的变更进行控制、对软件质量进行度量、对软件质量情况及时记录和报告。

4.软件测试的分类

（1）按测试阶段或测试步骤划分

a.单元测试：在软件单元完成编码后，首先进行单元测试，验证软件单元是否正确实现了规定的功能和接口等要求。（对象是单元）

b.集成测试：在确认没有问题后，将软件单元组装在一起进行集成测试，验证软件是否满足设计要求。（对象是部件=单元+单元）

c.确认测试：在确认没有问题后，将软件单元组装在一起进行集成测试，验证软件是否满足设计要求。（对象是配置项=部件+部件）

注：Alpha测试：在开发方的场所，用户在开发人员的指导下对软件进行测试，测试是受控的，开发人员负责记录错误和使用中出现的问题。

Beta测试：测试是由软件的最终用户在一个或多个用户场所来进行，开发人员通常不在现场，整个测试不被控制，用户记录下所有的问题，并报告给开发人员。

d.系统测试：最后使通过确认测试的软件与其他系统成分组合在一起，并使其在实际运行环境中运行，进行系统测试。（对象是系统=配置项+配置项）

（2）按测试对象划分

单元测试（黑盒、白盒、静态）、部件测试（黑盒、白盒、静态）、配置项测试（黑盒、白盒）和系统测试（黑盒）

（3）按使用的测试技术划分

（4）按软件质量特性划分

功能性测试、可靠性测试、易用性测试、效率测试、可移植性测试和维护性测试。

（5）按测试项目划分

功能测试、性能测试、健壮性、强度、压力、可用性、可靠性、兼容、文档等。

5.软件缺陷的概念

软件缺陷常常又被叫做Bug。所谓软件缺陷，即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。

一般地，软件缺陷定义如下：

软件未达到产品说明书中标明的功能。

软件出现了产品说明书中指明的不会出现的功能。

软件功能超出了产品说明书中指明的范围。

软件未达到产品说明书中指明应达到的目。

软件难以理解和使用、运行速度慢，或最终用户认为不好。

6.软件缺陷的属性（常识）

（1）缺陷标识

（2）缺陷类型

（3）缺陷严重程度

（4）缺陷优先级

（5）缺陷状态

（6）缺陷起源（这是阶段）

（7）缺陷来源（这是问题）

7.缺陷生命周期

8.缺陷管理工具

（1）Bugzilla

Bugzilla是Mozilla公司向我们提供的一个开源的免费缺陷跟踪工具。作为一个产品缺陷的记录及跟踪工具，它能够建立一个完善的Bug跟踪体系，包括报告Bug、查询Bug记录并产生报表、处理解决、管理员系统初始化和设置四部分。

（2）BugFree

BugFree是借鉴微软的研发流程和Bug管理理念，使用PHP+MySQL独立写出的一个Bug管理系统。简单实用、免费并且开放源代码(遵循GNU GPL)。命名BugFree。有两层意思：一是希望软件中的缺陷越来越少直到没有；二是表示它是免费且开放源代码的，大家可以自由使用传播

（3）HP Quality Center

Quality Center是一个基于Web的商业测试管理工具，可以组织和管理应用程序测试流程的所有阶段，包括制定测试需求、计划测试、执行测试和跟踪缺陷。此外，通过Quality Center还可以创建报告和图来监控测试流程。Quality Center是一个强大的测试管理工具，合理的使用Quality Center可以提高测试的工作效率，节省时间，起到事半功倍的效果。

（4）JIRA

JIRA是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。JIRA中配置灵活、功能全面、部署简单、扩展丰富， JIRA是目前比较流行的基于Java架构的管理系统，由于Atlassian公司对很多开源项目实行免费提供缺陷跟踪服务，因此在开源领域，其认知度比其他的产品要高得多，而且易用性也好一些。

（5）Mantis

Mantis是一个基于PHP技术的轻量级的缺陷跟踪系统，其功能与前面提及的JIRA系统类似，都是以Web操作的形式提供项目管理及缺陷跟踪服务。在功能上可能没有JIRA那么专业，界面也没有JIRA漂亮，但在实用性上足以满足中小型项目的管理及跟踪。更重要的是其开源，不需要负担任何费用。不过目前的版本还存在一些问题，期待在今后的版本中能够得以完善。

9.软件质量模型

第一层为质量特性，第二层为质量子特性，第三层为度量

10.软件测试原则

（1）完全测试程序是不可能的

不可行的原因主要有以下几个方面：程序输入量太大；程序输出量太多；软件实现途径太多

（2）软件测试是有风险的

不能做到完全测试，不测试又会漏掉一些软件故障。我们的目标应该是使有限的测试投资获得最大的收益，即以有限的测试用例检查出尽可能多的软件故障。

（3）测试无法显示隐藏的软件故障

通过测试可以查找并报告发现软件故障，但是不能保证软件故障全部被找到，也无法报告隐藏的软件故障。继续测试，可能还会发现一些。

（4）存在的故障数量与发现的故障数成正比

原因可能有以下几种：程序员怠倦；程序员往往犯同样的错误；某些软件故障可能是冰山之巅。

（5）杀虫剂现象

用于描述软件测试进行的越多，其程序免疫力越强的现象。为了避免杀虫剂现象的发生，应该根据不同的测试方法开发测试用例，对程序的不同部分进行测试，以找出更多的软件故障。

（6）并非所有软件故障都能修复

不修复软件故障的原因可能有以下几种：没有足够的时间；修复风险太大；不值得修复；不算真正的软件故障。

（7）不要丢弃测试用例

（8）应避免测试自己编写的程序

（9）软件测试是一项复杂的，具有创造性的和需要高度智慧的挑战性任务

11.测试停止准则

第一类标准：测试超过了预定的时间，停止测试

第二类标准：执行了所有测试用例但没有发现故障，停止测试。

第三类标准：使用特定的测试用例方法作为判断测试停止的基础。

第四类标准：正面指出测试完成的要求，如发现并修改70个软件故障。

第五类标准：根据单位时间内查出故障的数量决定是否停止测试。

注：覆盖率：用来度量测试完整性的手段，是测试技术有效性的度量。

第二章 软件测试策略

1.软件开发过程（了解）

软件开发过程是指为了获得高质量的软件所需完成的一系列任务框架。它规定了完成各项任务的工作部署，通常使用生命周期模型简洁描述。

软件开发过程：可行性研究；需求分析；概要设计；详细设计；实现；集成测试；确认测试；使用与维护。

2.软件开发过程模型

瀑布模型、(原型模型、)快速原型模型,增量模型、螺旋模型(、V字模型,W模型、X模型、H模型,喷泉模型、XP开发模型等等)

3.软件测试过程

（1）测试计划和控制

（2）测试分析和设计

（3）测试实现和执行

（4）测试出口准则的评估和报告

（5）测试结束活动

4.制定测试计划的目标

1）为测试各项活动制定一个现实可行的、综合的计划，包括每项测试活动的对象、范围、方法、进度和预期结果。

2）为项目实施建立一个组织模型，并定义测试项目中每个角色的责任和工作内容。

3）开发有效的测试模型，能正确地验证正在开发的软件系统。

4）确定测试所需要的时间和资源，以保证其可获得性、有效性。

5）确立每个测试阶段测试完成以及测试成功的标准、要实现的目标。

6）识别出测试活动中各种风险，并消除可能存在的风险，降低由不可能消除的风险所带来的损失。

5.软件测试与软件开发各阶段的关系

软件的开发和测试都是软件过程中重要的活动，是软件生命周期中重要的组成部分；软件开发是一个自顶向下、逐步细化的过程，软件计划阶段定义软件作用域；而测试过程是依相反顺序自底向上，逐步集成的过程。

6.常见软件测试模型（比前面软件开发模型重要）

（1）V模型

非常明确地标明了测试过程中存在的不同级别，清楚地描述了测试阶段和开发过程期间各阶段的对应关系。

V 模型非常明确地标注了测试过程中存在的不同级别，并使测试的每个阶段都与开发的阶段相对应。但 V 模型也存在着一定的局限，它不能发现需求分析等前期阶段产生的错误，直到编码完成之后才进行测试，因此早期出现的错误不能及时暴露。此外，V 模型只是对程序进行测试，早期的需求、设计环节并没有涵盖其中，也为后来的测试埋下了隐患。

（2）W模型

W模型强调“测试伴随着整个软件开发周期”。测试的对象不仅仅是程序，需求、功能和设计同样要测试。有利于尽早地发现问题。W模型有利于即时了解项目的测试风险，及早制定应对方案，加快项目进度。但W模型仍存在着较为明显的问题，因为它将开发活动认定为从需求开始到编码结束的串行活动，只有在上一活动结束后才能开始下一步的行动，无法支持需要迭代、自发性以及变更调整的项目。

（3）H模型

H模型将测试活动完全独立出来，形成一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来。

（4）X模型

X模型左边描述的是针对单独程序片段所进行的相互分离的编码和测试，然后进行频繁地交接，再通过集成最终合成为可执行的程序。清楚地描述了测试阶段过程，并且定位了探索性测试。

7.黑盒测试

（1）概念：是一种从软件外部对软件实施的测试，也称功能测试或基于规格说明的测试。无需考虑程序的内部结构，仅仅靠输入输出之间的关系和程序的功能来设计测试用例，推断测试结果的正确性，以程序的外部特性来判断是否正确运行。

黑盒测试的基本观点是：任何程序都可以看作是从输入定义域到输出值域的映射。

（2）方法：等价类划分、边界值设计、因果图分析、正交试验法等。

（3）常用工具：

a.QACenter帮助所有的测试人员创建一个快速，可重用的测试过程。主要包括功能测试工具QARun、性能测试工具QALoad、应用可用性管理工具EcoTools、应用性能优化工具EcoScope

b.WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能达到预期的功能及正常运行。WinRunner具有以下几个显著的功能：创建测试、插入检查点、检验数据、增强测试、运行测试、分析结果与维护测试。

8.白盒测试

（1）概念：白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件。

（2）规则：

a.一个模块中所有的独立路径都需至少得到一次测试。

b.所有逻辑值的真与假情况都需要被测试到。

c.为了保证程序结构的有效性，需要检查程序的内部逻辑结构。

d.在程序的上、下边界与可操作范围内都能保证循环的顺利运行。

（3）方法：逻辑覆盖测试、数据流测试、路径测试等

（4）常用工具：

a. Jtest是一个代码分析和动态类、组件测试工具，是一个集成的、易于使用和自动化的Java单元测试工具。它增强代码的稳定性，防止软件错误。

b. Jcontract在系统级验证类/部件是否正确工作并被正确使用。Jcontract是个独立工具，在功能上是Jtest 的补充。

c. C++Test可以帮助开发人员防止软件错误，保证代码的健全性、可靠性、可维护性和可移植性。

d. CodeWizard是代码静态分析工具，先进的C/C++源代码分析工具，使用超过500个编码规范自动化地标明危险的，但是编译器不能检查到代码结构。

e. Insure++是一个基于C/C++的自动化的内存错误、内存泄漏的精确检测工具。Insure++能够可视化实时内存操作,准确检测出内存泄漏产生的根源。Insure++还能执行覆盖性分析,清楚地指示那些代码已经测试过。

9.黑盒测试与白盒测试的比较

黑盒测试与白盒测试的主要区别在以下几个方面中：

（1）已知产品的因素

黑盒测试：已知程序的功能需求、设计规格，可以通过测试验证程序需要的功能是否已被实现，是否符合要求。
白盒测试：已知程序的内部工作结构，可以通过测试验证程序的内部结构是否符合要求，是否含有缺陷。

（2）检查测试的主要内容

a.黑盒测试主要检查的内容包括但不限于：

功能是否都满足需求；是否有功能出现缺陷。
接口上是否能正确接受输入；输出结果是否正确。
是否有数据结构信息或者外部信息访问错误。
是否有初始化或终止性错误。

b.白盒测试主要检查的内容包括但不限于：

所有程序模块的独立路径都需要至少被测试一遍。
所有的逻辑判定的真值与假值都需要至少被测试一遍。
在运行的界限内和循环的边界上执行循环体。
测试内部的数据结构是否有效。

（3）静态测试方法（重要）

静态黑盒测试方法：产品需求文档、用户手册、帮助文件等。
静态白盒测试方法：走查、复审、评审程序源代码、数据字典、系统设计文档、环境设置、软件配置项等。

（4）动态测试方法（重要）

动态黑盒测试方法：通过数据输入并运行程序来检验输出结果，如功能测试、验收测试和一些性能测试（或兼容性、安全性）等。
动态白盒测试方法：通过驱动程序来调用，如进行单元测试、集成测试和部分性能测试（或可靠性、恢复性）等。

第三章 黑盒测试与测试用例设计

1.测试用例设计原则

（1）测试用例最小化原则

对于一个测试用例来说，它本身应该尽可能简单，只包括所需要验证的部分，而不需要涵盖其他无关的部分，一味地捎带无关项只会增加测试阶段的负担和风险。这条原则是最重要的，同时也是最难达到、最易忽略的。它对其他几条原则都有着或多或少的影响。其优点如下：1）测试用例的覆盖边界更清晰；2）测试结果对产品缺陷的指向性更强；3）测试用例间的耦合度最低，因此彼此间的干扰也最低。

（2）测试用例替代产品文档功能原则

对于测试用例来说，它忠实反映了产品功能，否则的话测试用例就会执行失败。以往大家只是就把测试用例当作测试用例而已，其实对测试用例的理解应该再上升到另一个高度，它应该是能够扮演产品描述文档的功能。

（3）单次投入成本和多次投入成本原则

成本永远是任何项目进行决策时所要考虑的首要因素，软件项目中的开发需要考虑成本，测试工作同样如此。

（4）测试结果分析和调试最简单化原则

这条原则是实际上是第三条原则的扩展和延续。在编写自动化测试代码时，要重点考虑如何使得测试结果分析和测试调试更简单。

2.测试用例设计步骤

（1）测试需求分析（黑盒）

这一步需要测试人员从软件需求文档中，找出测试软件、测试模块的需求，并进行分析后整合出测试需求，清楚被测对象具有哪些功能。测试需求的特点是：包含软件需求，具有可测试性。

（2）业务流程分析（白盒）

软件测试不仅要从功能的角度进行测试，也要从软件的内部结构入手进行逻辑测试。从业务流程上，应得到这些信息：1）主流程是什么；2）条件备选流程是什么；3）数据流向是什么；4）关键的判断条件是什么。

（3）测试用例设计

a. 确定测试套件：测试套件是功能上的划分，是相似测试场景的组合，而非技术划分。

b. 对每一个测试套件，确定一个或多个基本流程和可选流程，即测试场景。

c. 针对每一个测试场景，确定一到多个测试用例，每一个测试用例都有其对应的预置条件、输入和期望结果。

d. 增加测试数据，完成测试用例：测试数据是测试用例中很重要的内容，一个用例可能对应多套测试数据，测试工程师根据某种测试技术，将尽可能地设计较少的测试数据完成“足够”的测试。

（4）测试用例评审

测试用例设计完成后，为了确保测试过程和方法的正确性，以及是否有遗漏的测试点，需要进行测试用例的评审。

（5）测试用例更新完善

测试用例完成后并不是这一阶段的终止，而是需要进行不断的更新、完善。软件产品新增功能或者更新需求后，测试用例也必须进行同步更新。

3.等价类划分方法（作业，重要）

（1）如果一个输入条件规定了输入值的范围，那么得到三个等价类：一个合法等价类，两个非法等价类。

（2）如果输入条件规定了一个输入值集合，并且每个处理起来都不同，那么为集合中每个元素生成一个合法等价类，一个非法等价类。

（3）如果处理每个合法输入的方式都不相同，那么为每个合法输入生成一个合法等价类。

（4）如果输入条件规定了合法输入的数目（假定为N），那么为正确的输入数目定义一个合法等价类，同时定义两个非法等价类。

（5）如果输入条件规定了必须满足的情形，那么生成两个等价类：一个合法等价类；一个非法等价类。

（6）如果一个等价类中的元素被程序处理的方式不同，那么就把该等价类分割为更小的等价类。一种直观的识别方式是简单值、普通值、极端值和典型值等。

注：在常见的等价类划分中，还会将等价类划分为四个类别：

（1）弱一般等价类：单缺陷假设，不讨论异常区域（即无效等价类的那部分）；

（2）强一般等价类：多缺陷假设，不考虑异常区域；

（3）弱健壮等价类：单缺陷假设，要考虑异常区域；

（4）弱健壮等价类：多缺陷假设，要考虑异常区域；即一个全笛卡尔积。

4.边界值设计方法（重要）

（1）概念：边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

（2）边界值测试原理：边界是测试用例的一些特殊情况。对于程序来说，一般大量的中间数值都是运行正确的，但有可能会在范围边界时出现错误。边界值分析法的基本思想是在等价类的极端情况下考虑软件测试工作，因为很容易发生错误很容易发生在输入值的关键点，即从合法变为非法的那一点。

优缺点：边界值分析法在测试范围的边界值上进行考虑，相对来说是比较简便易行的，生成测试数据的成本也很低。但对于整个测试过程来说，它的测试用例不够充分，也不能发现测试变量之间的依赖关系，因此只能作为初步测试用例使用。

（3）边界值分析原则

a. 如果输入条件规定了一个取值范围，那么从范围的边界生成合法测试用例，并为恰好超出边界的输入值生成非法测试用例。

b. 如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少1，比最大个数多1的个数创建测试用例。

c. 如果输出条件规定了一个取值范围，那么为输出范围的边界生成合法测试用例，并为恰好超出边界的输出值生成非法测试用例。

d. 如果程序的输入或输出是一个有序的集合（例如顺序文件、线性列表、表格等），那么需要关注第一个和最后一个元素。

e. 寻找其它边界条件。

（4）在进行健壮性测试时，需要注意以下几点：

a. 健壮性测试需要注意预期的输出。

b. 健壮性测试的主要价值是观察异常情况的处理。

c. 软件质量要素的衡量标准包括软件的容错性。

d. 软件容错性的度量可以是软件从非法输入中恢复的能力。

5.因果图法（重要）

（1）因果图

a) 恒等：若c1为1，则e1也为1。

b) 非：若c1为1，则e1为0。

c) 或：c1或c2或c3为1，则e1为1；否则e1为0。或可以有任意个输入。

d) 与：若c1和c2都为1，则e1为1；否则e1为0。与可以有任意个输入。

a) 异或：a和b最多有一个为1，即a和b不能同时为1。

b) 或：a和b至少有一个为1，即a和b不能同时为0。

c) 唯一：a和b有且仅有一个为1。

d) 要求：a为1时，b必须为1。其中1）~4）都是关于输入条件的约束。

e) 强制：强制约束是关于输出条件的约束。若结果a是1，则结果b强制。

6.决策表法（重要）

（1）组成：

a. 条件桩——列出问题的所有条件

b. 条件项——针对条件桩给出的条件列出所有的可能值

c. 动作桩——列出问题规定的可能采取的操作

d. 动作项——指出在条件项的各组取值情况下应采取的动作

（2）构建决策表的步骤：

a. 确定规则的个数。一般来说，有n个条件的决策表有2n个规则（每个条件都取真、假值）。

b. 列出所有的条件桩和动作桩。

c. 填入条件项。

d. 填入动作项，得到初始决策表。

e. 简化决策表，合并相似规则。

7.正交试验设计方法

（1）概念：正交试验设计是研究多因素多水平的又一种设计方法，它是根据正交性从全面试验中挑选出部分有代表性的点进行试验。

（2）正交表的构成

a. 行数(Runs)：正交表中的行的数量，即试验的次数，也是我们通过正交实验法设计的测试用例的个数。

b. 因素数(Factors) ：正交表中列的数量，即我们要测试的功能点。

c. 水平数(Levels)：任何单个因素能够取得的值的最大个数。

第四章 白盒测试

1.程序控制流图（重要）

会画流图

N={Start,1,2,3,4,End}

E={(Start,1),(1,2),(1,3),(2,4),(3,4),(4,End)}

2.逻辑覆盖测试（重要）

（1）语句覆盖（SC）：又称行覆盖（LineCoverage），段覆盖（SegmentCoverage），基本块覆盖（BasicBlockCoverage），就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。语句覆盖率=可执行的语句总数/被评价到的语句数量100%

（2）判定覆盖（DC）：判定覆盖又叫做分支覆盖，是设计足够多的测试用例，使得不仅每条语句都要被执行一次，且每个判定的每种可能的结果都应至少被执行一次。

（3）条件覆盖(CC)：条件覆盖是指选择足够的测试用例，使得运行这些测试用例后，使得不仅每条语句都要被执行一次，且使判定表达式的条件都取各种可能的值。

（4）条件/判定组合覆盖(CDC)：条件/判定组合覆盖是通过设计足够多的测试用例，使得运行这些测试用例后，要使每个判断中每个条件的可能取值至少满足一次，也使得程序中的每一个判断至少获得一次“真”和一次“假”。

（5）多条件覆盖（MCC）：多条件覆盖是指选择足够的测试用例，使得运行这些测试用例后，要使每个判断中每个条件的各种可能组合至少出现一次

（6）修正条件判定覆盖（MCDC）：条件组合覆盖要求覆盖判定中所有条件取值的所有可能组合。

（7）组合覆盖：组合覆盖是执行足够的测试用例，使得程序中每个判定的所有可能的条件取值都至少出现一次。

（8）路径覆盖：路径覆盖是利用设计足够多的测试用例，覆盖程序中所有可能的路径。

3.测试覆盖准则（了解）

测试覆盖准则主要讨论ESTCA（Error Sensitive Test Cases Analysis）错误敏感测试用例分析和LCSAJ（Linear Code Sequence and Jump）线性代码序列与跳转。

（1）ESTCA的规则：检查逻辑符号是否正确；检查程序中“差 1”问题；检查变量赋值错误。

（2）LCSAJ：层次LCSAJ覆盖准则。

4.路径分析与测试（重要）

（1）步骤：

a. 画出程序的控制流图。

b. 计算环形复杂度

c. 导出独立路径

d. 设计测试用例

5.数据流测试（重要）（简答题）

（1）定义-使用路径：关于变量v的定义一使用路径（记做du-path）是PATHS（P）中的路径，使得对某个v∈V，存在定义和使用节点DEF（v，m）和USE（v，n），使得m和n是该路径的最初和最终节点。

（2）定义-清除路径：关于变量v的定义清除路径（记做dc-path），是具有最初和最终节点DEF（v，m）和USE（v，n）的PATHS（P)中的路径，使得该路径中没有其他节点是v的定义节点。

（3）全定义覆盖准则：测试路径需要覆盖所有定义点和任意一个使用点，用dc-path扩展成测试路径

（4）全使用覆盖准则：测试路径需要覆盖所有定义点和所有使用点，用dc-path扩展成测试路径

（5）全定义-使用路径覆盖准则：测试路径需要覆盖所有定义点到所有使用点的路径，用dc-path扩展成测试路径

6.变异测试

（1）概念：程序变异是一种评价测试和增强测试的技术。当测试人员采用变异技术来评价测试集的充分性或是增强测试集时，这种活动就被称为是变异测试。

（2）变异和变体

变异是一种变更程序的行为，即使只是轻微的变更也可以被称为变异。一般来说，为了达到测试评价的目的，我们进行的变异只是一些比较轻微的变更。

在对程序进行测试的时候，仅经过一次变更而得到的变体被称为是一阶变体。同样的，二阶变体就是经过了两次简单变更得到的变体，三阶变体就是经过了三次简单变更而得到的，以此类推。高于一阶的变体被叫做高阶变体。

（3）测试用例检测变异体的方式分为：强变异（strong mutation）检测和弱变异（weak mutation）检测。

（4）变异测试的基本原则

基于两个假设：

熟练程序员假设(Competent Programmer Hypothesis，CPH)：即假设熟练程序员因编程经验较为丰富，编写出的有缺陷代码与正确代码非常接近，仅需作小幅度代码修改就可以完成缺陷的移除。
耦合效应假设Coupling Effect(CE)：若测试用例可以检测出简单缺陷，则该测试用例也易于检测到更为复杂的缺陷。

（5）变异的基本思想（作业）

第五章 软件测试的过程管理

1.软件测试的各个阶段

（1）测试需求的分析和确定：所谓测试需求就是在项目中要测试什么

（2）测试计划：软件测试计划是指导测试过程的纲领性测试执行文件

（3）测试设计：它是对测试工作进行有目的、有计划的、创造性的商业活动

（4）测试执行：书写相应的测试用例，按照测试用例中的步骤一步步执行

（5）测试记录和缺陷跟踪：通过测试软件的日志功能，在相应的测试用例执行之后记录相关日志文件

（6）回归测试：因为旧代码得到了修改，通常需要再次进行测试来验证修改是否引入了新的错误

（7）测试总结报告：编写测试总结报告首先是为了对测试结果进行分析。其次是要评估测试执行和测试计划是否相符。最后是要针对软件当中的缺陷

2.测试需求（了解）

（1）分类

按适用范围分为公共测试需求和项目测试需求；按需求类别分为显性测试需求和隐形测试需求。

（2）收集

主要来源是系统需求说明书（或者叫软件规格说明书）。测试需求还可以通过其他一些途径来获得：1）与待测软件相关的文档资料。2）与客户或系统分析员的沟通。3）业务背景资料。如待测软件业务领域的知识等。4）正式与非正式的培训。

（3）分析

软件需求分析、设计和实现阶段是软件的主要错误来源。因此一旦软件需求确定后，即可开始进行测试需求分析。在做测试需求分析时需要列出以下类别：常用的或规定的业务流程；各业务流程分支的遍历；明确规定不可使用的业务流程；没有明确规定但是应该不可以执行的业务流程；其他异常或不符合规定的操作。

（4）评审

测试需求评审的内容包括完整性审查和准确性审查。完整性审查是检查测试需求是否覆盖了所有的软件需求、以及软件需求的各项特征，关注功能要求、数据定义、接口定义、性能要求、安全性要求、可靠性要求、系统约束、行业标准等，同时还要关注系统隐含的用户需求。准确性审查是检查测试需求是否清晰、没有歧义、描述准确，是否能获得评审各方的一致理解，每一项测试需求是否都可以作为设计测试用例的依据。

参与测试需求评审的人员至少要包含：项目经理、开发负责人、测试负责人、系统分析人员、相关开发和测试人员。

3.测试计划

（1）测试经理的计划活动一般包括以下几项：

a. 定义测试的整体方式和策略

b. 确定测试环境

c. 定义测试级别以及它们之间的协作，将测试活动集成到其它项目活动中并进行协调

d. 确定如何评估测试结果

e. 选择监视和控制测试工作的度量，并定义测试出口准则

f. 确定要准备的测试文档，并确定模板

g. 编写测试计划并确定测试的内容、人员、进度以及测试范围

h. 估算测试工作量和成本，（再）估计和（再）计划测试任务

（2）划分测试优先级的准则

a. 软件使用时一个功能的使用频率或者失效的概率：如果系统的某些特定功能。

b. 经常被使用并且其中包含了故障，那么这个故障导致失效的概率很高。因此，用于此功能的测试用例应该比某个较少使用的功能的测试用例具有更高的优先级。

c. 失效的风险。为找到高风险失效而设计的测试用例应该比为找到低风险失效而设计的测试用例具有更高的优先级。

d. 失效对于最终用户的可见性是划分测试用例优先级的更进一步的准则。

e. 测试用例可以根据需求的优先级来选择。系统提供的不同功能对于客户来说其重要性也不尽相同。

f. 除了功能要求，质量特性对于客户也具有不同的重要性。必须要测试重要的质量特性是否已经正确实现。用于验证与必要的质量特性是否一致的测试用例具有更高优先级。

g. 划分优先级也可以从系统架构的开发人员的角度来完成。失效时导致严重的后果（比如系统崩溃）的组件需要加强测试。

h. 单独的组建和系统部件的复杂性也可以用来划分测试用例的优先级。

i. 存在高项目风险的失效应该尽早被发现。这些失效需要做大量的修正工作，否则会独占资源并导致项目明显延迟。

j. 项目经理应该为项目定义充分的优先级准则和优先级类别。测试计划中的每个测试用例都应当属于使用这些准则而确定的一个优先级类别。

4.测试设计及测试用例

（1）测试用例设计原则

a. 正确性：测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。

b. 全面性：覆盖所有的需求功能项。

c. 整体连贯性：用例执行粒度尽量保持每个功能有一个测点，不能同时覆盖很多功能点。

d. 可维护性：由于软件开发过程中需求变更等原因，常常需要对测试用例进行修改、增加、删除等。

e. 测试结果可判定性和可再现性：测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。可再现性表示对于同样的测试用例，系统的执行结果是相同的。

（2）测试用例设计方法（重要）

等价类划分法、边界值分析法、基本路径分析法、因果图法

（3）测试用例的粒度（重要）

对功能的细化和综合程度的一种度量，测试用例细化程度越高，粒度越小，用例所含功能越少；测试用例细化程度越低，粒度越大，用例所含功能越多。

（4）测试用例的评审的一些检查项（简单了解）

1）测试用例是否是按照公司定义的模板进行编写的；

2）测试用例的本身的描述是否清晰，是否存在二义性；

3）测试用例内容是否正确，是否与需求目标相一致；

4）测试用例的期望结果是否确定、唯一；

5）操作步骤与描述是否相一致；

6）测试用例是否覆盖了所有的需求；

7）测试设计是否存在冗余性；

8）测试用例是否具有可执行性；

9）是否从用户层面来设计用户使用场景和业务流程的测试用例

5.测试的执行

（1）测试用例的选择策略（重要）

a. 首先测试产品的核心功能，再测其它功能：核心功能是软件功能的重要体现是用户使用软件的核心目的，也是系统出现重大BUG的高发地。因此，应该集中资源，优先测试核心功能，保证系统安全、准时上线

b. 若产品具有支付交易功能，首先测试此功能，再测其它功能：资金的问题永远是最重大的问题，如果软件产品出现资金问题，无论是对产品运营方还是对用户体验都将产生重要的影响，并且处理起来也较为麻烦，因此，优先保证交易功能中BUG的排除是重中之重。

c. 首先测试常用功能，再测其它功能：常用功能是指用户使用频率较高的功能，比如一个系统的登录功能，这些功能会经常被用户使用到，是最容易出现问题也最不应该出现问题的地方。

d. 首先测试需求中被特别说明的地方，再测没有特别说明的地方：需求中被特别说明的地方，一般是重要功能点，或者是产品容易出错的地方，或者是产品的亮点，这些地方要保证不出问题。

e. 首先测试有变更的地方，后测试没有变更的地方：有时所需要测试的是整个系统中有需求变更的某个模块，但是我们不能保证变更处的代码改动是否会影响其他地方，所以我们往往需要重点测试变更的部分，然后再测试跟变更部分相关的部分乃至整个系统。

（2）测试人员分工（简单了解）

1）按照测试内容分工：它的优点在于分工较为明确，测试人员对于测试内容的重点具有清楚的认识。

2）按照测试流程分工：它具有流程清晰的特点

3）按照功能模块分工：它具有人员利用率高且容易发现深层错误的特点。

4）按照测试类型分工：它具有对测试人员的专业性要求高的特点。

（3）测试环境的搭建

a. 原因/目的（重点）：减少环境的变动对测试的影响，对测试效率的提高产生积极作用。

b. 内容：网络环境、测试数据、测试机器、操作系统、安装包

测试环境=软件+硬件+网络+数据准备+测试工具

（4）BVT测试与冒烟测试的区别（简单了解）

a. BVT测试只在 build 构建完成时进行而冒烟测试在各个阶段都会进行

b. BVT 测试可以加入自动测试脚本并执行少量固定的自动化测试，但冒烟测试与 build 的验证无关。

c. BVT 的结果直接决定新构建的 build 是否交付后续测试而冒烟测试并不影响其他日常测试工作。

（5）每日构建介绍

a. 概念（填空）：每日构建（Daily Build）也可称为持续集成（Continuous Integration），强调完全自动化的、可重复的创建过程，其中包括每天运行多次的自动化测试。

b. 优点

1）进度可见并可以控制到1-2天的细粒度，很容易看到进度的偏差。

2）可以尽早发现开发BUG和缺陷并分析解决，从而提高软件质量。

3）由于将大集成分解到每日构建中的小集成，消除了传统产品集成或集成测试时出现严重问题的可能性。

4）注重每次工作的正确性，减少了可能出现的错误

6.软件缺陷分析

（1）缺陷分析的作用

通过缺陷分析，发现各种类型缺陷发生的概率，掌握缺陷集中的区域、明晰缺陷发展趋势、了解缺陷产生主要原因。以便有针对性地提出遏制缺陷发生的措施、降低缺陷数量。对于改进软件开发，提高软件质量有着十分重要的作用。缺陷分析报告中的统计数据及分析指标既是对软件质量的权威评估，也是判定软件是否能发布或交付使用的重要依据。

（2）软件缺陷的分类

a. 按严重程度划分：5个等级：系统崩溃、严重、一般、次要、建议；

3个等记：严重、一般、次要

b. 按优先级划分：3个等级：高（应立即修复）、中（产品发布之前修复）、低（挂起）。

c. 按测试种类划分：逻辑功能类、性能类、界面类、易用性类、兼容性类

d. 按功能模块划分：测试的过程我们可以统计一下Bug主要集中在哪些模块里面，以便我们投入重点精力去测试。（二八定理）

（3）软件缺陷分析指标（选择）

a. 反映产品质量的指标：缺陷密度

b. 反映产品可靠性的指标：平均失效时间

c. 反映缺陷发现及修复效率的指标：缺陷检出率、发布前缺陷去除率、缺陷修正率

d. 反映缺陷修复成本的指标：平均修复时间、平均修复成本、相对返工成本

（4）缺陷报告内容（14个）