软件测试——测试概念
目录
一、需求概念
1.1用户需求
1.2软件需求
1.3软件需求文档表述（以邮箱注册为例）
二、开发模型
2.1模型由来
2.2软件的生命周期
2.3.瀑布模型
2.3.1瀑布模型概念
2.3.2瀑布模型使用场景
2.3.3瀑布模型的优缺点
2.4螺旋模型
2.4.1螺旋模型概念
2.4.2螺旋模型的使用场景
2.4.3螺旋模型的优缺点
2.5增量模型、迭代模型
2.5.1增量模型、迭代模型的区别
2.5.2增量模型、迭代模型的适用场景
2.5.3增量模型、迭代模型优缺点
2.6敏捷模型
2.6.1敏捷模型概念
2.6.2敏捷模型特点
2.6.3敏捷模型例子——Scrum模型（迭代式增量软件模型开发）
2.7测试模型
2.7.1V模型
2.7.2W模型（双V模型）
一、需求概念
1.1用户需求
用户需求一般不明确，简略
1.2软件需求
软件需求会详细描述开发人员必须要实现的软件功能。
软件需求也是测试人员进行测试的主要依据。
1.3软件需求文档表述（以邮箱注册为例）
软件需求文档表述包括但不限于，前置条件、功能概述、用户角色、前置条件、输入（数据输入的格式，字符长度，以及数据类型）基本事件流（例如：用户选择注册、用户协议界面、用户填写注册信息、向用户注册的邮箱发送激活码、执行激活操作、用户注册完成）扩展事件流（注册完成后，第一次登录提示用户完善用户信息）异常事件流（未收到邮箱激活码）输出、后置条件
用户需求不能直接作为开发和测试的依据
产品经理需要进行需求分析（技术可行性、市场可行性、成本投入、收益占比）
二、开发模型
2.1模型由来
软件工作涉及软件的整个生命周期，软件工作也包括很多技术性的管理工作。这些软件工作建立的标准规范叫做模型。
软件基本概念的形成：需求分析、设计、实现、测试、安装、部署、运行维护、软件更新替代新的版本
软件技术管理工作：过程管理、产品管理、资源管理、质量管理
2.2软件的生命周期
需求分析——计划——设计——编码——测试——运行维护
| 阶段 | 具体内容 | 产出 |
| 需求分析 | 从市场需求、技术等方面分析用户需求是否合理 | 需求文档 |
| 计划 | 对成立的需求文档执行计划 多长时间完成改需求，每段时间完成哪些功能 | 计划文档 |
| 设计 | 讲需求细化成一个个任务，团队领取任务进行技术设计（架构设计、接口设计、采用技术 | 技术文档 |
| 编码 | 开发人员进行代码编写 | 代码文件 |
| 测试 | 测试人员参考测试用例对软件进行测试 | 测试用例、测试设计计划、测试报告 |
| 运行维护 | 产品上线后，对产品进行线上维护 | - |
线上维护分为三个方面：
修复性维护：对项目中未发现的问题进行修复
完善性维护：对功能进行完善
防御性维护：对一些其他不可预料的问题进行防护
2.3.瀑布模型
2.3.1瀑布模型概念
瀑布模型是其他模型的基础框架，每个阶段只执行一次，线性顺序开发模型。
2.3.2瀑布模型使用场景
经常适用于需求固定的小项目
2.3.3瀑布模型的优缺点
| 优点 | 缺点 |
| 强调开发的阶段性 线性结构 其他模型的基础 | 测试后置：前面各阶段遗留风险到最后阶段才发现，导致项目大面积返工；测试时间短，会导致测试不充分，从而产品质量差 周期长，可能会导致产品上线时已经过时 |
2.4螺旋模型
2.4.1螺旋模型概念
螺旋模型时渐进式开发模型代表之一。
在瀑布模型的基础上每个阶段都会引入风险分析，不断修改原型。
不允许有一段独立测试的时间，测试必须跟随开发的迭代而迭代，因此会经常用到回归测试。
2.4.2螺旋模型的使用场景
在软件初期阶段需求不明确（渐进式开发模型）
适用于规模庞大、复杂度高、风险大的项目。
2.4.3螺旋模型的优缺点
| 优点 | 缺点 |
| 强调严格的全过程风险管理 强调各开发阶段的质量 增加风险分析和原型 | 项目中存在的风险与风险管理人员的水平直接相关 需求人员、资金、时间、投入成本增加、导致项目成本高 |
2.5增量模型、迭代模型
2.5.1增量模型、迭代模型的区别
增量模型是一个功能一个功能的开发
迭代模型是给出全部功能的雏形，最后进行细化
2.5.2增量模型、迭代模型的适用场景
结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一
适用于大型目标不明确的项目
2.5.3增量模型、迭代模型优缺点
| 优点 | 缺点 |
| 降低项目风险、与用户紧密联系每次开发都是一种循环的、可预测的方向驱动产品开发 | 每一次迭代都有需求更改，测试需要频繁进行 |
2.6敏捷模型
2.6.1敏捷模型概念
敏捷模型可以帮助项目快速适应变更需求，主要目的促使项目快速完成，避免任何浪费时间和经历的事。
在敏捷模型中，需求被分别为许多可以增量开发的小部分，每个增量部分都是在迭代中开发的，每次迭代。
2.6.2敏捷模型特点
轻文档、轻流程、重目标、重产出
轻文档所以测试人员，不能适用表格编写测试用例，使用思维导图、探索性测试、自动化测试；测试人员多跟开发人员了解需求讨论设计，一起研究bug原因。
2.6.3敏捷模型例子——Scrum模型（迭代式增量软件模型开发）
三个角色：
产品经理：负责整理用户故事，定义商业价值、对其进行排序、指定发布计划
项目经理：召开会议、协调方案
研发团队：完成每一次迭代任务，交付产品
五个重要会议
发布计划会议：产品经理讲解用户故事，对项目进行估算和排序
迭代计划会议：项目团队对每一个故事进行任务分解，每一个任务都要有明确负责人，完成工时初估计
每日例会：每天项目经理召开会议，团队成员回答昨天工作，今天计划，以及遇到问题
演示会议：迭代结束之后，召开演示会议。展示成果
回顾会议：对本期迭代进行总结，制定改进计划
2.7测试模型
2.7.1V模型
v模型的出现是为了改进软件开发的效率和效果，瀑布模型的变种。
| 优点 | 缺点 |
| 明确标注了测试过程重存在的不同测试类型，清楚描述了测试阶段和开发过程的对应关系，提升测试质量和效率 | 仅仅把测试作为在编码之后的一个阶段，未在需求阶段介入测试，容易导致返工现象 |
2.7.2W模型（双V模型）
未将测试前置的问题在W模型中得以解决。
W模型增加了软件开发各个阶段的测试活动，W模型由两个V字型模型组成，分别代表测试和开发过程
程序、需求、设计同样需要测试，测试开发同步进行
| 优点 | 缺点 |
| 有利于尽早全面发现问题 | 需求、设计、编码等活动被视为串行的 测试和开发也保持着一种线性的前后关系 重流程，无法支持敏捷开发模型，当前软件开发复杂多变W模型不能解决测试管理面临的困惑 |