目录

一. 需求

1. 用户需求

2. 软件需求

3. 从测试人员的角度看需求

二.  测试用例

三. BUG

四. 开发模型

1. 软件的生命周期

2. 开发模型

2.1 瀑布模型

 2.2 螺旋模型

2.3 增量，迭代模型

 2.4 敏捷模型

SCRUM

五. 测试模型 

1. V模型 

2. W模型 (双V模型) 

---

一. 需求

需求一般可以分为用户需求和软件需求。 

1. 用户需求

可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成 的任务。用户需求一般比较简略。

2. 软件需求

软件需求也可以称为功能需求，该需求会详细描述开发人员必须实现的软件功能。

大多数公司在进行软件开发的时候会把用户需求转化为软件需求(用户需求通常是几句话，而软件需求是一个文档)，开发人员和测试人员工作的直接依据就是软件需求，软件需求是测试人员进行测试工作的基本依据。

3. 从测试人员的角度看需求

在具体设计测试用例的时候，首先需要搞清楚每一个业务需求对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，然后针对每个测试需求点设计测试用例。

 业务需求—>软件功能需求点—>测试需求点—>测试用例

以 "用户登录"为例：

二.  测试用例

测试用例是为了实施测试而向被测试的系统提供的一组集合，其主要包括测试环境，测试数据，测试结果，操作步骤等...

测试环境一般包括操作系统环境，浏览器环境，以及PC端环境和手机端环境；

测试步骤即测试的具体过程，例如测试登录QQ，则测试步骤为：输入账号，输入密码，点击登录；

那么此时的测试数据就是账号和密码； 

预期结果就是成功登录；

测试用例可以降低测试人员工作的重复性问题，提高工作效率，同时也是建立自动化测试的基础。这一块测试用例的设计后续会详细分析。

三. BUG

当且仅当规格说明是存在的并且正确，程序与 规格说明 之间的 不匹配就是BUG；

(此处的规格说明也可以等价于软件需求)

又或者说：当程序实现的功能要求，与用户所期望得到的功能要求不符合的时候， 就是出现了BUG；

简单的说就是：预期结果不等于执行结果

四. 开发模型

1. 软件的生命周期

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

需求分析：根据需求文档，分析需求是否合理，是否完整；

计划(产出计划文档)： 决定开发和测试如何进行，怎样进行，什么时候进行，什么时候结束；

设计(产出设计文档)：针对需求，来进行技术设计(需要使用哪些技术，接口等)；

编码：开发人员根据计划文档和设计文档来进行程序设计；

测试(产出测试报告)：测试人员根据测试用例来进行测试； 测试报告需要包括：项目名称，开发人员，测试人员，产品经理，BUG，测试周期，开发周期，风险等内容；

运行维护：对项目进行线上维护，在出问题的时候，测试和开发就需要协助定位问题，解决问题； 

2. 开发模型

2.1 瀑布模型

显而易见，瀑布模型的特点就是线性的；

优点：在瀑布模型中，每个阶段做什么，产出什么都十分清晰；

缺点：由于测试介入的比较晚，因此风险往往会在后期阶段才被暴露出来，影响项目开发效率，也就是在前期阶段未发现的错误会传递并扩散到后面的阶段，而在后面阶段发现这些错误时，可能已经很难回头再修正，从而导致项目的失败。

依赖于早期进行的唯一一次需求调查，不能适应需求的变化；

因此也就适用于一些开发上线进度较快的小项目；

 2.2 螺旋模型

螺旋模型可以算是针对瀑布模型的一些缺陷进行改良，瀑布模型无法及时发现存在的一些风险。螺旋模型会在执行一定步骤之后进行一次风险分析。如下图中，需求计划后，进行风险分析，确定下来了软件需求，形成需求文档，然后进行需求确认，确认需求合理且完整，而后进行开发计划，再次进行风险分析...

优点：每一个阶段都会进行风险分析，可以极大程度上避免一些线上问题的发生；

缺点：首先风险分析只是对未来的一个预判，但并不是完全正确的，所以是有分析错的可能的，其次这样多次风险分析也是需要大量财力和人力的投入，也降低了时间效率；

适用于一些规模比较大，复杂度比较高，风险比较多的项目；

2.3 增量，迭代模型

增量模型：可以理解为以需求为单位来进行开发，开发完一个需求后，再继续开发下一个需求，例如一个功能包含有 A,B,C三个需求，那么在增量模型下，就需要开发完A需求，再去开发B需求，最后再去开发C需求； 

迭代模型： 可以理解A,B,C需求可以进行并发开发，可以先开发A需求的一部分内容，然后再去开发B需求的一部分内容，再去开发C需求的一部分内容，然后再返回开发A,B,C剩下的内容。

在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件

版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。

 

 2.4 敏捷模型

 敏捷宣言

• 个体与交互重于过程和工具 (轻流程，重交流)
• 可用的软件重于完备的文档 (轻文档，重产出)
• 客户协作重于合同谈判 (多和客户进行交流)
• 响应变化重于遵循计划 (拥抱变化)

在每对比对中，后者并非全无价值，但我们更看重前者。

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

SCRUM

其中包含有三个角色：

产品经理：根据用户的需求，完成出需求文档；

项目经理：负责召开各种会议，协调项目，为研发团队服务；

研发团队： 由后端，前端，测试等技术人员组成，通过紧密协同，完成每一次迭代的目标，交付产品；

SCRUM的基本流程 

首先由产品经理收集用户需求；

然后项目经理对需求进行优先级划分，计划项目什么时候开始，什么时候结束，由谁去做；然后由研发团队去完成每一项任务；

在这期间，会有每日例会，团队成员回答昨天做了什么今天计划做什么，有什么问题；

迭代结束之后，召开演示会议，团队负责向大家展示本次迭代取得的成果；

最后进行总结回顾，项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。

五. 测试模型 

1. V模型 

特点：左边是开发，右边是测试，有些类似于瀑布模型；

优点：测试过程比较完善，划分为多种测试类型；

缺点：测试介入时间点过晚，发现差错时机过晚；

2. W模型 (双V模型) 

特点：开发一个V状，测试一个V状； 

优点：测试人员介入时间变早了；

缺点：

1. 验收测试准备依赖于用户需求，系统测试准备依赖于系统设计，集成测试准备依赖于概要设计...因此测试人员和开发人员一定程度上还是串行的；

2. 另一方面，如果验收测试发现问题了，还是得回溯到系统测试，系统测试发现了问题，得回溯到集成测试...因此这个过程不能拥抱变化，不能适用于敏捷；