软件测试 - 基础理论篇

一、测试基础及分类

1.1.测试基础

软件测试：使用技术手段验证软件是否满足需求（为了发现软件中的问题而执行软件的过程，这个问题不仅包含程序的bug，还包括设计的缺陷）
软件测试目的：是软件必有缺陷，提前找到软件中的问题并修复降低商业风险

1.2.测试技能

需要掌握的技能
1.app、web项目实现功能测试
主流程+异常流程
2.使用工具（postman）或代码实现接口测试
3.使用工具或代码实现性能测试
4.使用工具（jemeter）或代码实现自动化测试（UI、接口）

1.3.测试分类

测试分类
1.按测试阶段划分：
单元测试（原代码测试）
集成测试（接口测试，模块间或系统间的接口进行验证）
系统测试（对整个系统进行功能、UI、兼容、文档【环境部署文档】测试）
验收测试（内测：α测试，公测：β测试，候选：r）
2.按代码可见度划分：
黑盒（看不见源代码，对程序功能进行测试，系统测试）
灰盒（看见部分代码，主要对程序集成测试）
白盒（看见全部代码，对程序源代码测试，单元测试）
3.测试策略
冒烟测试：在大规模执行测试前，先对程序主流程（主功能）进行测试，保证程序具有可测性

小结：
单元测试和白盒测试属于功能测试
集成测试和灰盒测试属于接口测试
系统测试和黑盒测试属于功能测试
自动化测试属于功能测试
性能测试和安全测试属于专项测试

1.4.测试方向

1.功能+接口
2.自动化+接口
3.性能+接口
测试的主要工作，工作流程

二、模型

2.1.质量模型

测试应该考虑哪些方面？

功能性：功能满足需求（产品+用户）
性能效率：接口请求响应速度快不快，高并发压力测试（同一时间段多人访问会不会崩溃）
兼容性：与主流硬件和软件是否兼容（UI是否错位：考虑设备或浏览器内核与分辨率，与其他软件的兼容性：安装后对电话，微信，支付宝等有没有影响）
易用性：注册流程是否复杂，有没有长辈版（文字放大）
可靠性：性能和功能应用可靠（不会出现瘫痪，闪退等情况）
安全性 ：信息在传输或存储过程的安全程度（如密码有没有加密，会不会被他人随意获取）
可维护性：文档和注释（语雀 ）
可移植性：很容易安装到其他设备上

例：花瓶设计测试用例
功能：能装水吗？会不会漏水？密封性好不好？能装多少水？能插花吗？花瓶瓶口多大？
性能：防摔吗？从1米高空掉落下来会碎吗？
兼容性：能装土吗？能装固体吗？能装热水吗？
安全性：有破损吗？会伤到手吗？装热水会不会烫手？易燃易爆吗？
易用性：什么材质？好看吗？什么形状？什么颜色？

2.2.测试模型~W模型

三、测试流程

需求评审测试人员的职责
1.读懂需求（需求清晰，没有疑惑）
2.找出错误（确认需求文档完整，准确，能够指导后期工作）
3.给出建议（对需求不合理的地方给出修改意见）
需求评审的形式
1.会议形式 2.邮件形式
需求评审人员
1.产品 2.开发 3.测试 4.UI 5.运营等

四、测试用例

4.1.测试用例 - what

用户使用的场景案例

4.2.测试用例 - why

目的：
1.防止漏测
2.制定实施测试的标准，记录前置和后置条件，测试该功能的步骤，要求让别人可以按照步骤执行复现，因为测试用例编写分为设计用例人员和执行用例人员，可能你写用例，别人来执行

4.3.测试用例编写格式

用例标题：预期结果（测试点）

五、测试方法

总结
设计测试用例的步骤
1.明确需求

①.测试目的
②.测试条件：长度（使用边界值划分，所有都要测试空）、类型（数字、非数字【包含字母、包含特殊字符、包含中文、包含空格】）、规则

2.划分等价类

①.有效
②.无效

3.确定边界值

上点、内点、离点（开内必外优化）
与等价类进行合并

4.提取数据编写测试用例

有效尽量一条包含多个，无效一条包含一个

5.1.等价类划分 - 解决穷举问题

说明：在所有测试数据中，具有某种共同特征的数据集合进行划分
分类：有效等价类（满足需求的数据集合，【长度、类型、规则】），无效等价类（不满足需求的数据集合）
键盘能输入的类型：数字、字母、中文、符号、空格、空
步骤：1.明确需求 2.确定有效和无效等价类 3.提取数据编写测试用例
技巧：1.正向一个用例尽量全部覆盖 2.逆向一条覆盖一条
适用场景：针对需要有大量数据测试输入，但没法穷举测试的地方：输入框，下拉列表，单选框，复选框

5.1.1.案例1 - qq号

5.1.2.案例2 - 验证某城市电话号码的正确性

非数字可以拆分为【包含字母，包含符号，包含中文，包含空格，空】数字【整数，小数，正数，负数】

5.2.边界值划分 - 解决边界限制问题

说明：对等价类划分的补充（数字类型的）
边界范围节点：上点（边界上的点，正好等于），离点（距离最近的点，刚刚大于，刚刚小于），内点：（区间范围内的点）
步骤：1.明确需求 2.确定有效和无效等价类 3.确定边界范围值 4.提取数据编写测试用例
技巧优化：离点：开内闭外：开区间选择内部离点，闭区间选择外部离点
适用场景：有边界范围的输入框，常见词语描述【大小，尺寸，重量，最大，最小，至多，至少】

5.2.1.案例1 - 标题长度

(0,10]，上点：0,10，内点：5，离点：-1,1,9,11，开内闭外原则去除-1和9，得到0,1,5,10,11，有效：1,5,10 无效：0,11

5.2.2.案例2 - qq号

5.3.判定表 - 解决多条件间依赖问题

定义：是一种以表格形式表达多条件逻辑判断的工具
组成：
条件桩：列出所有可能的条件，次序没有约束
动作桩：列出所有可能的操作，次序没有约束
条件项：列出条件对应的取值，真假
动作项：列出条件项各种取值下采取的动作结果
规则：
判定表中贯穿条件项和动作项的一列就是一条规则
假设有n个条件，每个条件的取值有两个，全组合有2^n个规则
设计用例步骤：
1.明确需求 2.画判定表（①.列条件桩和动作桩，②.填写条件项，对条件进行全组合，③.根据条件项的组合确定动作项，④.简化，合并相似规则，相同动作）3.根据规则编写测试用例
使用场景：多个输入条件，多个输出结果，输入条件组件有组合关系，输入条件和输出结果之间有依赖关系（一般适合条件组数较少的情况，4条及以下）（大于4个条件的可以使用正交表和因果图实现）

5.3.1.案例1 - 订购单检查

5.3.2.案例2 - 文件修改规范

5.3.3.案例3 - 拨打电话

5.4.场景法（流程图法）- 解决业务

场景法：也叫流程图法，是用流程图描述用户的使用场景，通过覆盖流程路径来设计测试用例
意义：
用户角度：用户使用的不是单功能，而是多功能组合使用
测试人员角度：将单个功能点组合起来进行组合测试
流程图优先于单功能，业务由于内部模块
通常将正确的场景来进行冒烟测试
流程图一般由谁来画：产品/开发的设计人员，当测试对产品非常熟悉后也可以来画流程图

5.4.1.流程图

是什么：使用标准图形和箭头来表达程序或业务的走向
作用：1.帮助测试人员看懂流程图，设计业务用例 2.需求文档信息不全时能够根据需求梳理流程
网页版绘制流程图：processon 软件：visio
椭圆：流程的开始和结束
长方形：流程处理或操作
菱形：流程节点的判断
平行四边形：流程流转过程中数据的输入/输出
箭头：流程的走向

5.4.1.案例1 - 登录下单

5.4.2.案例2 - ATM机取款案例

科普小知识1：ATM机是客户端，不存密码
科普小知识2：微软的主服务器放在苏格兰奥克尼岛附近的海底深处，阿里巴巴的数据中心建在了杭州的千岛湖，腾讯的数据中心则是建在了贵州贵安，低温可以冷却服务器，减少耗电

画泳道图

画流程图

编写测试用例（图1比较模糊，图二太扎眼，选择性浏览）

5.5.错误推测法

定义：通过经验推测系统可能出现的问题
思想：根据经验列举可能出现的问题清单，根据清单分析问题可能原因，推测发现缺陷
场景：1.时间紧任务多，没有时间写用例和测试点时，根据之前项目类似经验找出易出错的模块重点测试 2.项目上线前进行回归再测试

5.6.案例

5.6.1.单模块案例

无论是短信还是图片验证码测试点都是以下3个：是否为空，是否过期，是否错误

5.6.2.业务场景案例