【测试人员需要知道的事】

目录

1. 测试与调试的区别

2. 什么是需求

3. 测试用例

3.1 什么是测试用例

3.2 为什么要有测试用例

4. BUG

5. 软件的生命周期

6. 开发模型

6.1 瀑布模型

6.2 螺旋模型

6.3 增量、迭代模型

7. 测试模型

7.1 V 模型

7.2 W 模型

8. 软件测试教程

8.1 软件测试的生命周期

8.2 BUG 的级别

8.3 BUG 的生命周期

9. 测试用例

9.1 测试用例的基本要素

9.2 测试用例的设计方法

9.2.1 基于需求的设计方法

9.2.2 等价类

9.2.3 边界值

9.2.4 判定表

9.2.5 正交排列

9.2.6 场景设计法

---

1. 测试与调试的区别

软件测试与调试的区别：

目的不同

调试(Debug)：确保程序做了程序员想它做的事情

测试(Testing)：确保程序解决了它该解决的问题

参与角色不同

测试由测试人员和开发人员来执行，黑盒测试主要由测试人员完成、单元/集成测试主要是由开发人员执行。

调试由开发人员完成。

执行的阶段不同 

测试贯穿整个软件开发生命周期

调试一般在开发阶段。

2. 什么是需求

对于人来说，饿了想吃饭，困了想睡觉，这些是人的基本需求。但对于一个软件来说，什么才是需求呢？

需求的定义

1) 用户需求：可以简单理解为甲方提出的需求。如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。该需求一般比较简略。

2) 软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。

大多数公司在进行软件开发时，会把用户需求转化为软件需求。开发人员和测试人员工作的直接依据就是软件需求。

两者的区别就是，用户需求就是一句话，而软件需求是一个文档(详细描述用户需求是如何实现的)，日常工作中，程序员通常是用软件需求来进行开发测试。

3. 测试用例

3.1 什么是测试用例

测试用例是一组集合：测试环境、测试数据、预期结果、操作步骤等。下面用 登录QQ 来举一下例子：

测试环境：Windows 系统 + Chrome 浏览器 + 本地

测试数据：账号、密码

预期结果：输入账号、输入密码、点击登录

操作步骤：登录成功

3.2 为什么要有测试用例

1. 测试用例能提高测试人员的工作效率，降低测试人员工作的重复性问题

2. 测试用例是建立自动化的基础。自动化能够把测试人员的双手解放出来，让代码吗代替测试人员进行测试。

4. BUG

什么是 BUG 呢？

当且仅当规格说明存在并且正确，程序与规格说明之间不匹配才是错误的，也就是说预期结果不等于执行结果。

当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现最终用户合理预期的功能要求时，就是 BUG！

5. 软件的生命周期

人的生命周期：出生到死亡。

而软件的生命周期，可以概括成以下阶段：需求分析 → 计划 → 设计 → 编码 → 测试 → 运行维护 。

需求分析：分析需求是否合理，需求是否完整。

计划：谁来负责开发，开发多久，谁来负责测试等，测试多久。

编码：写代码。

测试：写测试报告

运行维护：如果线上出问题，此时测试人员需要协助开发一起定位问题，并解决问题。

6. 开发模型

6.1 瀑布模型

特点：线性的

优点：每个阶段做什么，产出什么非常清晰

缺点：风险往往得等到后期的测试阶段才会显露，不能及时纠正！

适用项目：小型项目，周期比较短的

6.2 螺旋模型

优点：每个阶段都会进行风险分析，避免一些线上问题发生。

缺点：风险分析可能分析错，需要人力财力的投入。

适用项目：适用较大型且风险较大的项目。

6.3 增量、迭代模型

增量模型：登录开发完成 → 创建课程 → 上课

迭代模型：登录开发一部分 → 创建课程开发一部分 → 开发上课模块一部分

敏捷：

个体与交互重于过程和工具，即更加注重个体之间面对面沟通

可用的软件重于完备的文档，指的是开发文档、需求文档

客户协作重于合同谈判，即劳动合同

响应变化重于遵循计划

每对比对中，后者并非全无价值，但我们更加注重前者。

scrum 三大角色：

scrum 由 product owner(产品经理)、scrum master(项目经理)和 team(研发团队)组成

其中产品经理负责整理 user stroy(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。项目经理负责召开各种会议，协调项目，为研发团队服务。而研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。

7. 测试模型

7.1 V 模型

用户需求：PM 将用户需求收集形成软件需求

需求分析与系统设计：验证需求是否正确，确定编程语言，确定框架

概要设计：项目结构如何设计

详细设计：每个接口，涉及哪些库表，设计哪些任务

编码：写代码

单元测试：Java 中测试每一个方法、类

集成测试：将许多方法集成到一起测试

系统测试：模块与模块之间没有影响

验收测试：验收的人，产品，运营

特点：左边是开发，右边是测试，类似于瀑布模型

优点：测试被划分成许多类型

缺点：测试人员介入台湾，发现问题时机太晚

7.2 W 模型

特点：开发一个 V ，测试一个 V

优点：测试人员尽早介入需求

缺点：测试人员和开发人员一定程度上还是串行的，不能拥抱变化，不能适用于敏捷。

8. 软件测试教程

8.1 软件测试的生命周期

软件测试的生命周期：需求分析 → 测试计划 → 测试设计、测试开发 → 测试执行 → 测试评估

8.2 BUG 的级别

描述 BUG

1. 发现问题的版本

开发人员需要知道出现问题的版本，才能获取对应版本的代码来重现故障，并且版本的标识也有利于统计和分析每个版本的质量。

2. 问题出现的环境

环境分为硬件环境和软件环境。如果是 web 项目，需要描述浏览器版本、客户端操作系统等，如果是 app 项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。

3. 错误重现的步骤

描述问题重现的最短步骤

4. 预期行为的描述

要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎么样的。如果是依据需求提出的故障，能写明需求的来源是最好的。

5. 错误行为的描述

描述错误的现象。crash 等可以上传 log，UI 问题可以有截图。

6. 其他

某些公司会有一些其他要求。

7. 不要把多个 bug 放在一起

在无法确认是同一段代码造成的故障时，不要将 bug 放在一起提交。

bug 的级别：

1、Blocker（崩溃）：

阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等

（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）

• 严重花屏
• 内存泄漏
• 用户数据丢失或破坏
• 系统崩溃/死机/冻结
• 模块无法启动或异常退出
• 严重的数值计算错误
• 功能设计与需求严重不符
• 其它导致无法测试的错误, 如服务器500错误

2、Critical（严重）：

系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等。如：软件中数据保存后数据库中显示错误，用户所要求的功能缺失，程序接口错误，数值计算统计错误等

（该等级问题出现在不影响其他功能测试的情况下可以继续该版本测试）

• 功能未实现
• 功能错误
• 系统刷新错误
• 数据通讯错误
• 轻微的数值计算错误
• 影响功能及界面的错误字或拼写错误
• 安全性问题

3、Major（一般）：

功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等

(该问题实际测试中存在最多，合理安排解决BUG，解决率关系版本的优化程度)

• 操作界面错误（包括数据窗口内列名定义、含义是否一致）
• 边界条件下错误
• 提示信息错误（包括未给出信息、信息提示错误等）
• 长时间操作无进度提示
• 系统未优化（性能问题）
• 光标跳转设置不好，鼠标（光标）定位错误
• 兼容性问题

4、Minor（次要）：

界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。如：错别字、界面格式不规范，页面显示重叠、不该显示的要隐藏，描述不清楚，提示语丢失，文字排列不整齐，光标位置不正确，用户体验感受不好，可以优化性能的方案等

（此类问题在测试初期较多，优先程度较低；在测试后期出现较少，应及时处理）

• 界面格式等不规范
• 辅助说明描述不清楚
• 操作时未给用户提示
• 可输入区域和只读区域没有明显的区分标志
• 个别不影响产品理解的错别字
• 文字排列不整齐等一些小问题

8.3 BUG 的生命周期

delay 的 bug 一定会被修复吗？理论上来说，一定会被修复的。 

9. 测试用例

9.1 测试用例的基本要素

测试用例(Test Case) 是为了实施测试，而向被测试的系统提供的一组集合，也就是测试用例的基本要素，包括测试环境，操作步骤，测试数据，预期结果等。

9.2 测试用例的设计方法

9.2.1 基于需求的设计方法

测试用例设计的万能公式：功能，界面，易用性，兼容，安全，行能，网络等。

9.2.2 等价类

依据需求将输入（特殊情况下会考虑输出）划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。

有效等价类：对于程序的规格说明书是合理的、有意义的输入数据构成的集合，利用有效等价类验证程序是否实现了规格说明中所规定的功能和性能。

无效等价类：根据需求说明书，不满足需求的集合。

等价类思想设计测试用例步骤：

① 充分理解需求

②划分有效等价类，划分无效等价类

③从有效等价类抽取其中一个数据进行设计测试用例；从无效等价类中抽取其中一个进行测试用例设计。

9.2.3 边界值

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

边界点：

上点：边界上的点

内点：边界内的点

离点：边界值附近的一个点(闭区间区间外距离上点最近的点，开区间区间内距离上点最近的点)

 拿上面等价类测试用例来说

上点：6、15

内点：10

离点：5、16

如果是开区间呢？

上点：6、15

内点：10

离点：7、16

边界值设计测试用例的方法：

①充分理解需求

②找到边界点

③针对边界点设计测试用例

9.2.4 判定表

判定表 (Decision table) 是一种表达逻辑判断的工具。

关系：

与、或、恒等(条件为真，结果一定为真)、非(条件为假，结果才为真)

如何设计测试用例：

(1) 分析所有可能的输入和输出。

(2) 找出输入与输出之间的对应关系

(3) 设计判定表，把判定表对应到每一个测试用例

假设业务单据的处理规则为：淘宝 618 活动，订单已提交，订单合计金额大于 300 元或有红包，则进优惠。

输入：订单已提交，订单金额大于 300，有红包

输出：优惠、不优惠

1) 订单已提交，金额大于 300，有红包，优惠

2) 订单已提交，金额大于 300，没有红包，优惠

3) 订单已提交，金额小于 300，有红包，优惠

4) 订单已提交，金额小于 300，没有红包，不优惠

5) 订单不提交，金额大于 300，有红包，不优惠

6) 订单不提交，金额大于 300，没有红包，不优惠

7) 订单不提交，金额小于 300，有红包，不优惠

8) 订单不提交，金额小于 300，没有红包，不优惠

9.2.5 正交排列

最简单的正交表是，含意如下：“L”代表正交表；L 下角的数字“4”表示有 4 横行，简称行，即要做四次试验；括号内的指数“ 3 ”表示有 3 纵列，简称列，即最多允许安排的因素是3 个；括号内的数“ 2 ”表示表的主要部分只有 2 种数字，即因素有两种水平 1 与 2。正交表的特点是其安排的试验方法具有均衡搭配特性。

正交表的两条性质：

1. 每一列中各数字出现的次数一样多。

2. 任何两列中的各有序数对出现的次数一样多。

两个非常重要的概念：

因素：输入变量

水平：每一个输入变量取值

如何通过正交表设计测试用例

① 充分理解需求

② 确定因素，确定水平

③ 画正交表

④ 补充正交表

⑤ 将正交表转换成测试用例

以注册的需求为例：

输入 姓名、邮箱、密码、确认密码、验证码这几个变量才能注册成功。而水平：填写 / 不填写。

使用 allpairs 来画正交表：

打开 cmd ，进入到 allparis 路径下，输入以下路径：

便可在 allpairs 目录下，得到一个新的文本文件，里面是根据上述内容所画的正交表：

9.2.6 场景设计法

---