什么是需求？测试用例？bug？软件开发模型和测试模型

一、需求的概念

什么是需求？

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

产品经理把用户需求转化为软件需求。

从软件测试人员角度看需求

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

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

过程：业务需求→ 软件功能需求点→ 测试需求点→ 测试用例

对于软件测试人员来说，从软件功能需求出发，不会遗漏测试需求，测试覆盖率高，比较有条理。

二、测试用例的概念

什么是测试用例？

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

测试用例解决的两大问题

测什么，怎么测。

三、软件错误（BUG）的概念

什么是bug？

如果软件需求规格说明书存在，并且合理，软件功能不符合软件需求规格说明书，我们就说是BUG。
如果软件需求不存在，如果用户的需求存在并且合理，软件功能和用户需求不符合，我们就说是软件错误。

如何描述一个BUG？

1.版本号(代码）

2.测试环境

①APP
硬件环境：手机（IOS苹果，Android，vivo，小米，华为，诺基亚，OPPO，三星等手机的不同型号）
软件环境 ：IOS系统，鸿蒙系统，Android系统等每一个系统的版本号
②Web系统
浏览器：edge，IE，Chrome，火狐，Opera，360，夸克，蜂鸟，via，Safari
浏览器的版本

3.测试数据

4.测试步骤

5.错误结果

6.预期结果

7.附件，截图，错误日志等

BUG的级别

• 崩溃：系统已经无法运行，严重阻碍了测试和开发工作。
• 严重：系统可以运行，但是不稳定，继续运行，会造成严重的问题。
• 一般：不影响系统的稳定运行，次要的功能没有实现，或者有错误。
• 次要：建议性的BUG，系统的基本功能都已经实现，只是影响用户的体验。

四、软件开发模型

五大开发模型：瀑布模型（Waterfall Model），螺旋模型（Spiral Model），增量模型，迭代模型，敏捷模型。

1.瀑布模型（Waterfall Model）

优点：串行的，每个阶段独立；强调早期的需求分析，以及后期的测试工作。
缺点：测试介入晚，前期的问题后期才会发现，导致错误失去了及时纠正的机会。

2.螺旋模型（Spiral Model）

优点：注重每一个迭代风险分析，适合于项目比较庞大，前期风险大的项目。
缺点：风险分析需要投入专业的人力资源，成本比较高。

3.增量模型，迭代模型

增量模型：按照一定的增量去开发系统的功能。如：一个系统开发 A B C D 四个模块， 2周之内完成。第一周完成 A B 模块，第二周完成 C D 模块。
迭代模型：第一周完成A B C D四个模块的基本功能，第二周在上一周基础之上完成剩余的较为复杂的功能。

优点：抗风险能力强。

4.敏捷模型（重点）

拥抱变化，不会单纯去注重文档，注重用户和研发团队之间的及时沟通和交流；注重在短期内交付一个高质量的可用的软件，而不是各种文档。

Scrum模型

角色：

• 产品经理PO（product owner）：①收集用户需求；②把用户需求转化为user story。
• 项目经理SM（scrum master）：保证整个敏捷流程的实施，负责召开各种会议,统计项目进度。
• 研发团队ST（team）：各种技能的人组成，开发人员，测试人员等。

基本流程：

• 产品发布会：PO负责讲解 user story，进行排序，确定出本期迭代的user story 形成 Sprint backlog（本期迭代的内容）。
• 迭代发布会：细化user story，分解任务，分配任务，确定任务完成的时间。
• 开发阶段每日站会：昨天干了什么，遇到的问题，今天的计划。
• 产品演示会议：给甲方演示开发完的产品（软件系统），甲方会提出意见，PO整理后形成user story，加入下一次迭代。
• 回顾会议：回顾一下本期迭代，哪儿做的好，哪儿做的不好，不好的地方下期迭代进行改进，优化敏捷流程。

核心：

测试工作

五、软件测试模型

测试模型：V模型，W模型

1.V模型

特点：串行，瀑布模型的变种。

左边的每一个阶段和右边每一个测试阶段一一对应，左边的每一个阶段是右边每一个阶段的依据。

缺点：测试介入比较晚，编码后才开始，导致前期问题，后期才发现，错误失去了最好的解决时机；不支持需求的改变。

2.W模型

双V模型，开发的每一个阶段，测试的每一个阶段分别构成V字型。

特点：测试和开发同时进行，测试在需求阶段就开始介入，有利于风险控制。

测试的每一个阶段和开发的每一个阶段一一对应。

缺陷：串行，不能够适应需求的变化；无法适应敏捷开发。