软件测试(期末随记)

软件测试

1.引言

为什么要进行软件测试,什么是软件测试

软件测试是软件质量保证的重要手段之一

测试和开发的关系

软件测试贯穿整个软件生命周期,从需求评审,设计评审开始,测试介入软件产品的开发活动或项目实施中,软件测试和开发在整个软件开发生命周期中交互协作,致力于按时高质量的完成项目

从四个层次完成软件的验证

即对需求,系统架构设计,产品详细设计和代码的验证

测试驱动开发(TDD)

测试在前,编码在后

1. 基于代码的TDD被称为UTDD(单元测试驱动开发)

2. ATDD(验收测试驱动开发) 在设计,写代码前就明确需求的验收标准

测试驱动开发的思想

测试和开发有一对一的关系,再往前一步就是测试驱动开发 TDD测试在前,编码在后

2.第二章 软件测试的基本概念

客户,质量,缺陷,和测试的关系

本章从软件质量出发,了解软件质量的内涵,然后引出软件缺陷的产生原因,种类和代价等

最后将全面介绍软件测试线管的概念,,包括软件测试的分类,测试的不同阶段,测试工作的具体内容和范畴

软件缺陷

要了解缺陷,就必须理解质量

1. 从软件内部看,软件缺陷是产品开发或维护过程中所出现的错误

2. 从外部看,软件缺陷是系统所需要实现的某种功能的失效

软件质量的内涵

质量是产品或服务所满足明示或暗示需求能力的固有特征和特征的集合

软件质量: 软件产品满足规定的和隐含的需求能力有关的全部特征和特性

软件质量的定义

软件产品满足规定的和隐含的与需求能力有关的全部特征和特性

包括

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

2. 软件各种属性的组合成都

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

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

质量模型

内部质量，外部质量，使用质量之间的关系

软件缺陷的定义

软件测试的分类

• 按测试层次分类

1. 底层测试：单元测试

   单元测试

   • 概念 单元测试是在编码阶段针对每个程序单元而进行的测试， 其测试的对象是程序系统中最小的单元---类，函数模块或组件等。

   • 主要使用白盒测试，从程序内部结构出发设计测试用例

2. 接口层次：集成测试。完成系统内单元之间接口和单元集成为一个完整系统的测试

   • 概念 在单元测试的基础上，按照设计要求不断进行集成而进行的相应测试，目的是发现单元之间的接口问题

   • 两种继承方式

     1. 一次性继承方式

     2. 渐层式继承方式

3. 系统层次：针对以及城的软件系统进行测试

   系统功能测试应该在集成测试完成之后进行，而且是针对应用系统进行测试之检查程序功能是否按照需求规格说明书的规定正常使用

4. 用户/业务层次：验收测试。验证是否为用户真正所需要的产品特性，验收测试关注用户环境，用户数据，而且用户也参与测试过程中

   此时采用Alpha和Beta测试的过程

• 按测试目的分类

  1. 功能测试

  2. 性能测试

  3. 安全性测试

  4. 兼容性测试

  5. 可靠性测试

  6. 易用性测试

  7. 回归测试

• 按测试方法或测试方式分类

  1. 手工测试

     测试人员手动执行测试用例,如功能测试,易用性测试

  2. 自动化测试

     使用自动化测试工具执行测试用例,如性能测试,兼容性测试

  3. 白盒测试

     测试人员对软件的内部实现进行了解和测试,如单元测试,集成测试

     白盒测试又分为静态白盒测试和动态白盒测试

  4. 黑盒测试

     只关心软件的输入数据和输出结果,不关心内部实现逻辑

  5. 灰盒测试

     介于白盒测试和黑盒测试之间,既了解软件的内部实现,又不了解全部的实现细节

产品评审

软件评审 审评是对软件元素或项目状态的一种评估手段,用来确定是否与项目计划保持一致,检查工作是否规范

• 形式 互为评审，走查 和会议评审

• 对象 管理评审，技术评审，文档评审和流程评审

验证和确认

1. 验证2

   Verification

   检验软件是否以正确的实现了产品规格说明书所定义的系统功能和特性

2. 有效性确认

   Validation

   要能保证所生产的软件可追溯到用户需求的一系列活动，确认过程提供证据表明软件是否真正满足客户的需求

3. 两者的区别

   Verification 是否正确的构造了软件。是否正确的做事，验证开发过程是否遵守已定义好的内容

   Validation 是否构造了正确的软件 是否做正确的事，确认开发过程是否正在构建用户所需要的功能

测试方法

1.黑盒测试和白盒测试

1. 白盒测试也成为结构化测试或逻辑驱动测试

2. 黑盒测试方法也成为数据驱动测试方法或基于需求规格的测试

2.静态测试和动态测试

3.主动测试和被动测试

3.软件测试方法（具体）

1.基于直觉和经验的方法

比较依赖于测试人的直觉和经验

1.1 As-hoc测试方法-自由测试

强调测试人员根据自己的经验不受测试用例的束缚

1.2 ALAC测试方法-（像客户那样做的简写）

1.3 错误推测法**（略

2.基于输入域的方法

通过数据的验证来验证系统的功能性

通过不同数据的输入，检查系统输出的数据，以判断测试是否通过，都归为基于输入域的方法

2.1 等价类划分法

用一组有限的数据去代表近似无线的数据

等价类划分法基于对输入或输出情况的评估，划分成两个或更多个子集来进行测试

等价类划分法时黑盒测试用例设计中一种重要的常用的设计方法

2.2 边界值分析法

因为错误最容易发生在边界值的附近

###

3.基于组合及其优化的方法

3.1 因果图法

借助图形着重分析输入条件的各种组合

由因果图法怎样生成测试用例呢?

(1)分析软件规格说明书中的输人输出条件并分析出等价类,将每个输入输出赋予一个标志符;分析规格说明中的语义,通过这些语义来找出相对应的输入与输人之间、输入与输出之间的关系。 (2)将对应的输入与输人之间、输入与输出之间的关系关联起来,并将其中不可能的组合情况标注成约束或限制条件,形成因果图。 (3)由因果图转换成判定表。 (4)将判定表的每一列拿出来作为依据,设计测试用例。

3.2 Pairwise方法

也称为“成对组合测试”

4.基于逻辑覆盖的方法

4.1 判定覆盖

4.2 条件覆盖

4.3 判定-条件覆盖

4.4 条件组合覆盖

4.5 基本路径覆盖

设计所有测试用例,来覆盖程序中的所有可能的,独立的执行路径

5.基于缺陷模式的测试

如果过去测试人员犯了不少错误(即产生软件缺陷),自然会想从中吸取教训,对过去所发现的各种具体缺陷进行归纳整理,抽象出共性,生成缺陷模式,

软件测试中,如果知道其缺陷模式,就可以根据缺陷模式进行匹配,然后发现类似的问题,这就是基于缺陷模式的测试

6.基于模型的测试

7.形式化测试方法

思考题

4.软件测试流程和规范

1.传统的软件测试过程

1.1 W模型

Evolutif公司针对V模型进行了改进,提出了W模型的概念

W模型由两个V字形模型组成,分别代表测试与开发过程,

测试和开发过程保持同步的关系

,软件分析、设计和实现的过程,同时伴随着软件测试、验证和确认的过程,

1.2 TMap

TMap 是一种业务驱动的,基于风险策略的,结构化的测试方法体系,目的是更早的发现缺陷

2.敏捷测试过程

不是测试方法,是为了适应敏捷开发儿特别设计的一套完整的软件测试解决方案

传统测试和敏捷测试的区别

敏捷测试具有鲜明的敏捷开发的特征,如测试驱动开发(TDD,验收测试驱动开发(ATDD),测试驱动开发的思想是敏捷测试的核心

单元测试是敏捷测试的基础

传统测试更强调测试的独立性,将开发人员和测试人员角色分的比较清除

3.软件测试学派

4.测试过程改进

)研制并推出了软件能力成熟度模型

1.TMMi

2.TPI

3.STEP

第二篇 软件测试的技术

第五章 单元测试与集成测试

按阶段进行测试是一种基本的测试策略,代码的静态测试和单元测试是测试执行过程中的第一个阶段

主要采用白盒测试方法 包括对代码的评审,静态分析等静态测试和结合测试工具进行动态测试

单元测试

单元测试的任务

1. 单元独立执行路径的测试

2. 单元局部数据结构的测试

3. 单元接口测试

4. 单元边界条件的测试

5. 单元容错性测试

6. 内存分析

驱动程序和桩程序

运行被测试单元,为了隔离单元,根据被测试单元的接口,开发相应的驱动程序和桩程序

类测试

面向对象的单元测试通常是对一个基类或其子类进行测试,因为类是面向对象软件的基本单位。对于类的单元测试可以看作是对类的成员函数进行测试。

单元测试工具

单元测试一般针对程序代码进行测试,这决定了其测试工具和特定的编程语言密切相关所以单元测试工具基本是相对不同的编程语言而存在,多数集成开发环境(如IntelliJIDEAMicrosoft Visual Studio、Eclipse)会提供单元测试工具,甚至提供测试驱动开发方法所需要的环境。最典型的就是xUnit工具家族。 (1)JUnit是针对Java的单元测试工具。 (2)CppUnit是 C++单元测试工具。 (3)NUnit是C#(.Net)单元测试工具。 (4)HtmlUnit,JsUnit,PhpUnit、PerlUnit、XmlUnit 则分别是针对HTML、JavascriptPHP、Perl、XML的单元测试工具(框架)。

集成测试

原因:单元测试时能确认每个模块都单独工作但继承后就有些模块不能正常工作 所以需要集成测试

单体架构的集成测试

1. 非渐增式测试模式

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

2. 建增式测试模式

把下一个要测试的模块同已经测试好的模块结合起来进行测试,测试实在模块一个一个的扩展下进行,其测试的范围逐步增大

微服务架构的集成测试

在微服务架构下,传统的单体应用拆分为多个微服务,形成了多个松耦合的微服务组件模块。原来单个系统内部的API接口调用变成了微服务之间的接口调用,而且不同的微服务很可能是由不同的开发团队负责开发。一个微服务的具体结构包括以下5部分。 (1)资源组件,负责将请求信息映射到业务逻辑,同时将业务逻辑组件产生的结果转换成预先定义好的数据格式响应信息。 (2)服务层,负责协调多个领域之间的操作以及和其他子系统之间的交互。 (3)领域层,负责表达业务概念、业务状态信息和业务规则,是软件应用的核心。 (4)仓库层,作为数据源的网关,处理连接、查询,以及将输出和领域对象模型进行适配等工作。 (5)数据映射器,负责在处理业务逻辑的领域对象和数据库之间传递数据 (6)网关和HTTP客户端,负责和外部服务进行通信。网关用来处理底层的通信协议封装了所有需要连接外部服务的逻辑,通常使用一个HTTP客户端连接其他外部服务。

持续集成及其测试

第六章 系统测试

集成测试后,进入系统测试

系统测试针对被测试的,已集成的系统来进行验证是否满足用户需求是否达预期.

系统测试时,需要考虑SUT的运行环境,所收到的条件约束和相关联的第三方系统,环境包括计算机硬件,某些基础软件或运行支撑软件,数据库和操作人员

系统测试一般分为功能性测试和非功能性测试

1.功能性测试

系统测试中,软件功能是最基本的 需要保证功能的正确性

1.1 UI测试

1.2 接口测试

1.3 回归测试

修正后的软件包重新从头进行测试

第七章 专项测试

根据产品质量模型,用户能直接感知到的第一层质量属性有六大类:功能适应性,兼容性,性能(有效性),安全性,可靠性和易用性(用户体验)

这样.对应的系统测试类型也分为系统的功能测试,兼容性测试,性能测试,安全性测试,可靠性测试,和易用性测试

\后面五中非功能性测试,也常称为"专项测试"

专项测试也及时验证整个系统是否满足非功能性的质量需求

如:(1)性能:在大量用户使用的情况下,系统能否经得住考验?(2)安全:系统是否有安全性漏洞被利用?系统是否经得起黑客 个功能点 用例，这些的攻击? (3)兼容:系统是否可以在不同操作系统或不同平台上正常运行?(4)可靠:系统是否能长期、稳定地运行下去?系统出错了,是否能很快恢复过来或将故障转移出去? 的,其他学剑 在IE,Ch 丸行,即学 (5)易用:系统使用起来是否方便、流畅?

1. 性能测试

2. 安全性测试

3. 兼容性测试

4. 可靠性测试

5. 易用性测试

第八章 软件本地化测试

考虑如何适应国际化的需求