目录

1. 初识软件测试 

1.1 什么是软件测试

1.2 软件测试和软件开发的区别

1.3 软件测试与调试的区别

2. 什么是需求

3. 认识测试用例

3.1 测试用例的概念 

3.2 为什么要设计测试用例

4. 关于BUG的常见问题

4.1 什么是BUG

4.2 如何描述一个BUG

4.3 BUG的生命周期 

4.4 BUG的级别  

4.5 因为BUG和开发人员发生冲突的解决方法 

5. 软件开发和测试的生命周期

6. 开发模型

6.1 瀑布模型

6.2 螺旋模型

6.3 增量模型，迭代模型

6.4 敏捷开发模型 

7. 测试模型

7.1 V模型

7.2 W模型（双V模型）

8. 一个优秀的软件测试人员所具备的素质

1. 初识软件测试 

1.1 什么是软件测试

软件测试就是验证软件的功能是否满足用户的需求，通俗的讲就是找BUG，找软件的缺陷

软件测试的特点：软件测试只是一个样本实验，具有不可穷尽性

1.2 软件测试和软件开发的区别

• 本质不同

软件测试：软件测试是验证软件功能是否满足用户的需求

软件开发：软件开发是将用户的需求采用编码的方式制作成软件（小程序，网站等） 

• 深度广度不同 

软件测试：技能要求比较广泛（业务能力，测试手段和工具的使用，用户模型分析和理解等），但技能要求专业度不高

软件开发：技能要求的专业度高，但技能要求不广泛（如C++开发，Java开发等会一个即可）

1.3 软件测试与调试的区别

• 目的区别

软件测试：是验证软件是否实现了用户的需求

软件调试：是软件开发人员验证软件是否实现了他想让软件实现的功能

• 角色区别

软件测试：是由开发人员（白盒测试）和测试人员共同完成的

软件调试：仅仅由开发人员完成

• 阶段区别

软件测试：贯穿了整个软件开发的生命周期（需求，计划，设计，编码，测试，运行维护）

软件调试：仅仅是在开发阶段

2. 什么是需求

需求就是用户的期望或者满足合同（文档，标准，规范）所需要的条件或者权限

需求包含了两个方面：

1. 用户需求：一般比较粗略的概括
2. 软件需求：从用户需求转化而来，是用户需求的细化和具体实现细节

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

软件测试人员如何深入了解需求？

1. 从需求分析阶段就开始介入了解需求
2. 站在用户的角度

3. 认识测试用例

3.1 测试用例的概念 

测试用例就是向被测试系统发起的一组集合，包含测试环境，测试数据，测试步骤，预期结果

示例：

3.2 为什么要设计测试用例

1. 测试用例可以衡量需求覆盖率
2. 测试用例可以复用
3. 测试用例具有借鉴意义
4. 测试用例可以用于回归测试
5. 防止遗漏测试的需求 

4. 关于BUG的常见问题

4.1 什么是BUG

当且仅当程序规格说明书（软件需求）存在并合理，如果软件功能和软件需求不符合，就说是软件错误（BUG）

当软件需求不存在，用户需求存在并合理，软件功能和用户功能不符合，就说是软件错误

4.2 如何描述一个BUG

对于如何描述一个BUG，可以从以下几点来进行描述

1. 测试版本（代码提交版本号）：方便开发人员快速定位BUG出现的位置
2. 测试环境：不同环境下测试的结果可能不同，如不同的浏览器，不同的操作系统，不同的设备
3. 测试步骤：测试数据和执行测试的详细步骤，方便开发人员复现BUG
4. 实际结果
5. 预期结果
6. BUG产生时的log日志，错误截图等附件

4.3 BUG的生命周期 

一个BUG从无到有的各种状态

问题：如果发现了一个BUG，开发人员修改了，但是测试人员又复现了这个BUG，是哪些原因可能导致的？

1. 测试环境不一样
2. 开发人员没有理解到，没有修改成功
3. 开发人员修改后没有提交代码到远程，测试人员仍然测试的是旧代码 

4.4 BUG的级别  

1. 崩溃：系统崩溃，不能运行，死循环，数据库死锁，资源分配不均等
2. 严重：服务器可以使用但是不稳定，继续使用会产生严重的错误，如数据库插入错误，威胁到用户的安全等
3. 一般：系统可以稳定的运行，次要的功能没有实现，提示语句不完整，弹出框没有关闭按钮等不影响用户的使用
4. 建议（次要）：建议性的，提示信息重叠，界面排版不符合用户使用习惯，颜色不符合软件使用场景等

4.5 因为BUG和开发人员发生冲突的解决方法 

• 检查自己的BUG描述，看看是否自己将BUG描述清楚
• 可以从用户角度考虑，说服开发人员
• BUG的定级要有理有据，符合公司规范
• 测试人员要不断提高自己的专业技能和业务水平
• 找产品经理去讨论问题的解决方案 

5. 软件开发和测试的生命周期

软件开发的生命周期 

软件测试的生命周期（软件测试的流程）

1. 需求分析：验证需求的合理性与正确性，细化需求，根据需求提炼测试点
2. 测试计划：确定测试范围，目表，测试人员，测试环境，时间等
3. 测试设计：开发测试用例
4. 测试执行：执行测试，提交BUG
5. 测试报告： 本次迭代的测试情况进行分析和总结，如写了多少测试用例，执行了多少，发现了多少BUG，修改了多少，剩余BUG的解决方案，测试的覆盖率

6. 开发模型

6.1 瀑布模型

特点：阶段性强，每一个阶段比较独立，看重前期的需求分析和后期的测试阶段

缺点：测试在编码后才开始介入，导致前期的问题到后期才发现，失去错误补救机会

6.2 螺旋模型

螺旋模型适合项目庞大，前期风险大，不是很明确的项目 

特点：强调每一个迭代的测试质量和风险分析，抗风险能力很强

缺点：风险管控人力物力投入多，成本较大 

6.3 增量模型，迭代模型

比如同一个系统四个模块A，B ，C，D要花两周开发完

• 增量模型：第一周开发A,B模块，第二周开发C，D模块
• 迭代模型：第一周开发A，B，C，D的基础功能模块，第二周开发A，B，C，D的其他功能模块

特点：抗风险能力强

说明：通常开发将两个模型结合使用，在迭代的基础上使用增量

6.4 敏捷开发模型 

特点：轻文档，轻流程，重目标，重产出，拥抱变化（用户可以随时更改需求）

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

scrum里的角色

scrum由产品经理（product owner），项目经理（scrum master），研发团队（team）组成

• PO：将用户需求转化为user story
• SM：管理整个团队，负责召开各种会议，协调项目，为研发团队服务
• Team：由各种技能的人员组成，通过紧密协同，完成每一次迭代的目标，交付产品

scrum的基本流程

1. 发布计划会议：产品经理收集需求形成userstory，讲解，排出本迭代需要进行开发的userstory形成sprint backlog
2. 迭代计划会议：分析userstory，把userstory分解成一个个任务，分配开发人员，指定开发计划
3. 每日例会：团队成员回答昨天干了什么，遇到的问题，今天的计划
4. 产品演示会议：甲方，用户演示产品，PO把不足的地方收集整理形成新的user story
5. 回顾计划会议：回顾整个迭代过程，把不足的地方找出，在下一次迭代过程中改进，优化迭代流程

7. 测试模型

7.1 V模型

特点：每一个阶段独立性强，左边每一个阶段是右边测试阶段的依据，和右边每一个测试阶段一一对应

缺点：瀑布模型的变种，编码后才进行测试，前期的错误后期才发现，会失去错误及时补救机会

7.2 W模型（双V模型）

特点：每一个阶段独立性强，测试一开始就介入，可以保证前期的问题及时发现和纠正，测试和开发是并行的

缺点：每一个阶段都是串行的过程，一个阶段完了之后就会进行下一个阶段

V模型和W模型都不支持敏捷开发 

8. 一个优秀的软件测试人员所具备的素质

• 综合能力：沟通能力，编程能力，学习能力，文字描述能力
• 自动化开发能力：开发自动化脚本和工具的能力
• 编写测试用例的能力：能够设计出高效的发现缺陷和保证产品质量的优秀测试用例
• 具有探索性思维，发散思维，对软件测试有浓厚的兴趣并且对工作有责任感和压力