2023年软件评测师教程笔记.doc

软件评测师教程（第一版）笔记

第一篇 理论篇
第1章软件测试概论
1.1概述
初期的测试等同于“调试”。
测试是为发现错误而执行的一个程序或者系统的过程。
测试是以评价一个程序或者系统属性为目的的任何一种活动，测试是对软件质量的度量。
1.3软件测试与软件项目的关系
软件测试的目的是为了发现软件中存在的错误，但是，其主线目的是为了提高软件质量，减少软件项目的风险。软件的质量风险表现在两个方面，一种是内部风险，一种是外部风险。内部风险是在即将销售的时候发现有重大的错误，从而延迟发布日期，失去市场机会；外部风险是用户发现了不能容忍的错误，引起索赔，法律纠纷，以及用于客户支持的费用甚至失去客户的风险。
软件测试只能证明软件存在错误，而不能证明软件没有错误。软件公司对软件项目的盼望是在预计的时间、合理的预算下，提交一个可以交付的产品，测试的目的就是把软件的错误控制在一个可以进行产品交付/发布的限度上，可以交付/发布的产品并不是没有错误的产品，因此软件测试不也许无休止地进行下去，而是要把错误控制在一个合理的范围之内，由于软件测试也是需要花费巨大成本的。
1.5第三方测试
第三方测试是指独立于软件公司自身测试的测试。第三方测试机构的测试除了发现软件问题之外，尚有对软件进行科学、公正的评价的职能，这就规定第三方测试机构要保持公正、廉洁、客观、科学、独立的态度。

第2章软件测试基础
1、什么是软件测试
测试（test）被当作一个常规的检查产品质量的生产活动。测试的含义为“为检查产品是否满足需求为目的”。
“软件测试”的经典定义是在规定条件下对程序进行操作，以发现错误，对软件质量进行评估。
软件是由文档、数据以及程序组成的，那么软件测试就应当是对软件形成过程的文档、数据以及程序进行的测试，而不仅仅是对程序进行的测试。
2、什么是软件质量
ISO9126中定义的“软件质量”是：软件满足规定或潜在用户需求特性的总和。
ISO14598中“软件质量”定义是：软件特性的总和，软件满足规定或潜在用户需求的能力。
ISO9126定义的软件质量涉及“内部质量”、“外部质量”、“使用质量”三部分。也就是说，“软件满足规定或潜在用户需求的能力”要从软件在内部、外部和使用中的表现来衡量。
3、软件测试是在规定条件下对程序进行操作，以发现错误，对软件质量进行评估。
4、软件质量定义是：软件特性的总和，软件满足规定或潜在用户需求的能力。
软件质量涉及：内部质量、外部质量、使用质量三个部分。
5、软件测试与质量保证的区别：
质量保证（QA）质量保证的重要工作通过防止、检查与改善来保证软件质量。QA采用“全面质量管理”和“过程改善”的原理开展质量保证工作。关注软件质量的检查与测量。
软件测试也与软件开发过程紧密相关，关心的不是过程的活动，而是对过程的产物以及开发出的软件进行剖析。测试员要“执行”软件，对过程中的产物开发文档和源代码进行走查，运营软件，以找出问题，报告质量。对测试中发现的问题的分析、追踪和回归测试。软件测试是保证软件质量的一个重要环节。

6、软件测试目的
测试目的三个观点：
测试是程序的执行过程，目的在于发现错误；
一个好的测试用例在于能发现至今未发现的错误；
一个成功的测试是发现了至今未发现的错误的测试；
测试的目的，是想以最少的人力、物力和时间找出软件潜在的各种错误和缺陷，通过修正各种错误和缺陷
提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造居的隐患所带来的商业风险。
测试是对软件质量的度量与评价，以验证软件的质量满足用户的需求的限度，为用户选择与接受软件提供有力的依据。

7、软件测试原则
所有的软件测试都应追溯到用户需求。
应当把“尽早地和不断地进行软件测试”作为软件测试者的座左铭。
完全测试是不也许的，测试需要终止。
    在有限的时间和资源条件下，软件趋于完美，是不也许的。重要有三个因素：
    软件入量太大；
    输出结果太多；
    途径组合太多。
测试无法显示软件潜在的缺陷
充足注意测试中的群集现象。
程序员应避免检查自己的程序。
尽量避免测试的随意性。（应当从工程的角度去理解软件测试，它是有组织、有计划、环节的活动。）

8、软件测试对象
根据软件定义，软件涉及程序、数据和文档，所以软件测试并不仅仅是程序测试。
在软件编码结束后，对编写的每一个程序模块进行测试，称为模块测试或单元测试。
在模块集成后，对集成在一起模块组件，有时称为部件，进行测试，称为集成测试。
在集成测试后，需要检测与证实软件是否满足软件需求说明书中规定的规定，称为确认测试。
将整个程序模块集成为软件系统，安装在运营环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称为系统测试。
软件错误中，属于需求分析和软件设计的错误约为64%，属于程序编写的错误仅占36%。
验证（verification）是保证软件正的确现特定功能的一系列活动和过程，目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目的。
确认（validation）是保证软件满足用户需求的一系列的活动和过程，目的是在软件开发完毕后保证软件与用户需求相符合。
验证与确认都属于软件测试，它涉及对软件分析、设计以及程序的验证和确认。
需求分析、概要设计、具体设计以及程序编码等各阶段所得到的文档，涉及需求规格说明、概要设计规格说明、具体设计规格说明以及源程序，都应成为“软件测试”的对象。在软件编码结束后，对编写的每一个程序模块进行测试，称为“模块测试”或“单元测试”；在模块集成后，对集成在一起的模块组件，有时也可称为“部件”，进行测试，称为“集成测试”；在集成测试后，需要检测与证实软件是否满足软件需求说明书中规定的规定，称为“确认测试”。将整个程序模块集成为软件系统，安装在运营环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称为“系统测试”。
测试过程按4个环节进行，即单元测试、集成（组装）测试、确认测试和系统测试。

9、软件测试分类
按照开发阶段划分软件测试可分为：单元测试、集成测试、系统测试、确认测试和验收测试。
单元测试：单元测试又称模块测试，是针对软件设计的最小单位——程序模块进行对的性检查的测试工作。其目的在于检查每个程序单元能否正的确现具体设计说明中的模块功能、性能、接口和设计约束等规定，发现各模块内部也许存在的各种错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。
集成测试：也叫组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检查程序单元或部件的接口关系，逐步集成为符合概要设计规定的程序部件或整个系统。
确认测试：就是通过检查和提供客观证据，证实软件是否满足特定预期用途的规定。确认测试是检测与证实软件是否满足软件需求说明书中规定的规定。
系统测试：它是为验证和确认系统是否达成其原始目的，而对集成的硬件和软件系统进行的测试。系统测试是在真实或模拟系统运营的环境下，检查完整的程序系统能否（涉及硬件、外设、网络和系统软件、支持平台等）对的配置、连接，并满足用户需求。
验收测试：按照项目任务书或协议、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接受或拒收系统。
l 按照开发阶段划分
Ø 单元测试。
单元测试又称模块测试，是针对程序模块进行对的性检查的测试工作。
Ø 集成测试
集成测试也叫组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检查程序或部件的接口关系，逐步集成为符合概要设计规定的程序部件或整个系统。
冒烟测试也叫验证测试、提交测试。
Ø 确认测试
确认测试是通过检查和提供客观证据，证实软件是否满足特定预期用途的需求。确认测试是检测与证实软件是否满足软件需求说明书中规定的规定。
Ø 系统测试
系统测试是为验证和确认系统是否达成其原始目的，而对集成的硬件和软件系统进行的测试。系统测试是在真实或模拟系统运营的环境下，检查完整的程序系统能否和系统（涉及硬件、外设、网络和系统软件、支持平台等）对的配置、连接、并满足用户需求。
Ø 验收测试
按照项目任务书或协议、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接受或拒收系统。
l 按照测试实行组织划分
按照测试实行组织划分，软件测试可分为开发方测试、用户测试（Beta测试）、第三方测试。
（1）开发方测试
通常也叫“验证测试”或“α测试”。验证测试是在软件开发环境下，由开发者检测与证实软件的实现是否满足软件设计说明或软件需求说明的规定。重要是指在软件开发完毕以后，开发方对要提交的软件进行全面的自我检查与验证，可以和软件的“系统测试”一并进行。
（2）用户测试
在用户的应用环境下，用户通过运营和使用软件，检测与核算软件实现是否符合自己预期的规定。用户测试不是指用户的“验收测试”，而是指用户的使用性测试，由用户找出软件的应用过程中发现的软件的缺陷与问题，并对使用质量进行评价。
（3）第三方测试
介于软件开发方和用户方之间的测试组织的测试。一般情况下是在模拟用户真实应用环境下，进行软件确认测试。
l 按照测试技术划分
按照测试技术划分：白盒测试、黑盒测试、灰盒测试。也可划分为静态测试和动态测试。静态测试是指不运营程序，通过人工对程序和文档进行分析与检查：静态测试技术又称静态分析技术，静态测试事实上是对软件中的需求说明书、设计说明书、程序源代码等进行非运营的检查，静态测试涉及：走查、符号执行、需求确认等。动态测试是指通过人工或使用工具运营程序进行检查、分析程序的执行状态和程序的外部表现。
（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、软件生命周期测试策略
Ø 软件开发与软件测试
软件开发的过程是一个自顶向下，逐步细化的过程。
测试过程则是依照相反的顺序安排自底向上，逐步集成的过程。

Ø 软件测试策略
测试过程按4个环节进行，即单元测试、集成（组装）测试、确认测试和系统测试。

1、测试信息流

测试过程需要以下三类输入：
软件配置：涉及软件需求规格说明、软件设计规格说明、源代码等。
测试配置：涉及测试计划、测试用例、测试驱动程序等。测试配置只是软件配置的一个子集。
测试工具：
2、分析设计阶段
分析设计阶段的测试工作是评审与测试相结合的过程，重要涉及需求说明书评测、概要设计说明书、具体设计说明书评测以及软件编码规范评测等。
编制良好的需求说明书8条原则：
功能与实现分离；
规定使用面向解决的规格说明语言；
描述该目的软件与系统的其他系统元素交互的方式；
规格说明必须涉及系统运营的环境；
系统规格说明必须是一个结识的模型；
规格说明必须是可操作的；
规格说明必须允许不完备性并允许扩充；
规格说明必须局部化和松散的耦合。
（1）需求说明书评测
需求说明书是分析任务的最终产物，通过建立完整的信息描述、具体的功能和行为描述、性能需求和设计约束的说明、性能需求和设计约束的说明、合适的验收标准，给出对目的软件的各种需求。
需求说明书评测内容：
系统定义的目的是否与用户的规定一致。
系统需求分析阶段提供的文档资料是否齐全。
文档中的所有描述是否完整、清楚、准确地反映用户规定；
与所有其他系统成份的重要接口是否都已经描述；
被开发项目的数据流与数据结构是否足够、拟定；
所有图表是否清楚，在不补充说明时能否理解；
重要功能是否已涉及在规定的软件范围之内，是否都已充足说明；
软件的行为和它必须解决的信息、必须完毕的功能是否一致；
设计的约束条件或限制条件是否符合实际；
是否考虑了开发的技术风险；
是否考虑过软件需求的其他方案；
是否考虑过将来也许会提出的软件需求；
是否具体制定了检查标准，它们能否对系统定义是否成功进行确认；
有没有漏掉、反复或不一致的地方；
用户是否审查了初步的用户手册或原型；
项目开发计划中的估算是否受到了影响。

（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）错误解决测试
比较完善的模块设计规定能预见犯错的条件，并设立适当的犯错解决，以便在一旦程序犯错时，能对犯错程序重做安排，保证其逻辑上的对的性。模块和错误解决功能包具有错误或缺陷：
犯错的描述难以理解；
犯错的描述局限性以对错误定位，局限性以拟定犯错的因素；
显示的错误与实际的错误不符；
对错误条件的解决不对的；
在对错误进行解决之前，错误条件已经引起系统的干预等。
5）边界测试
单元测试环节：
驱动模块（driver）相称于所测模块的主程序。它接受测试数据，把这些数据传送给所测模块，最后输出实测结果。
桩模块（stub）也叫存根模块。用以代替所测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。

（2）集成测试
集成测试也叫做组装测试或联合测试。在单元测试的基础上，需要将所有模块按照概要设计说明书和具体设计说明书的规定进行组装。
组成时需要考虑的问题：
1）在把各个模块连接起的时候，穿越模块接口的数据是否会丢失；
2）一个模块的功能是否会对另一个模块的功能产生不利的影响；
3）各个子功能组合起来，能否达成预期规定的父功能；
4）全局数据结构是否有问题；
5）单个模块的误差累积起来，是否会放大，以至达成不能接受的限度。
子系统的集成测试称为部件测试，它所做的工作是要找出组装后的子系统与系统需求规格说明之间的不一致。
模块组装成为系统的方式。
模块组装成为系统的方式有两种：一次性组装方式和增殖式组装方式。
1）一次性组装方式
它是一种非增殖式组装方式，也叫做整体拼装。使用这种方式，一方面对每个模块分别进行模块测试，再把所有模块组装在一起进行测试，最终得到规定的软件系统。
2）增殖式组装方式
这种组装方式又称渐增式组装，是一方面对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后通过增殖逐步组装成为规定的软件系统。
自顶向下的增殖方式。环节如下：一方面以主模块作为所测模块兼驱动模块，所有直属于主模块的下属模块所有用桩模块代替，对主模块进行测试。再采用深度优先或广度优先的策略，用实际模块替换相应的桩模块，再用桩模块代替它们的直接下属模块，与已测试的模块或子系统组装成新的子系统。然后，进行回归测试（即重新执行以前做过的所有测试或部分测试），排除组装过程中引新的错误的也许。最后，判断是否所有的模块都已组装到系统中。

自顶向下的增殖方式在测试过程中较早地验证了重要的控制和判断点。在一个功能划分合理的程序模块结构中，判断经常出现在较高的层次里，因而，可以较早地碰到这种问题。
假如选用按深度方向组装的方式，可以一方面实现和验证一个完整的软件功能，可先对逻辑输入的分支进行组装和测试，检查和克服潜藏的错误和缺陷，验证其功能的对的性，就为其后对重要加工分支的组装和测试提供了保证。
自底向上的增殖方式。

提高测试效率。
进行集成测试时，测试者应当拟定关键模块，对这些关键模块及早进行测试。关键模块至少应具有以下几种特性之一：
满足某些软件需求；
在程序的模块结构中位于较高的层次（高层控制模块）；
较复杂、较易发生错误；
有明拟定义的性能规定。
在做回归测试时，也应当集中测试关键模块的功能。
集成测试的组织和实行。
集成测试是一种正规测试过程，必须精心计划，并与单元测试的完毕时间协调起来。在制定测试计划时，应考虑如下因素：
（1）采用何种系统组装方法来进行集成测试。
（2）集成测试过程中连接各个模块的顺序。
（3）模块代码编制和测试进度是否与集成测试的顺序一致。
（4）测试过程中是否需要专门的硬件设备。
集成测试完毕的标志。
集成测试完毕的标志重要有以下几项。
（1）成功地执行了测试计划中规定的所有集成测试。
（2）修正了所发现的错误。
（3）测试结果通过了专门小组的评审。
集成测试需要提交的文档有集成测试计划、集成测试规格说明书和集成测试分析报告。
（3）确认测试
确认测试的任务是验证软件的功能和性能及其他特性是否与用户的规定一致。对软件的功能和性能规定在软件需求规格说明中明确规定。确认测试一般涉及有效性测试和软件配置复查，确认测试一般由独立的第三方测试机构进行。
进行有效性测试。
有效性测试是在模拟的环境下，运用黑盒测试的方法，验证所测软件是否满足需求规格说明书列出的规定。
在所有软件测试的测试用例运营完后，所有的测试结果可以分为两类。
（1）测试结果与预期的结果相符。这说明软件的部分功能或性能特性与需求规格说明书相符合，从而接受了这部分程序。
（2）测试结果与预期的结果不符。这说明软件的这部分功能或性能特性与需求规格说明不一致，因此要为它提交一份问题报告。
软件配置复查。
（4）系统测试
系统测试是将通过集成测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际或模拟运营（使用）环境下，对计算机系统进行一系统列测试。
（5）验收测试

4、软件验证与确认（V&V）过程
软件的V&V过程是拟定按照规定的软件过程开发的产品是否符合活动的规定，软件是否满足它的预期用途和用户需要。软件的V&V过程涉及软件产品和过程的分析、评价、评审、审核、评估和测试。
软件测试活动是软件V&V过程的一个组成部分。软件测试过程的任务与管理也要符合软件V&V过程的有关规定。
（1）V&V基本概念
验证（Verfication）：通过检查和提供客观证据，证实规定的需求已满足。
确认（Validation）：通过检查和提供客观证据，证实预期用途的需求是否得到满足。
独立验证和确认：由在技术、管理和财务上与开发组织有规定限度独立性的组织执行的V&V过程。
（2）软件V&V过程
软件生存周期的V&V过程框架。
软件开发过程的V&V概述。
（3）软件V&V过程中的测试
测试过程。
需求V&V活动中的测试。
2.8软件失效分类与管理
2.8.1软件失效分类
软件错误（software error）
软件缺陷（software defect）
软件故障（software fault）
软件失效（software failure）
软件失效机理可描述为：软件错误è软件缺陷è软件故障è软件失效
（1）软件错误是指在软件生存期内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。可见，软件错误是一种人为过程，相对于软件自身，是一种外部行为。
（2）软件缺陷存在于软件（文档、数据、程序）之中的那些不希望或不可接受的偏差。其结果是软件运营于某一特定条件时出现软件故障，这时称软件缺陷激动。
（3）软件故障是指软件运营过程中出现的一种不希望或不可接受的内部状态。
（4）软件失效是指软件运营时产生的一种不希望或不可接受的外部行为结果。
错误的广义定义是：不对的的事务和行为。
错误是在系统运营时，引起或也许潜在地引起失效的缺陷，是一种面向开发概念。
软件缺陷：
（1）软件未达成产品说明书中标明的功能；
（2）软件出现了产品说明书中指明的不会出现的错误；
（3）软件功能超过了产品说明书指明的范围；
（4）软件未达成产品说明书虽未指出应达成的目的；
（5）软件测试人员认为软件难以理解、不易使用、运营速度慢，或最终用户认为不好使用。
产品说明书是软件缺陷的第一来源，也就出自于软件需求说明书自身的问题。
设计方案（软件设计说明书）是软件缺陷第二来源。
2.8.2缺陷与错误分布

2.8.3缺陷与错误严重性和优先级
软件存在的缺陷与错误会带来软件失败的风险，重要软件故障与失效会导致重大经济损失与劫难。给软件缺陷与错误划分严重性和优先级的通用原则是：
（1）表达软件缺陷所导致的危害的恶劣限度；
（2）优先级表达修复缺陷的重要限度和顺序；
严重级：
严重：系统崩溃、数据丢失、数据毁坏
较严重：操作性错误、错误结果、漏掉功能
一般：小问题、错别字、UI布局、罕见故障
建议：不影响使用的瑕疵或更好的实现
优先级：
最高优先级：立即修复，停止进一步测试
次高优先级：在产品发布之前必须修复
中档优先级：假如时间允许应当修复
最低等优先级：也许会修复，但是也能发布

2.8.4软件错误跟踪管理
软件测试的重要目的在于发现软件存在的错误（Bug），如何解决测试中发现的错误，将直接影响到测试的效果。只有对的、迅速、准确地解决这些错误，才干消除软件错误，保证要发布的软件符合需求设计的目的。
在实际的软件测试过程中，每个BUG都要通过测试、确认、修复、验证等的管理过程，这是软件测试的重要环节。
作为一个错误跟踪管理系统，需要对的记录错误信息和错误解决信息的所有内容。
（1）BUG记录信息
重要涉及以下几项内容。
测试软件名称
测试版本号
测试人名称
测试事件
测试软件和硬件配置环境
发现软件错误的类型
错误的严重等级
具体环节
必要的附图
测试注释
（2）BUG解决信息
解决者姓名
解决时间
解决环节
错误记录的当前状态
2、软件错误的状态
新信息（New）：测试中新报告的软件BUG
打开（Open）：被确认并分派给相关开发人员解决。
修正（Fixed）：开发人员已完毕修正，等待测试人员验证。
拒绝（Declined）拒绝修改BUG
延期（Deferred）：不在当前版本修复的错误，下一步修复。
关闭（Closed）：BUG已被修复。
3、错误管理流程

4、错误流程管理原则

2.9白盒测试

2.10黑盒测试
黑盒测试也称为功能测试，它是通过测试来检测每个功能是否都能正常使用。在完全不考虑内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求说明书的规定正常使用，程序是否能适本地接受输入数据而产生对的的输出信息。重要针对软件界面和软件功能进行测试。
黑盒测试法注重于测试软件的功能需求，重要试图发现下列几类错误。
功能不对的或漏掉
界面错误
数据库访问错误
性能错误
初始化和终止错误
黑盒测试用例设计方法涉及等价类划分法、边界值分析法、错误推测法、因果图法、鉴定表驱动法、正交实验设计法、功能图法等。

2.11自动化测试
2.11.1自动化测试的基本概念
自动