一、理解软件测试

1.1 是什么？

IT领域、研发部门、质量岗位

1.2 特点

入行易，有深度、技术与管理并举

1.3 核心目标

尽早、尽快、尽多发现软件缺陷，促进软件质量与客户端满意的提升

1.4 如何理解“尽早”–案例解读？

软件测试始于需求（业务需求）：

软件测试始于需求（技术-Web系统）：

1）等价类划分法

测试输入无穷无尽怎么办----等价类划分

等价类划分法：将无穷的测试输入变成有限的输入

N–>2种

有效方法：199001-2049-12，720个

无效方法：205001，-1，abc，##，%，.3

2）边界值法

如何选择等价类中的数据–边界值法

边界值法：从划分的等价类里面选取数据的方法

如果使用边界值法，以上有效等价类中，应该选择那个数据？199001、204912、20

3）因果图法

有多个输入条件怎么办—因果图

因果图法：考虑输入数据之间的组合关系

4）用户故事法

如何模拟用户的行为–用户故事

用户故事只是描述系统的外在行为

5）错误推测法（探索式测试法）

做测试尽量要有自己的检查表

①Web网站：超连接测试工具、兼容性、安全、SQL注入

6）测试方法格式化–测试用例

测试设计：测试用例示例

面试时被问你是否写过测试用例：回答–测试用例无非就是测试过程中的文档化/格式化

企业级项目：

二、测试用例设计技术

2.1 什么是测试用例？

测试用例就是设计一种情况，软件在这种情况下能够正常运行并且达到期望执行结果

如果程序在这种情况下不能正常运行，而且这种问题会重复发生，那可能是一个软件缺陷

2.2 测试用例从哪里来？–需求-客户

2.3 测试用例的作用是什么？

避免漏测、评审测试用例等

2.4 测试用例包含哪些内容？

其中，最重要的是测试标题：标题需要写详细

对接需求的是：预期结果

2.5 如何设计测试用例？

测试用例设计三部曲：

①要测试什么–了解系统业务是什么

②怎么样测试–测试环境搭建

③如何判断正确与否–对照需求

按照需求理解系统需要测试什么，然后搭建环境

2.6 一线软件企业测试用例设计思维

软件需求：

编写测试用例实例：

测试前用思维导图画出给测试人员查看，这个过程叫做测试评审

画思维导图软件：FreeMind、XMind

三、软件缺陷管理

3.1 错误、缺陷和失效—不是所有bug都需要修复的原因

所有人都会犯错误（mistake），这样就会导致软件代码或者其他相关工作产品中引入缺陷（defect，bug）。如果执行了存在缺陷的代码，就可能会导致失效（failure）

面试官：所有的bug都要修复吗？

面试者：不是所有的bug都要修复，原因：如果执行了存在缺陷的代码，就可能会导致失效（failure）

3.2 正确理解bug–从哪里找bug

1）软件未实现产品说明书要求的功能–没有功能

2）软件出现了产品说明书指明不应该出现的错误–有功能，但是错误

3）软件实现了产品说明书未提到的功能

4）软件未实现产品说明书虽未提到但应该实现的目标

5）软件难以理解、不易使用、运行速度慢、或者软件测试员认为最终用户会认为不好

注：尚未发现或未观察到的软件缺陷只能说是潜在缺陷

3.3 哪些人关注bug–理解干系人对于bug的态度

3.4 bug修复成本趋势–理解为什么要尽早报bug

3.5 提交bug–bug包含哪些内容

bug标题、严重程度（站在客户角度考虑）、优先级（根据开发工程师内部角度考虑）

3.6 如何更好地发现bug–发现更多的bug

除了根据软件需求说明书来发现软件缺陷外，可以尝试使用如下建议：

 1）查找时间依赖和竞争条件的问题

 2）查找边界条件软件缺陷、内存泄漏和数据溢出缺陷

 3）查找状态转换时出现的缺陷

 4）查找资源依赖性：内存、网络、硬件等方面的缺陷

 5）查找和硬件相关方面的缺陷，比如硬件兼容性方面的缺陷

3.7 误报&漏报–该如何避免？

假阳性结果（误报）：由于测试执行方式的错误，或测试数据、测试环境或其他测试件中的缺陷，可能会出现误报

假阳性结果记录为缺陷，但实际上并不是缺陷

假阴性结果（缺陷的漏报）：相似的错误或却下会导致漏报

3.8 bug根本原因分析–技能提升更高层次

 缺陷的根本原因（root cause）：是导致缺陷产生的最早的行为或条件。可以分析缺陷并找出其根本原因，以减少类似的缺陷以后再发生

 缺陷的根本原因分析的作用：通过将关注点放在最重要的根本原因，根本原因的分析可以促进过程的改进，从而防止将来引入大量的缺陷

3.9 bug管理系统–案例实战

3.10 问题分析

1)你觉得你与你们项目组其他测试同事的优势是什么？

 我会对bug的根本原因进行分析

2)BUG分配给前端还是后端，怎么分？

 后端：运算，前端：展示

3）怎么提交BUG？

 禅道

4）接口返回NULL是BUG？

 看需求，如果预期结果输入NULL，则不是BUG

5）BUG的类型划分？

 功能性问题、性能问题

6）无法重现的BUG怎么办？

 将BUG置为延期

7）延期的BUG怎么处理，一直放着吗？

 由管理层人员决定

四、禅道的搭建和使用

4.1 禅道介绍

 禅道项目管理软件集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体

 功能完备的项目管理软件，完美的覆盖了项目管理的核心流程

主要特点：

 【1】一体化研发管理

 【2】概念清晰，功能完备

 【3】轻量级实现

 【4】可扩展的系统

 【5】开源免费的系统

4.2 禅道的业务流程

使用禅道进行用例测试

 测试结果：

Pass：通过

Fail：BUG

NA：忽略 没有执行（因为没有环境或者没有工具造成用例不能执行）—NA（没有环境）/NT（没有工具）

Block：阻塞 因为bug造成不能执行

使用禅道进行产品发布

使用禅道进行模块维护

4.3 禅道上的bug

 bug：

1.尽早提交，重复bug是属于无效bug，bug绩效 5个/天

2.bug跟踪

3.不管是界面还是功能的bug：都需要提交截图，视频，日志

4.bug标题：在什么环境下做了什么操作发生了什么现象

 一般的bug类型是：

代码错误

UI界面缺陷

功能缺陷

bug在禅道上的流程：

开发者在解决bug时常见的备注信息：

 1.拒绝

理由xxx

 2.确认

产生原因xxx

验证版本xxx

 3.延期

延期理由

验证bug：

 1.必现

验证版本：

验证次数：必现5-10次/偶现：20-50次，偶现bug需要验证连续三个版本

验证步骤：一般情况下复制bug描述中复现步骤，依据功能验证

验证结果：

1.pass—>关闭

2.Fail—>重新激活

依托于禅道工具分享测试流程：

 开发和测试脱离

测试环境搭建：

 Linux + 数据库