软件测试（概念篇）
前言
从这篇博客开始，我们将开始正式学习测试，在开始第一次软件测试之前，我们需要先了解软件测试的一些基本概念。
这些基本概念将帮助我们更加明确工作的目标，以便于更快的融入到测试团队中去
在这里我们将回答以下问题：
什么是需求
什么是bug
什么是测试用例
开发模型和测试模型
配置管理和软件测试
衡量软件测试结果的依据 - 需求
在理解需求之前，我们需要了解一件事：软件是如何诞生的？
上市之后，就是我们见到的软件了。
下面，我们就来了解需求是什么？
需求的概念
需求：满足用户的期望或正式规定的文档（合同、标准、规范）所具有的条件和权限。
需求：包含用户需求和软件需求。
用户需求通常是简略的。【对应着上述中的 “用户的期望”】
软件需求，是用户需求的细化，以及具体的实现细节，最后演变成文档。【正式规定的文档】
这里提出一个很简单的问题：用户需求 和 软件需求 之间的关系，是怎样的？
软件需求 是 用户需求转化而来的。
又或者说：软件需求 是 用户需求 的 进一步的细化和分解。
案例 - 用户需求 - 平台支持邮箱注册
从软件测试人员角度看需求
需求是测试人员进行软件测试工作的依据。
在具体设计测试用例的时候，首先需要搞清楚每一个业务需求对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，然后针对每个测试需求点设计测试用例。
过程如下:
业务需求—>软件功能需求点—>测试需求点—>测试用例
以“用户登录”为例，来阐述下整个过程
通过这样的方式，我们就可以有条不紊的完成我们职责。
而且，漏掉某一项测试的概率也会非常小。
既然漏掉了，再根据这个 按照需求制作的表格，一个个查证，很快就能锁定，并且补上对应测试。
为什么需求对软件测试人员如此重要
从软件功能需求出发，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率
对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计
其实还有一个非常重要的点：如何快速理解需求 ？
在未来的工作，通过参加公司的需求讨论会就行了，一般都会阐述这个需求的背景。
就类似公司一个公开的 学习 + 培训 的“课程”。
测试用例的概念
测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
测试用例解决了两大问题：测什么，怎么测
案例
大家乍一看，可能就会觉得，这个测试用例很正常。
唯一缺点：就是不够详细。
是的，没有错！
测试用例，就如同 上图给标题一样“正确的用户名密码可以成功登录邮箱”，它是一个非常模糊 和 片面的说法。
而我们通过将其划分成 4 个部分，来将这个测试用例进行初步的划分，
而且，划分出的这几个部分，其实也是可以进行细分的！
划分成一个个测试点
测试用例 和 测试点，两者其实是一样的。
只不过测试点，更加详细和具体。
软件错误（BUG）的概念
只有当软件需求规格说明书（软件需求文档）存在并且合理，软件的功能不符合规格说明书，就是软件错误（BUG）。
如果软件需求规格说明书不存在，而用户的需求存在，并且合理，那么，软件的功能 和 用户的需求 不相符合，就是软件错误（BUG）。
简单来说：软件需求文档 和 用户的需求，就像是一个“圈 / 规则”。
跳出这个圈 / 打破这个规则，你的代码就是有问题的（存在BUG）。
记住！无论是哪种方式，一定要是合理的。
不合理，即代表代码是无法实现出 整个软件 / 软件上的某项功能 ，
以后在工作的时候，就经常会遇到 用户提出的一些不合理的需求。
通常 用户提出的需求，都是会存在 一些 看似美好的想法，但是实际上却实现不了。
那么，就会导致做出来的东西 与 期望中的效果，完全不同！
开发模型和测试模型
软件开发的生命周期
软件开发的生命周期，其实就是一个软件从无到有的过程：
需求分析 >>
计划（如何进行开发软件，规定一个范围，一个方向） >>
设计（正式开始设计软件的具体功能…） >>
代码实现 >>功能测试 >>
（测试通过了）进行线上的运行维护
开发的五大模型
瀑布模型（Waterfall Model）
瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。
优点：
1、强调开发的阶段性；
2、强调早期计划及需求调查
3、 强调产品测试。
缺点：
1、依赖于早期进行的唯一一次需求调查，不能适应需求的变化；
2、由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；
3、风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。
瀑布模型的一个最大缺陷在于：
可以运行的产品很迟才能被看到。
这会给项目带来很大的风险，尤其是集成的风险。
因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶
段的工作大面积返工，业界流行的说法是：“集成之日就是爆炸之日”。
尽管瀑布模型存在很大的缺陷，
例如，在前期阶段未发现的错误会传递并扩散到后面的阶段，而在后面阶段发现这些错误时，可能已经很难回头再修正，从而导致项目的失败。但是目前很多软件企业还是沿用了瀑布模型的线性思想，在这个基础上做出自己的修改。例如细化了各个阶段，在某些重点关注的阶段之间掺入迭代的思想。
在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有足够的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接遗留给用户。
简单来说：瀑布模型，一旦是开始项目操作，中途是没有 “刹车 和 回炉” 的操作。（非常头铁）
之所以称为 瀑布模型，你见过瀑布的水逆流而上吗？或者说，你见过瀑布的水，流到一半静止的吗？
采用 瀑布模型，是没有“后悔药”可以吃的。
螺旋模型（Spiral Model）
一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。
这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重要性就不言而喻了。
优点：
1、强调严格的全过程风险管理。
2、强调各开发阶段的质量。
3、提供机会检讨项目是否有价值继续下去。
缺点：
1、引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高
的要求。这需要人员、资金和时间的投入。
增量模型 && 迭代模型
增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。
增量开发模型，鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。
因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作。
增量通常和迭代混为一谈，但是其实两者是有区别的。
增量是逐块建造的概念，
例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……
而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。
简单来说：
假设我们要实现一个系统，该系统需要 4个模块 ABCD。
增量模型： 将4个模块分为两个部分【AB，CD】，先完成 AB 模块，然后再来完成 CD 模块。【使每部分的开发联系起来】
迭代模型：先将4个模块的基础 框架搞定，然后在这个基础上，继续完善4个部分的一些代码。【你可以理解为盖房子，先打好基础，然后再一层层完善。】
敏捷模型
2001年，以Kent Beck、Alistair Cockbum、Ward Cunningham、Martin Fowler等人为首的“轻量”过程派聚集在犹他州的Snowbird，决定把“敏捷”(Agile)作为新的过程家族的名称。
在会议上，他们提出了《敏捷宣言》我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工怍，我们形成了如下价值观。
个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者。
核心思想：轻流程，轻文档，重目标，重产出，响应变化，
由敏捷宣言可以看出：
敏捷其实是有关软件开发的社会工程(Social Engineering)的。
敏捷的主要贡献在于他更多地思考了如何去激发开发人员的工作热情，这是在软件工程几十年的发展过程中相对被忽略的领域。
敏捷开发有很多种方式，其中 scrum(敏捷开发) 是比较流行的一种。
软件测试模型
V 模型
特点：
1、左边每一个阶段 和 右边的阶段，都是一一对应的
2、左边的每个阶段是右边测试每一个阶段的依据
3、它和瀑布模型一样，是串行执行。
其实 测试V模型 就是 开发的瀑布模型的变种。
因此，瀑布模型的缺点，V模型也有。
1、就像瀑布一样，水（阶段）只能往下流（只能顺着执行，不可能回头）。
2、测试介入晚，前期的问题，后期才发现，导致前期问题不能及时解决
W 模型
W 模型，也称作双V模型。
看图说话：就是两个 V 模型 组成的。
特点：
1、开发一个V，软件测试一个V【双卡双待】
换个说法：软件开发 和 软件测试 是 同步进行的。
这样做，就解决了 V 模型的缺陷：W模型能够及时发现，并处理前期出现的问题。
缺点：
它仍然是 串行执行的过程，它是不支持 需求的变化。
也就是说：W模型是不支持敏捷开发的。