软件测试学习笔记

相关概念

软件的定义
软件由程序，数据和文档构成。

软件的划分
按层次来划分时，可分为系统软件跟应用软件
按组织来划分时，可分为商业软件跟开源软件
按结构来划分时，可分为分布式软件跟单机软件

软件质量
软件产品的特性可以满足用户的功能、性能需求的能力。

软件缺陷的定义

• 软件未实现产品说明书要求的功能；
• 软件出现了产品说明书指明不应该出现的功能；
• 软件实现了产品说明书未提到的功能；
• 软件未实现产品说明书虽未明确提及但应该实现的目标；
• 软件难以理解、不宜使用、运行缓慢或者（从测试的角度看）最终用户会认为不好；

所有不满足需求或超出需求的都是缺陷
没有不存在缺陷的软件，只有迄今为止尚未发现的缺陷

软件测试的起源
软件测试起源于上世纪70年代中期

• 《测试数据选择的原理》
• 《软件测试的艺术》

20世纪80年代早期，软件行业开始逐渐关注软件产品质量，并在公司建立的软件质量保证部门** QA（QUALITY ASSURANCE）或 SQA。**

软件测试的定义

正向思维
出发点：使自己确信产品是能够正常工作的评价一个程序和系统的特性和能力，并确信它是否达到期望的结果，以此为目的的测试行为。

反向思维
出发点：测试是为发现错误而执行一个程序或系统的过程。测试就是为了证明程序有错。

IEEE 定义的测试
IEEE（Institute of Electrical and Electronics Engineers）电气与电子工程师协会，是一个国际性的电子技术与信息科学工程师的协会，也是全球最大的非营利性专业技术学会

• 在规定条件下运行系统或构建的过程：观察和记录结果，并对系统或构建的某些方面给出评价
• 分析软件项目的过程：检测现有状况和所需状况之间的不同，并评估软件项目的特性

广义软件测试定义
软件测试是对软件形成过程中的所有工作产品（包括程序以及相关文档）进行的测试，而不仅仅是对程序的运行进行测试

确认（Validation）：通过检查和提供客观证据来证实特定目的的功能或应用是否已经实现。

验证（Verification）：通过检查和提供客观证据来证实指定的需求是否满足。

软件测试的目的

• 以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，保证各种错误和缺陷得以修复，避免软件发布后由于潜在的软件错误和缺陷造成的隐患所带来的商业风险。
• 同时利用测试过程中得到的测试结果和测试信息，作为后续项目开发和测试过程改进的重要输入，避免在将来的项目开发和测试中重复同样的错误。
• 采用更高效的测试管理手段，提高软件测试的效率和软件产品的质量。
• 一个成功的测试用例在于它能发现至今未发现的错误，一个成功的测试是发现了至今未发现的错误的测试。

软件测试项目从什么时候开始？为什么？

软件测试应该在需求分析阶段就介入，因为测试的对象不仅仅是程序编码，应该对软件开发过程中产生的所有产品都测试，并且软件缺陷存在放大趋势。缺陷发现的越晚，修复它所花费的成本就越大。

软件测试的八个原则

1. 所有测试的标准都是建立在用户需求之上
2. 始终保持“质量第一”的觉悟，当时间和质量冲突时，时间要服从质量
3. 需求阶段应定义清楚产品的质量标准
4. 软件项目一启动，软件测试就已经开始，而不是等程序写完，才开始进行测试
5. 第三方进行测试会更客观，更有效
6. 软件测试计划是做好软件测试工作的前提
7. 测试用例是设计出来的，不是写出来的
8. 对发现错误较多的程序段，应进行更深入的测试

测试和调试的区别

1. 二者在主体、目标、方法和思路上有所不同

	测试	调试
主体	测试人员	开发人员
目标	找出软件缺陷	将错误修改正确
方法	黑盒测试、白盒测试等	从程序结构和逻辑算法出发考虑
思路	反向思维	正向思维

2. 测试是从已知的条件开始的，使用预先定义的过程，并且有预知的结果；调试是从未知的条件开始的，结果的过程可能不可预计。
3. 测试可以计划，可以预先制定测试用例和过程，工作进度可以度量；描述调试的过程或持续时间相对比较困难
4. 测试的对象包括软件开发过程中的文档、数据以及代码，而调试的对象一般来说只是代码

软件危机
软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现的一系列严重问题的现象。

软件工程
基于软件危机对于计算机发展的阻碍，1968年，在联邦德国召开的国际会议上，北大西洋公约组织的计算机科学家讨论软件危机问题。提出了软件工程这一名词，从此软件生产进入工程化时代。
软件工程包括两方面内容：

1. 软件开发技术：技术开发方法学、软件工具和软件工程环境
2. 软件项目管理：软件质量、项目估算、进度控制、人员组织、配置管理、项目计划

• 引起软件危机的主要问题是软件质量问题
• 软件工程主要解决的就是软件质量问题
• 软件测试是软件质量管理体系中的一个非常重要的手段

软件生存周期
软件生存周期是软件开发全部过程、活动和任务的结构框架，是从可行性研究到需求分析、软件设计、编码、测试、软件发布维护的过程。

软件配置管理
软件配置管理作为软件开发过程的必要环节和软件开发管理的基础，贯穿整个软件生命周期，同时对软件开发过程的宏观管理即项目管理也有重要的支持作用。
一个软件开发组织真正有效的实施软件配置管理，将会使软件开发过程有更好的可预测性，使系统具有可重复性，大大提高软件组织的竞争力。

软件配置包括如下内容：

1. 配置项识别
2. 工作空间管理
3. 版本控制
4. 变更控制
5. 状态报告
6. 配置审计

软件产品质量特性

1. 功能性：适应性、准确性、互操作性、依从性、安全性。
2. 可靠性：成熟性、容错性、以恢复性。
3. 可使用性：易理解性、易学习性、易操作性。
4. 效率：时间特性、资源特性。
5. 可维护性：易分析性、易变更性、稳定性、易测试性。
6. 可移植性： 适应性、易安装性、遵循性、易替换性。

测试人员在软件开发过程中的任务是什么？
1、寻找 Bug；
2、避免软件开发过程中的缺陷；
3、衡量软件的品质；
4、关注用户的需求。
总目标是：确保软件的质量。

软件生命周期及常见模型

软件生命周期模型

软件生命周期模型（Life Cycle Model）是指软件在经历需求、分析、设计、实现、部署后，被使用并进入维护阶段，直到最后由于缺少维护费用而逐渐消亡这样的一个过程。
软件生命周期由软件定义、软件开发与运行维护 3 个时期组成，每个时期又进一步划分成若干个阶段。

问题定义：通过对用户的调查访问，确立用户的问题性质，工程目标等。
可行性研究：确立问题研究的范围与可行性、哪些阶段应该投入更多的人力物力。
需求分析：与客户进行密切访问充分交流信息，以得出用户想要的系统逻辑模型（是以后设计和实现目标的基础）。
总体设计：应该先设计出实现目标系统的几种可能性方案，还有设计程序的体系结构，即确定程序由哪些模块组成及模块之间的关系。
详细设计：解决了具体实现系统的任务，详细地设计每个模块，确定模块功能所需要的算法及数据结构。
编码和单元测试：写出正确的容易理解、易于维护的程序模块。
综合测试：通过各种类型的测试达到预定的要求。最基本的测试是集成测试和验收测试。
软件维护：维护阶段的关键任务是，通过各种必要的维护活动使系统持久地满足用户的需要。有四种维护：改正性维护；适应性维护；完善性维护；预防性维护。

常见模型

1. 瀑布模型
2. 增量原型
3. 螺旋模型
4. 迭代模型
5. 快速原型
6. 喷泉模型
7. 敏捷开发

瀑布模型

瀑布模型是最早提出的软件开发的过程模型，瀑布模型各个阶段为：计划，需求分析，设计，程序编码，软件测试，运行维护。
瀑布模型将软件生命周期的各项活动自上而下如瀑布流水依次连接，上一阶段的输出作为下一阶段的输入，同时，在每一个阶段如果发现问题，都可以逆流而上，向上一阶段进行反馈，然后做适当的修改，但是只能逐层反馈，不能跨级反馈。
通过瀑布模型归纳得出：如果每一阶段都能保证有效性，那么最终产生的结果也能保证其有效性。
瀑布模型的优点

1. 为项目提供了按阶段划分的检查点
2. 当前一阶段完成后，只需要关注后续阶段
3. 可在迭代模型中应用瀑布模型
4. 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

瀑布模型的缺点

1. 各个阶段划分固定，阶段之间产生大量文档，极大增加了工作量
2. 强调时间顺序的严格执行，前阶段不完成，后阶段不开展
3. 线性开发，用户等到整个过程的末期才能见到开发成果，增加了开发风险
4. 不适应用户需求的变化
5. 将测试放在了编码之后，没有体现出测试贯穿软件生命周期的原则，导致需求的问题一直延续到代码完成才暴露或者被发现

增量模型

增量模型将需求进行分段，分成一系列增量产品，每一增量可以分别开发，即：将软件模块化，每一模块为一增量组件，然后分别进行开发，所有增量叠加在一起就形成了最终的软件产品。
另外，每一个模块分别开发时，都是一个瀑布模型，所以可以把增量模型看成是瀑布模型的升级版，瀑布模型的变体。

增量模型的优点
由于增量模型作为瀑布模型的变体，所以增量模型具有瀑布模型的所有优点，除此之外还有：

• 第一个可交付版本所需成本和时间相比于瀑布模型来说是很少的，比如说第一个增量只有软件的核心功能。
• 能很快的看到一些成果，增加开发人员的信心。
• 开发风险相对不大。（大事化小，小事化了，分而治之）
• 由于可以很快的发布第一格版本，因此可以减少用户需求的变更，对用户形成了制约。

增量模型的缺点

• 由于初始增量是后续增量的基础，所以如果要对初始增量的需求进行修改，可能会影响后续的增量。
• 增量模型要求必须有一部分的需求是可以确定的（即：不用把所有需求都确定下来，但是必须要先确定一部分），因为每一个增量都相当于是一个瀑布模型，这样就不难理解了。
• 增量过多会造成管理成本超支，影响进度。

螺旋模型

螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控，引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。

一个迭代过程为：制定计划，风险分析，实施工程，项目评估。这四个活动分布在笛卡尔坐标的四个象限中，一个象限表示一个活动。从制定计划开始，然后风险分析，如果通过了风险分析，则进入开发阶段，开发完成后再进行评估。评估后又进入外一层螺旋进行下一次循环迭代，制定计划，风险分析…直到项目开发完成或者没有通过风险分析为止。

螺旋模型的优点

• 对大型的项目有较好的风险控制能力。

螺旋模型的缺点

• 需要分析人员有风险分析的经验，因为分析失误会造成很大的损失。
• 螺旋模型周期相对较长，所以不适用于大部分软件开发项目

迭代模型

迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必须的所有其他元素，强调开发的深入。
在某种程度上，开发迭代是一次完整的经过所有工作流程的过程：需求分析、设计、实施和测试工作流程

迭代模型的优点

• 降低了在一个增量上的开支风险
• 降低了产品无法按照既定进度进入市场的风险
• 加快了整个开发工作的进度
• 迭代过程这个模式使适应需求的变化更容易

迭代模型的缺点

• 每个迭代都会有管理成本，较多的迭代使得管理成本较大。
• 容易让开发团队有不进行需求分析的借口。
• 用户不易理解该模型不断迭代演化的特点，因此当某次迭代后的反馈不理想时，用户容易产生抱怨情绪。（实际上，这一缺点也是帮助了开发团队能从用户那儿获取到更明确的需求，因为用户抱怨，不满意，所以会提出改进意见，使得需求更加明确，促进了下一次的迭代）

快速原型

快速原型是快速建立起来的程序，它只是最终产品的子集（或雏形），建立快速原型的作用是帮助用户确定需求以及可以用于确定项目的可行性。

快速原型模型主要部分
原型快速分析：分析者和用户相互配合，快速确定软件系统的基本需求。
原型构造：在原型快速分析的基础上，只考虑主要特性，快速构造一个可运行的系统。
原型运行与评价：开发人员与用户频繁沟通，发现问题，消除误解，目的是发现新需求并修改原有需求。
原型修正：根据新需求对原型系统进行修正。
判定原型完成：若原型修改后获得了参与者的一致认可，那么原型开发的迭代就可以结束了。

快速原型模型的优点

• 主要针对于小型的、快捷的，并且需求不明确的项目；
• 有的软件原型可以作为最终产品的一部分

快速原型模型的缺点
快速建立的系统结构加上连续修改可能导致产品质量低下，原型系统的内部结构可能不好。

喷泉模型

喷泉模型是以用户需求为动力，以对象为驱动的模型，主要用于采用对象技术的软件开发项目。

喷泉模型与传统的结构化生存期比较，具有更多的增量和迭代性质，生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。就像水喷上去又可以落下来，可以落在中间，也可以落在最底部。

喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。

喷泉模型的优点:
可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。

喷泉模型的缺点:
由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理；此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。

敏捷开发

敏捷开发模型（Agile-Development-Model）是一种以人为核心、迭代、循序渐进的开发方法。

在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

敏捷开发小组主要的工作方式

• 作为一个整体工作；
• 按短迭代周期工作，每次迭代交付一些成果，关注业务优先级，检查与调整。

敏捷开发的4个核心思想

• 强调面对面的沟通，人和人的相互交流胜于任何流程和工具；
• 把精力集中在可执行的程序上，可以运行的产品胜于编制综合性文档，强调了原型、模型、demo等的重要性；
• 团队合作和团队激励，合作胜于谈判，敏捷开发能将需求、开发、测试等全部团队成员融合成一个整体，大家都是一条线上的蚂蚱；
• 超强的适应能力，适应变化胜于按部就班，敏捷开发的特点就是快速

敏捷开发的优点

• 项目进入实质开发迭代阶段，用户很快可以看到一个基线架构版的产品。
• 敏捷注重市场快速反应能力，也即具体应对能力，客户前期满意度高。

敏捷开发的劣势

• 敏捷注重人员的沟通，忽略文档的重要性，若项目人员流动大太，又给维护带来不少难度，特别项目存在新手比较多时，老员工比较累。
• 需要项目中存在经验较强的人，要不大项目中容易遇到瓶颈问题。