一.名词解释(需求.bug,测试用例)
1.需求
定义：满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。
用户需求：甲方提出的要求，如果没有甲方，那么终端用户使用产品时必须要完成的任务，比如王者荣耀没有甲方。
软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。
大多数公司在进行软件开发的时候，产品经理会把用户需求转化为软件需求，开发人员和测试人员工作的直接依据 就是软件需求
测试人员要依据软件需求来编写测试用例
具体设计测试用例的时候，首先需要搞清楚每一个业务需求对应的多个软件功能需求点，然后分析出 每个软件功能需求点对应的多个测试需求点，然后针对每个测试需求点设计测试用例。
过程如下，业务（用户）需求—>软件功能需求点—>测试需求点—>测试用例
-
从软件功能需求出发，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的
测试覆盖率 -
对于识别出的每个测试需求点，需要采用
具体的设计测试用例的方法来进行测试用例的设计
2.bug
BUG定义：
- 当且仅当规格说明是存在的并且正确，程序与规格说明之间的 不匹配才是错误。
- 当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的 功能要求时，就是软件错误。
ps:
- 需求文档/软件需求文档/规格说明书
- 软件错误/软件缺陷/Bug
3.测试用例
定义： 测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含四个要素：测试环境、操作步骤、测试数据、期望结果等要素。
测试用例解决了两大问题：测什么，怎么测。
为什么要设计测试用例？
- 围绕着软件需求来设计测试用例，保证覆盖率
- 解决了重复测试的问题，原则：测试用例避免用后即弃
- 不设计测试用例，测试的盲目性导致大量冗余测试
重复测试：
- 提bug=>开发人员对bug修复后=>对bug进行回归验证
- 版本迭代：对新版本的历史功能也需要进行测试（自动化测试）
eg-验证我们的首页是否正确：
标题：注册网易邮箱
- 测试环境：chrome103.XXX版本(windows11，64位操作系统)—–硬件+版本+软件+版本
- 测试数据：邮箱地址，密码，手机号，验证码
- 测试步骤：打开谷歌浏览器，打开网易注册网址，输入邮箱地址，密码，手机号，发送验证码并输入验证码，勾选用户协议，点击注册。
- 期望结果：展现注册成功的结果页面
法律标准：测试用例包含测试环境、操作步骤、测试数据、预期结果等要素。
事实标准：工作中通常使用脑图来编写测试用例！（思维导图）
二.软件的生命周期模型
6个阶段：需求分析，计划，设计，编码，测试，运行维护
- 需求分析：收集用户需求，分析用户需求是否是合理的（市场/技术可行性）=>软件需求文档（产品经理编写）
- 计划：确定耗时耗力，什么时候开始，什么时候结束
- 设计：将需求细化成一个个任务，各种图，进行技术设计（哪些接口，哪些技术）=>软件设计文档
- 编码：开发人员按照需求文档和设计文档来进行编码
- 测试：测试人员参考测试用例来执行测试
- 运行维护：项目上线后对产品进行线上的维护
维护：
- 修复性维护：对项目中未发现的问题进行修复
- 完善性维护：对功能进行完善（可能之前比较简略）
- 预防性维护：居安思危，避免出现极端情况
三.开发模型
1.瀑布模型
开发模型中的瀑布模型很像很像软件的生命周期模型：
顺向:上一阶段的结果为下一阶段的开始,要逐步下行
逆向:因为测试在后面,测试发现问题,要逐步回溯,寻找问题
特点：线性的开发流程
缺陷（2个）：后置到测试才发现前期的错误，所以要从前期的错误点开始
重新执行开发流程。为了及时给甲方交付软件，时间一定，预留给测试部分的时间缩短，这可能会导致测试不充分，从而将缺陷直接遗留给用户。适用于需求固定的一些小项目。
但是瀑布模型是所有其他模型的基础框架。
2.螺旋模型
螺旋模型引入全流程的风险分析,每次分析完都会生成一个新的原型.
风险分析能力是和产品遗留的风险是成反比的
缺点:时间拉长,人力和资金消耗
使用场景:规模宏大,复杂度高,风险度高
3.增量模型
对用户友好:没实现一个功能就让用户及时体验,而非就等总体上线.
4.迭代模型
先开发一个基础版本(包含功能A,B,C),但是A,B,C的功能都比较简陋,接下来我会继续在基础版本上对A,B,C功能就行迭代优化.
5.敏捷模型
四句宣言想表达敏捷模型的特点：
轻流程，轻文档，重目标，重产出
ps:
scrum中的三个角色：
产品经理：收集用户的需求，编写需求文档，对产品负责的人
项目经理：什么时候该完成到项目的哪一个阶段，协调项目，催作业的人
研发团队：开发人员，测试人员，UI设计人员等
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
