测试的基本知识点

 

 

 

 

 

 

 

 

目录

一．知识总结...2

1．软件工程要点...2

1.1软件...2

1.2软件危机...3

1.3软件工程...3

1.4应用软件生命周期管理...3

2．软件测试基础...4

2.1软件测试的基本概念...4

2.2软件测试工作...5

3软件测试职业...6

3．基于生命周期的软件测试...6

3.1生命周期的概念...6

3.2生命周期各个阶段的测试要求...8

3.3HP ALM对生命周期软件测试的支持... 10

4．软件测试分类与分级...10

4.1  软件测试分类... 10

4.2 软件测试分级... 11

5．软件缺陷管理...12

5.1 软件缺陷... 12

5.2 软件缺陷度量、分析与统计... 15

5.3软件缺陷报告...16

6．软件测试过程及测试过程管理...16

6.1软件测试过程...16

6.2软件测试过程管理...18

7．软件静态测试...19

7.1 各阶段评审... 19

7.2代码检查...20

7.3 软件复杂性分析... 22

7.4软件质量模型...23

7.5        软件质量管理... 24

7.6 惠普静态分析工具HPFortifySCA.. 25

8.动态测试...25

8.1 白盒测试... 25

8.2        黑盒测试... 28

8.3        灰盒测试... 30

8.4测试用例设计...31

8.5单元测试...32

8.6集成测试...32

8.7确认测试...33

8.8系统测试...33

9.   软件手工测试与自动化测试... 36

二．实训问题反馈..37

三．学习规划..37

 

 

 

 

一．知识总结

1．软件工程要点

1.1软件

软件就是由数据、程序、文档组成

软件按应用范围划分为应用软件、中间件、系统软件、支撑软件。

1.2软件危机

软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件。

1.3软件工程

软件工程的方法是将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件：项目计划与估算、需求分析、书记结构、总体设计、编码、测试与维护等；软件工具为工程方法提供了自动或半自动的软件支撑环境：软件工具、软件支撑环境、计算机辅助软件工程等；软件的过程是将软件工程方法和工具综合起来，以达到合理、及时进行计算机软件开发的目的，方法使用的顺序、需交付的文档、变更管理、里程碑管理等；

1.4应用软件生命周期管理

应用软件生命周期阶段：定义、设计、实施、测试、部署、运行、维护

1-1软件生命周期

软件生命周期模型：瀑布模型

1-2瀑布模型

1-3软件生命周期模型

2．软件测试基础

2.1软件测试的基本概念

软件测试的目的：

1）发现缺陷，提高质量

2）验证是否满足要求

3）建立软件质量的信心

 

软件测试原则：

1）测试显示缺陷的存在

2）穷尽测试是不可能的

3）测试尽早介入

4）缺陷集群性

5）杀虫剂悖论

6）测试活动依赖于测试背景

7）不存在缺陷

2-1软件开发对应的软件测试过程

 

2.2软件测试工作

2-2软件测试流程

软件测试工作的认识误区：

1. 整体认识上重开发而轻测试
2. 软件开发完成后进行软件测试
3. 软件测试是为了证明软件的正确性
4. 软件发布后如果发现质量问题，那是软件测试人员的错
5. 软件测试要求不高，随便找个人多都行
6. 软件测试是软件开发的对头
7. 软件测试是测试人员的事情，与程序员无关
8. 项目进度吃紧时少做些测试，时间富裕时多做测试

3软件测试职业

测试人员的思维:

l  技术思维能力

       对技术的建模能力和理解原因与后果的能力。

l  创造思维能力

       提出新想法和预见可能性的能力。

l  批判思维能力

       评价想法并进行推理的能力。

l  实践思维能力

       将想法变成现实的能力

3．基于生命周期的软件测试

3.1生命周期的概念

3-1软件测试的过程

 

3-2生命周期各阶段的测试工作

 

基于开发生命周期的测试特点:

1)在软件开发过程中持续的进行测试

2)在尽可能早的阶段点去介入

3)需要正式的开发流程来支持

4)组建专门的测试团队

5)当软件整体开发活动开始的时候，测试活动就可以开始

测试要素：

1）正确性

2）文件完整性

3）授权

4）进程追踪

5）系统运行的联连续性

6）服务水平

7）权限控制

8）一致性

9）可靠性

10）易于使用

11）可维护性

12）可移植性

13）耦合性

14）性能

15）操作性

测试计划

内容：描述测试活动的范围、方法、资源和进度的文档

确定：测试项、被测特性、测试任务、任务执行者、各种可能风险

作用：有效预防计划的风险，保障计划的顺利实施

软件生命周期各类软件测试的定义和概念：

1)     质量控制：决定软件产品正确性的过程和动作；一组功能基线，保证产品符合标准/需求所做的工作。

2)       缺陷：有三种表现形式——遗漏、错误和多余；用户不满意的任何事情，不管是否在规定说明书中规定。

3)       验证：在整个软件生命周期中的全部质量控制活动，确定交付的中间产品符合输入规格说明。

4)       确认：软件生命周期中的测试阶段，保证最终产品符合规格说明。

5)       静态测试：在系统编码之前进行的验证。

6)       动态测试：在系统编码之后进行的验证和确认。

7)       单元测试：对单一独立的模块或编码单元进行测试。

8)       集成测试：对一组模块进行的测试，确保模块之间的数据和控制能正常传递。

9)       系统测试：预先确定的测试组合，当执行成功时，系统符合需求与单元测试不同的各种更高等级测试类型的通用术语。

10)    验收测试：保证系统符合最终用户要求的测试。

11)    回收测试：在系统改变后进行的测试，以确保不希望的变化不引入系统。

12)    功能测试：认为系统应该做什么的业务需求测试。

13)    结构测试：确认系统是如何实现的系统结构测试。

14)    “黑盒”测试：数据驱动的、基于外部规格说明而无须了解系统是如何构造的测试。

风险的概念：

可定义为事件、危险、威胁或情况等发生的可能性以及由此产生不可预料的后果,即一个潜在的问题

基于风险的软件测试的活动实践

1)       确定测试优先级

2)       确定测试完备性

3)       确定测试资源分配

4)       监控测试进度

5)       加速测试信心提升

3.2生命周期各个阶段的测试要求

全生命周期中软件测试的最终要求：

1)       保证软件系统在全生命周期中每个阶段的正确性，验证在整个软件开发周期中各个阶段的软件质量是否合格

2)       保证最终系统符合用户的要求和需求，验证最终交付给用户的系统是否满足用户需要、符合其需求

3)       用样本测试数据检查系统的行为特性

4)       把尽可能多的问题在产品交给用户之前发现并改正

需求测试的目标：

保证需求分析的正确性和充分性。具体来说，需求阶段测试的目标是保证需求正确表现出了用户的需要，需求已被定义和文档花=化，项目的花费和收益成正比，需求的控制被明确，有合理的流程可以遵循，有合理的方法可供选择。

分析测试要素：

1)       需求的设计是否遵循了已定义的方法

2)       提交了已定义的功能说明

3)       定义了系统界面

4)       已经估计了性能标准

5)       容忍度被预先估计

6)       预先定义了权限规则

7)       需求中预先定义了文件完整性

8)       预先定义了需求的变更流程

9)       预先定义了失败的影响

设计阶段测试：

概要设计阶段，测试人员应阐述测试方法和测试股评准测，编写测试计划，组织成立独立的测试小组，安排具有里程碑的测试日程

详细设计阶段，测试人员要开发或获取确认支持工具，生成功能测试数据和测试用例，以此来检查设计中遗漏的情况。错误逻辑、模块接口的部匹配、数据结构不合理、错误的I/O假定、用户界面的补充等。

编码阶段测试：

在编程阶段完成测试用例开发，对程序进行实际的测试：

1）系统是否可维护

2）解决的首要问题是编码是否和设计一致

3）系统的规格说明是否正确地实现

4）编码是否按照既有的标准进行

5）是否有充分的测试计划评价可执行的程序

6）程序是否提供了足够的文档资料

7）程序内部是否有足够的注释等

测试阶段：

1)       在全生命周期软件测试方法中，由于在需求、设计、编码阶段都进行了测试，因此测试阶段的问题相对传统的软件测试中的问题要少一些

2)       在测试阶段要进行第三方的正式确认测试，检验所开发的系统是否能按照用户提出的要求运行

3)       在测试阶段要使得用户能成功地安装一个新的应用系统来进行测试

安装阶段测试：

1）对程序安装的正确性和完整性进行核对

2） 校验产品文件的完整性

3）安装的审查，追踪被记录

4）安装之前，该系统已经被证实没有问题

5）如果安装失败，系统有相应的解决方案

6）安装过程，进行了权限控制（安全性）

7）安装遵循一定的方法，步骤

8）需要的配套程序和数据已经放进了产品中

9）已交付使用说明

10）   相关文件已经完整(可维护性）

11）   接口已经被合理调整（耦合性）

12）   综合的性能达到了用户要求

验收阶段：

1）定义用户角色

2）定义验收标准

3）编制验收计划

4）执行验收计划和填写验收结论

维护阶段：

软件交付使用后的阶段，工作重点是测试和培训

3.3HPALM对生命周期软件测试的支持

HP ALM能为客户带来以下优势

 

1）项目规划及跟踪建立发布标准并实时监控

2）需求、开发及质量工具间的三路追踪

3）对应用变化的快速组内分析及执行

4）惠普敏捷加速器可灵活支持不同项目类型的交付方式

4．软件测试分类与分级

4.1 软件测试分类

计算机软件配置项

软件配置缩写为CSCI(ComputerSoftware Configuration Item)，是为独立的配置管理而设计的且能满足最终用户要求的一组软件，简称软件配置项。

在软件开发过程中，产生的所有信息构成软件配置，它们是：代码、文档、报告等，统称为配置项（Configuration Item，CI）

软件配置管理控制这些软件配置项的投放和变更，并且记录并报告配置的状态和变更要求，验证配置的完整性、正确性和一致性。

基线（baseline）即软件技术状态基线:

指需受配置管理控制的某个研制阶段的结束点时软件成分的技术状态，是已经经过正式审核和同意，它是下一步软件开发的基础

任何一个软件配置项，一旦形成文档并审议通过，即成为基线

对于已经成为基线的软件配置项进行修改时，必须按照特殊的、正式的过程进行评价，确认其修改

对于未成为基线的软件配置项，可以进行非正式的修改

基于CSCI的软件测试分类

功能测试依据：软件功能规格说明书-业务流程说明

工具与技术：黑盒测试技术

目标：验证功能特征是否符合软件功能规格说明书

非功能测试依据：软件非功能性说明书

 工具与技术：黑盒测试技术

静态测试技术

自动化测试工具

目标：度量系统非功能性指标

性能测试

负载测试压力测试

                可用性测试

结构测试依据：软件详细设计说明书

  工具与技术：白盒测试技术

静态测试技术

代码覆盖率测试工具

目标：测量测试的完整性

•      语句覆盖

•      判断覆盖

•      条件覆盖

•      路径覆盖

4.2软件测试分级

针对不同的测试级别，应该明确

1）不同的测试对象

2）每个测试级别的测试目的

3）测试用例设计的基础（所参考的软件产品或测试需求）

4）发现的典型缺陷和失效

5）测试工具的需求和支持

6）不同的测试技术和方法

 

4-1四种软件测试级别

5．软件缺陷管理

5.1软件缺陷

软件缺陷的定义

•     软件错误或软件缺陷是软件产品的固有成分，是软件“生来具有”的特征

•     软件缺陷包括检测缺陷和残留缺陷

•     错误是由软件错误、软件失效、软件故障组成

一般符合下列5个规则之一，就是软件缺陷

Ø   软件未实现产品说明书要求的功能

Ø   软件出现了产品说明书指明不应该出现的错误

Ø   软件实现了产品说明书未提到的功能

Ø   软件未实现产品说明书虽未明确提及但应该实现的目标

Ø   软件难以理解、不易使用、运行缓慢或者——从测试员的角度看——最终用户会认为不好

软件缺陷描述

编号

 

编号

 

1

缺陷标题

8

缺陷的类型

2

标识

9

严重性

3

报告人

10

优先级

4

报告日期

11

关键词

5

程序的名称

12

缺陷描述

6

版本号

13

重现步骤

7

配置

14

结果对比

表5-1软件缺陷描述

图5-1缺陷的分类--严重程度

图5-2缺陷的分类—解决优先级

 

图5-3缺陷的分类--生命周期

缺陷跟踪管理的目标

•      确保每个被发现的缺陷都能够被解决

•      收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段

•      收集缺陷数据并进行数据分析，作为组织的过程财富

图5-4缺陷管理基本流程

 

 

图5-5缺陷管理流程中的各种角色

 

5.2软件缺陷度量、分析与统计

软件缺陷度量

缺陷度量是对项目过程中产生的缺陷数据进行采集和量化，将分散的缺陷数据统一管理，使其有序而清晰

软件缺陷度量的主要方法有：

1）缺陷密度（缺陷在规模上的分布）

缺陷密度=已知缺陷的数量/产品规模

2）缺陷率（缺陷在时间上的分布）

缺陷率=一定时间范围内的缺陷数/错误几率

3）缺陷清除率

整体缺陷清除率=开发过程中发现的所有缺陷数/发现的总缺陷数

阶段性缺陷清除率=开发阶段清除的缺陷数/产品潜伏的缺陷总数

软件缺陷分析

将软件开发各个阶段产生的缺陷信息进行分类和汇总统计,计算分析指标，编写分析报告的活动

图5-6缺陷分析步骤

从统计的角度出发，可以对软件过程的缺陷进行度量

      软件功能模块缺陷分布、缺陷严重程度分布、缺陷类型分布、

缺陷率分布、缺陷密度分析、缺陷趋势分布、缺陷注入率/消除率等

统计的方式

      表格、散点图、趋势图、因果图、直方图、条形图、排列图等

5.3软件缺陷报告

报告缺陷的基本原则

1.       尽快报告软件缺陷

2.       有效的描述软件缺陷

3.       在报告软件缺陷时不做任何评价

4.       确保缺陷可以重现

为书写更好的缺陷报告，需要遵守“5C”准则

Correct(准确)：每个组成部分的描述准确，不会引起误解

Concise(简洁)：只包含必不可少的信息，不包括任何多余的内容

Clear(清晰)：每个组成部分的描述清晰，易于理解

Complete(完整)：包含复现该缺陷的完整步骤和其他本质信息

Consistent(一致)：按照一致的格式书写全部缺陷报告

6．软件测试过程及测试过程管理

6.1软件测试过程

软件测试过程中的关键活动包括

软件测试过程度量指标

1．测试覆盖率：测试覆盖率是指测试用例对需求的覆盖情况

2.测试执行率：实际执行过程中确定已经执行的测试用例比率

3.测试执行通过率：在实际执行的测试用例中，执行结果为“通过”的测试用例比率

4.测试缺陷解决率：某个阶段已关闭缺陷占缺陷总数的比率

软件测试过程度量原则

1)  要制定明确的度量目标

2)  建立软件测试过程质量度量的指标体系，度量指标的定义应该具有一致性、客观性

3)  度量的方法应该尽可能简单、可计算

4)  度量数据的收集应该尽可能自动化

软件测试过程成熟度TMM

初始级，定义级，集成级，管理和测量级，优化、预防缺陷和质量控制级

 

图6-1TMM5个级别

软件成熟度模型(CMM)

初始级、可重复级、定义级、管理级、优化级

图6-2CMM5个级别

6.2软件测试过程管理

图6-3软件测试过程流程

7．软件静态测试

静态测试的概念及特点：

静态测试：通常是指而寻找代码中可能存在的错误或评估程序代码的过程

静态测试对象：各种与软件相关的有必要进行测试的产物，比如各类文档、源代码等。

静态测试的特点

1.不必动态地运行程序。

2.可以人工进行，充分发挥人的思维优势。

3.不需要特别的条件，容易展开。

4.对测试人员要求比较高。

 

图7-1静态测试的主要内容

7.1各阶段评审

同行评审

一般包括审查、小组评审、走查、桌面评审、临时评审五种类型。

同行评审越正式，发现的缺陷越多，但评审越正式，花费成本越高

 

 

 

图7-2同行评审

 

图7-3同行评审

 

7.2代码检查

定义：是以组为单位阅读代码，是一系列规程和错误检查技术的集合

代码评审开展时间：代码全部或部分完成后

测试目的：及早发现缺陷

具体方法：一般采用静态“白盒”测试的方法

代码检查输出的信息：度量标准、易产生错误的代码、代码规则的执行、流图和调用图的分析

代码检查内容：

1)       完整性检查

2)       一致性检查

3)       .正确性检查

4)       可修改性检查

5)       可预测性检查

6)       .健壮性检查

7)       .可理解性检查

8)       .可验证性检查

9)       结构性检查

10)   .可追溯性检查

11)   代码标准符合性检查

图7-4代码检查方法

 

代码审查的要点：

1)       代码和设计的一致性

2)       代码执行标准的情况

3)       代码的逻辑表达正确性

4)       代码结构的合理性

5)       代码的可读性等

代码审查内容：

1)       控制流分析

2)       数据流分析

3)       信息流分析

4)       断言分析

 

 

代码审查步骤

代码审查由4个步骤组成：

准备、程序阅读、审查会、编写报告

代码审查组组成

由组长、资深程序员、程序编写者与专职测试人员等组成

组长不能是被测程序的编写者

 

审查代码方式

采用讲解、提问并用检查表的方式审查代码

有正式的计划、流程和结果报告

 

 

表7-1代码检查方法

桌面检查

程序员自己检查自己所编写的程序

根据相关的文档对源程序代码进行分析、检验，以发现程序中是否有错误的过程

主要工作：桌面检查主要做的工作是检查

1)       代码和设计是否一致

2)       代码是否遵循标准、是否可读

3)       代码逻辑表达是否正确

4)       代码结构是否合理

5)       程序编写与编写标准是否符合

6)       程序中是否有不安全、不明确和模糊的部分

7)       编程风格是否符合要求

代码走查

1)       代码走查的讨论过程是非正式的

2)       代码走查比代码审查要更技术性些

3)       在代码走查中编写代码的程序员要向5人小组或者其他程序员和测试人员组成的小组做正式陈述

技术评审

是最正式的审查类型，具有高度的组织化，要求每一个参与者都接受训练

1)       技术评审由开发组、测试组和相关人员（QA、产品经理等）联合进行

2)       技术评审与走查和审查的不同之处在于表述代码的表述者

7.3软件复杂性分析

  软件危机产生的最直接原因是：

1)       软件的复杂性已经远远超出人们对复杂性控制的能力。

2)       软件可靠性问题的本质就是复杂性问题。

3)       软件的可维护性跟复杂性也存在联系。

目的

1)       减少由软件设计方法和技巧使用不当而带来的复杂性

2)       确保软件产品的质量

3)       降低由复杂性引发软件错误的可能性

4)       提高软件的可靠性和可维护性

5)       更好地对软件开发过程进行控制

产生原因

1)       需求复杂、应用要求高

2)       开发环境复杂

3)       软件应用框架、结构及模型复杂

4)       软件开发过程复杂

5)       涉及人的智力和管理复杂

6)       项目设计与验证复杂

7.4软件质量模型

软件质量的重要性

1)       导致项目进度延误、预算超支或项目失败、项目终止

2)       软件质量高降低项目开发成本，包括维护成本、修复成本等

软件质量的特性

1）用户--如何使用软件、软件性能和使用软件的效果

2）开发者--中间产品的质量以及最终产品

3）管理者--总的质量，而不是某一特性

软件质量可用6个特性

1)       功能性：软件所实现的功能达到它的设计规范和满足用户需求的程度

2)       可靠性：在满足一定条件的应用环境中，软件能够正常维持其工作的能力

3)       可用性：对于一个软件，用户在学习、操作和理解过程中所做努力的程度

4)       效率：在规定条件下，用软件实现某种功能所需的计算机资源(包括时间)的有效程度

5)       维护性：当环境改变或软件运行发生故障时，为使其恢复正常运行所做努力的程度

6)       可移植性：为使一个软件从现有运行平台向另一个运行平台过度所做努力的程度

软件质量分层模型

 

图7-5GB/T 16260-2006质量模型

 

 

 

 

软件度量元选择原则

1)       选择充分体现该领域软件特征的度量元

2)       可操作性好、度量项数据易获得且其获取的代价较小

3)       少而精、规模适中

4)       子特性、度量元尽量不相关

5)       标准符合性要突出

7.5 软件质量管理

软件质量管理三个关键阶段

1)       质量计划制定

2)       质量控制

3)       质量保证

软件质量管理的方法

1)       技术评审

2)       过程检查

3)       实施软件测试

7.6惠普静态分析工具HP FortifySCA

五大扫描引擎

1)       数据流引擎

2)       配置引擎

3)       控制流引擎

4)       结构引擎

5)       语义引擎

8.动态测试

8.1白盒测试

白盒测试的概念

“白盒”测试又称为结构测试或逻辑驱动测试是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的一种测试方法。

白盒测试的特点

1)       可以构成测试数据使特定程序部分得到测试

2)       有一定的充分性度量手段

3)       可获得较多工具支持

4)       通常只用于单元测试

白盒测试的基本测试内容

1)     对程序模块的所有独立执行路径至少测试一次

2)       对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次

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

4)       测试内部数据结构的有效性

 

静态白盒测试技术

动态白盒测试技术

1.代码检查

2.编码标准和规范

 

1.逻辑覆盖测试

2.路径测试

3.数据流测试

4.信息流分析

5.覆盖率分析

表8-1白盒测试技术

逻辑覆盖的概念

逻辑覆盖是以程序内部的逻辑结构为基础的测试方法，属于“白盒”测试。

逻辑覆盖的种类

1)       语句覆盖

2)       判定覆盖

3)       条件覆盖

4)       判定/条件覆盖

5)       条件组合

6)       路径覆盖

语句覆盖

语句覆盖是最起码的测试要求，使得每一条语句至少被执行一次

对程序的逻辑覆盖很少，只关心判定表达式的值，是很弱的逻辑覆盖标准。

 

图8-1例子流程图

测试用例输入

输出

判定N的取值

覆盖路径

A=2,B=0,X=4

A=2,B=0,X=3

 

T

 

P1(a-c-e)

表8-2语句覆盖

判定覆盖

要求设计足够的测试用例，使得程序中的每一个分支至少通过一次即每一条分支语句的“真”值和“假”值都至少执行一次。

测试用例输入

输出

判定N的取值

覆盖路径

A=2,B=0,

X=4

A=2,B=0,X=3

T

 

P1:(a-c-e)

 

A=1,B=1,

X=1

A=1,B=1,X=1

 

F

 

P2:(a-b-d)

 

表8-3判定覆盖

条件覆盖

1)       不仅每一个语句至少执行一次，使得判定中的每个条件获得各种可能的结果。

2)       判定覆盖只关心整个判定表达式的结果，条件覆盖关心的则是每个条件各种取值的结果。

 

测试用例输入

输出

具体取值条件

覆盖路径

A=2,B=0,

X=4

A=2,B=0,

X=3

A>1,B=0,

A=2,X>1

P1:(a-c-e)

A=1,B=1,

X=1

A=1,B=1,

X=1

A<=1,B!=0,A!=2,X<=1

 

P4:(a-b-d)

 

表8-4条件覆盖

判定/条件覆盖

设计足够多的测试用例，使得判定中每个条件的所有可能取值至少能够获取一次，同时每个判断的所有可能的判定结果至少执行一次。

 

测试用例输入

输出

取值条件

具体取值条件

覆盖路径

A=2,B=0,X=4

A=2,B=0,X=3

 

T1,T2, T3, T4

A>1,B=0,

A=2,X>1

P1:(a-c-e)

 

A=1,B=1,X=1

 

A=1,B=1,X=1

 

F1, F2, F3,F4

A<=1,B!=0,A!=2,X<=1

 

P4:(a-b-d)

 

表8-5判定/条件覆盖

条件组合覆盖

1)       要求设计足够多的测试用例，使得每个判定中条件的各种组合至少出现一次。

2)       满足条件组合覆盖标准的测试用例，也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。

1） A>1, B =0     2） A>1, B≠0

3） A≤1, B =0    4） A≤1, B≠0

5） A=2, X>1      6） A=2,  X≤1

7） A≠2, X>1     8）A≠2, X≤1

测试用例输入

输出

取值条件

具体取值条件

覆盖路径

A=2,B=0,X=4

A=2,B=0,X=3

T1,T2,T3,T4

1,5

P1:(a-c-e)

A=2,B=1,X=1

A=2,B=1,X=2

T1,F2,T3,F4

2,6

P3:(a-b-e

表8-6条件组合覆盖

路径测试

根据程序的逻辑控制所产生的路径进行测试用例设计的方法。

它是从一个程序的入口开始，执行所经历的各个语句的完整过程，完成路经测试的理想情况是做到路径覆盖。

数据流测试

数据流测试是指关注变量接受值的点和使用（或引用）这些值的点的结构性测试形式。

目的

1)       最初是随着编译系统要生成有效的目标码而出现的。

2)       发现定义/引用异常缺陷

定义

1)       以程序数据流的视角

2)       基于数据流关系

3)       使用程序图来描述数据“定义-使用”对

4)       通过对路径进行“真实性检查”

覆盖率分析及测试覆盖准则

代码覆盖率是指采用白盒法进行测试时，考虑的是测试用例对程序内部逻辑的覆盖程度。

覆盖率分析主要对代码的执行路径覆盖范围进行评估，这些覆盖从不同要求出发，为设计测试用例提出依据。

覆盖测试的做法

1)       对程序模块的所有独立的执行路径至少测试一次。

2)       对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次。

3)       在循环的边界和运行界限内执行循环体。

4)       测试内部数据结构的有效性。

8.2     黑盒测试

黑盒测试又称功能测试或数据驱动测试，把测试对象当作看不见内部的黑盒，在完全不考虑程序内部结构和处理过程的情况下，测试者仅依据程序功能的需求规范考虑，确定测试用例和推断测试结果的正确性.，站在使用软件或程序的角度，从输入数据与输出数据的对应关系进行的测试，在软件的接口处进行测试，通过导出执行程序所有功能需求的输入条件集，实现功能覆盖，需求覆盖

黑盒测试要求

1)       每个软件特性或功能必须被一个测试用例或一个被认可的异常所覆盖

2)       构造数据类型和数据值的最小集测试

3)       测试排斥不规则输入的能力

4)       对影响性能的关键模块，应测试模块性能

黑盒测试包括等价类划分法、边界值分析法、因果图方法、随机数法、猜错法

什么是等价类划分

1)     等价类，把所有可能的输入数据,即程序的输入域划分成若干部分,

2)       划分，从每一部分中选取少数有代表性的数据做为测试用例，代表性数据等同于该类中的其他值

划分等价类的考虑因素

1.       输入数据

2.       输出数据

1)       有效等价类：对于程序规格说明来说，是合理的，有意义的输入数据构成的集合

2)       无效等价类：对于程序规格说明来说，是不合理的，无意义的输入数据构成的集合

等价类划分的方法

1)       按区间划分

2)       按数值划分

3)       按数值集合划分

4)       按限制条件或规划划分

5)       按处理方式划分

等价类划分步骤：

1)       划分确定等价类

2)       选取测试用例

划分等价类的原则

1)       输入条件的取值范围，可以划分出一个有效等价类和两个无效等价类

2)       如果输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，这时可确立一个有效等价类和一个无效等价类

3)       如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类。

4)       如果规定了输入数据的一组值(假设N个)，而且程序要对每个输入值分别进行处理。

5)       如果规定了输入数据必须遵守的规则，则可确立一个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)

6)       在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小的等价类

图8-2确立测试用例

 

边界值分析

1.       边界的含义

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法,稍高于其边界值及稍低于其边界值的一些特定情况

2.       边界值分析方法

选取正好等于，刚刚大于，或刚刚小于边界的值做为测试数据的方法

边界值分析原则

1)       如果输入条件规定了值的范围，则应取刚达到这个范围的边界值，以及刚刚超越这个范围的边界值作为测试的输入数据。

2)       如果输入条件规定了值的个数，则用最大个数，最小个数，比最小个数少一

3)       最大个数多一的数作为册数数据。

4)       根据规格说明的每个输出条件，使用原则 1）

5)       如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的一个

6)       素和最后一个元素作为测试用例。

7)       分析规格说明，找出其他可能的边界条件。

定义

      是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，该方法充分考虑了输入情况的各种组合及输入条件之间的相互制约关系。

因果图适用范围

1)       适合检查程序输入条件的各种组合情况

2)       产生背景

3)       等价类法、边界值法分析着重考虑输入条件，未考虑输入条件之间的关系

用因果图生成测试用例的基本步骤

1)       分析软件规格说明描述：原因、结果、标识符

2)       分析软件规格说明描述中的语义：找出逻辑关系

3)       由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现，添加必要的约束条件

4)       把因果图转换成判定表

5)       把判定表的每一列拿出来作为依据，设计测试用例

随机测试

随机测试指测试输入数据是所有可能输入值中随机选取的，是一种基本的黑盒测试方法。

猜错法

1)       猜错法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。

2)       猜错法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。

8.3     灰盒测试

“灰盒”测试与白盒测试的区别

1)       “白盒”测试在测试过程中测试者可以看到被测的源程序，通过分析程序的内部结构，根据其内部结构设计测试用例

2)       灰盒测试无需关心模块内部的实现细节

灰盒测试与黑盒测试的区别

1)       “黑盒”测试是在测试者完全不考虑程序内部结构和内部特征的情况下，根据需求规格说明书设计测试用例和推断的测试结果的正确性

2)       “黑盒”测试只考虑了程序的输入，以及在该情况下的输出，并没有考虑程序的内部结构。

3)       灰盒测试需关心模块与模块之间的交互。

灰盒测试

“灰盒”测试是一种综合测试法，它将“黑盒”测试、“白盒”测试、回归测试结合在一起，构成一种无缝测试技术。

“灰盒”测试思想

1)       基于程序运行时的外部表现同时又结合程序内部逻辑结构来设计用例，执行程序并采集程序路径执行信息和外部用户接口结果的测试技术

2)       其目的是验证软件满足外部指标以及软件的所有通道或路径都进行了检验

“灰盒”测试的优点

1)       能够进行基于需求的覆盖测试和基于程序路径覆盖的测试；

2)       测试结果可以对应到程序内部路径，便于bug的定位、分析和解决；

3)       能够保证设计的“黑盒”测试用例的完整性，防止遗漏软件的一些不常用的功能或功能组合；

4)       能够需求或设计不详细或不完整对测试造成的影响。

8.4测试用例设计

测试用例更具体的设计原则

1)       测试用例考虑单次投入成本和多次使用成本

2)       总体思路是先进行基本功能测试，再进行复杂功能测试；

3)       先进行一般用户测试，在进行特殊用户使用测试；

4)       先进行正常情况测试，再进行特殊情况测试；

5)       用测试用例文档替代产品文档

6)       避免冗长和复杂的测试用例

测试用例的覆盖内容

1)       正确性测试

2)       容错性(健壮性)测试

3)       完整(安全)性测试

4)       接口测试

5)       数据库测试

6)       边界值测试

7)       压力测试

8)       等价划分测试

9)       错误推测

10)    效率

11)    可理解(操作)性测试

12)    可移植性测试

13)    回归测试

14)    比较测试

8.5单元测试

1)       单元测试的好处

2)       程序最小组成部分

3)       可以并行开展

4)       规模小，复杂性低

5)       做好单元测试后，后续的集成测试和系统测试会很顺利

6)       不管怎样，集成测试或系统测试将会抓住所有的bug

7)       尽早的发现缺陷，降低测试成本

8.6集成测试

为什么要开展集成测试

1)       把各个单元模块连接起来的时候，穿越模块接口的数据是否会丢失

2)       一个单元模块的功能是否会对另一个单元模块的功能产生不利的影响

3)       各个子功能组合起来，能否达到预期要求的父功能

4)       全局数据结构是否有问题

5)       共享资源访问是否有问题

6)       单个模块的误差积累起来，是否会放大，从而达到不能接受的程度

7)       引入一个模块后，是否对其他与之相关的模块产生负面影响

集成测试的内容

1)       集成后的功能性测试

2)       接口测试

3)       全局数据结构测试

4)       资源测试（共享资源测试和资源极限测试）

5)       性能测试

6)       稳定性测试

集成测试的步骤

1)       体系结构分析

2)       模块分析

3)       接口分析

4)       风险分析

5)       可测试性分析

6)       集成测试策略分析

图8-3集成策略

集成测试各阶段

1)       集成测试计划阶段(5W)+资源、测试进度及测试用例

2)       集成测试设计与开发阶段

3)       执行阶段

4)       评估阶段

8.7确认测试

确认测试基本概念

确认测试是严格遵循有关标准的一种符合性测试，以确定软件产品是否满足所给定的要求。

确认测试是在完成集成测试后，依据确认测试准则，针对需求规格说明进行的测试，以确定所开发的软件系统是否能满足规定的功能和性能要求。

确认测试的实施

1)       确认测试必须有用户参加，或者是以用户为主进行

2)       用户应参与设计测试方案，使用用户界面输入测试数据，并分析测试结果

3)       为使用户积极参与测试，有效使用系统，通常需要对用户进行培训

8.8系统测试

系统测试的概念

系统测试是将已经集成好的软件系统与计算机硬件、外设、网络、数据等其他元素结合在一起，在实际运行环境下，对软件信息系统的各种组装测试和确认测试。

系统测试的目的

通过与系统的需求定义比较，检查软件是否存在于系统定义不符合或与之矛盾的地方，以验证软件系统的功能和性能等满足其规约指定的要求

系统测试的对象

需要测试的产品系统的软件，软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及接口

系统测试过程定义

8-4系统测试过程

系统测试需求分析的几条准则

1)       测试需求必须是可观测、可评测的行为

2)       每个用例或系统的补充需求与测试需求之间不存在一对一的关系

3)       需求规格说明书中的每个功能、性能、安全描述等将派生一个或多个测试需求

4)       功能测试需求和性能测试需求是整个系统测试需求中的核心

系统测试的测试类型

1)       功能测试、性能测试、接口测试

2)       强度测试、人机交互界面测试、余量测试

3)       可靠性测试、安全性测试、恢复性测试

4)       边界测试、数据处理测试、安装性测试

5)       容量测试、互操作性测试、敏感性测试

6)       标准符合性测试、兼容性测试、中文本地化测试

图8-5测试设计的一般流程

 

系统测试手段

1)       软件故障模型

2)       典型攻击方法

3)       软件故障植入

图8-6典型攻击方法——考虑因素

图8-7软件故障植入方式

 

9.  软件手工测试与自动化测试

软件手工测试概念

1)       按照事先为覆盖被测软件而编写的测试用例，

2)       根据测试步骤和方法，手工地一个一个的输入执行，然后观察结果，看被测程序是否存在问题，或在执行过程中是否会有异常发生，

3)       包括与被测软件进行交互，属于比较原始但是必须执行的一个步骤。

自动化测试的概念

1)       将大量重复性的测试工作交给计算机去完成，

2)       使用自动化测试工具来模拟手动测试步骤，

3)       执行用某种程序设计语言编制的测试程序，控制被测软件的执行，

4)       完成全自动或半自动测试的过程。

手工测试的特点

1)       大量文档、报表的制订和整理工作，使测试员力不从心

2)       受软件分发日期、开发成本及人员、资源等诸多方面因素的限制，难以进行全面的测试

3)       难应用于回归测试

4)       缺乏有效的管理手段，责任含糊不清，工作效率低

5)       重复测试疲劳，测试标准前后不一，测试花费时间越久，严格性约低

6)       难以对不可视对象/对象的不可视属性进行测试

自动化测试的特点

1)       高效率地进行测试

2)       可以执行一些手工测试困难或者不可能做的测试；

3)       测试的准确性得到提高，测试人员的技术要求可以降低；

4)       具有一致性和可重复性，有利于进行回归测试

5)       资源利用率得到提高，缩短测试的时间

6)       测试具有移植性和可重复性

图9-1软件测试活动的实施过程

二．实训问题反馈

整理等价类划分、边界值、飞机订票系统实验中遇到的问题及解决方法

序号

问题描述

解决方法

1

在等价类中用例考虑的不全面

根据需求考虑分不同的类考虑

2

在边界值中对同时满足多个条件中的值不知道该什么写

通过和小组商量尽可能的把输出期望值靠近给的值

3

在飞机订票系统中自己写完了的东西，反复的看也不会发现问题

让别人检查一下，就会把一些错误找出来了

三．学习规划

接下来要学习测试工具，希望自己能跟的上进度，突然感觉时间过的好快啊，感觉自己学的东西都没有很好的吸收，要在网上找一些视频提前看看，这样等老师上课讲的时候才能更好的吸收知识。

每天制定计划，晚上回宿舍后把白天老师讲的知识点再复习一下，提前看看接下来老师要讲的东西，这样上课的效果就会好点。