软件测试理论基础

---

前言

一、测试的阶段划分

1. 单元测试:主要是针对测试程序源代码。为的是确保各单元模块被正确的编译，比如有具体到模块的测试，也有具体到类，函数、方法的测试等。一般是开发来完成
2. 集成测试:针对接口测试。单元测试后,将各单元组合成完整的体系,测试软件单位之间的接口是否正确、数据能否正常传递。比如说注册和充值这两个功能是否能够连通
3. 系统测试:针对功能和非功能测试。把软件系统搭建起来,按照软件规格说明书中所要求，测试软件其性能功能等是否和用户需求相符合，在系统中运行是否存在漏洞等。根据测试用例，进行完整的系统测试。
4. 验收测试:内测、公测。主要就是用户在拿到软件的时候，在使用现场，会根据前边所提到的需求，以及规格说明书来做相应测试，以确定软件达到符合效果的。用户对软件进行验收。
   验收测试分为：
   Alpha测试:把用户请到开发方对软件进行的测试，测试环境受开发方控制，测试人不多,测试时间比较集中 执行者:测试人员、用户、公司内部人员
   beta测试:测试环境不受开发方控制，测试人比较多，测试时间不集中
   两者的最大区别:
   1、测试场所不一样
   2、一般先做Alpha测试再做beta测试

二、测试分类

1.按代码可见度划分

黑盒测试(常用):不关注源代码针对功能测试（系统测试）。只需要关注外部的输入与输出，不需要关注程序内部的逻辑
白盒测试:针对源代码进行测试（单元测试）。需要关注内部逻辑具体实现，而不需要关注外部的输入与输出
灰盒测试:针对接口进行测试（集成测试）。需要关注外部的输入与输出，也需要关注内部逻辑具体实现(两者都需要关注)

2.被测试对象是否运行划分

动态测试、静态测试(文档检查、代码走查)

3.按不同的测试手段划分

手工测试(点点点)、自动化测试(替代手工工具/写代码)

4.按测试包含的内容划分

功能测试、界面测试、安全测试、兼容性测试、
易用性测试:被测系统的各个功能是否操作方便、是否容易理解、是否容易上手
性能测试(负载测试、压力测试) :某个特定的时间，用户数量剧增，软件的是否正常

5.其他测试

冒烟测试：在进行正式测代前对主要功能核心功能进行的测试。
回归测试:开发对存在问题的功能进行修改后，再一次进行的测试
探索性测试/自由测试(测试思维):根据自己项目经验而进行的随意测试

6.质量模型的重点5类

功能、性能、兼容、易用、安全

三、测试流程6步

1. 需求评审

角色：产品经理、开发、测试
目的：需求理解一致、知道被测项目有哪些功能模块

需求分析

面试题：
1.遇到隐性需求怎么办?
充分熟悉产品，参考成熟产品，站在用户的角度去考虑，从而挖掘需求分析，为功能测试和非功能测试。
2. 给你一个带有logo的水杯，你会如何去测试? (测试思维 )

• 功能：
  装水、是否漏水、装热水、冰水、茶水、饮料、是否保温
• 非功能：
  1.界面: logo与原型图是否一致、是否美观、是否掉色 、材质
  2.易用性:防滑、防烫、带手把、携带是否方便、会不会刺到嘴巴
  3.兼容性:是否能装其他的液体
  4.安全性:装热水的候，会不会水有毒
  5.性能：防摔、挤压

2. 测试计划

测什么、谁来测、怎么测

3. 用例设计（重点）

针对穷举进行设计

1. 用例编写格式八大步骤：

4. 用例执行

用例执行不通过为缺陷，需要进行缺陷管理。

5. 缺陷管理

6. 测试报告

三.3、测试用例的方法

1.等价类划分

解决穷举场景设计测试。
有效等价：符合需求范围之内的为有效
无效等价：符合需求范围之外

重点：
正向:一条用例尽可能覆盖多条
逆向:每一条都是单独用例

应用场景：针对需要有大量数据测试输入，但是没法穷举测试的地方。
输入框、下拉列表、单选复选框
典型代表:页面的输入框类测试。

一般情况：完整的用例应该是等价类和边界值一块写任

案例1：qq合法性

需求：验证6-10自然数的qq合法性
步骤：

案例2：城市电话号码合法性

步骤：

2.边界值划分

解决限定边界规则设计的测试。
1.边界范围节点.
●选取正好等于、 刚好大于、刚好小于边界的值作为测试数据
➢上点:边界上的点(正好等于)
➢离点:距离上点最近的点(刚好大于。刚好小于)
➢内点: 范围内的点(区间范圈内的数据)，一般中间值

注意：1、有关范围限制，最多7条用例(暂时未优化)
2、边界值能解决位数限制问题，但是不能解决类型问题(要结合等价类)

2.步骤：
1、明确需求
2、确定有效和无效等价(类型)
3、确定边界范围
4、提取数据编写用例

3.使用场景：
在等价类的基础上针对有边界范围的测试数据输入的地方(重点关注边界)
常见词语描述:大小、尺寸、重量、最大、最小、至多、至少等修饰词语
典型代表:有边界范围的输入框类测试

强调:单个输入框，常用的方式边界+等价类
面试题:最常用的用例设计方法有哪些? -等价类、边界值

例1:通过边界值法验证标题长度的合法性

例2：通过边界值法验证QQ号码的合法性

要求: 6~10位自然数
步骤：

优化（7点优化5点）

重点：
上点:必选(不考虑区间开闭)
内点:必选(建议选择中间范围)
离点:开内闭外(考虑开闭区间,开区间选择内部离点，闭区间选择外部离点)

半开半闭区间:开区间一边的边界值不包括在内，而闭区间一边的边界值包括在内。[a,b)、(a,b]

优化例2：（开内闭外）

3.判断表法

解决多条件有依赖关系的测试。

介绍和步骤

1. 介绍
   a.定义:是一种以表格形式表达多条件逻辑判断的工具
   b.组成:
   ➢条件桩: 列出问题中的所有条件,列出条件的次序无关紧要。
   ➢动作桩: 列出问题中可能采取的操作,操作的排列顺序没有约束。
   ➢条件项: 列出条件对应的取值,所有可能情况下的真假值。
   ➢动作项: 列出条件项的、各种取值情况下应该采取的动作结果。
   c.规则:
   ➢判定表中 贯穿条件项和动作项的一列就是一条规则
   ➢假设有n个条件，每个条件的取值有两个(0,1),全组合有2的n次方种规则
2. 步骤：
   1、明确需求
   2、画出判定表 (条件有n个就是：2**n)
   1)、列出条件桩和动作桩
   2)、填写条件项，对条件进行全组合
   3)、根据条件项的组合确定动作项
   4)、简化、合并相似规则(有相同的动作)
   3、根据规则编写测试用例
3. 使用场景
   ●有多个输入条件，多个输出结果,输入条件之间有组合关系，输入条件和输出结果之间有依赖(制约)关系
   ●判定表一般适用于条件组合数量较少的情况(比如4个条件以下)

1、多条件之间有依赖关系，使用判定表来进行测试覆盖。
2、判定表一般适合4个以内条件依赖关系
3、如果条件超过4个，就不适合覆盖所有条件，应采用(正交法) 来解决。

例1：订单

例2：文件修改

4.场景法

业务测试覆盖。
1、覆盖业务测试，需要使用流程图法
2、先测试业务，在测试单功能、单模块、单页面

1. 流程图

提示:业务用例是根据流程图来梳理的,需要先了解流程图

2. 适用场景
   根据实际的应用场景，来测试业务用例，可以使用场景法。

例1：ATM取款机

流程图：


测试用例：

5.错误推荐法

定义：通过经验推测系统可能出现的问题。

场景：
1.时间紧任务量大时，根据之前项目类似经验找出易出错的模块重点测试。
2.实践宽裕通过该方法列出之前出现问题较多的模块

思想
根据经验列举出可能出现问题的清单，根据清单分析问题可能原因，推测发现缺陷。

应用场量:当日用例都执行完毕，BUG都修改完成。 离上线还有一段时间， 在这段时间中可是使用错误推荐法复测主要业务或测试未覆盖的内容。

面试：时间紧，任务量大，你会怎么测？
首先跟产品人员沟通，确定完哪些是最重的业务，我会去把最重的业务先覆盖完，然后再去验证主功能的正向和逆向，再按时间节点走。

三.5、缺陷

1.用例执行

用例执行不通过为缺陷，需要进行缺陷管理

2. 缺陷描述

面试题:当你发现缺陷后，首先会怎么办?
确定bug可复现，确定是bug。之后再决定提不提交给开发。

1. 定义：软件中存在的各种问题， 都为缺陷，简称bug;
2. 缺陷的判定标准：
   1、少功能
   2、功能错误
   3、多功能
   4、缺少隐形功能
   5、易用性(软件测试人员认为)
3. 缺陷原因：
   需求阶段:需求描述不易理解，有歧义、错误等
   ●设计阶段: 设计文档存在错误或者缺陷
   ●编码阶段: 代码出现错误
   ●运行系统: 软硬件系统本身故障导致软件缺陷
4. 缺陷的跟踪流程：提交、验证、修复
5. 缺陷的生命周期

1、回归测试:
①常规项目回归:项目本次发布新增2个模块，最基本要测新增模块功能及新增模块关联的旧模块。
②非常规项目(银行、部队、航天) :新增功能，必须全部复测。
2、回归bug:上一个版本发现的缺陷，开发修复完毕，在下个版本进行重新验证。

3. 缺陷的核心内容

4. 缺陷提交要素

例：提交下图缺陷用例

缺陷用例：

5.缺陷内容

1、功能错误
2、UI页面错误
3、兼容性
4、数据(数据库)
5、易用性
6、建议
7、架构缺陷

6. 工作流程

1、设计用例->执行用例 (执行测试) ->缺陷(提交、验证、关闭)
2、缺陷定义:任何问题(Bug)
3、缺陷标准:多功能、少功能、错误、缺少隐性功能、易用性
4、描述缺陷重点:缺陷标题、前置条件、复现步骤、预期结果、实际结果、附件备注
5、提交缺陷信息:指派人、缺陷等级、修复优先级、类型、状态(统计缺陷)|

7.缺陷管理

1、Exel

exel一般用来写用例。

2、禅道-项目管理工具

一般提bug等等。

1. 安装地址：https://www.zentao.net/

8. 缺陷标题分析扩展

作用是什么?想要达到什么效果？–>让人看明白哪里错了

• 描述测试数据+实际结果(预期结果)
• 测试数据描述+预期结果(实际结果)
• 测试数据描述+实际结果(需求)

以上三选一描述清楚就行！
例如：
标题15位纯数字结果合法 (期望:不合法)
标题15位纯数字预期不合法 (实际:合法)
标题15位纯数字结果合法(需求:标题为15位字符串)

例1：注册

三.6、测试报告

一般报告为如下几个模块：
1、项目背景 2、测试目标 3、提测标准 4、结束标准(上线标准) 5、风险控制 6、bug统计 7、bug分析 8、测试总结

• 项目背景
  文档中的描述
• 测试目标
  哪些模块：1.登录模块 2.发布文章模块…
• 提测标准
  1、冒烟测试用例100%通过
  2、被测内容符合约定版本及功能
• 结束标准
  1、p0~p2全部修复完成
  2、p3修复完成95%
• 风险控制
  1、人员风险(多储备1-2名、测试、开发、产品)
  2、环境风险(开发、运维、测试共同完成)
  3、需求风险(跟产品确定有可能变动部分)
• bug统计
  1、登录模块: 8个
  2、发布文章: 1个 --> p0
• bug分析
• 测试总结
  问题：
  1、登录需求(验证码)不明确
  2、选择频道需求不明确
  3、上传图片功能有些干扰发布文章主线
  收获：
  1、先设计主功能，其次设计独立功能点
  2、设计用例之前先设计测试点，可以避免遗漏。

登录项目的实施

1. 明确需求
   登录需求-1：
   
   登录需求-2：
   
2. 登录功能的测试点提取

用例条数：

3. 测试用例