✏️作者：银河罐头
📋系列专栏：JavaEE

🌲“种一棵树最好的时间是十年前，其次是现在”

需求

需求的定义

满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。

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

软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。

大多数公司在进行软件开发的时候会把用户需求转化为软件需求，开发人员和测试人员工作的直接依据 就是软件需求。

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

测试人员眼中的需求

需求是测试人员开展软件测试工作的依据。

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

为什么需求对测试人员如此重要

从软件功能需求出发，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率

对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计

如何深入理解需求

测试人员在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好 时机。 只有真正理解了原始业务需求之后，才有可能从业务需求的角度去设计针对性明确，从终端用户的使用 场景到端到端的覆盖率较高的测试用例集。

测试用例

定义

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

测试用例解决了两大问题：测什么，怎么测。

举例：登录 QQ

测试环境：windows 系统

操作步骤：输入账号，密码，点击登录按钮

测试数据：账号，密码

预期结果：登陆成功

为什么要有测试用例

测试用例提高测试人员的工作效率/降低测试人员工作的重复性问题

测试用例是建立自动化的基础

软件错误（BUG）的概念

bug 定义：当且仅当规格说明是存在的并且正确，程序与规格说明之间的 不匹配才是错误。

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

软件的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。

6 个阶段：需求分析、计划、设计、编码、测试、运行维护。

需求分析: 分析需求是否合理，需求是否完整。

计划：谁开发，谁测试，开发多久，测试多久。

编码：写代码。

测试：测试报告。

运行维护：如果线上有问题，此时测试人员需要协助开发定位问题 + 解决问题。

开发模型

瀑布模型

特点：线性的

优点：每个阶段做什么，产出什么非常清晰

缺点：风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。

适用的项目：小型的项目适合这种模型。

螺旋模型

优点：每个阶段都会进行风险分析，避免一些线上问题的发生。

缺点：风险分析可能分析错，人力财力的投入。

适用项目：适用比较大的项目，风险比较多。

增量、迭代

增量是逐块建造的概念，例如画一幅人物画，我 们可以先画人的头部，再画身体，再画手脚……

而迭代是反复求精的概念，同样是画人物画，我们可以 采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。

敏捷

个体与交互重于过程和工具

可用的软件重于完备的文档

客户协作重于合同谈判

响应变化重于遵循计划

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

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

scrum

scrum里面的角色

scrum由**product owner(产品经理)、scrum master(项目经理)和team(研发团队)**组成。

product owner：负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布 计划，对产品负责。

scrum master ：负责召开各种会议，协调项目，为研发团队服务。

研发团队：则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

(team 由许多人构成，后端开发，前端开发，UI 设计师，测试)

迭代开发

与瀑布不同，scrum将产品的开发分解为若干个小sprint(迭代)，其周期从1周到4周不等，但不会超过4 周。参与的团队成员一般是5到9人。每期迭代要完成的user story是固定的。每次迭代会产生一定的交付。

scrum的基本流程

测试模型

v 模型

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

优点：测试被划分成很多个类型。

缺点：测试人员介入太晚，发现问题时机太晚。

W 模型

特点：开发一个 v ，测试一个 v.

优点：测试人员尽早介入了需求

缺点：开发人员和测试人员一定程度上还是串行的。不能拥抱变化，不能适用于敏捷。