软件测评师教程第一、二章——软件测试概述&基础

第一章 软件测试概述

        软件测试只能证明软件存在错误，不能证明软件没有错误。测试的目的是把软件错误控制在一个可以进行产品交付的程度上，可以交付的产品并不是没有错误的产品，因此软件测试不可能无休止的进行下去，而是要把错误控制在一个合理的范围之内。

        Pua"只有高水平的开发者，才能胜任测试工作"

第二章 软件测试基础

2.1 软件测试与软件质量

定义：在规定条件下对程序进行操作，以发现错误，对软件质量进行评估。软件是由文档、数据以及程序组成的，因此软件测试应该是对软件形成过程的文档、数据以及程序进行测试，而不仅仅是程序本身。

软件质量：软件特性的总和，软件满足规定或潜在用户需求的能力。

2.2 软件测试目的

软件测试的目的是为了发现软件中存在的错误，但是其根本目的是为了提高软件质量，降低软件项目的风险。

2.3 软件测试原则

• 所有的测试都应追溯到用户需求

• 尽早测试、不断测试

• 完全测试是不可能的、适度

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

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

       群集现象：测试后程序中残存的错误数目与该程序中已发现的错误数目成正比。

2.4 软件测试对象

        软件测试应贯穿于整个软件生命周期，在整个周期中，各个阶段有不同的测试对象，包括需求规格说明书、概要设计规格说明、详细设计规格说明以及源程序等。

2.5 软件测试分类

2.5.1 按照开发阶段划分

按照开发阶段划分：单元测试、集成测试、系统测试、确认测试和验收测试。

单元测试

又称模块测试，针对软件设计的最小单位——程序模块进行正确性检验。其目的是检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求。

集成测试

也叫组装测试。通常是在单元测试的基础上，将所有的程序模块进行有序、递增的测试。集成测试是检验程序单元的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统。

软件集成的过程是一个持续的过程，会形成很多的临时版本。在每个版本提交时，都要进行冒烟测试，即对程序主要功能进行验证。冒烟测试也叫版本验证测试、提交测试。

确认测试

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

系统测试

系统测试是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统（包括硬件、外设、网络等）正确配置、连接，并满足用户需求。

验收测试

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

2.5.2 按照测试实施组织划分

按照测试实施组织划分：开发方测试、用户测试和第三方测试

开发方测试

也叫验证测试、α测试。在软件开发环境下，由开发者检测与证实软件的实现是否满足软件设计说明的要求。主要是指在软件开发完成以后，开发方对要提交的软件进行全面的自我检查与验证，可与软件的“系统测试”一并进行。

用户测试

在用户的应用环境下，用户通过运行和使用软件，检测软件是否符合自己预期的要求。通常情况用户测试不是指“验收测试”，而是指用户的使用性测试，由用户找出软件的应用过程中发现的缺陷和问题，对使用质量进行评价。

β测试通常被看成是一种用户测试。β测试主要是把软件产品有计划地免费分发到目标市场，让用户大量使用，并评价、检查软件。

第三方测试

也称独立测试，是介于软件开发方和用户方之间的测试组织的测试。

2.5.3 按照测试技术划分

按照测试技术划分：白盒测试、黑盒测试、灰盒测试或静态测试和动态测试

白盒测试

白盒测试又称结构测试。通过对程序内部结构的分析、检查来寻找问题。可以把程序看成装在一个透明的白盒子里，也就是清楚了解程序结构和处理过程。

黑盒测试

通过软件的外部表现来发现其缺陷和错误。黑盒测试把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程。

具体的黑盒测试用例设计方法包括：等价类划分法、边界值分析法、错误推测法、因果图法、判定表驱动法、正交试验设计法、功能图法等（后面详细介绍）。

灰盒测试

介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但又不像白盒测试那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态。

静态测试

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

静态测试包括;走查(code walkthrough)是开发人员与架构师集中讨论代码的过程、符号分析、需求确认等。

动态测试

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

2.6 软件测试过程模型

V模型

局限性：它把测试过程作为软件开发的最后一个阶段，主要是针对程序进行测试寻找错误，而需求分析阶段隐藏的问题一直到后期的验收测试才被发现。

W模型

优点：W模型强调测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能、和设计同样要测试。测试与开发是同步进行的，从而有利于尽早发现问题。

局限性：把软件的开发视为需求、设计、编码等一系列串行的活动。软件开发和测试是一种线性的前后关系。上一阶段完全结束，才可正式开始下一阶段。这样无法支持迭代、自发性以及变更调整。对于当前很多文档需要事后补充或者根本没有文档的做法下，开发人员和测试人员都面临着同样的困惑。

H模型

在H模型中，软件测试是一个独立的流程，贯穿于整个产品周期，与其他流程并发地进行。当某个测试时间点就绪时，软件测试即从测试准备阶段进入测试执行阶段。

X模型

X模型提出了一个探索性测试，不进行事先计划的特殊类型测试，诸如“我这么测一下，结果会怎么样”这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。

前置测试模型

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

1. 开发和测试相结合

2. 对每一个交付内容进行测试，图中椭圆框表示了其他一些要测试的对象。

3. 在设计阶段进行测试计划和测试设计

4. 让验收测试和技术测试保持相互独立

总结

2.7 软件生命周期测试策略

2.7.1 软件开发与软件测试

• 自顶向下vs自底向上

2.7.2 软件测试策略

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

1 测试信息流

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

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

测试工具：为测试提供服务。

2 分析设计阶段

分析设计阶段的测试工作是评审与测试相结合的过程。

需求说明书评测

开发方与需求方存在理解偏差。双方一起对需求说明书进行审查。

概要设计说明书评测

详细设计说明书评测

同概要设计

软件编码规范评测

1. 源程序文档化。符合的命名、程序注释（序言性注释和功能性注释）、标准的书写格式

2. 数据说明.

3. 语句结构

4. 输入和输出

3 开发阶段

单元测试

单元测试需要从程序的内部结构出发设计测试用例，旨在发现各模块内部存在的各种差错。

下图是单元测试的内容。

• 模块接口测试

        单元测试之前，应对通过所测模块的数据流进行测试，如果数据不能正确的输入和输出，就谈不上其他的测试。

• 局部数据结构测试

        如：不正确或不一致的数据类型说明，使用尚未赋值或初始化的变量。

• 路径测试

        对基本执行路径和循环进行测试，可以发现大量的路径错误。设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。

• 错误处理测试

        比较完善的模块设计要求能预见出错的条件，并设置适当的出错处理。（处理一些异常）

• 边界测试

        在边界上出现错误是常见的。要特别注意数据流、控制流中刚好等于、大于、小于确定的比较值时出错的可能性。

单元测试的步骤

通常单元测试是在编码阶段进行的。源代码经评审无语法错误后，就开始单元测试用例的设计。

模块不是一个独立的程序，考虑与之相联系的其他模块。

• 驱动模块：相当于所测模块的主程序。接受输入，调用所测模块，输出结果。

• 桩模块：也叫存根模块，用以代替所测模块调用的子模块。即用来模拟所测模块实际调用的子模块。

二者的区别可参考：https://blog.youkuaiyun.com/amberinheart/article/details/77878894

 所测模块、驱动模块以及桩模块共同构成一个测试环境。

集成测试

在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题。

模块组装成为系统的方式

• 一次性组装方式        

        首先对每个模块分别进行模块测试，再把所有模块组装在一起进行测试。如下图，d1,d2,d3,d4,d5分别是为单元测试而建立的驱动模块，s1,s2,s3,s4,s5分别是桩模块。

由于程序中不可避免的存在设计模块间接口、全局数据结构等问题，一次试运行成功的可能性并不大。

• 增殖式组装方式

        首先对一个个模块进行测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。

        自顶向下：能够较早地发现主要控制方面的问题，但需要建立桩模块十分困难。

        自底向上：建立驱动模块一般比建立桩模块容易，最先组装测试了涉及到复杂算法和真正输入/输出的模块。但程序一直未能作为一个实体存在，直到最后一个模块加上去。

        混合增殖式测试

        通常把以上两种方式结合起来进行组装和测试。

确认测试

        确认测试一般包括有效性测试和软件配置复查，由第三方测试机构进行。

• 有效性测试

        运用黑盒测试的方法，验证所测软件是否满足需求规格说明书列出的需求。

• 软件配置复查

        软件配置复查的目的是保证软件配置的所有成分都齐全，各方面的质量都要符合要求。

系统测试

        将通过集成测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据、人员等其他系统元素结合在一起，在实际或者模拟运行环境下测试。

验收测试

        验收测试以用户为主，软件开发人员和质量保证人员也应参加。一般使用生产中的实际数据进行测试。

4 软件验证与确认(V&V）过程

2.8 软件失效分类与管理

2.8.1 软件失效分类

• 软件错误：软件生存期内的不希望或不可接受的人为错误。

• 软件缺陷：存在与软件之中的那些不希望或不可接受的偏差，如少一逗号等。

• 软件故障：运行过程中出现的不希望或不可接受的内部状态。

• 软件失效：运行过程中出现的不希望或不可接受的外部行为结果。

2.8.2 缺陷与错误严重性和优先级

2.8.3 软件错误跟踪管理

        为了正确地跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条记录输入指定的错误跟踪管理系统。

2.9 自动化测试

        自动化测试就是通过测试工具或其他手段，按照测试工程师的预定计划对软件产品进行自动的测试。

优点：

• 提高测试质量

• 提高效率

• 通过测试覆盖率

• 更好的利用资源等