[软件测试]：什么软件测试？如何设计测试用例？
目录
[软件测试]：概念篇
用户需求和软件需求
开发模型
软件的生命周期
瀑布模型
螺旋模型
增量模型和迭代模型
敏捷模型
Scrum模型
[软件测试]：BUG篇
[软件测试]：用例篇
设计测试用例的万能公式
特殊测试场景
弱网测试
安装卸载测试
设计测试用例的方法
基于需求的设计方法
1. 需求文档
1 注册账号
1.1 功能概述
1.2 用户角色
1.3 前置条件
1.4 输入
1.5 处理
1.5.1 基本事件流
1.5.2 扩展事件流
1.5.3 异常事件流
1.6 输出
1.7 后置条件
2. 结合万能公式，设计测试用例
具体设计方法
1. 等价类
2. 边界值
3. 正交法
4. 场景法
5.判定表法
6.错误猜测法
[软件测试]：概念篇
高频面试题
软件测试开发工程师和测试工程师的区别
相同点：都称为测试人员，对产品质量负责，保障产品的质量
不同点：测试开发比测试多了开发，开发是指开发测试效率工具，通过效率工具来提升测试效率和测试质量，比如自动化测试，性能测试就属于效率工具
测试岗位为什么还要学习开发知识？
测试人员也需要编写代码，如自动化测试，性能测试，开发测试效率工具等。测试人员需要能够看懂大啊，了解开发框架。
学好开发知识能够提高软件测试质量。通过查看代码中数据的走向能够更好的从代码层面去发现问题。
为什么走测试岗位而不走开发岗位？
用户需求和软件需求
-
用户需求：没有经过合理评估的一句话
-
软件需求：开发人员和测试人员执行工作的依据
-
用户需求不能直接作为开发和测试的依据，针对用户的需求，产品经理需要进行需求分析(技术可行性，市场可行性，成本投入和收益占比等)后才可转变为软件需求。
开发模型
软件的生命周期
需求分析--> 计划--> 设计--> 编码--> 测试-->运行维护
瀑布模型
需求分析--> 计划--> 设计--> 编码--> 测试-->运行维护
-
优点：每个流程只执行一次，线性的开发流程
-
缺点：可以运行的产品很迟才能被看到
-
适用场景：固定需求的小项目
螺旋模型
-
优点：引入原型和风险分析，原型就是快速构建的一个系统草图或简化模型，
-
缺点：项目中可能存在的风险性与风险管理人员的技术水平有直接关系，需要投入人员，资金等，可能导致项目成本太高
-
适用场景：规模庞大、复杂度高、风险大的项目
增量模型和迭代模型
-
增量模型：将一个大的需求拆分成多个小需求，每个需求单独开发测试
-
迭代模型：先构建整体框架，然后不断对项目进行迭代优化
敏捷模型
为了克服瀑布模型的缺点，就是在项目开发期间处理客户的变更请求以及合并这些变更所需的高成本和时间。在1990年代中期提出了敏捷开发模型。
敏捷宣言
个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化终于遵循计划
敏捷模型的四个特点：轻文档，轻流程，重目标，重产出
Scrum模型
Scrum模型是敏捷模型的一种，有三个角色和五个会议
三个角色
-
Product Owner(产品负责人)：整理需求，设定优先级和目标，对目标进行排序
-
Scrum Master(项目经理)：召开会议，协调项目，为开发团队服务
-
team(开发团队)：负责开发项目，完成交付
Scrum的开发是按周期进行的，每个周期称为一个Sprint，通常为1~4周
五个会议
[软件测试]：BUG篇
描述bug的要素：问题出现的版本，问题出现的环境，问题出现的步骤，预期结果，实际结果，bug级别
bug的基本要素包括但不限于这些。
高频面试题
与开发产生争执怎么办？
先检查自身，bug是否描述清楚
站在用户角度考虑并抛出问题
bug定级要有依据
提高自身技术水平，不仅能提出问题，最好也能给出解决方案
bug评审
bug评审需要有三个代表：测试代表，开发代表，产品代表。bug评审主要解决两个问题：如何处理bug，分析bug原因
[软件测试]：用例篇
测试用例的要素：用例编号，测试环境，测试数据，测试步骤，预期结果，实际结果。这是基本要素，还可以考虑其他要素
-
笔试时编写测试用例题，需要按照excel表格的方式来答题，会涉及到测试用例的要素
-
面试时回答测试用例题，按照思维导图的方式回答，不会涉及到测试用例要素
设计测试用例的万能公式
功能测试+界面测试+性能测试+兼容性测试+易用性测试+安全测试
-
功能测试：验证软件功能是否符合需求文档
-
界面测试：测试UI界面符合文档需求且设计规范
-
性能测试：测试软件在不同负载下的响应速度，稳定性
-
兼容性测试：测试软件在不同环境下是否满足需求文档
-
易用性测试：测试用户能否简单，快速的使用产品
-
安全测试：找出软件的漏洞，保证数据安全
特殊测试场景
弱网测试
弱网测试是模拟网络信号差，延迟高，丢包率高的环境，验证软件在不稳定网络下的表现，确保用户体验和系统稳定性
一般用fiddler来模拟弱网环境。
fiddler使用教程：抓包工具Fiddler的下载、安装、配置、基本使用_fiddler下载-CSDN博客
安装卸载测试
对于需要部署在本地的软件，进行安装，更新，卸载测试。如：验证安装流程，检查兼容性，确保升级正常，验证卸载干净，保障系统稳定性
设计测试用例的方法
基于需求的设计方法
以注册邮箱账号为例
1. 需求文档
1 注册账号
1.1 功能概述
用户可以通过填写邮箱信息在平台注册个人用户。
1.2 用户角色
匿名用户。
1.3 前置条件
无。
1.4 输入
序号 栏位名称 栏位说明 长度 类型 备注 1 姓名 必填，录入个人姓名 6~15 位 字符型 2 电子邮箱 必填，录入电子邮箱 字符型 3 密码 必填，输入的密码隐藏*号显示 6~15 位 字符型 4 确认密码 必填，输入的密码隐藏*号显示 6~15 位 字符型 5 验证码 必填，录入验证码 字符型 6 注册 注册操作 操作型 1.5 处理
1.5.1 基本事件流
用户选择注册；
系统展现用户协议界面，并请用户确认是否同意用户协议：
若用户不同意协议，系统禁止用户注册；
若用户同意协议，用户进行注册信息填写；
用户填写注册信息（注册个人需填写：姓名、电子邮箱、密码、确认密码、验证码）；
用户提交注册信息；
系统提示用户并向用户注册的电子邮件地址发送一封含有激活信息的电子邮件。系统并提示用户，若未收到激活邮件，可使用注册的邮箱和密码登录系统后再次发送激活邮件；
用户可执行激活操作，直接跳转至注册邮箱门户页面；
用户通过接收到的电子邮件中的激活信息激活账号，用户注册完成，流程结束。
1.5.2 扩展事件流
用户注册并激活成功后，第一次登录平台时，提示用户完善信息。
1.5.3 异常事件流
若用户未收到激活邮件，可在登录界面录入电子邮件及密码后，再次发送激活邮件。每次发送的激活邮件，仅在发送邮件后起24小时之内有效，超过24小时后需重新发送激活邮件。
1.6 输出
用户注册成功。
1.7 后置条件
该模块为用户登陆等的前置模块。
2. 结合万能公式，设计测试用例
具体设计方法
1. 等价类
依据需求将输入划分为若干个等价类。从等价类中选取一个测试用例，如果通过代表这一类等价类测试通过，这样可以用较少的测试用例覆盖更多的功能
-
有效等价类：符合需求文档合理数据，应该被正确处理
-
无效等价类：不符合需求文档的非法数据
2. 边界值
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值是对等价类划分的补充
-
边界值：给定数据的左边界和右边界，比如：[6~15]，6和15就是边界值
-
次边界值：若边界值为有效等价类中的数据，则次边界值就是无效等价类的边界，若边界值是无效等价类中的数据，则次边界值是有效等价类的边界
结合等价类和边界值对测试用例中的姓名进行分析
3. 正交法
正交表的结构：因素，水平，行数，如最简单的L4(2^3) 正交表，4代表有4行，2表示有两种水平1和2，3表示有3个因素
因素：对指标的影响条件，通常是正交表中的一列
水平：因素对应的可选项
正交表的性质
-
每一列中，不同的数字出现的次数相等，一列中每个数字出现的次数是相同的
-
任意两列中数字的排列方式齐全且均衡
正交法的目的是为了减少用例数目，用尽量少的用例覆盖输入的两两组合
可以根据正交表设计测试用例，更合理，更简洁。
4. 场景法
通过模拟用户的实际操作流程，设计测试用例，覆盖正常流程，异常流程和边界情况。
-
基本流：按照用户预期方式完成操作的流程，没有出现异常情况
-
备用流：用户在操作过程中遇到异常或错误，系统需要正确处理这些情况
比如：
确定基本流和备用流后，编写测试用例：
-
基本流：点击注册入口，同意协议，输入正确的信息，点击注册，成功激活
-
备用流：点击注册入口，不同意协议，重新点击注册入口，同意协议，输入正确的信息，点击注册，成功激活
-
备用流：点击注册入口，不同意协议，点击注册入口，不同意协议，输入错误的信息后重新输入正确的信息，点击注册，成功激活
5.判定表法
通过具体的方法能够将测试用例设计的更加完整和规范。需求中会存在各种各样的场景，比如：用户输入的账号中包含admin字符，或者通过内部链接进入注册页面，提交注册按钮，成为管理员，否则无法成为管理员。
我们可以根据这个需求设计判定表,确定输入条件和输出条件，找出输入条件和输出条件的关系
根据判定表设计测试用例
6.错误猜测法
错误猜测法是对被测试软件设计的理解，过往经验以及个人直觉，推测出软件可能存在的缺陷，从而针对的设计测试用例的方法。
错误猜测法特别依赖个人能力。