软件测试学习笔记.docx

软件测试学习笔记.docx

《软件测试学习笔记.docx》由会员分享，可在线阅读，更多相关《软件测试学习笔记.docx（23页珍藏版）》请在冰豆网上搜索。

软件测试学习笔记

一、概述1

1.软件质量的定义1

2.软件质量的模型2

3.软件缺陷3

4.软件测试的狭义与广义观点3

5.测试与开发4

6.制定项目规范5

二、单元测试5

1.白盒测试：

6

2.代码审查8

3.单元测试工具种类9

三、集成测试9

四．需求评审9

1、软件评审的方法与技术9

2、产品需求评审10

五、测试计划10

六、设计验证12

七、功能测试（黑盒测试）12

1、功能测试内容和方法12

2、等价类划分法13

3、边界值分析法14

4、因果图法15

5、决策表法和错误推测法15

6、场景法和状态图法16

八、非功能测试用例设计16

九、国际化和本地化测试17

十、系统测试17

一、概述

1.软件质量的定义

软件产品反应实体满足明确的和隐含的与需求能力有关的全部特征和特性的综合，包括：

软件产品质量满足用户要求的程度

软件各种属性组合的程度

用户对软件产品的综合反映程度

软件在使用过程中满足用户要求的程度

实体是可以单独描述和研究的事物，如产品、活动、过程、组织和体系等

软件质量其它定义

v客户满意度：

使最终的软件产品能最大限度地满足客户需求的程度。

v一致性准则：

在生命周期的每个阶段中，其工作产品总能保持与上一阶段工作产品的一致性，最终可追溯到所分配的需求。

v软件质量度量：

设立软件质量度量指标体系，并以此来度量软件产品的质量。

v过程质量观：

软件的质量就是其开发过程的质量

软件产品质量的需求

v功能性需求

▪PRD/MRD,UIMock-up,FunctionalSpec

▪也可称为可说明性

v非功能性需求

▪性能、兼容性、安全性、可用性、可靠性等

▪可扩展性和灵活性，以适应一定程度的需求变化

▪能有效处理例外或异常情况

v软件质量实际上是各种特性的复杂组合

2.软件质量的模型

vBoehm质量模型

vMcCall质量模型

vISO的软件质量模型

Boehm质量模型

v分成可移植性，可用性和可维护性

v可用性分为可靠性，效率，人类工程

v可维护性分为可测试性，可理解性，可修改性

McCall质量模型

ISO的软件质量模型

v按照ISO/IEC9126-1：

2001,软件质量模型分为：

内部质量和外部质量模型。

v内部质量和外部质量规定了六个质量特性，它们可以进一步细分为子特性

v功能性：

适合性，准确性，互用性，保密性，功能性的依从性

v可靠性：

成熟性，容错性，易恢复性，可靠性的依从性

v易用性：

易理解性，易学性，易操作性，吸引性，易用性的依从性

v效率：

时间特性，资源利用性，效率依从性

v可维护性：

易分析性，易变更性，稳定性，易测试性，可维护性的依从性

v可移植性：

适应性，易安装性，共存性，可替换性，可移植性的依从性

3.软件缺陷

从内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；

从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背

v软件缺陷的主要类型/现象：

▪功能、特性没有实现或部分实现

▪设计不合理，存在缺陷

▪实际结果和预期结果不一致

▪没有达到产品规格说明书所规定的特性、性能指标等

▪运行出错，包括运行中断、系统崩溃、界面混乱

▪数据结果不正确、精度不够

▪用户不能接受的其他问题，如存取时间过长、界面不美观

▪硬件或系统软件上存在的其它问题

软件缺陷与软件错误之辩

软件缺陷范围更广，涵盖了软件错误，还涵盖不一致性问题、功能需求定义缺陷和产品设计缺陷等。

软件错误，属于软件缺陷的一种——程序或系统的内部缺陷，往往是软件代码本身的问题

4.软件测试的狭义与广义观点

程序测试是为了发现错误而执行程序的过程

将测试延伸到需求评审、设计审查活动中去。

由静态测试和动态测试构成一个全过程的、完整的软件测试

静态测试和动态测试

v静态测试是指不运行被测程序本身而尝试查找缺陷的方法。

比如，分析或检查源程序的语法、结构、过程、接口，审查需求设计及其它文档。

v动态测试是通过运行程序检查运行结果与预期结果的差异，并分析运行效率和健壮性等性能，这种方法由三部分内容组成：

构造测试实例、执行程序、分析程序的输出结果.

软件测试的其它视点

v风险观点：

软件测试是对软件系统中潜在的各种风险进行评估的活

v经济学观点：

一个好的测试用例是在于它能发现至今未发现的错误。

缺陷发现得越早，所造成得代价就越低，这就是从经济学的观点来说明测试越早越好。

v标准观点：

软件测试就是“验证（Verification）”和“有效性确认（Validation）”活动构成的整体，即软件测试=V&V

验证和确认（V&V）

Verification：

Arewebuildingtheproductright？

验证产品满足规格设计说明书的一致性,我们正确地构造产品了吗？

Validation：

Arewebuildingtherightproduct?

验证产品所实现的功能是否满足用户的需求。

我们构造了正确的产品吗？

软件测试的目标

v直接目标——就是为了更快更早地将软件产品或软件系统中所存在的问题找出来，以促进系统分析人员、设计人员和程序员尽快地解决这些问题。

v间接目标——软件测试的间接目标是验证了所有功能已按照事先设计或定义而实现。

但其直接目的并非验证每个功能都能实现，而是设法找到每个功能不能正常实现的地方，即尽量促使软件故障的产生。

软件测试的非完备性因素

v测试覆盖率不可能达到100%

v发现缺陷越多的地方，往往漏掉缺陷的可能性更大

v修正过去的缺陷会产生新的缺陷

v测试人员对产品的理解不能完全代表实际用户的理解

v测试环境难以和实际运行或用户的环境完全吻合。

v没有缺陷不是靠测试来保证的，而是靠软件过程的各个环节来保证的。

5.测试与开发

制度性设置

v测试部门与开发部门的独立设置是软件开发质量得到保证的一个制度性设置。

v测试对于开发有效监督与反馈，从源头促进质量提高，保证软件构造的质量。

v开发因测试结果而不断完善，测试还起着“把关”或“守门员”的作用

测试&开发的同步关系

测试&开发的依赖关系

v测试对象是软件开发的阶段性成果

v软件开发的进一步活动有依赖于测试结果

前期更多地依赖于开发过程，设计和实现能力决定整个软件过程的进展状态。

后期更多地依赖于测试过程，测试策略和能力，会直接影响测试效率，测试效率高就能更快地发现缺陷，缺陷就能得到更快地修正

6.制定项目规范

软件测试规范就是对软件测试的流程过程化，并对每一个过程元素进行明确的界定，形成完整的规范体系

测试活动过程

v制定测试计划

v测试设计

v开发测试工具和脚本

v执行单元测试

v执行集成测试

v执行系统测试

v评估测试

角色和职责

v测试主管

v测试组组长（测试计划文档，测试规范说明文档）

v测试分析员（负责设计和实现用于完成AUT测试的一个或多个测试脚本，协助组长生成测试规格说明文档）

v测试者（负责执行由测试分析员建立的测试脚本，并负责解释测试用例的结果并将结果录到文档中）

测试阶段

v单元测试

v集成测试

v系统测试

v系统集成测试

v验收测试

v回归测试

二、单元测试

单元测试就是对已实现的软件最小单元进行测试，以保证构成软件系统的各个单元的质量

单元测试应从各个层次来对单元内部算法、外部功能实现等进行检验，包括对程序代码的评审和通过运行单元程序来验证其功能特性等内容。

黑盒测试

白盒测试

优点

①适用于各阶段测试

②从产品功能角度测试

③容易入手生成测试数据

①可构成测试数据使特定程

序部分得到测试

②有一定的充分性度量手段

③可获较多工具支持

缺点

①某些代码得不到测试

②如果规格说明有误，则无法发现

③不易进行充分性测试

①不易生成测试数据（通常）

②无法对未实现规格说明的部分进行测试

③工作量大，通常只用于单元测试，有应用局限

性质

是一种确认技术，回答“我们在构造一个正确的系统吗”

是一种验证技术，回答“我们在正确地构造一个系统吗？

”

驱动程序和桩程序

v驱动程序（driver），对底层或子层模块进行（单元或集成）测试时所编制的调用被测模块的程序，用以模拟被测模块的上级模块

v桩程序（stub），也有人称为存根程序，对顶层或上层模块进行测试时，所编制的替代下层模块的程序，用以模拟被测模块工作过程中所调用的模块

1.白盒测试：

测试覆盖率：

用于确定测试所执行到的覆盖项的百分比。

其中的覆盖项是指作为测试基础的一个入口或属性，比如语句、分支、条件等

测试覆盖率可以表示出测试的充分性，在测试分析报告中可以作为量化指标的依据，测试覆盖率越高效果越好。

但覆盖率不是目标，只是一种手段

v测试覆盖率包括功能点覆盖率和结构覆盖率：

Ø功能点覆盖率大致用于表示软件已经实现的功能与软件需要实现的功能之间的比例关系。

Ø结构覆盖率包括语句覆盖率、分支覆盖率、循环覆盖率、路径覆盖率等等。

逻辑覆盖法

逻辑覆盖又可分为语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、组合覆盖和路径覆盖

Ø语句覆盖：

选择足够多的测试用例，使得程序中的每个可执行语句至少执行一次。

Ø判定覆盖：

通过执行足够的测试用例，使得程序中的每个判定至少都获得一次“真”值和“假”值，也就是使程序中的每个取“真”分支和取“假”分支至少均经历一次，也称为“分支覆盖”。

Ø条件覆盖：

设计足够多的测试用例，使得程序中每个判定包含的每个条件的可能取值（真/假）都至少满足一次。

Ø判定/条件覆盖：

设计足够多的测试用例，使得程序中每个判定包含的每个条件的所有情况（真/假）至少出现一次，并且每个判定本身的判定结果（真/假）也至少出现一次。

——满足判定/条件覆盖的测试用例一定同时满足判定覆盖和条件覆盖。

Ø组合覆盖：

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

——满足组合覆盖的测试用例一定满足判定覆盖、条件覆盖和判定/条件覆盖。

Ø路径覆盖：

设计足够多的测试用例，要求覆盖程序中所有可能的路径。

测试覆盖准则

vFoster的ESTCA覆盖准则：

在容易发生问题的地方设计测试用例，即重视程序中谓词（条件判断）的取值。

规则1]对于ArelB型（rel可以是<、=或>）的分支谓词，应适当的选择A与B的值，使得测试执行到该分支语句时，AB的情况分别出现一次

——这是为了检测逻辑符号写错的情况，如将“AB”。

Ø[规则2]对于ArelC型（rel可以是>或<,A是变量，C是常量）的分支谓词：

当rel为<时，应适当的选择A的值，使A=C-M（M是距C最小的机器容许正数，若A和C都为正整数时，M=1）；当rel为>时，应适当的选择A的值，使A=C+M。

——这是为了检测“差1”之类的错误，如“A>1”错写成“A>0”。

Ø[规则3]对外部输入变量赋值，使其在每一个测试用例中均有不同的值与符号，并与同一组测试用例中其他变量的值与符号不同。

——这是为了检测程序语句中的错误，如应该引用某一变量而错成引用另一个常量。

基本路径测试方法

在不能做到所有路径覆盖的前提下，如果某一程序的每一个独立路径都被测试过，那么可以认为程序中的每个语句都已经检验过了，即达到了语句覆盖。

这种测试方法就是通常所说的基本路径测试方法

控制流图

计算环形复杂度的方法

vV（G）=区域数目

vV（G）=边界数目–节点数目+2

vV（G）=判断节点数目+1

v独立路径是指程序中至少引入了一个新的处理语句集合或一个新条件的程序通路。

采用流图的术语，即独立路径必须至少包含一条在本次定义路径之前不曾用过的边。

循环测试方法

测试简单循环。

设其循环的最大次数为n，可采用以下测试集：

Ø跳过整个循环；

Ø只循环一次；

Ø只循环两次；

Ø循环m次，其中m

Ø分别循环n-1、n和n+1次

测试嵌套循环。

如果将简单循环的测试方法用于嵌套循环，可能的测试次数会随嵌套层数成几何级数增加。

此时可采用以下办法减少测试次数：

Ø测试从最内层循环开始，所有外层循环次数设置为最小值；

Ø对最内层循环按照简单循环的测试方法进行；

Ø由内向外进行下一个循环的测试，本层循环的所有外层循环仍取最小值，而由本层循环嵌套的循环取某些“典型”值；

Ø重复上一步的过程，直到测试完所有循环。

测试串接循环。

若串接的各个循环相互独立，则可分别采用简单循环的测试方法；否则采用嵌套循环的测试方法。

对于非结构循环这种情况，无法进行测试，需要按结构化程序设计的思想将程序结构化后，再进行测试。

其它白盒测试方法

程序插桩方法是借助往被测程序中插入操作，来实现测试目的的方法

v如果我们想要了解一个程序在某次运行中所有可执行语句被覆盖的情况，或是每个语句的实际执行次数，最好的办法是利用插桩技术。

在程序中特定部位插入某些用以判断变量特性的语句，使得程序执行中这些语句得以证实，从而使程序的运行特性得到证实。

我们把插入的这些语句称为断言。

Z路径覆盖下的循环测试方法在循环简化的思路下，循环与判定分支的效果是一样的，即：

循环要么执行、要么跳过。

域测试是一种基于程序结构的测试方法。

域测试正是在分析输入域的基础上，选择适当的测试点以后进行测试的

符号测试的基本思想是允许程序的输入不仅仅是具体的数值数据，而且包括符号值，这一方法也因此而得名。

2.代码审查

代码审查的目的就是为了产生合格的代码，检查源程序编码是否符合详细设计的编码规定，确保编码与设计的一致性和可追踪性

审查的内容

☐业务逻辑的审查

☐算法的效率

☐代码风格

☐编程规则

代码缺陷检查表

把程序设计中可能发生的各种缺陷进行分类，以每一类列举尽可能多的典型缺陷，形成代码缺陷检查表

在不同的测试节点，测试的侧重点不同：

在单元测试阶段，以代码检查、逻辑覆盖为主；在集成测试阶段，需要增加静态结构分析等；在系统测试阶段，应根据黑盒测试的结果，采取相应的白盒测试。

3.单元测试工具种类

☐代码规则/风格检查工具

☐内存资源泄漏检查工具

☐代码覆盖率检查工具

☐代码性能检查工具

静态测试工具和动态测试工具

☐静态测试工具不需要运行代码，而是直接对代码进行语法扫描和所定义的规则进行分析，找出不符合编码规范的地方，给出错误报告和警告信息。

☐动态测试工具则需要通过运行程序来检测程序，需要写测试脚本或测试代码来完成分支覆盖、条件覆盖或基本路径覆盖的测试。

三、集成测试

集成测试的模式

非渐增式测试模式：

先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。

渐增式测试模式：

把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。

驱动程序/驱动模块（driver），用以模拟被测模块的上级模块。

驱动模块在集成测试中接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印出相应的结果。

桩程序/桩模块（stub），也有人称为存根程序，用以模拟被测模块工作过程中所调用的模块。

桩模块由被测模块调用，它们一般只进行很少的数据处理，例如打印入口和返回，以便于检验被测模块与其下级模块的接口

v自顶向下集成测试

v自底向上集成测试

v混合策略

四．需求评审

1、软件评审的方法与技术

软件评审是对软件元素或者项目状态的一种评估手段，以确定其是否与计划的结果保持一致，并使其得到改进。

产品需求审查是软件开发重要环节之一，也是测试活动之一，即静态测试——需求验证。

借助需求审查保证用户需求在市场/产品需求文档及其相关文档中得到准确、完整、无歧义的反映，并使各类开发人员在需求理解上达成一致。

技术评审

文档评审

管理（流程）评审

评审的技术：

检查表、场景分析、头脑风暴和工具等

2、产品需求评审

重要性

测试人员在需求评审中作用

测试人员主要起着评审员的作用，检查需求定义是否合理和清楚

标准

过程

五、测试计划

1、测试计划的内容

☐确认测试目标、范围和需求

☐识别测试风险，制订相应的测试策略

☐对测试任务和工作量进行估算

☐确定所需的时间和资源

☐进度安排和资源分派，包括团队角色、责任和培训

☐测试阶段划分，包括阶段性任务和成果

☐跟踪和控制机制

1）测试需求

功能性测试需求主要是根据产品规格说明书来检验被测试的系统是否满足软件各方面的功能的使用要求，包括用户界面的友好性。

非功能性质量需求，包括系统性能、安全性、兼容性、扩充性，其测试需求会因不同的项目类型差异较大。

各个阶段测试任务

需求分析审查—设计审查—单元测试—集成测试—功能测试—系统测试—验收测试—版本发布—维护

测试范围分析

如何通过测试的执行来满足测试的需求，这就需要分析测试的范围、任务和其他条件，从而估算工作量和测试时间，安排测试进度和配置资源。

☐功能测试范围可以借助流程图和框图按功能层次分解，也可以按功能区域、功能逻辑进行分解

☐非功能性测试范围可以分别从性能测试、兼容性测试、适用性测试和安全性测试等各个方面进行分析

2）工作量估计

测试工作量是根据测试范围、策划任务和开发阶段来确定的，测试范围和测试任务是测试工作量估算的主要依据

估算方法

v工作分解结构表方法

测试工作量的估算依赖于测试任务的细化，对每项测试任务进行分解，然后根据分解的子任务进行估算。

通常分解粒度越小，估算精度越高

v功能点方法、对象点方法

v测试用例估算

v代码行预估

v历史数据推算（相似规模、同类型）

v经验法（资深人员或专家小组）

v综合方法

3）资源安排和进度管理

v1测试资源需求

v2团队组建与培训

v3测试进度管理

4）测试风险的控制

☐风险识别的有效方法就是建立风险项目检查表

控制风险的对策

v消除执行风险

v降低进度风险

v减少人员风险

5）测试策略的内涵

测试策略描述当前测试项目的目标和所采用的测试方法，描述不同测试阶段的测试对象、范围和方法以及每个阶段内所要进行的测试类型，或者说是在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。

6）完整的测试计划书

v目标和范围：

产品特性、质量目标、范围和限制

v项目估算：

工作量、资源的估算

v风险计划：

风险分析、识别与回避/缓解对策

v进度安排：

分解项目工作结构，指定时间/资源表

v资源配置：

人员、硬件和软件等分配。

v跟踪和控制机制：

质量保证、变更控制等

六、设计验证

1、设计审查

测试人员参与设计评审保证需求能在设计中得到准确和完整的表示，也就是保证产品规格说明书的质量。

☐系统架构的审查

☐设计规格说明书的审查

☐系统部署设计的审查

☐多层次审查:

high-levellow-level

2、软件设计验证的需求

v软件运行和服务的设计验证需求：

性能、安全性、可用性、功能性、可使用性

v软件部署和维护周期的设计验证需求：

可修改性、可移植性、可复用性、可继承性、可测试性

v与体系结构本质相关的验证需求：

概念完整性、正确性、完备性和可构造性

3、系统设计的评审标准

4、系统架构设计的审查

产品设计规格说明书的复审

系统部署设计的审查

七、功能测试（黑盒测试）

功能测试一般采用黑盒测试方法

黑盒测试被称为功能测试或数据驱动测试。

不深入代码细节的测试方法称为动态黑盒测试。

软件测试员充当客户来使用它。

1、功能测试内容和方法

v内容

▪界面测试

▪数据测试

▪操作测试

▪逻辑测试

▪接口测试

v方法

▪全面理解功能特性􀂙

▪客户需求导向的思维方式􀂙

▪用例􀂙

▪工作流图/数据流图/UMLcharts􀂙

▪负面测试

主要的功能测试方法

v也就是黑盒测试用例设计方法

▪等价类划分法

▪边界值法

▪因果图法

▪决策表法

▪错误推测法

▪……

2、等价类划分法

等价类划分法是把所有可能的输入数据，即程序的输入域划分为若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例

有效等价类、无效等价类

等价类的划分原则

（1）按照区间划分

（2）按照数值划分

（3）按照数值集合划分

4）按照限制条件或规则划分

（5）细分等价类

等价类划分法的测试用例设计

（1）首先为等价类表中的每一个等价类分别规定一个唯一的编号。

（2）设计一个新的测试用例，使它能够尽量覆盖尚未覆盖的有效等价类。

重复这个步骤，直到所有的有效等价类均被测试用例所覆盖。

（3）设计一个新的测试用例，使它仅覆盖一个尚未覆盖的无效等价类。

重复这一步骤，直到所有的无效等价类均被测试用例所覆盖。

v针对是否对无效数据进行测试，可以将等价类测试分为标准等价类测试和健壮等价类测试。

v标准等价类测试——不考虑无效数据值，测试用例使用每个等价类中的一个值。

v健壮等价类测试——主要的出发点是考虑了无效等价类。

对有效输入，测试用例从每个有效等价类中取一个值；对无效输入，一个测试用例有一个无效值，其他值均取有效值。

健壮等价类测试存在两个问题：

（1）需要花费精力定义无效测试用例的期望输出

（2）对强类型的语言没有必要考虑无效的输入

3、边界值分析法

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。

通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类边界

1、用边界值分析法设计测试用例

（1）每次保留程序中一个变量，让其余的变量取正常值，被保留的变量依次取min、min+、nom、max-和max。

（2）对程序中的每个变量重复

（1）。

推论：

对于一个含有n个变量的程序，采用边界值分析法测试程序会产生4n+1个测试用例。

健壮性测试

健壮性测试是作为边界值分析的一个简单的扩充，它除了对变量的5个边界值分析取值外，还需要增加一个略大于最大值（max+）以及略小于最小值（min-）的取值，检查超过极限值时系统的情况。

因此，对于有n个变量的函数采用健壮性测试需要6n+1个测试用例。

利用边界值作为测试数据

边界值

测试用例的设计思路

字符

起始-1个字符/结束+1个字符

假设一个文本输入区域允许输入1个到255个字符，输入1个和255个字符作为有效等价类；输入0个和256个字符作为无效等价类，这几个数值都属于边界条件值。

数值

最小值-1/最大值+1

假设某软件的数据输入域要求输入5位的数据值，可以使用10000作为最小值、99999作为最大值；然后使用刚好小于5位和大于5位的数值来作为边界条件。

空间

小于空余空间一点/大于满空间一点

例如在用U盘存储数据时，使用比剩余磁盘空间大一点（几KB）的文件作为边界条件。

选择测试用例的原则

（1）