2024-软件测试基础理论
1：软件测试的定义
1：什么是软件
操作系统，微信，京东 这些类似 控制 计算机硬件工作 的 工具
2：软件组成 【客户端，服务器，数据库】
1：客户端页面
2：代码服务器
3：数据服务器【数据库】
3：软件产生过程 产品怎么 0 到 1
1：需求产生 【产品经理 + 需求方】【需求方定制，刚需】【产品经理根据市场调研创造软件】
2：需求文档 【产品经理】
3：设计效果图 【UI设计师，画图，美工】
4：产品开发 【前端+后端】
5：产品测试 【测试】【验证产品，研发开发的产品和产品需求的产品是否一致】
6：部署上线 【运维】
4：什么是软件测试
使用技术手段验证软件是否满足使用需求
5：软件测试的目的
减少Bug，缺陷，保证软件质量
需求方面的缺陷，描述错误
UI设计不正确
产品开发不正确
整个环节都可能出现缺陷
6：测试的主流技能
1：功能测试 根据程序的功能，别人功能，购物车这些功能 功能测试主要验证程序的功能是否满足需求
2：自动化测试 代码或者工具自动读取用例数据去检测期望和预期是否一致
3：接口测试 代码或者工具对服务端提供的接口进行测试
4：性能测试 模拟多人使用软件，查找服务器缺陷
7：什么是接口
2：7种测试分类的区别
1：按照阶段划分
单元测试 针对程序的源代码进行测试，代码覆盖率，条件的覆盖率，分支的覆盖率【验证每一块积木是不是合格】
集成测试 接口测试，针对模块之间访问地址进行测试【验证积木之间组装，组装，接口测试】
系统测试 对整个系统进行测试【功能测试，兼容性测试，文档等测试 功能 + 非功能进行测试】
验收测试 内测，公测，使用不同人群来发掘项目缺陷 专业人士测试的局限性
2：按照代码可见度划分
1：黑盒测试 看不见程序源代码，功能 + 非功能测试 都是黑盒--系统测试，功能测试
2：白盒测试 能看到源代码，针对程序源代码测试--单元测试
3：灰盒测试 能看见部分固定的代码【接口，能看到接口请求参数调用和url这些，后台处理代码逻辑无法查看】--集成测试 接口测试
3：其他
性能测试：归属于专项测试
安全测试：归属于专项测试
3：质量模型的重点5项
开发模型：W，v
质量模型：一个优秀的软件应该具备哪些方面【衡量一个优秀软件的维度】
功能性：
性能：
兼容性：操作系统，浏览器，不同平台
【谷歌，IE，火狐，欧朋【欧洲市场】，苹果】
【操作系统：win4，win5，win10】
【手机：分辨率，品牌，网络，其他【应用】】
易用性：软件是否好用，是否顺手
【简洁：审美，经验】
【友好：标识文字，图片，颜色设计【暖色系】】
【流畅：操作起来比较流程】
【美观：】
可靠性： 性能相关测试可以测试出来
【经常出现无响应，不可靠】
【卡顿，响应时间慢】
【死机】
安全性：
【传输数据加密这些，存储，传输加密】
可维护性： 架构相关
【代码规范，便于维护】
可移植性： 架构相关
【网站数据迁移，网站数据扩容 】
4：测试流程6个步骤
1：需求评审 【看需求是不是完善，是否遗漏，确保各个部门需求理解一致】
2：计划编写 【项目测试计划，项目测试计划--谁来测试，怎么测试，测试时间，测试风险，需要哪些测试资源】
3：用例设计 【验证项目是否符合需求的操作文档】
4：用例执行 【项目模块开发完成开始执行用例文档实施测试】
5：缺陷管理 【提交，回归，关闭】
6：测试报告 【实施测试结果文档】
5：测试模板8个要素
1：什么是用例
用户使用的案例，模拟不同用户使用这个软件的场景
2：什么是测试用例
为测试项目而设计的执行文档 【为了更精准的执行 用户行为和场景】
3：测试用例的作用
1：防止漏测
2：实施测试的标准 【测试用例可能不是自己执行】
4：用例设计编写格式
用例编号 项目简称+下划线+模块+编号
用例标题 期望结果+测试点
项目/模块 所属的项目/模块
优先级 P0最高，用例重要程度
前置条件 执行用例前需要提交准备的步骤【前置操作】
测试步骤 描述操作步骤
测试数据 执行用例的关键数据
预期结果 执行用例得到的期望结果
6：测试用例设计方式——等价类 【对穷举场景设计测试点】
1：针对穷举场景设计测试点
2：能对限定边界规则设计测试点
3：能对多条件依赖关系进行设计测试点
4：能对于项目业务进行设计测试点
等价类解决场景--穷举
在所有测试数据中，具有某种共同特征的数据集合进行划分
有效等价类：满足需求的数据集合
无效等价类：不满足需求的数据集合
说明：根据相同特征数据集合进行划分
分类：有效等价类，无效等价类
步骤：
1：明确需求
2：确定有效和无效等价类 【划分等级】 【长度，类型，规则 来划分有效等价类和无效等价类】
3：提取数据编写测试用例
场景：针对需求大量数据输入，但是无法穷举测试用例的场景
1：输入框
2：下拉列表 【下拉比如很多选择：北京，上海，长沙等，选一个就行】
3：单选复选框
典型场景：页面输入框类测试
例子：比如验证 qq账号的1合法性 6-10位
有效等价类：8位自然数
无效等价类：4位自然数，12位自然数，8位非自然数
等价类编写案例：如下 正向2条，逆向8条
花瓶设计测试用例 质量模型
1：功能性
插花，装水，养鱼，种菜.....
2：性能
防摔，耐高温低温，耐压，耐酸碱性环境
3：兼容性能
4：易用性
防滑，便携，瓶口设计是否容易添加水
5：可靠性
6：安全性
是否有异味，是否含有有害物质
7：可维护
修补【花瓶某个位置漏了个洞，是否可以修复】
8：可移植性
不同文档下是否可以正常使用【太阳，冷】
9：属性【硬件】
长，宽，高，样式，材质，重量
7：测试用例设计方式——边界值 【对限定边界规则设计测试点】
1：边界范围节点
整好等于，刚好大于，刚好小于的边界值作为测试数据
上点：边界上的点【整好等于】
离点：距离上点最近的点【刚好大于，刚好小于】
内点：范围内的点【区域范围内的数据】 一般取居中的点
文本框，参数限制范围，最多 7 个边界值 用例
边界值设计用例步骤： 边界值 + 等价类 结合编写用例 长度交给边界值覆盖，类型校验交给等价类覆盖
1：明确需求
2：确定有效和无效等价类 类型校验
3：确定边界值范围
4：提取数据编写测试用例
等价类+边界值组合编写用例
1：明确需求：
长度 大于 0，小于等于30个字符
2：划分有效等价类和无效等价类 【只关注类型，长度交给 边界值】
这里没有类型划分，所有没有 等价类
3：划分边界
上点：0 30
离点：-1 1 29 31 【长度不能为 -1 ，所以这里 3个离点】
内点：15
一共 6 条用例
4：提取数据，设计用例 【转换成用例模板】
为空
30个字符
1个字符
29个字符
.....
等价类+边界值组合编写用例 1：明确需求： qq号码合法性，6-10位自然数 2：划分有效等价类和无效等价类 【只关注类型，长度交给 边界值】 有效：自然数
无效：非自然数 3：划分边界 上点：6 10 离点：5 7 9 11 内点：84：提取数据，设计用例 【转换成用例模板】 边界值 5 6 7 8 9 10 11
无效等级类：6-10位位非自然数 1234567A
常规测试：
账号类型测试
1：为空
2：已存在账号
测试用例优化： 优化离点
上点：必选【不考虑区间开闭】 测试等号
内点：必选【建议选择中间范围】 验证范围的连续性【测试程序连续性的范围，必测】
离点：内开外闭【考虑开闭区间，开区间选择内部离点，闭区间选择外部离点】 【优化离点】
10 < a <=20 (10, 20]
开区间：不包含
闭区间：包含
开区间指的是区间边界的两个值不包含在内； (a,b)
闭区间指的是区间边界的两个值包含在内；[a, b]
半开半闭区间，开区间一切的边界值不包括在内，闭区间的一边的边界值包含在内
20 <= b < 60 开内闭外 20都完了，再测21没必要，选择19就行，60都测完了再测61也没必要【优化重复的测试点】
上点：20 60
内点：30
离点：19【闭外：19和21选择19】 59【开内：59和61选择内是59】
针对有边界范围的测试数据输入的地方
大小，重量，最大，最小，至多，至少等
典型的就是输入框类型测试
8：测试用例设计方式——判定表 【对多条件限制依赖关系进行测试点设计】 【画表格，列出条件】
等价类边界值分析法主要关注单个输入类条件测试
并未考虑输入条件之间的各种组合，输入条件与输出结果之间有相互制约关系的测试 ---判断表
表格形式来表达多条件逻辑判断工具
条件桩：列出问题中的所有条件，列出条件的次序无关紧要
动作桩：列出问题中可能采取的操作，操作的顺序没有约束
条件项：列出条件对应的取值，所有可能情况下的真价值
动作项：列出条件项的各种取值下的采取的动作结果
规则：
判定表中贯穿条件项和动作项的一列就是一条规则
N个条件，每个条件取值两个，全组合就是2的n次方种规则
1：明确需求： 金额大于500，又未过期，发出批准单和提货单子 金额大于500，未过期，不准批准单和提货单子 金额大小于等于500，不论过期与否不准批准单和提货单子 过期情况下不论金额大小，不准批准单和提货单子，还需发出通知单 2：划分判定表
条件：
金额：大于500
过期：是否过期
操作：批准单，提货单，通知单 3：画判定表
4：转换成用例
使用场景：
1：有多个输入条件，多个输出结果，输入条件之间组合关系，输入条件和输出结果之间有 依赖 制约 关系
2：判定表一般适用于条件组合数量较少的情况【比如 4个 条件 以下】
条件组合很多使用因果图去解决
9：测试用例设计方式——场景发 【对项目业务点进行测试点设计】【学会查看和编写流程图】
说明：
场景法也叫流程图，用流程图描述用户使用场景，然后通过覆盖流程图路径来设计测试用例
意义：
用户使用角度：用户平时使用的不是单个功能，而是多个功能的组合
测试人员角度：平常测试的都是单个功能点测试，容易忽略多个功能点的组合测试
如上的 流程图：一共 6条测试用例
冒烟测试：【批量开始测试之前，执行业务正向用例，验证软件是否具备可测性】
测试软件主要功能，核心功能
冒烟测试 一般 开发测试，只验证核心
10：测试用例设计方式——错误推断发 【基于经验】
定义：
通过经验推测系统可能出现的问题
思想：
根据经验列举出可能出现的问题的清单，根据清单分析问题可能原因，推测发现缺陷
场景：
时间紧急任务量大时候，根据之前项目类似经验找出易出错的模块重点测试
时间宽裕通过该方法列出之前出现问题较多的模块再次进行测试
