软件测试模型

软件生命周期

软件生命周期 同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、成熟、衰亡等阶段，一般称为软件生命周期。软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。

软件测试模型

边做边改模型（最原始模型）

许多产品都是使用“边做边改”模型来开发的。在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。

在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户满意为止。

这是一种类似作坊的开发方式，对编写几百行的小程序来说还不错，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：

（1） 缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；

（2） 忽略需求环节，给软件开发带来很大的风险；

（3） 没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。

瀑布模型

瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位。它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。无法应对需求经常变化的项目。

优点：

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

2. 当前一阶段完成后，只需要去关注后续阶段。

缺点：

1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。

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

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

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

*V模型

V 模型的左边下降的是开发过程各阶段，与此相对应的是右边上升的部分，即各测试过程的各个阶段。

V 模型的优点：在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发各阶段的对应关系。

V模型的缺陷及解决思路：

V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。

解决的思路：当一个软件开发的时候，研发人员和测试人员需要同时工作，测试在软件做需求分析的同时就会有测试用例的跟踪，这样，可以尽快找出程序错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。

*W模型

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

敏捷开发和敏捷测试

整体介绍

轻文档，重沟通

版本1.0 需求分析--需求评审--开发编程--->进行测试

版本1.1 需求分析--需求评审--开发编程--->进行测试

第一周: 产品经理提出新的需求--->对需求进行分析--->需求评审--->开发编程----->编程完提测 ---->写测试用例---->测试---->提bug-->上线

第二周: 产品经理提出新的需求--->对需求进行分析--->需求评审--->开发编程----->编程完提测 ---->写测试用例---->测试---->提bug-->上线

敏捷开发

敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

由于版本节奏比较快，开发与测试几乎并行，一个版本周期内会有两版在推动，也就是上图中提到的波次发布，波次发布用于尝试新加入的功能，做小范围快速的开发，验证和发布，为下个大版本的功能做实验和调研。快速发版的需求要求测试快速响应，敏捷测试模式适应项目需求。

模型特点

工作任务划分清晰，工作效率较高

与开发和产品沟通紧密，团队协作性强

测试介入到整个项目的所有会议中，对整体版本信息情况把控全面

轻文档，重沟通。

敏捷的科学定义

敏捷测试既不是一种方法（如黑盒方法、白盒方法等），也不是一种方式（如探索式测试）

敏捷测试是一套解决方案、一类测试操作与管理的框架、一组实践或由一定顺序的测试活动构成的特定的测试流程 ”

敏捷测试是顺应敏捷开发方法、力求达到质量和效率平衡的一系列的测试实践

敏捷测试特点

多关注用户体验、系统使用场景，把单功能测试，交给开发自测

测试尽早介入，参与项目全流程

Code review（代码评审，代码复查）、单元测试、自动化测试，都非常重要

轻文档，重沟通。

用户故事

由于敏捷测试有一个特点叫轻文档，重沟通。有些时候，对于需求，没有特定的文档，可能就会用”用户故事”进行描述。

用户故事（user story）是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：

　　1. 角色：谁要使用这个功能。

　　2. 活动：需要完成什么样的功能或目标。

　　3. 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

英文：

　　As a <Role>, I wantto <Activity>, so that <Business Value>.

　　中文：

　　作为一个<角色>,我想要<活动>, 以便于<商业价值>

比如:

作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。

作为用户，我想要查看我的订单列表，以便于了解我的购物信息。

作为用户，我想搜索我的足迹，以便了解我过去1年去过哪些城市。