软件测试 → 第一章 基础-> 软件与软件危机

一、 软件概念

1、软件是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。
2、程序是按事先设计的功能和性能要求执行的指令序列。
3、数据是使程序能正常操纵信息的数据结构。
4、文档是与程序开发，维护和使用有关的图文材料。

二、 软件特性

　　形态特性、智能特性、开发特性、质量特性、生产特性、管理特性、环境特性、维护特性、废弃特性、应用特性

三、 软件种类

　　1、系统软件：操作系统 数据库管理系统 设备驱动程序 通信和网络处理程序等
　　2、支撑软件（工具软件）
　　　　①、纵向支撑软件：分析、设计、编码、测试工具等；
　　　　②、横向支撑软件：项目管理工具，配置管理工具等
　　3、应用软件：工程与科学计算软件 商业数据处理软件 ERP软件 计算机辅助设计／制造软件 系统仿真软件 智能产品嵌入软件 事务管理、办公自动化软件
　　    4、可复用软件：标准函数库、类库、构件库等

四、 软件危机及其原因

　　软件的发展速度远远滞后于硬件的发展速度，不能满足社会日益增长的软件需求。软件开发周期长、成本高、质量差、维护困难。

五、 软件工程

　　采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。

六、 软件生命周期

6.1 什么是软件生命周期

　　软件的生命周期，亦称软件的生存周期。软件开发项目中，有几种常见的生命周期模型，如瀑布模型、增量模型，螺旋模型、原型开发、倒V模型等。它是按开发软件的规模和复杂程度，从时间上把软件开发的整个过程（从计划开发开始到软件报废为止的整个历史阶段）进行分解，形成相对独立的几个阶段，每个阶段又分解成几个具体的任务，然后按规定顺序依次完成各阶段的任务并规定一套标准的文档作为各个阶段的开发成果，最后生产出高质量的软件。

6.2 软件生命周期的阶段划分

　　　需求分析->软件设计->程序编码->软件测试->运行维护

6.3 软件生命周期模型

　　生命周期常见的有：瀑布模型、V模型、敏捷开发模型。

• 瀑布模型

　　瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，包括问题定义及规划、需求分析、软件设计、程序编码、软件测试和运行维护等六个基本活动，并且规定了他们自上而下，相互衔接的固定次序，形如瀑布流水，逐级下落，具有顺序性和依赖性，最终得到软件产品。
　　因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。
　　包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。

　　

每个阶段规定的文档需进行评审，评审完后才可以进入下一个阶段。

优点：
1）为项目提供按阶段划分的检查点
2）当前一阶段完成后，你只需要关注后一阶段
3）可在迭代模型中应用瀑布模型
4）提供一个模板，这个模板使得分析，设计，编码，测试和支持的方法可以在该模板下有一个共同的指导
缺点：
1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4）瀑布模型的突出缺点是不适应用户需求的变化

• V模型

通过开发和测试同时进行的方式来缩短开发周期，提高开发效率。其形状像一个字母A，故称为V模型。

对应关系：
　　一般来讲：单元测试所对应的是详细设计环节，也就是说，单元测试的测试用例是和详细设计一起出现的，在研发人员做详细设计的时候，相应的测试人员也就把测试用例写了出来；集成测试对应概要设计，在做模块功能分析及模块接口，数据传输方法的时候，就把集成测试用例根据概要设计中模块功能及接口等实现方法编写出来，以备以后作集成测试的时候可以直接引用；而系统测试，就是根据需求分析而来，在系统分析人员作系统分析，编写需求说明书的时候测试人员就根据客户需求说明书，把最后能实现系统功能的各种测试用例写出来，为做最后系统测试作准备。验收测试与用户需求对应，是非设计流程。
适用范围：
　　V模式是一种传统软件开发模型，一般适用于一些传统信息系统应用的开发，而一些高性能高风险的系统、互联网软件，或一个系统难以被具体模块化的时候，就比较难做成V模式所需的各种构件，需要更强调迭代的开发模型或者敏捷开发模型。

• 敏捷开发模型

是一种以用户需求进化为核心（强调沟通、弱化文档）、迭代、循序渐进的开发方法。强调以人为本，专注于交付对客户有价值的软件。是一个用于开发和维持复杂产品的框架。就是把一个大项目分为多个相互联系，但也可以独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

流程：
　　1）、产品负责人将整个产品设计成产品代办列表。就是一个个需求列表。（可以理解为需求或者要做的事情）
　　2）、召开产品迭代计划会议，确定哪些需求是需要在第一个迭代中完成的，评估迭代的时间（建议是2-4周），得到相应的迭代周期任务列表。
　　PS:提前发布功能需求列表，会议提倡所有团队人员参与
　　3）、把迭代的功能需求写在纸条上贴在任务墙，让大家（自主认领）认领分配。（任务墙就是把未完成、进行中、已完成的工作状态贴到一个墙上，这样大家都可以看到任务的状态）
　　举行每日站立会议，让大家在每日会议上总结昨天做的事情，遇到什么困难，今天开展什么任务。（每日站立会议，是在每天早上定时和大家在任务墙前站立讨论，时间控制在15分钟内）
　　绘制燃尽图，保证任务的概况能够清晰看到。（燃尽图把当前的任务总数和日期一起绘制，每天记录一下，可以看到每天还剩多少个任务，直到任务数为0，这个迭代就完成了)
　　PS:在开发人员开始开发一个任务时，需要找来对应的测试人员讲解该任务功能，以便测试人员有一致的理解，并且一开始就进行测试用例，自动化系统测试脚本的开发（若需要自动化测试的话）。
4）、评审会议是在迭代完成时举行，要向客户演示自己完成的软件产品，并获得客户的反馈。
　　PS:很多用户对软件开发是没有概念的，他只知道自己有某种需求。所以就要通过不断的让用户看到产品的模型，这个过程用户才会逐步的对产品产生概念。
5）、最后是总结会议，以轮流发言方式进行，每个人都要发言，总结好的实践和教训，并落实到后续的开发中。不要流于形式。
适用原则：
1、个人与互动：重于流程与工具
　　--强调人与人的沟通，所以尽可能要集中化办公。异地开发模式容易让人疲惫
　　--个人技能要提高。尤其对于架构师要求很高。
　　--管理者要多参与项目有关的事情。
　　-- 减少对开发人员的干扰，问题集中整理问。
2、可用的软件：重于详尽的文件
　　--强调文档的作用。必要的文档是必须的，具有传承性。
3、与客户合作：重于合约协商
　　--做好客户引导。客户都是想在尽可能短的时间内，交付尽可能多的功能。
4、回应变化：重于遵循计划
　　--无理变化，举棋不定的结果，并不是说都需要及时响应，会导致很多浪费。

补充知识：

• 系统工程的目标

　　运用先进的软件开发技术和管理方法来提高软件的质量和生产率，也就是要以较短的周期、较低的成本生产出高质量的软件产品，并最终实现软件的工业化生产。

• 软件生存期

软件定义、软件开发、运行维护

• 软件工程方法概述

　　目前使用最广泛的软件工程方法学：传统方法学（结构化方法学），面向对象方法学。
　　三要素：方法、工具和过程

• 软件工具概述

　　软件工具是指能支持软件生存周期中某一阶段（如系统定义、需求分析、设计、编码、测试或维护等）的需要而使用的软件工具。

• 常用软件工具

需求分析与设计工具、编码工具与排错工具、测试工具

• 软件工程知识体系及知识域

　　1、软件工程教育(3个历史时期)

　　1978年以前：软件工程教育以计算机专业的一门孤立的课程形式存在。
　　1978—1988年期间：早期的研究生学位教育，开始建立软件工程专业的研究生学位教育项目。
　　1988年以后：快速发展的研究生学科教育，使软件工程的理论快速发展，其中，卡内基·梅隆大学软件工程研究所（SEI）的影响不可忽视。

　　2、软件工程知识体系指南的内容 SWEBOK指南将软件工程知识体系划分为15个知识域（knowledge areas，KA），这些知识域又划分为三类： 软件工程基础类、软件生存期过程类、软件工程管理类。