一、什么是软件测试？
1、定义：使用技术手段验证软件是否满足使用需求
2、目的：减少软件缺陷，保障软件质量。
二、主流技术：
1、功能测试：验证程序的功能是否满足需求
2、自动化测试：使用代码或工具代替手工，对项目进行测试
3、接口测试：有硬件接口、软件接口；使用代码或工具对服务端提供的接口进行测试，接口访问是否正常
4、性能测试-代码实现：模拟多人使用软件，查找服务器缺陷
三、测试分类
*按测试阶段划分
- 单元测试：对程序源代码进行测试（开发自己做）
- 集成测试：接口测试；对模块之前访问地址进行测试
- 系统测试：对整个系统进行测试包括功能、兼容、文档等测试
- 验收测试：分为内测、公测、使用不同人群来发掘项目缺陷。
*按代码可见度划分
- 黑盒测试：功能测试；源代码不可见
- 灰盒测试：部分源代码可见，功能可见
- 白盒测试：结构测试，全部代码可见，UI功能可见
四、 模型
1、质量模型：
功能性、性能、兼容性、易用性、安全、可移植性、可维护性
五、测试流程
- 需求评审：确保各部门需求理解一致
- 计划编写：测试什么、谁来测、怎么测
- 用例设计：
- 用例执行：验证项目是否符合需求的操作文档
- 缺陷管理：
- 测试报告：
六、测试用例
1、用例：用户使用的案例
用户是否能开机、验证内存、验证屏幕、检查运行速度
2、什么是测试用例？
为测试项目而设计的执行文档
3、测试用例作用：防止漏测、实施测试的标准
4、用例设计编写格式
七、测试模板8个要素
1、测试编号：项目简称_模块简称_编号
2、用例标题：预期结果（测试点）
3、项目/模块：用例所属项目获模块
4、优先级：p0-p4（p0最高）
5、前置条件/预置条件：操作步骤之前的操作
6、测试步骤：执行步骤
7、测试数据：执行步骤中的重点数据
8、预期结果：用例执行结果+不同角色隐形结果
八、能对穷举场景设计测试点——等价类划分法
1、说明：在所有测试数据中，具有某种共同特征的数据集合进行划分
2、分类：有效等价类：满足需求的数据集合
无效等价类：不满足需求的数据集合
3、步骤：
明确需求
确定有效和无效等价类
提取数据编写测试用例
4、典型场景：页面输入框类测试
qq验证
重点：正向用例：一条尽可能覆盖多条
逆向用例：没一条数据，都是一条单独用例
九、解决边界限制问题——边界值分析法
1、边界范围节点
上点：边界上的点（绿色）
离点：距离边界最近的点（黄色）
内点：范围内的点（蓝色）
2、边界值法设计用例步骤
- 明确需求
- 确定有效和无效等价类
- 确定边界范围值
- 提取数据编写测试用例
测试案例1：
测试案例2：需求：验证qq号合法性，6-10位自然数
3、边界值优化策略：
重点：开内闭外（开区间选包含的点，闭区间选不包含的点）
开区间：不包含边界上的点（没有等号），如，a<10
闭区间：包含边界上的点（有等号），如，a<=10
结论：7个优化为5个点
上点：必选（不考虑区间开闭）
内点：必选（建议选中间范围）
离点：开内闭外（考虑开闭区间，开区间选择内部离点，闭区间选择外部离点）
典型代表：有边界范围的输入框类测试
十、解决多条件有依赖关系测试——判定表法
案例：验证“若用户欠费或关机，则不允许被叫”功能测试
1、定义：是一种以表格形式表达多条件逻辑判断工具
2、组成：
- 条件桩：列出问题中的所有条件，列出条件的次序无关紧要
- 动作桩：列出问题中可能采取的操作，操作的排列顺序没有约束
- 条件项：列出条件对应的取值，所有可能情况下的真假值
- 动作项：列出条件项的，各种取值情况下应该采取的动作结果。
3、规则：判定表中贯穿条件项和动作项的一列就是一条规则
假设有n个条件，每个条件的取值有两个（0,1），全组合有2的n次方种规则
4、设计用例步骤：
首先，明确需求
其次，画出判定表
（1）列出条件桩和动作桩
（2）填写条件项，对条件进行全组合
（3）根据条件项的组合确定动作项
（4）简化、合并相似规则（有相同的动作）
最后，根据规则编写测试用例
测试案例：
需求规则：
（1）若金额大于500元，未过期，则发出货单
（2）若金额大于500元，但过期了，则不发出
（3）若金额小于等于500元，则不论是否过期都发出货单
（4）在过期的情况下，不论金额大小还需要发出通知单
5、使用场景：
- 有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖（制约）关系
- 判定表一般适用于条件组合数量较少的情况（比如4个条件以下）
十一、测业务——场景法
1、流程图：使用标准图形和箭头来表达程序或业务的走向
2、作用：能够看懂流程图，设计业务用例，根据需求，梳理信息
3、工具：https://processon.com/diagraming/ 或者visio
4、使用场景：
5、业务用例：银行ATM用例
十二、错误推荐法
1、定义：通过经验推测系统可能出现的问题
2、思想：根据经验列举出可能出现问题的清单，根据清单分析问题可能原因，推测发现缺陷
3、场景：
- 时间紧急任务量大时，根据之前项目类似经验找出易出错的模块重点测试
- 实践宽裕通过该方法列出之前出现问题较多的模块再次测试
十三、缺陷
1、定义：软件在使用过程中存在的任何问题都叫软件的缺陷，简称bug
2、判定标准：
- 软件未实现需求（规格）说明书中明确要求的功能——少功能
- 软件出现了需求（规格）说明书中指明不应该出现的错误——功能错误
- 软件实现的功能超出需求（规格）说明书中的范围——多功能
- 软件未实现需求（规格）说明书中虽未明确指明但应该实现的要求——隐形功能错误
- 软件难以理解，不易使用，运行缓慢，用户体验不好——不易使用
3、缺陷产生的原因：
需求阶段：需求描述不易理解，有歧义、错误等
设计阶段：设计文档存在错误或缺陷
编码阶段：代码出现错误
运行阶段：软硬件系统本身故障导致软件缺陷
4、缺陷的生命周期：
解决A缺陷，可能产生信的B缺陷
5、缺陷类型：
- 缺陷的标题：描述缺陷的核心问题
- 缺陷的预置条件：缺陷产生的前提
- 缺陷的复现步骤：复现缺陷的过程
- 缺陷的预期结果：希望得到的结果
- 缺陷的实际结果：实际得到的结果
- 缺陷的必要附件：图片、日志等信息（证据）
6、缺陷提交要素
7、软件缺陷类型：
- 功能错误
- 界面（UI）错误
- 数据
- 兼容性
- 易用性
- 改进建议
- 架构
8、缺陷编写
-
缺陷报告示例
-
缺陷跟踪流程
-
提交缺陷注意事项：可重现、规范性（符合公司或项目要求）、唯一性（一个缺陷上报一个问题）
-
缺陷编写规范
面试题：当你发现缺陷后，首先会怎么办？
答：先确定缺陷可重现，其次确定其是bug。提交时，要检查缺陷是否已存在
9、缺陷管理工具
- 禅道工具/JIRA
（1）介绍：https://demo.zentao.net/user-login.html
选中登录页面：测试甲，再登录
（2）特点：
三权分立：产品部门、研发部门、测试部门
四角协同：产品经理、项目经理、研发团队、测试团队
（3）使用流程
登录
创建缺陷
提交缺陷
关闭缺陷
10、缺陷标题分析
如下：
- 15位数字验证合法，期望：不合法
- 描述测试数据+实际结果（预期结果）——标题15位纯数字结果合法（期望：不合法）
- 测试数据描述+预期结果（实际结果）——标题15位纯数字预期不合法（实际：合法）
- 测试数据描述+实际结果（需求）——标题15位纯数字结果合法（需求：标题为15位字符串）
示例：15位数字验证合法，期望：不合法
输入第一类A或B，第二列不是数字，预期结果输出L、M（实际输出：L）
输入第一类A或B，第二列不是数字执行结果输出L（期望：输出L、M）
输入不正确的取款金额，结果取款成功（预期：取款失败，提示：不是正确金额）
11、代码注释
html代码
十四、项目介绍
1、项目背景：
2、产品定位：
3、项目目标：
4、产品功能架构：
十五、项目功能测试
1、测试对象
2、登录文章来源：https://www.toymoban.com/news/detail-409744.html
- 登录需求
- 输入正确账号
- 点击发送验证码
- 点击按钮进行验证
- 输入验证码
十六、登录测试点提取
1、项目实施文章来源地址https://www.toymoban.com/news/detail-409744.html
- 登录模块
（1）功能：账号，验证码，协议，滑块
（2）非功能：兼容性——5大浏览器，界面布局——布局与UI原型一致且图片与文字准确与UI原型无误
到了这里，关于软件测试工程师的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
