目录
第一章、测试基础
1-1 阶段目标及路线
阶段目标：能独立完成软件的功能测试。
测试基础：20% 软件及测试相关知识
测试设计：40% 如何进行测试
缺陷管理：10% 测试不通过如何处理
项目——黑马头条：30% 项目实战
1-2 测试相关概念
⚠️学习目标！！：
① 能复述软件测试的定义
使用技术手段验证软件是否满足需求。
② 能说出7种测试分类的区别
按阶段划分（4种）：单元测试、集成测试、系统测试、验收测试。
按代码可见度划分（3种）：黑盒测试、白盒测试、灰盒测试。
③ 能说出质量模型的重点5项
功能、性能、兼容、易用、安全。
④ 能说出测试流程的6个步骤
需求评审、测试计划、用例设计、用例执行、缺陷管理、测试报告。
⑤ 能说出测试模版8个要素
用例编号、用例标题、项目/模块、优先级、前置条件、测试步骤、测试数据、预期结果
【补充】
用例设计：
① 什么是测试用例？
执行测试执行的文档。
② 用例的作用？
防止漏测、执行标准。
③ 设计方法。
解决穷举问题（等价类划分、）
1-2-1 什么是软件测试（概念、过程、目的）？
1、什么是软件？
软件：控制计算机硬件工作的工具。
软件产生过程：
需求产生→需求文档→设计效果图→产品开发→产品测试→部署上线。
什么是软件测试？
使用技术手段验证软件是否满足使用需求。
软件测试目的：
减少缺陷，保证软件质量。
1-2-2 测试主流技能
（1）功能测试：主要验证程序的功能是否满足需求。
非功能测试：兼容性等。
（2）自动化测试：使用代码或工具代替手工，对项目进行测试。（属于功能测试）
（3）接口测试：使用代码（unittest、pytest）或工具（jmeter、postman）对服务端提供的接口进行测试。
（4）性能测试：模拟多人使用软件，查找服务器缺陷。
功能测试、自动化测试、接口测试、性能测试
就业方向（一）：功能测试+接口测试
就业方向（二）：功能测试+性能测试
就业方向（三）：功能测试+web自动化
1-2-3 测试分类
（1）按测试阶段划分：单元测试、集成测试、系统测试、验收测试。
① 单元测试：针对程序源代码进行测试。
② 集成测试：又称接口测试，针对模块之间访问地址进行测试。
③ 系统测试：对整个系统进行测试包括：功能、兼容、文档等测试。
④ 验收测试：主要分为：内测、公测，使用不同人群来发掘项目缺陷。
（2）按代码可见度划分：黑盒测试、
① 黑盒测试：源代码不可见。UI功能可见。
② 灰盒测试：部分源代码可见。功能不可见。 看见部分代码（接口），针对程序接口进行测试。
③ 白盒测试：全部代码可见。UI功能不可见。
1-2-4 质量模型
质量模型：功能性、性能、兼容性、易用性、可靠性、安全性、可维护性、可移植性。
【案例】：需求：
1、开发一款网络游戏（要求：10个主功能）
2、游戏支持web（浏览器）端、APP端
3、游戏上线后预计每日，20W用户玩家在线。
功能性：需求：10个功能
测试：功能数量为10个、功能正确实现、错误处理情况。
性能：需求：① 预估每日在线人数20W
测试：① 服务器每秒处理请求数；② 服务器硬件配置是否满足。
兼容性：浏览器：谷歌、ie、火狐、苹果、欧朋
操作系统：win系统：win7/8/11
手机：分辨率、品牌、系统、网络、其他。
易用性：简洁、友好、流畅、美观
可靠性：无响应（出现无响应）、卡顿（响应时间慢）、死机（系统崩溃）
安全性：
可移植性：
可维护性：
1-2-5 测试流程 （6个步骤）
需求评审→计划编写→用例设计→用例执行→缺陷管理→测试报告。
需求评审：确保各部门需求理解一致。
计划编写：测什么、谁来测、怎么测
用例设计：验证项目是否符合需求的操作文档。
用例执行：项目模块开发完成开始执行用例文档实施测试。
缺陷管理：对缺陷进行管理的过程。
测试报告：实施测试结果文档。
1-3测试用例
1-3-1 用例（什么是用例、作用）
1、什么是用例 case？
用例：用户使用的案例。
2、测试用例
是为测试项目而设计的执行文档。
3、测试用例的作用
① 防止漏测。
② 实施测试的标准。
1-3-2 用例格式说明
测试用例编写8大要素
① 用例编号 项目_模块_编号
② 用例标题 预期结果（测试点）
③ 项目/模块 所属项目或模块
④ 优先级 P0最高（正确、成功的都为P0） P0~P4
⑤ 前置条件 要执行此条用例，有哪些前置操作
⑥ 测试步骤 描述操作步骤
⑦ 测试数据 操作的数据，没有的话可以为空
⑧ 预期结果 期望达到的结果
【案例】：qq用例练习
需求：qq登录（4条）
1、账号为空
2、账号未注册
3、密码为空
4、密码错误
第二章、用例设计方法
⚠️学习目标：设计测试点
1、2-1 能对穷举场景设计测试点（等价类划分）
2、2-2 能对限定边界规则设计测试点（边界值）
3、能对多条件依赖关系进行设计测试点（判定表）
4、能对项目业务进行设计测试点（场景法）
其他-错误推测法
2-1 等价类
有效等价类：满足需求的数据集合。
无效等价类：不满足需求的数据集合。
等价类测试步骤：
① 明确需求
② 划分等价类（有效、无效）（通过 长度、类型、规则 进行划分）
③ 提取数据编写测试用例
适合场景：
输入框、下拉框、单选复选框。
【案例1】：验证qq账号的合法性
要求：6-10位自然数
步骤：
1、明确需求。 6-10位自然数
2、划分。 有效 8位、无效（4位自然数、12位自然数、8位非自然数）
3、提取数据设计用例。 根据2中的划分，可以知道有4个测试用例。
【编写的测试用例如下：】
【案例2】验证某城市电话号码正确性
要求：
1、区号：空或者是三位数字
2、前缀码：非“0”且非“1”开头的数字
3、后缀码：四位数字
步骤：
1、明确需求
2、划分
分析出来一共10条测试用例：
【编写的测试用例如下：】
【作业——面试题】：
目标：花瓶设计测试用例
要求：10条测试用例以上
提示：参考质量模型。
功能、性能、兼容、易用、安全、可靠、可维护、可移植。
答：
功能性：插画、装水、养鱼、种菜...
性能：防摔、耐高温、耐低温
易用性：防滑、便携
属性（硬件）：长、宽、高、样式、材质、重量。
可移植：不同的温度下是否正常使用
可维护性：修补
2-2 边界值
1、边界范围节点：
选取正好等于、刚好大于、刚好小于边界的值作为测试数据。
上点：边界上的点（正好等于）
离点：距离上点最近的点（刚好大于、刚好小于）
内点：范围内的点（区间范围内的数据） ，一般取居中的点。
【步骤】
1、明确需求
2、确定有效和无效等价类 （类型：等价类；长度：边界值）
3、确定边界范围值
4、提取数据编写测试用例
【使用场景】
（1）在等价类的基础上针对有边界范围的测试数据输入的地方（重点关注边界）
（2）常见词语描述：大小、尺寸、重量、最大、最小、至多、至少等修饰词语。
（3）典型代表：有边界范围的输入框类测试。
【案例1】：
需求：通过边界值法验证标题长度的合法性。
要求：标题长度大于0，小于等于30个字符。
【案例2】：
需求：通过边界值法验证qq号码的合法性。
要求：6-10为自然数
【测试用例优化】：
结论：7个优化 为5个点
上点：必选（不考虑区间开闭）
内点：必选（建议选择中间范围）
离点：开内闭外（开区间选择内部离点，闭区间选择外部离点）
例子： 10<a<=20 使用开区间表达 (10,20]
上点：10,20
内点：15
离点：开内 11，闭外 21
例子： 20<=a<60 使用开区间表达 [20,60）
上点：20, 60
内点：40
离点：开内 59，闭外 19
为什么内点必测呢？
答：因为内点是用来验证范围的连续性的。
对上述【案例2】进行优化，如下所示：
2-3 判定表
2-3-1 定义：
判定表：是一种以表格形式表达多条件逻辑判断的工具。
组成：
① 条件桩：列出问题中所有条件，列出条件的次序无关紧要。
② 动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束。
③ 条件项：列出条件对应的取值，所有可能情况下的真假值。
④ 动作项：列出条件项的各种取值情况下应采取的动作结果。
规则：
判定表中贯穿条件项和动作项的一列就是一条规则。
假设有n个条件，每个条件的取值有两个(0,1)， 全组合有2^n 种规则。
使用场景：
有多个输入条件、多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系。
判定表一般适用于条件组合数量较少的情况。（比如4个条件以下）
【案例1】：
案例：验证“若用户欠费或关机，则不允许主被叫” 功能的测试。
用例编写：
【案例2】：
需求：
（1）如果金额大于500元，又未过期，则发出批准单和提货单。
（2）如果金额大于500，但过期了，则不发批准单与提货单。
（3）如果金额小于等于500元，则不论是否过期都发出批准单核提货单。
（4）在过期的情况下不论金额大小，还需要发出通知单。
【画出判定表】：
【编写测试用例】
【案例3】：
规则：
（1）输入的第一列字符必须是A或B
（2）第二列字符必须是一个数字
（3）如果第一列字符不正确，则给出信息L
（4）如果第二列字符不正确，则给出信息M
（5）如果两列字符输入正确，则修改文件成功。
【判定表】
【编写测试用例】
2-4 场景法（流程图）
流程图：使用标准图形和箭头来表达程序或业务的走向。
【练习——画流程图】：
需求：
练习1、用户名为admin，密码为：123456，输出：登录成功
练习 2、登录、搜索商品、添加购物车、去结算、支付；如果支付成功，则提示下单成功，否则提示支付失败。
场景法：
场景法，也可以叫流程图法，是用流程图描述用户的使用场景，然后通过覆盖流程图路径来设计测试用例。
意义：
用户使用角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用。
测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试。
2-5 错误推测法
冒烟测试：在批量测试之前，执行业务正向用例，验证软件是否具备可测性。
错误推测法：
通过经验推测系统可能出现的问题。
场景：① 时间紧，任务量大时，根据之前项目类似经验找出易出错的模块重点测试。
② 时间宽裕，通过该方法列出之前出现问题较多的模块，再次测试。
时间：2025年02月25日、2025年02月26日
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
