软件测试用例模板和例子_软件生命周期

软件生命周期定义

定义：软件生命周期是指从软件定义、开发、使用、维护到报废为止的整个过程,一般包括问题定义、可行性分析、需求分析、总体设计、详细设计、编码、测试和维护。 阶段：需求分析—>软件设计—>程序编码—>软件测试—>运行维护 在不同的阶段里，由不同的组织和人员执行不同的任务，需要消耗不同的资源。

软件生命周期模型

软件生命周期模型也称为软件过程模型，反应软件生存周期各个阶段的工作如何组织、衔接，常用的有瀑布模型、V模型、敏捷开发模型、原型模型、螺旋模型、增量模型、喷泉模型，还有建造-修补模型，MSF过程模型、快速原型模型。 瀑布模型 瀑布模型是指将软件生命周期的各项活动规定为按固定顺序而连接的若干阶段工作，包括问题定义与规划、需求分析、软件设计、程序编码、软件测试和运行维护等六个基本活动，并且规定了它们自上而下，相互衔接的固定次序，形如瀑布流水，逐级下落，具有顺序性和依赖性，最终得到软件产品。每个阶段的主要工作成果(文档)从一个阶段传递到下一个阶段，必须经过严格的评审或测试，以判定是否可以开始下一阶段工作。 因此 ，如果有信息未被覆盖 或者发现了什么问 题， 那么最好 “返回 ” 上一个阶段 并进行适当的 修改， 项目 开发过程从一个阶段 “流动 ” 到下 一个 阶 段 ，这也是 瀑布模型 名称的由来。 包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。

优点：

• 1.为项目提供按阶段划分的检查点

• 2.当前阶段完成后，你只需要关注后一阶段

• 3.可在迭代模型中应用瀑布模型

• 4.提供一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导

缺点:

• 1.各个阶段的划分基本固定，阶段之间产生大量的文档，极大地增加了工作量

• 2.由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险。

• 3.通过过多的强制完成日期和里程碑来跟踪各个项目阶段。

• 4.瀑布模型突出的特点是不适应用户需求的变化。

V模型

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

对应关系：

一般来讲，单元测试所对应的是详细设计环节，也就是说，单元测试的测试用例是和详细设计一起出现的，在研发人员做详细设计的时候，相应的测试人员也就把测试用例设计出来；

集成测试对应概要设计，在做模块功能分析及模块接口，数据传输方法的时候，就把集成测试用例根据概要设计中模块功能和接口等实现方法编写出来，以备以后作集成测试的时候可以直接引用；

而系统测试，就是根据需求分析而来，在系统分析人员做系统分析，编写需求说明书的时候测试人员就根据客户需求说明书，把最后能实现系统功能的各种测试用例写出来，为做最后系统测试做准别。

验收测试与用户需求对应，是非设计流程。

适用范围：

V模型是一种传统软件开发模型，一般适用于一些传统信息系统应用的开发，而一些高性能高风险的系统，互联网软件，或是系统难以被具体模块

敏捷开发模型

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

敏捷开发的流程

1.产品负责人将整个产品设计成产品代办列表，就是一个个需求列表。可以理解为需求或者要做的事情。

2.召开产品迭代计划会议，确定哪些需求是需要在第一个迭代中完成的，评估迭代的时间(建议2~4周)，得到相应的迭代周期任务列表。

PS:提前发布功能需求列表，会议提倡所有团队人员参与

3.把迭代的功能写在纸条上贴在任务墙，让大家(自主认领)认领分配。(任务墙就是把未完成、进行中、已完成的工作状态贴到一个墙上，这样大家都可以看到任务的状态)

• 举行每日站立会议，让大家在每日会议上总结昨天做的事情，遇到来什么困难，今今天开展什么任务。每日站立会议是在早上定时和大家在任务墙前站立讨论，时间控制在15分钟内。

• 绘制燃尽图，保证任务的概况能够清晰看到。(燃尽图把当前的任务总数和日期一起绘制，每天记录一下，可以看到每天还剩多少个任务，直到任务数为0,这个迭代就完成了)

  PS:在开发人员开始开发一个任务时，需要找来对应的测试人员讲解该任务功能，以便测试人员有一致的理解，并且一开始就进行测试用例，自动化系统测试脚本的开发(若需要自动化测试的话)。

4.评审会议是在迭代完成时举行，要向客户演示自己完成的软件产品，并获得客户的反馈。PS：很多用户对软件开发是没有概念的，他只知道自己有某种需求。所以就要通过不断的让用户看到产品的模型，这个过程用户才会逐步的对产品产生概念。

5.最后是总结会议，以轮流发言方式进行，每个人都要发言，总结好的实践和教训，并落实到后续的开发中。不要流于形式。

敏捷开发适用原则

1.个人与互动：重于流程与工具

强调人与人沟通，所以尽可能要集中化办公。异地开发模式容易让人疲惫。

个人技能要提高，尤其对于架构师的要求很高。

管理者要多参与项目相关的事情。

减少对开发人员的干扰，问题集中整理问。

2.可用的软件：重于详尽的文件

强调文档的作用，必要的文档是必须的，具有传承性。

3.与客户合作：重于合约协商

做好客户引导，客户都是想尽可能短的时间内，交付尽可能多的功能。

4.回应变化：重于遵循计划

无理变化，举棋不定的结果，并不是说都是要及时响应，会导致很多浪费。

-end-