软件测试概念篇

什么是软件测试

测试人员验证软件特性是否满足用户需求，软件测试人员不仅要看出软件特性是否符合用户需求，还要指出不符合的地方

软件特性：功能、界面、兼容性、性能…

软件功能

1. 是否可以正常运行
2. 是否满足用户需求

软件调试和软件测试区别

1. 目的
   1. 软件调试：开发人员确保软件完成了他想让软件实现的功能
   2. 软件测试：测试人员验证软件实现了它该实现的功能
2. 角色
   1. 软件调试：开发人员
   2. 软件测试：测试人员（黑盒测试），开发人员（白盒测试，单元/集成测试）代码相关
3. 阶段
   1. 软件调试：开发阶段
   2. 软件测试：贯穿了整个软件开发的生命周期【需求阶段，计划阶段，设计阶段，编码阶段，测试阶段，执行及运行发布阶段】
4. 难易
   1. 软件开发：技能广度小，但是专业度比较高
   2. 软件测试：技能要求广度大，但是专业度比较低

一个优秀的测试人员需要具备的素质

1. 综合素质
   1.1. 快速学习能力
   1.2. 沟通能力、文字能力
   1.3. 开发能力
2. 优秀的设计测试用例的能力
3. 掌握自动化技术
4. 责任感和压力

示例：登录功能的测试要点

1. 账户名、密码、邮箱
2. 二维码
3. 第三方登录
4. 人脸
5. 声音
6. 虹膜
7. 收集验证码
   1. 刷新，输入图片上的字符
   2. 向右滑动
   3. 数字运算
   4. 成语填空
8. 用户名密码大小写反过来
9. 输入的用户名不存在
10. 输入的用户名错误，密码正确
11. 输入的用户名正确，密码错误
12. 账户冻结，注销，禁用，有违规操作
13. 多地登录，多设备登录
14. 弱网
15. 多次输入错误，账户被锁定
16. 失去时效的验证码，错误的验证码
17. 密码明文加密

软件测试点能否完全检测

软件测试只是一个样本测试，没有办法进行一个完整测试但要保证常用功能和核心流程的正确性

工具

1. 接口：soupUI，postman，jmeter
2. 自动化测试：Python，Java，selenium，unittest，testNG
3. 性能测试：loadrunner，jmeter
4. 抓包：Charles，Fiddler
5. APP测试：appium，Macaca

衡量软件测试的结果——需求

用户需求：甲方提出的要求【终端用户使用的产品必须要完成的任务。该需求一般比较简略】
软件需求：也叫做功能需求，会详细描述开发人员必须实现的软件功能

客户需求会被转化为软件需求，开发人员和测试人员工作的直接一句就是软件需求
软件需求是测试人员进行测试工作的基本依据

测试用例

要素

测试用例： 是向被测试系统发起的一组集合，这个集合包含测试环境，测试数据，测试步骤，预期结果，标题，重要性，功能模块，优先级，是否手工

举例

正确的用户名：admin
正确的密码：root
用以上正确的用户名和密码可以成功登陆邮箱
测试环境：win11 Edge 105.0.1343.33
测试数据：admin root
测试步骤：

1. 打开Egde浏览器，输入URL
2. 输入用户名和密码
3. 点击登录按钮（Enter），触发登录

预期结果：登陆成功或者页面跳转

什么是BUG

1. 当且仅当软件需求说明书存在且合理，软件的功能不符合需求规格说明书，就是软件错误（BUG）【软件需求规格说明书也就是软件需求文档】
2. 如果软件需求规格说明书不存在，那么用户的需求存在并且合理。软件的功能和用户需求不相符合就是软件错误（BUG）

软件开发的五大模型和软件测试的两大模型

软件开发的生命周期

需求分析——计划——设计——编码——测试——运行维护【软件从产品的设想开始到软件不再使用而结束的时间】

1. 需求分析
   1.1. 市场分析【有没有需求量，是否存在大量的需求用户】
   1.2. 投入和收益的占比
   1.3. 技术分析【技术是否i可以实现以及实现的难度】
2. 计划
   2.1. 什么时候开始
   2.2. 什么时候结束
   2.3. 耗时多久
3. 设计
   3.1. 将需求细化成一个个任务，进行技术设计【要涉及哪些接口，用到哪些框架，采用哪些技术…】
4. 编码
   4.1. 开发人员参考需求文档和技术文档进行编码
5. 测试
   5.1 测试人员要参考测试用例来执行测试
6. 运行维护
   6.1. 修复性的维护，对项目中未发现的问题进行修复
   6.2. 完善性维护：对功能进行完善
   6.3. 预防性维护：居安思危，为了避免产品在线上出现一些意想不到的问题

开发五大模型

瀑布模型（Waterfall Model）

• 特点：每一个阶段比较独立，串行，注重前期需求分析，后期系统测试
• 缺点：测试介入晚，导致软件前期的问题到了后期测试阶段才发现，失去了错误及时修正的机会，不响应需求的变化
• 适应场景：需求固定的小型项目

螺旋模型

• 特点：注重质量管理，每一次迭代都会进行风险评估
• 缺点：每次迭代风险分析投入人力，资源，管理成本，成本比较高
• 适应场景：需求不确定，变化的可能性很大，项目庞大复杂，风险性较高的项目

增量、迭代模型

增量模型

• 将项目进行模块化，使其每个模块都能够进行独立的开发和上线
• 优势：产品能够在较短时间内尽快的交付给用户使用，抗风险能力比较强

迭代模型

• 迭代模型会完成各个功能的基础版本，会再经历一期一期的迭代优化，直到各个功能非常的优秀
• 优势：产品抗风险能力比较强

敏捷模型

thought works

• 特点：轻文档、轻流程，重目标、重产出，重响应变化
• 经典的敏捷流程：scrum 流程

scrum里的角色

1. PO【Product Owner】产品经理：负责收集需求，转化成 用户需求【User Story】
2. SM【Scrum Master】项目经理：负责保证这个敏捷流程的实施
3. ST：各种技能的研发人员组成，测试，研发，UI…

scrum基本流程

1. 发布计划会议：PO把整理好的 User Story 进行讲解，排优先级，找出优先级高的组成本次的迭代内容，形成 Sprint Backlog
2. 迭代计划会议：SM 和 ST 人员一起把本期要迭代的需求进行分析，任务分配和时间估算
3. 每日站会：昨天做了什么，遇到的问题，今天的计划
4. 产品演示：给客户演示产品，讲解，把不足的地方和客户提出的修改意见整理成 User Story 放到下一期迭代
5. 回顾会议：回顾本次的敏捷流程，把不好的地方找出来，下次迭代改进，优化敏捷流程

测试两大模型

V 模型

• 特点：左边每一个阶段和右边的阶段一一对应，左边的每个阶段是右边测试的每一个阶段的依据，串行【瀑布模型的变种】
• 缺点：测试在编码之后进行，测试介入晚，前期的问题后期才发现，导致前期问题不能及时解决

W模型（双V模型）

• 特点：开发一个V，测试一个V。软件开的过程和软件测试同步进行，保证项目前期的问题能够及时被发现，串行
• 缺点：不支持需求的变化所以不支持敏捷开发