软件测试工程师

一、什么是软件测试？

1、定义：使用技术手段验证软件是否满足使用需求
2、目的：减少软件缺陷，保障软件质量。

二、主流技术：

1、功能测试：验证程序的功能是否满足需求
2、自动化测试：使用代码或工具代替手工，对项目进行测试
3、接口测试：有硬件接口、软件接口；使用代码或工具对服务端提供的接口进行测试，接口访问是否正常
4、性能测试-代码实现：模拟多人使用软件，查找服务器缺陷

三、测试分类

*按测试阶段划分

1. 单元测试：对程序源代码进行测试（开发自己做）
2. 集成测试：接口测试；对模块之前访问地址进行测试
3. 系统测试：对整个系统进行测试包括功能、兼容、文档等测试
4. 验收测试：分为内测、公测、使用不同人群来发掘项目缺陷。

*按代码可见度划分

1. 黑盒测试：功能测试；源代码不可见
2. 灰盒测试：部分源代码可见，功能可见
3. 白盒测试：结构测试，全部代码可见，UI功能可见

四、 模型

1、质量模型：
功能性、性能、兼容性、易用性、安全、可移植性、可维护性

五、测试流程

1. 需求评审：确保各部门需求理解一致
2. 计划编写：测试什么、谁来测、怎么测
3. 用例设计：
4. 用例执行：验证项目是否符合需求的操作文档
5. 缺陷管理：
6. 测试报告：

六、测试用例

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、登录

• 登录需求
• 输入正确账号
• 点击发送验证码
• 点击按钮进行验证
• 输入验证码

十六、登录测试点提取

1、项目实施

• 登录模块
  （1）功能：账号，验证码，协议，滑块
  （2）非功能：兼容性——5大浏览器，界面布局——布局与UI原型一致且图片与文字准确与UI原型无误