软件测试--概念篇

名词解释

1、需求的概念

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

①用户需求 简单理解为甲方提出的需求，若没有甲方，那么终端用户使用产品时必须要完成的任务。该需求一般比较简略。
②软件需求 或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能
【多数公司会在软件开发时将用户需求转为软件需求】

---

【需求分析需要考虑的问题：】

【产品经理编写需求文档】

2、测试用例

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

设计测试用例原因？

围绕着软件需求来设计测试用例，解决了重复测试问题。

测试用例原则

【避免用后即弃】

3、什么是bug – 软件缺陷

当且仅当规格说明是存在且正确，程序与规格说明之间的不匹配才是错误的
当程序没有实现最终用户合理预期的功能要求时，就是软件错误

软件的生命周期

从软件产品设想开始到软件不再被使用而结束的时间

【分为六个阶段】

开发模型

1、瀑布模型

start -->需求分析–>计划–>设计–>编码–>测试–>end
特点： 线性的开发流程
缺点： ①风险后期测试阶段才显露，失去早纠正的机会！②留给测试的时间不充裕，从而把缺陷遗留给用户 ③开发周期延迟

适用场景： 需求固定的小项目

2、螺旋模型

【基于瀑布模型中在每一步后加风险分析】
【适用于 规模庞大、复杂度高、风险大的项目】
【缺点：项目开发时间拉长。人力资金花费变大】

3、增量模型

【较短时间中可以交付功能】

4、迭代模型

先开发一个版本，但是功能比较简陋，接下来继续在基础版本上对功能进行迭代优化

5、敏捷模型（主流）

【特点：轻流程、轻文档、重目标、重产出】

敏捷模型下的scrum模型

三个角色、五个会议

五个会议： 发布会议、迭代计划会议、每日例会、演示会议、回顾会议

软件测试的生命周期

bug

如何描述一个bug

应有的内容：
0、标题
1、发现bug的版本
2、发现bug的环境
3、发现bug的步骤
4、期望的结果
5、实际的结果
6、其他（bug类型，bug等级）

bug的等级

【各个公司bug定级文档不一样】
崩溃 --很少见，基本不可见
严重 --比较少见
一般
次要 --实际工作中见的较多的级别

bug的生命周期

和开发产生争执怎么办？**

测试模型

V模型**

W模型（双V模型）