软件评测师教程笔记之软件测试基础Word下载.docx

软件评测师教程笔记之软件测试基础Word下载.docx

《软件评测师教程笔记之软件测试基础Word下载.docx》由会员分享，可在线阅读，更多相关《软件评测师教程笔记之软件测试基础Word下载.docx（29页珍藏版）》请在冰豆网上搜索。

在有限的时间和资源条件下，软件趋于完美，是不可能的。

主要有三个原因：

软件入量太大；

输出结果太多；

路径组合太多。

测试无法显示软件潜在的缺陷

充分注意测试中的群集现象。

程序员应避免检查自己的程序。

尽量避免测试的随意性。

（应该从工程的角度去理解软件测试，它是有组织、有计划、步骤的活动。

）

8、软件测试对象

根据软件定义，软件包括程序、数据和文档，所以软件测试并不仅仅是程序测试。

在软件编码结束后，对编写的每一个程序模块进行测试，称为模块测试或单元测试。

在模块集成后，对集成在一起模块组件，有时称为部件，进行测试，称为集成测试。

在集成测试后，需要检测与证实软件是否满足软件需求说明书中规定的要求，称为确认测试。

将整个程序模块集成为软件系统，安装在运行环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称为系统测试。

软件错误中，属于需求分析和软件设计的错误约为64%，属于程序编写的错误仅占36%。

验证（verification）是保证软件正确实现特定功能的一系列活动和过程，目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标。

确认（validation）是保证软件满足用户需求的一系列的活动和过程，目的是在软件开发完成后保证软件与用户需求相符合。

验证与确认都属于软件测试，它包括对软件分析、设计以及程序的验证和确认。

需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为“软件测试”的对象。

在软件编码结束后，对编写的每一个程序模块进行测试，称为“模块测试”或“单元测试”；

在模块集成后，对集成在一起的模块组件，有时也可称为“部件”，进行测试，称为“集成测试”；

在集成测试后，需要检测与证实软件是否满足软件需求说明书中规定的要求，称为“确认测试”。

将整个程序模块集成为软件系统，安装在运行环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称为“系统测试”。

测试过程按4个步骤进行，即单元测试、集成（组装）测试、确认测试和系统测试。

9、软件测试分类

按照开发阶段划分软件测试可分为：

单元测试、集成测试、系统测试、确认测试和验收测试。

单元测试：

单元测试又称模块测试，是针对软件设计的最小单位——程序模块进行正确性检验的测试工作。

其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。

单元测试需要从程序的内部结构出发设计测试用例。

多个模块可以平行地独立进行单元测试。

集成测试：

也叫组装测试。

通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。

集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。

确认测试：

就是通过检验和提供客观证据，证实软件是否满足特定预期用途的要求。

确认测试是检测与证实软件是否满足软件需求说明书中规定的要求。

系统测试：

它是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。

系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接，并满足用户需求。

验收测试：

按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。

●按照开发阶段划分

Ø

单元测试。

单元测试又称模块测试，是针对程序模块进行正确性检验的测试工作。

集成测试

集成测试也叫组装测试。

集成测试是检验程序或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。

冒烟测试也叫验证测试、提交测试。

确认测试

确认测试是通过检验和提供客观证据，证实软件是否满足特定预期用途的需求。

系统测试

系统测试是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。

系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络和系统软件、支持平台等）正确配置、连接、并满足用户需求。

验收测试

●按照测试实施组织划分

按照测试实施组织划分，软件测试可分为开发方测试、用户测试（Beta测试）、第三方测试。

（1）开发方测试

通常也叫“验证测试”或“α测试”。

验证测试是在软件开发环境下，由开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的要求。

主要是指在软件开发完成以后，开发方对要提交的软件进行全面的自我检查与验证，可以和软件的“系统测试”一并进行。

（2）用户测试

在用户的应用环境下，用户通过运行和使用软件，检测与核实软件实现是否符合自己预期的要求。

用户测试不是指用户的“验收测试”，而是指用户的使用性测试，由用户找出软件的应用过程中发现的软件的缺陷与问题，并对使用质量进行评价。

（3）第三方测试

介于软件开发方和用户方之间的测试组织的测试。

一般情况下是在模拟用户真实应用环境下，进行软件确认测试。

●按照测试技术划分

按照测试技术划分：

白盒测试、黑盒测试、灰盒测试。

也可划分为静态测试和动态测试。

静态测试是指不运行程序，通过人工对程序和文档进行分析与检查：

静态测试技术又称静态分析技术，静态测试实际上是对软件中的需求说明书、设计说明书、程序源代码等进行非运行的检查，静态测试包括：

走查、符号执行、需求确认等。

动态测试是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。

（1）白盒测试

通过对程序内部结构的分析、检测来寻找问题。

了解程序结构和处理过程，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。

（2）黑盒测试

通过软件的外部表现来发现其缺陷和错误。

黑盒测试法把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程。

黑盒测试是在程序界面处进行测试，它只是检查程序是否按照需求规格说明书的规定正常实现。

（3）灰盒测试

灰盒测试关注输出对于输入的正确性

静态测试

它是指不运行程序，通过人工对程序和文档进行分析与检查；

静态测试技术又称静态分析技术，静态测试实际上是对软件中的需求说明书、设计说明书、程序源代码等进行非运行检查，

静态测试包括：

动态测试

它是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。

白盒测试

又称结构测试。

黑盒测试

它是在程序界面处进行测试，它只是检查样序是否按照需求规格说明书的规定正常实现。

10、软件测试过程模型

V模型

它反映了测试活动与分析和设计的关系，从左到右，描述了基本的开发过程和测试行为，非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系，如图所示，图中的箭头代表了时间方向，左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。

V模型指出，单元和集成测试是验证的程序设计，检测程序的执行是否满足软件设计的要求；

系统测试应当验证系统设计，检测系统功能、性能的质量特性是否达到系统设计的指标；

测试员和用户进行软件的确认测试和验收测试，追溯软件需求说明书进行测试，以确定软件的实现是否满足用户需求或合同的要求。

V模型存在一定的局限性，它仅仅是测试过程作为在需求分析、概要设计、详细设计及编码后的一个阶段。

需求分析阶段隐藏的问题一直到后期的验收测试才被发现。

V模型的软件测试策略既包括低层测试又包括了高层测试，低层测试是为了源代码的正确性，高层测试为了使整个系统满足用户的需求。

W模型

1、W模型建立

V模型的局限性在于没有明确地说明早期的测试，不能体现“尽早地和不断地进行软件测试”的原则。

在V模型中增加软件各开发阶段应同步进行的测试，被演化为一种W模型，因为实际上开发是“V”，测试也是与此相并行的“V”。

基于“尽早地和不断地进行软件测试”的原则，

优点：

测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。

体现“尽早地和不断地进行软件测试”的原则。

在V模型中增加软件和开发阶段应同步进行的测试。

局限性：

软件开发和测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可正式开始下一个阶段。

这就无法支持迭代、自发性以及变更调整。

2、W模型应用

它强调：

只要相应的开发活动完成，我们就可以开始执行测试，可以说，测试与开发是同步进行的，有利于尽早地发现问题。

以需求为例，需求分析一完成，我们就可以对需求进行测试，而不是等到最后才进行针对需求的验收测试。

参与前期工作的测试者可以预先估计问题和难度，这将可以显著地减少总体测试时间，加快项目进度。

根据W模型的要求，一旦有文档提供，就要及时确定测试条件，以及编写测试用例。

W模型也是有局限性。

W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动。

同样的，软件开发和测试保持一种线性的前后关系，需要有严格的指令表示上一阶段完全结束，才可正式开始下一个阶段。

这样就无法支持迭代、自发性以及变更调整。

H模型

1、H模型建立

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

2、H模型应用

软件测试不仅仅指测试的执行，还包括很多其他的活动。

软件测试是一个独立的流程，贯穿产品整个生命周期，与其他流程并发地进行。

软件测试要尽早准备，尽早执行。

软件测试是根据被测物的不同而分层次进行的。

不同层次的测试活动可以是按照某个次序先后进行的，但也可能是反复的。

在H模型中，软件测试模型是一个独立的流程，贯穿于整个产品周期，与其他流程并发地进行。

其他模型

1、X模型

该模型定位了探索性测试。

Marick对V模型最主要批评是V模型无法引导项目全部过程。

他认为一个模型必须能处理开发的所有方面，包括交接、频繁重复的集成以及需求文档的缺乏等。

2、前置测试模型

它是一个将测试和开发紧密结合的模型，该模型提供了轻松的方式，可使你的项目加快速度。

前置测试模型体现了以下的要点：

（1）开发和测试相结合；

前置测试模型将开发和测试的生命周期整合在一起，标识了项目生命周期从开始到结束之间的关键行为。

（2）对每一个交付内容进行测试；

每一个交付的开发结果都必须通过一定的方式进行测试。

（3）在设计阶段进行测试计划和测试设计；

设计阶段是作测试计划和测试设计的最好时机。

（4）测试和开发结合在一起；

前置测试将测试执行和开发结合在一起，并在开发阶段以编码——测试——编码——测试的方式来体现。

（5）让验收测试和技术测试保持相互独立。

验收测试应该独立于技术测试，这样可以提供双重的保险，以保证设计及程序编码能够符合最终用户的需求。

10、软件生命周期测试策略

软件开发与软件测试

软件开发的过程是一个自顶向下，逐步细化的过程。

测试过程则是依照相反的顺序安排自底向上，逐步集成的过程。

软件测试策略

1、测试信息流

测试过程需要以下三类输入：

软件配置：

包括软件需求规格说明、软件设计规格说明、源代码等。

测试配置：

包括测试计划、测试用例、测试驱动程序等。

测试配置只是软件配置的一个子集。

测试工具：

2、分析设计阶段

分析设计阶段的测试工作是评审与测试相结合的过程，主要包括需求说明书评测、概要设计说明书、详细设计说明书评测以及软件编码规范评测等。

编制良好的需求说明书8条原则：

功能与实现分离；

要求使用面向处理的规格说明语言；

描述该目标软件与系统的其他系统元素交互的方式；

规格说明必须包括系统运行的环境；

系统规格说明必须是一个认识的模型；

规格说明必须是可操作的；

规格说明必须容许不完备性并允许扩充；

规格说明必须局部化和松散的耦合。

（1）需求说明书评测

需求说明书是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。

需求说明书评测内容：

系统定义的目标是否与用户的要求一致。

系统需求分析阶段提供的文档资料是否齐全。

文档中的所有描述是否完整、清晰、准确地反映用户要求；

与所有其他系统成份的重要接口是否都已经描述；

被开发项目的数据流与数据结构是否足够、确定；

所有图表是否清楚，在不补充说明时能否理解；

主要功能是否已包括在规定的软件范围之内，是否都已充分说明；

软件的行为和它必须处理的信息、必须完成的功能是否一致；

设计的约束条件或限制条件是否符合实际；

是否考虑了开发的技术风险；

是否考虑过软件需求的其他方案；

是否考虑过将来可能会提出的软件需求；

是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；

有没有遗漏、重复或不一致的地方；

用户是否审查了初步的用户手册或原型；

项目开发计划中的估算是否受到了影响。

编制良好的需求说明书8条原则。

原则1：

功能与实现分离，即描述要“做什么”而不是“怎样实现”。

原则2：

要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明。

原则3：

如果目标软件只是一个大系统中的一个元素，那么整个系统也包括在规格说明的描述之中。

原则4：

规格说明必须包括系统运行的环境。

原则5：

系统规格说明必须是一个认识的模型，而不是设计或实现的模型。

原则6：

规格说明必须是可操作的。

原则7：

规格说明必须容许不完备性并允许扩充。

原则8：

需求说明书的框架。

需求说明书是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。

需求说明书评测内容。

需求说明书评测作为需求分析阶段工作的复查手段，应该对功能的正确性、完整性和清晰性，以及其他需求给予评测。

评测的主要内容是：

（1）系统定义的目标是否与用户的要求一致；

（2）系统需求分析阶段提供的文档资料是否齐全；

（3）文档中的所有描述是否完整、清晰，准确地反映用户要求；

（4）与所有其他系统成份的重要接口是否都已经描述；

（5）被开发项目的数据流与数据结构是否足够、确定；

（6）所有图表是否清楚，在不补充说明时能否理解；

（7）主要功能是否已包括在规定的软件范围之内，是否都已充分说明；

（8）软件的行为和它必须处理的信息、必须完成的功能是否一致；

（9）设计的约束条件或限制条件是否符合实际；

（10）是否考虑了开发的技术风险；

（11）是否考虑过软件需求的其他方案；

（12）是否考虑过将来可能会提出的软件需求；

（13）是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；

（14）有没有遗漏、重复或不一致的地方；

（15）用户是否审查了初步的用户手册或原型；

（16）项目开发计划中的估算是否受到了影响。

（2）概要设计说明书评测

设计说明书的框架

设计说明书的框架内容：

（1）可追溯性

（2）接口

（3）风险

（4）实用性

（5）技术清晰度

（6）可维护性

（7）质量

（8）各种选择方案

（9）限制

（10）其他具体问题

为评测设计是否达到目标，必须建立衡量设计的技术标准。

如下：

主要评测内容：

可追溯性；

接口；

风险；

实用性；

技术清晰度；

可维护性；

质量；

各种选择方案；

限制；

其他具体问题。

（1）设计出来的结构应是分层结构，从而建立软件成分之间的控制；

（2）设计出来的结构应是分层结构，从而建立软件成分之间的控制；

（3）设计应当既包含数据抽象，也包含过程抽象；

（4）设计应当建立具有独立功能特征的模块；

（5）设计应当建立能够降低模块与外部环境之间复杂连接的接口；

（6）设计应当根据软件需求分析获取的信息，建立可驱动、可重复的方法。

（3）详细设计说明书评测

与概要设计说明书基本相同。

（4）软件编码规范评测

程序实际上也是一种供人阅读的文章，有一个文章的风格问题。

程序良好的风格表现在源程序文档化、数据说明的方法、语句结构的输入/输出方法这四个方面，软件编码规范评测也是围绕这四个方面展开。

源程序文档化

（1）符号名的命名。

符号名即标识符，包括模块名、变量名、常量名、标号名、子程序名、数据区名以及缓冲区名等。

（2）程序的注释。

注释分为序言性注释和功能性注释。

（3）标准的书写格式。

数据说明

（1）数据说明的次序应当规范化。

（2）说明语句中变量安排有序化。

（3）使用注释说明复杂数据结构。

语句结构

在设计阶段确定了软件的逻辑流结构，但构造单个语句则是编码阶段的任务。

语句构造力求简单、直接，不能为了片面追求效率而使语句复杂化。

输入和输出

输入和输出信息是与用户的使用直接相关的。

输入和输出的方式和格式应当尽可能方便用户的使用。

一定要避免因设计不当给用户带来的麻烦。

因此，在软件需求分析阶段和设计阶段，就应基本确定输入和输出的风格。

系统能否被用户接受，有时就取决于输入和输出的风格。

不论是批处理的输入/输出方式，还是交互式的输入/输出方式，在设计和程序编码时都应考虑下列原则。

在设计和程序编码时都应考虑下列原则。

（1）对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性；

（2）检查输入项的各种重要组合的合理性，必要时报告输入状态信息；

（3）使输入的步骤和操作尽可能简单，并保持简单的输入格式；

（4）输入数据时，应允许使用自由格式输入；

（5）应允许缺省值；

（6）输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目；

（7）在交互式输入时，要在屏幕上使用提示符，明确提示交互输入的请求，指明可使用选择项的种类和取值范围。

同时，在数据输入的过程中和输入结束时，也要在屏幕上给出状态信息；

（8）当程序设计语言对输入/输出格有严格要求时，应保持输入格式与输入语句要求的一致性；

（9）给所有的输出加注解，并设计输出报表格式。

3、开发阶段

（1）单元测试

单元测试的内容：

在进行单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之黑盒测试的测试用例。

使之对任何合理的输入和不合理的输入，都能鉴别和响应。

这要求对所有的局部的和全局的数据结构、外部接口和程序代码的关键部分，都要进行桌面检查和严格的代码审查。

在单元测试中进行的测试工作如图2-9所示，需要在五个方面对所测模块进行检查。

在进行单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。

1）模块接口测试

在单元测试的开始，应对通过所测模块的数据流进行测试。

如果数据不能正确地输入和输出，就谈不上进行其他测试。

为此，对模块接口可能需要如下的测试项目：

调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配；

所测模块调用子模块时，它输入给子模块的参数与子模块中的形式参数在个数、属性、顺序上是否匹配；

是否修改了只作输入用的形式参数；

输出给标准函数的参数在个数、属性、顺序上是否正确；

全局量的定义在各模块中是否一致；

限制是否通过形式参数来传送。

2）局部数据结构测试

设计测试用例以检查以下各种错误：

不正确或不一致的数据类型说明；

使用尚未赋值或尚未初始化的变量；

错误的初始值或错误的缺省值；

变量名拼写错或书写错；

不一致的数据类型。

3）路径测试

常见的不正确计算有：

运算的优先次序不正确或误解了运算的优先次序；

运算的方式错，即运算的对象彼此在类型上不相容；

算法错；

初始化不正确；

运算精度不够；

表达式的符号表示不正确。

4）错误处理测试

比较完善的模块设计要求能预见出错的条件，并设置适当的出错处理，以便在一旦程序出错时，能对出错程序重做安排，保证其逻辑上的正确性。

模块和错误处理功能包含有错误或缺陷：

出错的描述难以理解；

出错的描述不足以对错误定位，不足以确定出错的原因；

显示的错误与实际的错误