一.了解软件测试的基础概念

1.需求

什么是需求？

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

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

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

软件需求是测试人员进行测试工作的基本依据。（用户需求不可以直接作为测试/开发工作的依据! ! ! 用户的需求不一定是正确的、合理的，需要进行用户需求的提取和分析~）

如果说用户需求是合理的，而且有开发的必要产品经理就会将用户需求转变成软件需求文档

---

2.测试用例

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

假如我们现在要测试这样的一个输入框，我们该怎么测试?能够设计出哪些测试用例
 
输入一个空内容，检查结果
输入一个关键词，检查结果是否跟关键词相关
输入C语言/c语言，检查结果是否相同
输入字符串检查结果是否符合预期
输入带有空格的关键词，检查结果
是否存在SQL注入的情况
…

想一个测试一个，尤其是软件功能比较复杂的时候，仅仅通过头脑风暴来记住测试肯定是不科学的同时，测试用例的存在能够提高测试覆盖率，如果不设计测试用例来进行测试， 可能会造成漏测的风险，测试人员要尽可能的去避免漏测，保证线上不会出现明显的问题。

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

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

---

3.BUG

当且仅当规格说明(软件需求文档)是存在的并且正确，程序与规格说明之间的不匹配才是错误。

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

---

二.开发模型和测试模型

也可以理解为 开发流程/项目推进 流程（软件的生命周期）。

---

软件测试贯穿于软件的整个生命周期

软件测试人员需要执行的测试 任务/动作 也是分阶段的

软件测试的生命周期：需求分析——测试计划——测试设计与开发——执行测试——测试评估。（测试设计开发：测试人员需要借助需求文档+技术文档来编写测试用例）

1.瀑布模型

线性结构∶意味着前一个阶段结束后一个阶段才能开，导致风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。

测试被后置，需要保留足够的时间给测试，否则导致测试不充分，缺陷直接暴露给用户

一个最大缺陷在于，可以运行的产品很迟才能被看到瀑布模型是不能够很好的迎接变化

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

---

2.螺旋模型

在瀑布模型的基础上增加了风险分析生成新的原型（原型图)

螺旋模型增加了风险分析阶段一定是耗时耗力，会专门招聘风险分析人才

成本高，团队需要耗费一定的资金和时间去招聘风险分析人才

适用场景:需求不确定，变化的可能性很大的大型项目

---

3.增量模型和迭代模型

增量模型：将项目进行模块化，使其每个模块都能够进行独立的开发和上线。

优势︰产品能够在较短时间内尽快的交付给用户去使用

迭代模型：假如说有一个产品包含五个功能 A B C D E，迭代模型会先完成这五个功能的基础版本，会再经历一起一起的迭代优化，直到这五个功能非常的优秀。

4.敏捷模型

• 个体与交互重于过程和工具
• 可用的软件重于完备的文档
• 客户协作重于合同谈判
• 响应变化重于遵循计划

敏捷宣言的解读：强调团队内部人员尽可能的进行高效的沟通敏捷模型最终的标准就是︰可交付的软件

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

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

scrum：

了解三个重要的角色和五个重要的会议

三个角色：产品经理+项目经理+研发团队

产品经理：定义商业价值，负责收集用户需求，把用户需求整合为软件需求，推动研发团队进行研发，对产品负责。

项目经理：在一定时间内检验团队是否完成工作，召开会议，协调项目，为研发团队服务。

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

收集用户需求，在需求池中评估需求，展开以下会议：

• 会议1：需求发布会议

产物：确定本次迭代要是实现的需求

• 会议2：迭代计划会议

需求拆分成一个个任务，明确每个任务对应的责任人，初步评估工时

• 会议3：每日会议

会议中每个研发团队成员需要回答三个问题:

1. 昨天做了什么
2. 今天要做什么
3. 遇到了什么问题

每日会议结束之后的产物：可交付的软件

• 会议4:演示会议

每日会议结束之后的产物︰用户的需求

• 会议5:回顾会议

scrum 模型中每个迭代周期为1 ~ 4 周，通常情况下为一周。

---

三.软件测试模型

V模型

左边和右边是一一对应的，其中单元和集成测试一般都是开发人员根据详细和概要设计文档来测试的，而系统测试是根据需求分析和系统文档来由测试人员测试的。

特点：明确了测试有不同类型，而且每个类型和前期的开发工作之间的对应关系。

缺陷：测试后置

---

W模型

优点：测试从一开始就介入（软件测试贯穿于软件的整个生命周期），有利于尽早发现问题

缺点：开发和测试虽然是同步的，但是仍然存在着前后的线性关系，不支持敏捷模型。

---

四.BUG篇

1. 如何合理的创建 bug

创建 bug 的要素：问题的版本，发现问题的环境，发现问题的步骤，预期结果，实际结果等等。

问题的版本：QQ浏览器 xxx 版本
发现问题的环境：windows10家庭版
发现问题的步骤：…
预期结果：用户可以快速通过输入框找到想要的标签
实际结果：没有可以用的输入框，用户只能挨个儿查找，对用户不友好

---

2. bug 级别

• 崩溃

• 严重

• 一般

• 次要

为什么要介绍 bug 的优先级？
 
bug 的等级跟优先级有一定关系
出现线上问题进行问题定级，定级会涉及到对应的惩罚范围

---

3. bug 的生命周期

• New：新发现的 Bug，未经评审决定是否指派给开发人员进行修改。
• Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。
• Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。
• Rejected：如果认为不是Bug，则拒绝修改。
• Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改。
• closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。
• Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。

4. 跟开发产生争执怎么办

1. 先检查自身，是否 bug 描述不清楚

2. 站在用户的角度去考虑问题，可以反问：如果你是用户，你能够接受这样的实现吗?

3. BUG 定级要有理有据, bug 等级对于开发人员来说是非常敏感

bug等级越严重，说明程序员在实现的实现出现的问题比较严重，就可能上升到工作态度问题?开发能力问题?

4. 不光能提出bug，最好也要能提出解决方案

5. 组织bug评审

邀请代表人参加：产品代表、开发代表、测试代表

bug评审会议里要解决以下问题:
1)如何修改bug
2)如何避兔类似的问题发生