软件测试期末复习

第四章 边界黑盒测试续

4.3边界值设计方法

1.边界值设计方法：故障往往出现在定义域或边界值上。通常边界值分析法是作为对等价类划分法的补充。其测试用例来自等价类的边界。是对输入或输出的边界值进行测试的一种黑盒测试方法。

2.边界值分析法和等价类划分法的区别：

①边界值分析法不是从等价类中随便挑一个做代表，而是使这个等价类的每个边界都要作为测试条件。

②边界值分析不仅考虑输入条件、还要考虑输出空间产生的测试。

3.边界值分析法的基本思想：在等价类的极端情况下考虑软件测试的工作。

4.边界值选取：选择正好等于、刚刚大于或者刚刚小于等价类边界的值作为测试数据。边界是测试用例的一些特殊情况。

5.常见边界值：

 6.

内部边界值作为测试数据：在测试用例设计过程中，某些边界值条件是不需要呈现给用户的，或者说用户是很难注意到的，但同时确实属于检验范畴内的边界条件，称为内部边界值条件或子边界值条件。

7.如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。

如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。

8.测试用例健壮性分析：①仅考虑有效区间单个变量边界值（一般边界值分析法）

 ②仅考虑有效区间多个变量边界值同时使用（一般最坏情况边界值分析法）

③同时考虑有效区间和无效区间单个变量边界值（健壮边界值分析法）：

除了在最小值，略高于最小值，正常值，略低于最大值和最大值处取变量的值，还要在略超过最大值以及略小于最小值处取值

 ④同时考虑有效区间和无效区间多个变量边界值同时作用（健壮最坏情况边界值分析法）

9.边界值分析法的优缺点：

优点：在测试范围的边界上考虑，比较简单易行

缺点：测试用例不充分，也不能发现测试变量之间的依赖关系。测试用例不考虑含义和性质，因此只能作为初步测试用例使用。

10.边界值分析法的应用：

4.4因果图设计方法

1.错误推测法:基于经验和直觉推测程序中所有肯存在的各种错误，从而有针对性的设计测试用例的方法。常作为一种补充设计测试用例的方法。

2.错误推测法：基本思路：分析程序中最易出错的场景和情况，在此基础上有针对性的设计测试用例。需要完成的前提条件如下：①深度熟悉被测系统的业务、需求②对被测系统或类似系统之前的缺陷分布情况进行系统的分析。包括功能缺陷、数据缺陷、接口缺陷和界面缺陷等等。

3.错误推测法优缺点：

优点：充分发挥个人的经验和潜能，命中率高

确定：覆盖率难以保证；过多依赖于个人经验

4.等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。

4.因果图法：考虑了输入情况的各种组合及输入情况之间的相互制约关系。因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

5.因果图法设计测试用例的步骤：

6.因果图法基本图形符号：

Ci：表示原因；Ei：表示结果；各节点表示转台，可取值“0”或“1”

“0”表示某状态不出现。“1”表示某状态出现

7.因果之间的关系：

8.条件的约束关系:

输入状态相互之间还可能存在某些依赖关系，称为“约束”

6.因果图优点：

（1）考虑到了输入情况的各种组合以及各个输入情况之间的相互制约关系。

（2）能够帮助测试人员按照一定的步骤，高效率的开发测试用例。

（3）因果图法是将自然语言规格说明转化成形式语言规格说明的一种严格的方法，可以指出规格说明存在的不完整性和二义性。

7.例题：

8.决策表：决策表是分析和表达多逻辑条件下执行不同操作的情况的工具。基于决策表（也称为判定表）的测试是最为严格、最具有逻辑性的测试方法。因此利用决策表能够设计出完整的测试用例集合。一种呈表格状的图形工具。决策表能将多个独立的条件和多个动作直接的联系清晰的表示出来。

9.决策表优缺点：

优点：把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏。

缺点：不能表达重复执行的动作，例如循环结构

10.决策表的组成（结构）：

11.我们把任何一个条件组合的特定取值及其相应要执行的操作称为一条规则。

12.构建决策表步骤：①确定规则个数：有n个条件的决策表有2n个规则（每个条件都取真、假值）。

②列出所有的条件桩和动作桩

③填入条件项

④填入动作项，得到初始决策表

⑤简化决策表，合并相似规则

13.规则化简：

决策表的简化以合并规则为目标：

    有两条或多条规则具有相同的动作，并且其条件项之间存在着极为相似的关系，就可以将规则合并。

14.

15.

第五章 白盒测试

5.1 程序控制流图

1.静态白盒测试主要包括代码检查和静态结构分析两种方法。

2.动态白盒测试主要包括程序插桩、逻辑覆盖测试、基本路径测试、循环结构测试等。动态白盒测试方法是白盒测试中发现软件缺陷的主要手段。其中，逻辑覆盖测试和基本路径测试方法是实际工作中最常用到的两种动态白盒测试技术。

3.白盒测试针对的是程序的内部结构和运行过程。白盒测试重视测试覆盖率的度量，被看做是“基于覆盖的测试”，要求对被测程序的结构能够做到一定程度的覆盖，通过不同类型的覆盖准则来判断测试执行的充分性，所以白盒测试又称为结构测试或逻辑驱动测试。

4.白盒测试原则：

    保证程序模块中的所有独立路径都至少被使用一次；

    保证程序中的所有逻辑值都能测试True和False两种情况；

    在循环的边界和运行的界限内执行循环体；

    测试程序内部数据结构的有效性以及完成边界数据取值情况下的测试。

5.软件复杂性：软件度量的一个重要分支就是软件复杂性度量。软件复杂性与质量属性有密切关系。

6.软件复杂性度量参数：

        (1) 规模： 即总共的指令数， 或源程序行数。 

        (2) 难度： 通常由程序中出现的操作数的数目所决定的量来表示。 

        (3) 结构： 通常用与程序结构有关的度量来表示。 

        (4) 智能度： 即算法的难易程度。 

7.软件复杂性的度量方法：①代码行度量法②McCabe度量法

McCabe度量法：

McCabe度量法是一种基于程序控制流的复杂性度量方法。 McCabe复杂性度量又称环路度量，它认为程序的复杂性很大程度上取决于控制的复杂性，单一的顺序程序结构最为简单，循环和选择所构成的环路越多，程序就越复杂。这种方法以图论为工具，先画出程序图，然后用该图的环路数作为程序复杂性的度量值。

因此，它往往把一个简单的IF语句与循环语句的复杂性看成是一样的，把嵌套的IF语句与CASE语句的复杂性看成是一样的。

因此McCabe环路复杂度量值实际上是为软件测试的难易程度提供了一个定量度量的方法， 同时也间接地表示了软件的可靠性。 实验表明，源程序中存在的错误数以及为了诊断和纠正这些错误所需的时间与McCabe环路复杂度度量值有明显的关系。 

8.程序控制流图：简称流图，本质上是一种“退化”了的程序流程图，用于突出表示程序的控制结构。流图只呈现程序的控制流程，完全不表现具体的语句以及选择或循环的具体条件。

（1）结点（有编号的圆圈）：用圆表示。一个结点代表一条或多条顺序执行的语句。程序流程图中的一个顺序的处理框序列和一个菱形判定框，可以映射成控制流图中的一个结点。

  （2）边（带箭头的弧和线）：用箭头线表示。边代表控制流，一条边必须终止于一个结点，即使这个结点并不代表任何语句。

9.程序流程转化控制流图结构原则：

    1、控制流图中的箭头（边）表示了控制流的方向，类似于流程图中的流线，一条边必须终止于一个结点。

    2、在选择或者是多分支结构中，分支的汇聚处应当添加一个汇聚结点，即使是该处并没有实际的可执行语句也应如此，这样可以使控制结构表现地更为完整和清晰。

    3、由边和结点围成的面积称为区域。当计算区域总数时，图形外未被围起来的那个区域也要记为一个区域。

    4、一个节点包含1个或多个连续的无分支语句。

10.程序流程转化控制流图方法：

判断节点（谓词节点）：

       包含条件的节点被称为判断节点。

           由判断节点发出的边必须终止于某一个节点。

区域

       由边和节点所限定的范围被称为区域。

           当对区域计数时，图形外的区域也应记为一个区域.

11.

12.

13.

14.

15.

5.2 逻辑覆盖测试

1.逻辑覆盖测试是一种常用的动态白盒测试方法，主要包括语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖和路径覆盖。逻辑覆盖是基于程序的内部逻辑结构进行的测试，要求在设计测试用例时，对被测程序的逻辑结构有清晰的了解。

2.语句覆盖：每一条可执行语句至少执行一次（即每行代码是否被执行了并且被测试了）

  

3.覆盖率只是我们度量的手段

4.语句覆盖的优缺点：

优点：

  1、检查所有语句；

  2、结构简单的代码的测试效果较好；

  3、容易实现自动测试；

  4、代码覆盖率高；

  5、如果是程序块覆盖，则不涉及程序块中的源代码。

缺点：

  它对一些控制结构不敏感，对程序执行逻辑的覆盖率很低，往往发现不了判断逻辑中逻辑运算符出现的错误。

5.分支覆盖（判定覆盖）：报告在控制结构中是否测试了布尔表达式取值分别为真和假的情况。分支覆盖保证只要程序能跳转，就能跳转到所有可能的目标语句。

6.分支覆盖优缺点：

    1、注意程序中包含两种类型的判定语句。一种是双值判定语句，其取值或者是True或者是False。另一种是多值判定语句。因此，判定覆盖更一般的含义是设计测试用例，使每一个分支获得每一种可能的结果。

    2、判定覆盖比语句覆盖具有更好的测试充分性。由于可执行语句要不就在判定的真分支，要不就在假分支上。所以，只要满足了判定覆盖标准的测试用例就一定满足语句覆盖标准，反之则不然。

    3、判定覆盖的测试充分性仍然很弱，它只是判断整个判定表达式的最终取值结果，而不考虑表达式中每个条件的取值情况，因此必然会漏检一些条件错误。判定表达式往往由多个条件组合而成，某个条件的取值结果可能会掩盖其它条件的取值结果情况。

7.条件覆盖：设计若干测试用例，执行被测程序以后，要使每个判断中的每个条件的可能取值至少满足一次。

8.

9.条件覆盖优缺点：

10.判定-条件覆盖：

由判定覆盖和条件覆盖可知，条件覆盖不一定包含判定覆盖，反之亦然。因此，就需要一种能将两者结合起来的逻辑覆盖标准，这就是判定-条件覆盖，也称为分支-条件覆盖或条件判定组合覆盖。

11.

12.

注意：

   条件组合覆盖并不一定能够查出逻辑表达式中的所有错误。从测试充分性上来看，满足条件组合覆盖就一定能够满足判定-条件覆盖、条件覆盖、判定覆盖和语句覆盖。

以上四个测试用例覆盖了8种条件组合，同时覆盖了4个分支，从路径角度看仅覆盖了3条路径，漏掉了路径acd。

13.

14.

15.路径覆盖：路径覆盖就是设计足够多的测试用例，使被测程序的每条可执行路径都至少执行一次。  

16.

17.逻辑覆盖指标：

第六章 软件测试过程

1.传统软件测试流程：

2.测试需求分类：

①按适用范围分类：公共测试需求，项目测试需求

②按需求类别分类：显性测试需求，隐性测试需求

3.测试需求的主要来源是系统需求说明书（软件规格说明书），还可以通过以下途径获得：

1）与待测软件相关的文档资料。如Use case、界面设计、项目会议或与客户沟通时有关于需求信息的会议记录、其他技术文档等。

2）与客户或系统分析员的沟通。

3）业务背景资料。如待测软件业务领域的知识等。

4）正式与非正式的培训。

4.原则上，所有的软件需求都应该是可测试的。当测试需求已经收集完毕后，还需要考虑相应的需求覆盖率(功能需求、性能需求）。测试需求的覆盖率通常是由与软件需求所建立的对应关系来确定的。如果一个软件的需求已经和测试的需求存在了一对多或者一对一的对应关系，就可以说测试需求已经覆盖了此功能点。按照这样的方式进行推断，当所有的软件需求都建立了相应的测试需求，那测试需求的覆盖率就等于百分之百。但是这并不表示测试需求的覆盖程度高，因为测试需求的覆盖率只计算了显性的因素（明确规定的功能与特性），但是隐形的并没有计算在内。所以需要对测试需求进行不断地补充或优化，并将更新补充到测试用例中，从而更好地提高测试需求的覆盖程度。

5. 软件需求分析、设计和实现阶段是软件的主要错误来源。因此一旦软件需求确定后，即可开始进行测试需求分析

6.集成测试阶段主要是检验程序单元或部件的接口关系；系统测试阶段，重点是为了验证和确认系统是否达到了其原始目标，通过与系统的需求定义做比较，发现软件与系统定义不符合或与之矛盾的地方。

7.测试需求采集之后得到的是一张没有优化的需求表，需要对这份原始需求表进行初步的规划：删除冗余重复的需求，各个需求间没有过多的交集；需求需覆盖业务流程、功能、非功能方面的需求。

8.测试需求评审的内容包括完整性审查和准确性审查。可以采取正式的小组会议的形式，测试需求评审还可以采取非正式的走查和轮查形式。对于重大项目可能还会采取正式审查方式进行评审，包含了制定评审计划、组织会议、会后跟踪分析审查结果等。参与测试需求评审的人员至少要包含：项目经理、开发负责人、测试负责人、系统分析人员、相关开发和测试人员。测试需求评审通过以后，才可以跟进测试需求来制定测试计划及编写测试用例。

9.测试计划是指描述了要进行的测试活动的范围、方法、资源和进度的文档，它确定了测试项、被测特性、测试任务、谁执行任务、各种可能的风险，通常作为关于质量的重要文档呈现给管理层。

10.测试计划的目标：

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

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

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

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

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

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

11.测试计划内容：

1、确定测试范围

2、制定测试策略

3、确定测试任务

4、确定测试资源与工作量

5、进度安排

6、风险及对策

12.测试设计内容：

1）确立测试技术和策略

2）准备和建立测试程序设计标准

3）确定测试程序和测试脚本的清单、层次

4）分配测试程序和脚本到测试组成员

5）生成测试程序/脚本的设计输入及期望的输出

6）建立自动测试脚本库

13.测试用例的选择：

（1)首先是测试产品的核心功能，再测其它功能（2）首先测试常用功能，再测其它功能

（3）首先测试需求中被特别说明的地方，再测没有特别说明的地方（4）首先测试有变更的地方，后测试没有变更的地方

14.软件测试的分工：

15.缺陷分析：通过缺陷分析，发现各种类型缺陷发生的概率，掌握缺陷集中的区域、明晰缺陷发展趋势、了解缺陷产生主要原因。

16.缺陷分类：

17.缺陷分析方法：

18.缺陷分析报告：缺陷报告的重要性不仅仅在于文档化，同时也是使发现的缺陷被修正的唯一方法

19.敏捷测试：

    首先敏捷测试(Agile testing)是测试的一种，原有测试定义中通过执行被测系统发现问题，通过测试这种活动能够提供对被测系统提供度量等概念还是适用的。

敏捷测试是遵循敏捷宣言的一种测试实践：

    1、强调从客户的角度，即从使用系统的用户角度，来测试系统。

    2、重点关注持续迭代地测试新开发的功能，而不再强调传统测试过程中严格的测试阶段。

    3、建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。

20.敏捷测试最大特点：高度迭代，有周期性，并且能够及时、持续地响应客户的频繁反馈。

21.敏捷测试流程：

第七章 软件质量保证

1.软件测试与软件质量保证的异同：

从共同点的角度看，软件测试和软件质量保证的目的都是尽力确保软件产品满足需求，从而开发出高质量的软件产品。

 二者的不同之处在于软件质量保证工作侧重对软件开发流程中的各个过程进行管理与控制，杜绝软件缺陷的产生。而测试则是对已产生的软件缺陷进行修复。

2.质量是体现在开发过程中，通过科学的管理得到控制。

软件质量保证就是通过对软件产品有计划地进行检查和审计来验证软件是否合乎标准，找出改进的方法，以达到防止产生软件缺陷的目的。

3.软件质量保证SQA：是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。

4.软件质量保证的目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。

5.

6.软件质量保证SQA内容：

7.软件质量标准：

1）ISO9000标准

2）CMM

   等级1（初始级）：该等级的软件开发过程是随意的，甚至是混乱的。项目能否成功依靠个人的能力和运气，具有偶然性。软件开发过程没有定义，没有通用计划，难以监视和控制。开发的时间和费用无法预知。测试过程和其他过程混杂在一起。

    等级2（可重复级）：该等级成熟度主要集中在项目级。建立基本的项目管理过程去跟踪成本、进度、功能和质量。可以借鉴以前成功项目的经验，应用到新项目中。软件开发具有一定的组织性，使用了基本软件测试行为，例如测试计划和测试用例。

    等级3（已定义级）：该等级具备了组织化思想，而不仅仅是针对具体项目。软件开发中的管理活动和工程活动被文档化和标准化，并且形成整个软件组织的标准软件过程。所有项目均采用在标准软件过程中进行。

    等级4（已管理级）：在该成熟度等级中，组织过程处于在统计的控制下。软件过程和产品质量有具体的度量标准，软件过程和产品质量得到了定量理解和控制。

    等级5（优化级）：通过来自过程、新技术和新思想等各方面的定量信息反馈，着能够进行持续地过程改进，以期达到质量更佳的等级。 

   ISO 9000系列标准是ISO国际标准化组织制定的国际标准，它为所有制造行业设立了质量管理和质量保证等标准。ISO9003质量体系是为软件产品的开发和测试提供质量保证模式，可以作为软件测试的质量保证规范。

   软件能力成熟度CMM作为软件行业的标准模型，可以定义和评价软件公司开发过程的成熟度，为提高软件质量提供指导。

3）6 Sigma（六西格玛）

六西格玛计算：（1-缺陷数/1000000）*100%

8.质量：实体基于这些特性满足需要的程度。

9.质量定义包含的要素：实体+特性集合+需求

10.软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”

11. 如何评价软件质量：

12.影响软件质量的要素：

流程：来自成功的经验，提高软件质量，流程对项目的成本和进度控制有很大帮助。

技术：需求是项目的灵魂。软件质量是设计出来的；编码技术产生正确高效的代码；测试是保证软件的最后一道防线。

组织：技术的载体

13.软件质量是软件的生命

14.评价质量的优劣：

1️⃣软件需求是衡量软件质量的基础，不符合需求的软件就不具备质量。设计的软件应在功能、性能等方面都符合要求，并能可靠的运行

2️⃣软件结构良好，易读、易于理解，并易于修改维护。

3️⃣软件系统具有有好的用户界面，便于用户使用

4️⃣软件生存周期中各阶段文档齐全、规范、便于配置、管理

15.软件质量特性：功能性、可靠性、可充用性、效率可维护性、可移植性

16.

17.度量的概念：

度量：对事物属性量化表示。 

软件度量：对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程。

18.度量的目的：

      提高软件生产率，缩短产品研发周期，降低研发成本和维护成本。

      提高软件产品质量，提高用户满意度；

      为组织持续改进提供量化的指标和反馈。

19.度量的作用：

1️⃣理解：通过度量，获得对过程、产品、资源等的理解，确定以后预测的基线和模型。

2️⃣预测：     通过度量，可以理解过程、产品、项目各要素之间的关系并建立度量模型，预测就是由这些已知的要素推算、估计其他要素，以便合理分配资源、合理制定计划。

3️⃣评估：

          1）开发活动与计划的符合程度。如工作量估计偏差、进度偏差等。

          2）产品质量。如软件复杂度、缺陷密度、平均失效时间间隔等。

          3）新技术的影响。

4️⃣改进：    根据得到的量化信息，可与帮助我们识别要因、查找问题的根源，以及提高产品质量和过程效率的其他方法；与以前的量化信息比较，可以验证这些方法是否有效。

20.度量过程：

1）识别目标   2）根据度量目标，定义度量过程的如下内容 3）数据收集 4）数据分析与反馈 5）过程改进

21.测试的复杂性：

22.黑盒测试的复杂性：

23.白盒测试的复杂性：

24.软件测试的一个基本问题是经济学问题？