『软件测试』概念篇Ⅱ

1、软件测试的目的和原则

目的：验证软件有或没有问题。
原则：以客户为中心，遵循软件测试的规范、流程、标准和要求

2、需求

用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该 需求一般比较简略。
软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。

软件需求是测试人员进行测试工作的基本依据

3、Bug

①当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是 错误。
②当没有需求规格说明书时，判断标准以终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软 件错误。

4、测试用例

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步 骤、测试数据、预期结果等要素。

5、开发模型和测试模型

随着软件工程学科的发展，人们对计算机软件的认识逐渐深入。软件工作的范围不仅仅局限在程序编写，而是扩展 到了整个软件生命周期，如软件基本概念的形成、需求分析、设计、实现、测试、安装部署、运行维护，直到软件 被更新和替换新的版本。软件工程还包括很多技术性的管理工作，例如过程管理、产品管理、资源管理和质量管 理，在这些方面也逐步地建立起了标准或规范。

5.1 软件的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。 如果把软件看成是有生命的事物，那么软 件的生命周期可以分成6个阶段，即需求分析、计划、、设计、编码、测试、运行维护。

5.2 瀑布模型:

需求分析→计划→设计→编码→测试
瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

优点： 各个阶段分配很明确；强调开发的阶段性； 强调早期计划及需求调查；强调产品测试。
缺点： 依赖于早期进行的唯一一次 需求调查，不能适应需求的变化；由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程； –风险往 往迟至后期的测试阶段才显露，因而失去及早纠正的机会。
适用于： 项目需求比较稳定，变化比较少的项目。

5.3 螺旋模型：

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。

优点： 有着严格的全过程的风险管理。
缺点： 项目进度可能长一点，因为每一阶段都要进行风险分析，需要人员、资金和时间的投入，引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技术水平提出了很高的要求。
适用于： 规模庞大、复杂度高、风险大的项目尤其适合。

5.4 增量、迭代：

增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程佳实践之一。
增量是逐块建造的概念，迭代是反复求精的概念。

5.5 敏捷：

1）人与人之间的沟通：个体与交互重于过程和工具
2）轻文档: 可用的软件重于完备的文档
3）客户全过程参与: 客户协作重于合同谈判
4）拥抱变化：响应变化重于遵循计划

敏捷开发有很多种方式，其中scrum是比较流行的一种

5.5.1 scrum

scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。

• 其中product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产 品负责。
• scrum master 负责召开各种会议，协调项目，为研发团队服务。
• 研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

迭代开发： 与瀑布不同，scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4周。参与的 团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。

5.6 敏捷中的测试

挑战1：轻文档
挑战2：快速迭代

1）测试工作的核心内客是没有变的，就是不断地找Bug，只是要调整好自己的心态，一切以敏捷的原则为主。

2）测试人员不能依赖文档，测试用例作用减弱，更多的采用思维导图、探索性测试（强调自由度，设计和执行同 时执行，根据测试结果不断调整测试计划）、自动化测试

3）敏捷讲求合作，在敏捷项目组中，测试人员应该更主动点，多向开发人员了解需求、讨论设计、一起研究Bug 出现的原因。总结：

调整好自己的心态

自动化测试代替手工测试

团队之间的合作

敏捷开发模型流程：

po整理 USER STORY----确定每次迭代需要的 user story----user story 分配，时间评估----开发中----开发完成-----测试中—测试完成-----发布上线

5.7 软件测试v模型 :

V模型早是由Paul Rook在２０世纪８０年代后期提出的，目的是改进软件开发的效率和效果。是瀑布模型的变种
1)明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的 对应关系
2)V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的 质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求
3)局限性:仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试.

5.8软件测试W模型

W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试 与开发过程，图中明确表示出了测试与开发的并行关系。
W模型特点: 测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的 .
W模型优点: 有利于尽早地全面的发现问题。例如，需求分析完成后，测试人员就应该参与到对需求的验证和 确认活动中，以尽早地找出缺陷所在。同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制 定应对措施，显著减少总体测试时间，加快项目进度。
局限性： 需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段 完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模 型并不能解除测试管理面临着困惑。

6.配置管理和软件测试

在参与当代软件开发时，必须具备软件配置管理方面的基本素养。不懂软件项目的配置管理，就不懂软件开发管 理。没有对软件项目进行配置管理，其实就没有进行软件项目开发管理。

6.1 什么是配置管理

配置管理( Configuration Management)是通过对在软件生命周期不同的时间点上的软件配置进行标识，并对这些 被标识的软件配置项的更改进行系统控制，从而达到保证软件产品的完整性和可溯性的过程。

6.2 软件配置管理的应用

软件开发过程中会产生大量软件产品（包括文档、源代码和数据等），且这些产品之间存在关联关系。同一软件产 品也会发生变更，从而产生许多版本。软件开发小组必须清晰地知道会有哪些产品、这些产品会有哪些不同的形式 和版本。开发小组必须清晰地知道如何将产品的变更通知给受影响的小组。如果不能有效地了解软件产品及其变 更，开发小组将很难组装这些软件产品，很难得到所需的软件产品。

6.3 实施配置管理的好处

(1)能够对项目中的文档、代码等的变化进行有效管理。
(2)能够方便地重现某个文件的历史版本。
(3)能够重新编译某个历史版本，使维护工作变得容易。
(4)能够使 异地多团队开发、并行开发成为现实。
(5)从公司级看，实行统一的配置管理流程可提高项目组间人员流动时的工 作效率。

6.4 配置管理与软件测试

测试人员是SCM中的参与者，有些公司也会把测试人员和配置管理员合二为一。如果配置管理流程不规范，或者没有遵循一定的配置管理流程进行软件测试活动，也可能导致很严重的后果。测试人员应该从配置库取源代码编译后再测试，只有看到新的构建版本不再出现那个Bug，才能把缺陷库中的Bug关闭。