一、软件测试的基础概念

1.1 需求

在企业中，需求主要分为用户需求和软件需求~

用户需求：

可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务；用户需求一般是比较简略的，没有一定限制的（五花八门）~

举个例子：假如现在有一个声控灯的话，那么就可以有多个用户需求：声控灯是熊猫形状的、声控灯是黄金制作的、声控灯的声控范围就是在楼梯这一段距离......

由此可见,用户需求是五花八门的,不可以做为实现参考的依据（技术上、投入成本、收益......），需要进行用户需求的提取和分析才可以~

软件需求：

也叫做功能需求，该需求会详细描述开发人员必须实现的软件功能~

软件需求是测试人员进行测试工作的依据~

举个例子，解释用户需求和软件需求的不同点：

npy提出了一个需求：就想要喝奶茶（这个是用户需求）~

于是自己就可以取跑去买了，但是需要去和npy去反复的确认：是哪个门店的？是哪款奶茶啊？是热的还是冰的啊？要不要加一些料啊？（这个就是软件需求）~

1.2 测试用例

测试用例是测试人员执行测试的一组依据，测试人员在执行测试之前需要编写测试用例，测试用例的好坏与产品测试质量具有很大的关联关系~

测试用例要尽可能的广~

之后，就可以根据测试用例，一个一个的进行测试了~

如果没有测试用例，那么测试的时候仅仅只能靠着头脑去测、去记，到最后到底测试过哪些东西，自己也会搞混了~

所以说，测试用例的存在，可以引导进行有条不紊的测试，提高测试的覆盖率，防止出现 "漏测" 的风险~

当然，虽然说在测试中有一句话叫做 "不可能做到完全的测试"，但是测试人员要尽可能的去避免 "漏测"，保证线上不会出现明显的问题~

测试用例的出现主要解决了两个问题：测什么、怎么测~

测试用例是为了实施测试而向被测试的系统提供的一组集合，这组集合包括：测试环境、操作步骤、测试数据、预期结果等要素~

比如说，上面的第一个测试用例，就可以这样写：

可是，如果是针对某一个功能，需要去设计几十个甚至上百个测试用例，岂不是非常的麻烦~

实际上，现在的互联网企业，主要使用的是 "思维导图" 的方式去编写测试用例，如：

1.3 BUG

第一个BUG的由来链接——来自知乎

当且仅当规格说明是存在的并且正确，程序与规格之间的不匹配才是错误，即BUG~

当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现最终用户合理预期的功能要求时，就是BUG~

BUG实例：

比如说，在实现用户登录功能的时候，需求规格说明书上面明确规定：密码最短输入为6位，最长为15位；但是，实际上如果输入5位，也可以通过的话，那么这就是一个BUG~

比如说，向其他人分享资料，有的时候显示的是一个默认组件的样式，有的时候显示的具有图片；此时，分享的功能是正常的，但是发给其他人的时候展示的不好看，此时也可以提BUG的（但是在需求文档中可能不会提到）~

二、开发模型和测试模型

2.1 开发模型

开发模型，可以理解为开发流程/项目推进流程~

常见的开发模型有：瀑布模型、螺旋模型、增量模型、迭代模型、敏捷模型等等~

当然，也可以理解为软件的生命周期（软件从开始到结束的这一段时间），软件的生命周期可以分为六个阶段：需求分析、计划、设计、编码、测试、运行维护~

下面，来举一个例子更好地理解这六个阶段：

假如现在需要建造一个房子，那么房子的生命周期是什么？

需求分析阶段：

首先需要明确，为什么要建造房子~

房子是用于商用的还是民用的~

假如需要建造商用房，需要在哪里建造，建造多少层~

建造的投入与收入比例是否过大~

......

计划阶段：

什么时候开始建造房子~

房子什么时候动工，房子什么时候竣工~

大概需要一年的时候来建造，2023年1月1日开始动工，2024年竣工并投入使用~

......

设计阶段：

先出设计图，对房子有一个明确的布局，

如：谁来负责打地基，谁来负责建筑框架，谁来负责砌墙，谁来负责粉刷~

......

编码阶段：

脚踏实地的按照需求和计划一步一步的建造房子~

......

测试阶段：

等到房子交付的日期了，就要进行房子的验收测试，

如：房子有没有漏水，房子有没有偷工减料，房子是否按照规定的样子来建造~

......

运行维护阶段：

房子交房之后，用户也已经住进去了，后期也许会出现一些异常的情况，

如：房子漏水，墙皮掉落~

需要用户自己来进行维护~

通过上述建造房子的例子，就可以更好地理解软件的各个生命周期~

软件生命周期各阶段需要进行的部分内容如下：

如上，软件开发有它自己的整个生命周期，

其实软件测试也有着它自己的生命周期：它诠释了测试人员在软件整个生命周期里面，在各个阶段需要做的事情~

软件测试的生命周期 5个阶段：

需求分析 -> 测试计划 -> 测试设计与开发 -> 执行测试 -> 测试评估

ps：

需求分析：软件测试人员往往是最了解需求的人~

测试计划：测试人员也需要编写测试计划文档，明确标注了：有多少个测试人员，什么时候开始测试~

测试设计与开发：测试人员需要借助需求文档 + 技术文档来编写测试用例~

2.1.1 瀑布模型

瀑布模型

需要注意的是，瀑布模型不重视测试的，即：在编码及之前的几个阶段，都不涉及到测试的动作（当然，也是包含前面的测试 5个阶段）~

这就意味着，瀑布模型更看重于前面的几个阶段~

瀑布模型很容易的可以看出，它是一个线性结构：这就意味着前一个阶段结束之后，后一个阶段才会开始~

这就意味着，在最终测试的时候，发现的错误可能不仅仅是编码阶段的错误，前面阶段也可能会出现错误~

这就埋下了一个隐患：风险往往会延迟到后期的测试阶段才会显露，因而失去及早纠正的机会~

特别是，测试被后置，就说明需要把足够的时间留给测试，如果最后留给测试的时间有限，那么测试就可能不充分，最终就可能会把一些问题暴露给用户~

当然，瀑布模型的最大缺陷就在于：

由于瀑布模型是一个线性模型，所以项目需要实现的所有功能必须要在一个周期里面完成~

而如果是一个大型项目的话，每一个阶段都要经历很久，到最后用户在很晚之后才可以看到~

但是，我们不可能保证，在这一段时间内，用户的需求会不会发生变化（某一段时间很急需某个需求A，当时没有上线；等已经不需要需求A了，才上线）~

当然，瀑布模型在软件工程中占有着重要的地位，它是所有其他模型的基础框架，后面的其他模型都是在瀑布模型的基础上不断优化的~

瀑布模型适用场景：需求固定的小型项目（不能很好的迎接需求的变化）~

2.1.2 螺旋模型

螺旋模型

螺旋模型是在瀑布模型的基础上进行优化的，在每个阶段都增加了风险分析（把那条曲线拉直）~

发现有风险了，消除风险之后，会生成新的原型~

但是，这种模型一定是耗时耗力的，成本大，需要去找专门的风险分析人才~

螺旋模型适用场景：需求不确定，变化的可能性很大的大型项目~

2.1.3 增量模型、迭代模型

ps：计划之类的阶段就没有画出来了

增量模型：使项目进行模块化，每个模块都可以进行独立的开发和上线~

优势：产品可以在较短的时间内尽快的交付给用户去使用~

迭代模型：假如说一个产品有A、B、C三个功能，迭代模型会先完成这三个功能的基础版本，之后再经历一期又一期的迭代优化，直到这三个功能非常的优秀~

总之，增量模型和迭代模型是通常混为一谈的，但是其实它们是有区别的~

增量模型一定是逐块建造的，可以先开发功能A，也可以先开发功能B、功能C~

迭代模型一定是在基础的版本上进行更新优化，是精益求精的过程~

2.1.4 敏捷模型

在敏捷模型中，没有强调类似于其他模型中重流程的一些东西~

提出了《敏捷宣言》：通过身体力行和帮助他人来揭示更好的软件开发方式，形成了如下价值观：

敏捷宣言

ps：

敏捷模型强调了团队内部人员需要尽可能的进行高效的沟通~

强调了最终的标准就是：可交付的软件；至于开发软件过程中写了多少份文档并不是特别在乎，而在一个周期结束之后，需要给一个结果：或有一个新的功能，或有一个新的产品等等~

强调了须把客户的需求放在第一位，与客户之间需要有一个高效的协作；如：之前客户有需求A，以合同的形式告诉；后来客户有需求B，那就需要去实现需求B了~

强调了需要时刻响应变化，而不是和前面几个模型一样，一直不变，否则如果出现问题的话，开发的成本就会越来越高了~

即：敏捷宣言的特点是：轻流程、轻文档、重目标、重产出~

2.1.4.1 scrum模型

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

在 scrum模型里面，需要了解三个重要的角色和五个重要的会议~

三个角色

scrum 由产品经理、项目经理、研发团队三个角色组成~

产品经理：收集用户需求，转变成软件需求，推动研发团队去进行功能的开发~

项目经理：很多企业是没有项目经理这一角色的，此时由产品经理承担，其职责是在合理的周期内，去推进项目可以如期的进行；如在计划阶段规定了项目什么时候开始，什么时候结束，项目经理就需要检查到了这段时间计划的有没有完成，如果遇到项目问题就需要去协调解决问题，召开会议，为研发团队服务；可以简单的理解——项目经理就是催加班、催进度的~