测试理论知识学习笔记 Day1

一、软件测试概述

1.什么是软件

• 硬件概念：由电子，机械和光电元件等组成的各种物理装置的总称

 特点：看的见摸得着。

• 软件概念： 是一些连招特定顺序组织的计算机数据和指令的集合

特点:看的见摸不着   

 2.软件分类

• 按照开发规模划分

1. 小型软件：开发周期四个月内，参与人数10人以下
2. 中型软件：开发周期一年内，参与人数10-100人
3. 大型软件：开发周期一年以上，参与人数100人以上

• 按照用户对象划分

1. 产品：微信/office/QQ/百度，用户是大众，没有针对的甲方（用户自行去选择使用的）
2. 项目：为企业定制的OA系统

• 按照是否需要联网划分

1. 单机软件：不需要联网就可以使用像蜘蛛纸牌、画图软件等
2. 网络软件：        

                C/S架构：客户端软件，需要安装的软件例如QQ/LOL/微信

                B/S架构：搜狐/百度

两者的区别：B/S架构属于C/S架构，只不过是一个特殊的架构，C/S架构的软件是需要下载客户端进行安装使用的，而B/S架构的软件是可以直接在浏览器搜索使用。

•  按照功能进行划分

应用软件：给人使用的软件，例如美团、淘宝

系统软件：例如操作系统：Linux、iOS；驱动软件：主板、显卡、声卡驱动

3.什么是软件测试

• 概念：在规定条件下对程序进行操作，以发现程序错误，对其是否能满足设计要求进行评估的过程
• 目的：找缺陷（找bug）
• 对象：

1.  源程序：开发的程序
2. 目标程序：运行起来的程序
3. 数据：是否符合设计规定
4. 文档：说明书是否可以看懂

二、软件的开发流程（要求：清楚、理解、记忆）

1.开发模型的分类：

• 边做边改模型：
• 瀑布模型：
• 快速原型模型：
• 增量模型：
• 螺旋模型：
• 喷泉模型：
• 。。。

2.瀑布模型

2.1 概念

将软件的生命周期划分为制定计划，需求分析，软件设计，程序编写，软件测试和运行维护的六个基本活动，并且规定了它们自上而下，相互衔接的固定次序如同瀑布流水，逐级下落

 组成阶段有六个

 2.2 参与角色与产出

	制定计划	需求分析	软件设计		程序编写	软件测试	运行维护
			概要设计	详细设计
参与角色	boss 产品经理 客户	产品经理 开发人员	开发(老大)	开发人员	开发人员	测试人员	运维人员
产出内容	可行性分析报告 （立项） 项目计划书	需求文档 （PRD） 是一切测 试活动的依据	概要设 计说明书	详细设 计说明书	程序	测试报告 操作手册	运维手册

2.3 小结

1. 特点：线性模型，是其他模型的基础
2. 应用场景：需求特备清晰的大型项目，如建筑，银行，保险等
3. 优点：阶段清晰
4. 缺点：返工量大，不适用于需求变化的项目

 2.4 面试题 

软件生命周期?[1]

项目立项-->计划阶段-->需求分析-->设计环节-->编码阶段-->测试阶段-->运行维护

“软件生命周期通常包括以下阶段：项目立项、制定计划、需求分析、设计、开发、测试维护。需求分析阶段确定软件的功能和要求；设计阶段制定系统架构和详细方案；开发阶段进行编码实现；测试阶段验证和修复缺陷；部署阶段将软件发布到生产环境；维护阶段处理问题并进行必要的更新。”

3.敏捷开发

3.1 背景

90%以上的公司采用敏捷开发

• 20世纪90年代后逐渐引起广泛关注的新型软件开发方法

也叫敏捷方法、敏捷过程、敏捷模型

• 它的具体名称，理论，过程，术语都不尽相同
• 它是一种以人为本，迭代，循序渐进的开发方法

3.2基本原则

• 以人为本：相信自己团队，规律的反省/优化，重视客户胜过合同
• 一切从简：简化流程、简化文档，简化交流方式
• 迭代：持续交付，周期越短越好

4.项目构成

4.1 说明

一个项目基本由前端、后端和数据库三部分组成

• 前端：用户所使用的浏览器或客户端
• 后端：运行在应用服务器上，作为前端和数据库的中间人，处理业务和数据
• 数据库：运行在数据服务器上，用于存储数据

4.2 中间件

• 概念

介于系统和应用之间的一类软件

可以简单理解为，中间件可以在系统上帮助应用开放端口

• 常用的中间件

1. Tomcat：主要运行Java程序
2. Apache：主要运行PHP程序 

三、软件的测试流程

1.软件测试模型分类

1.1 V模型（重点）

• 概念

概念：以编码为黄金分割线，把整个过程分为开发和测试，并且开发和测试之间是串行的关系

• 图示

 

• 特点：

开发与测试串行，测试介入过晚，返工量比较大 

1.2 W模型（重点）

• 概念

概念：W模型是由两个V模型组成的，一个是开发阶段，一个是测试阶段，又称双V模型

• 图示

•  特点

 开发跟测试是并行的关系，测试可以提早介入，但是总体流程依然是串行的，不支持迭代

1.3 X模型

1.4 H模型

四、最佳实践流程-1

1.团队角色介绍

• 产品经理/项目经理（负责人）做策划工作
• UI（界面设计）
• 前端开发工程师
• 后端开发工程师
• 软件测试工程师
• 运维人员/运营人员

疑问：迭代每个环节的耗时？

五、软件测试的分类

1.按阶段划分

1.1 单元测试

• 概念

指对软件中的最小可测单元（一般可以理解为函数）进行检查和验证

1.2 集成测试

• 概念

在单元测试的基础上，将所有的模块按照设计要求组装，组装成子系统或者系统，然后进行测试

1.3 系统测试

• 概念

 系统测试时将软件和操作系统和硬件看做一个整体，在实际运行环境下进行测试

1.4 验收测试

• 概念

 对完成的系统是否满足最开始的需求进行验证

分类

• 按照用户对象来划分
  项目验收：甲方发起，验证乙方系统是否满足甲方业务需求
  产品验收：产品经理发起验证自研软件是否满足用户需求
• 按照阶段划分
  α测试（内测）：只有公司内部成员参与
  β测试（公测）：由用户完成

测试阶段--负责人员--项目环境的关系

测试阶段	负责人员	项目环境
单元测试	开发人员	开发环境（开发人员使用的电脑）
集成测试	开发人员	开发环境
系统测试	测试人员	测试环境
验收测试	产品经理/甲方	预生产环境

主要的项目环境

开发环境：开发人员自己使用的电脑

测试环境：

预生产环境：

线上环境/生产环境：

2.按是否考虑代码的逻辑来划分

2.1 黑盒测试

• 概念
  把测试对象看作一个黑盒子，测试时，测试人员不用考虑盒子里的逻辑结构，只需要检查程序的功能是否符合需求文档。
• 重点
  验证程序的功能是否符合需求文档
• 测试依据
  依据需求文档（PRD）
• 分类

1. 界面测试/UI测试：检查页面元素是否符合UI设计，页面是否美观
2. 功能测试：检查产品的功能是否满足需求
3. 应用型测试：用户体验
4. 兼容性测试：验证软件在各个环境下功能是否正常
5. 性能测试：模拟用户场景，测试系统的各项性能指标，查看是否满足需求

2.2 白盒测试（开发人员自测）

• 概念
  与黑盒测试相反，这种方法是把测试对象看做是一个透明的盒子，测试时，测试人员会对程序的所有逻辑路径进行测试，检验每条路径是否都能走通。
• 重点
  验证源代码的逻辑结构是否符合设计，
• 测试依据
  依据代码规范、详细设计文档

2.3 灰盒测试 

• 概念
  介于黑盒与白盒之间的一种测试方法，需要了解代码逻辑，重点验证程序的功能
• 案例
  商城中，用户支付时可以使用优惠券

1. 黑盒测试，考虑各个用户，各个商品，各种价位、各种金额大小的优惠券
2. 灰盒测试，先了解业务逻辑，在进行测试（了解开发的思维，精简测试的逻辑）

与各个测试阶段的对应关系 

按阶段分类	按是否考虑代码逻辑
单元测试	白盒测试
集成测试	白盒测试
系统测试	黑盒测试/灰盒测试
验收测试	黑盒测试

 面试题

白盒测试与黑盒测试的区别[1]

首先，策略不同，黑盒不考虑代码的逻辑，白盒需要考虑

其次，阶段不同，白盒进行比较早，单元和集成测试都属于白盒，黑盒进行的比较晚，UI/功能/易用性都属于黑盒

再次，上手难度不同，白盒要求具备代码能力，上手难度较大，黑盒要求测试/用户思维，上手难度较小

最后我想说，黑盒和白盒不能互相替代都是不可或缺的

3.按照是否运行划分

3.1 静态测试

• 概念 

指不运行被测试程序本身，检查文档或者源程序的语法，结构，过程等（程序员）

• 测试对象

1. 文档（需求文档/各类设计文档）
2. 源程序
3. 数据

3.2 动态测试

•  概念
  指通过运行被测程序，进行测试
• 测试对象
  1、源程序
  2、目标测试
  3、数据

4.按是否自动化划分

 4.1手工测试

概念：手工的方式去执行测试

4.2 自动化测试

概念：需要借助工具或者代码进行测试

5.其他

5.1 冒烟测试

针对最基本的功能或者流程进行测试

5.2 回归测试

• 概念
  修改代码后重新进行测试
• 应用场景
  
  1、bug回归：当前迭代的bug修复后，需回归，以前的版本中概率性出现的bug,可能需要连续跟踪几个版本
  2、旧功能回归：新功能更新后，需检查旧功能是否收到了影响  

5.3 面试题

回归测试测的重点？[3]

我做回归测试的方向主要有两个：bug回归和旧功能回归
如果是bug回归，重点是修改过的功能或者模块，还有与之关联的功能或模块；
如果是旧功能回归，重点是分清重要的核心功能，以及使用频率高的功能

5.3 随机测试 [了解]

概念

测试其他人没有测到的部分或者功能或场景（特别依赖测试人员的经验）

5.4 探索性测试

测试的设计和测试的执行同时执行（特别依赖测试人员的经验）

六、最佳实践流程-2

1.测试流程

1.1 需求分析，需求评审 

1.2 编写测试计划

1.3 编写测试用例以及发起用例评审

1.4 【可选】搭建测试环境，冒烟测试

1.5 系统测试，编写测试报告

轮次	工作
第一轮	新功能的功能测试
第二轮	bug回归测试
第三轮	bug回归测试
第四轮	。。。
最后一轮	旧功能的回归测试

1.6 验收测试，编写测试报告

1.7 线上，点点点

测试报告一般保留上线前的那一份即可        

2. 时间规划

# 以周迭代为例

需求分析 + 需求评审 -- 0.5天

测试计划 + 测试用例以及评审 -- 2.5天

系统测试 -- 1.5天

验收测试 -- 0.5天

#以两周一个迭代为例（各阶段时间 * 2 ）

3.面试题

3.1 你们公司的测试流程是怎样的？[3] 

1. 首先是产品经理发起需求评审会议，各角色都参会评审，直到PRD定稿

2. 组长输出测试计划（分配测试任务）

3. 测试人员根据自己的任务来设计测试用例，以及发起用例评审

4. 开发人员完成冒烟测试并搭建测试环境并提测

5.接下来就是系统测试了，一般情况大致有四轮

• 第一轮执行新功能的测试用例，会发现很多bug
• 开发修复bug后，第二轮进行bug回归测试
• 第三轮，对修复失败的缺陷和新引入的bug再次进行回归测试
• 最后一轮，已知bug基本请0，对旧功能做一轮回归测试

 6.系统测试结束后，测试人员辅助产品经理完成验收测试，通过后，测试人员编写测试报告，开发做上线前的准备

7.上线后，测试人员去线上点点点，验证线上有没有明显的bug

3.1冒烟测试的作用？[2]

如果没有经过冒烟测试，开发直接测试，出现阻塞性bug，会影响团队的进度

冒烟测试能确保主业务流程没问题，也能避免返工的情况出现，可以提高整体效率

七、测试计划和测试方案

1.测试计划

1.1 概念

概念：是指描述了要进行的测试活动的范围，资源和进度的文档

1.2 内容

• 测试的目标和测试范围
• 角色分工和测试范围
• 任务的安排/进度与资源分配
• 风险评估和应急计划
• 测试的各项标准

测试计划的重点

•  资源分配（人，时间，其他测试资源）
• 风险评估（测试不到的部分）
  — 时间不够
  — 技术不足，无法进行测试
  — 场景无法模拟，无法进行测试

2.测试方案 

2.1概念

概念：是从技术的角度去分析重点体现了测试策略与技术实现的文档

2.2 内容

• 测试的策略

1. UI 出发
2. 功能出发
3. 易用性
4. 兼容
5. 性能...

•  测试方法

1. 手工 or 自动化
2. 黑盒 or 白盒

• 测试工具的设计和选择 

2.3 测试设计和测试方案的区别

• 测试计划是管理型文档，测试方案是技术型文档

测试计划解决的是谁来做？谁来做？做什么？

测试方案主要解决怎么做？

• 在敏捷过程中 ，可以把测试计划看作是测试计划＋测试方案，并且文档也是可以省略的（50%以上的公司是不会写的）

 3.面试题

有哪些常见的系统测试的策略？[1]

UI测试

功能测试

易用性测试

性能测试

安全测试等等

你们公司的测试计划是怎么写的？[2]

首先是做好资源分配工作，包括开始和结束时间，人力方面的资源，服务器和测试机器等测试资源

其次是做好风险评估，把技术和场景原因没办法测试的或者时间不够导致可能测不完的内容列出来，并给出应急办法，当然还有各阶段的通过标准

当然还包括测试策略的选择等等

八、测试用例

1.概念

指导对软件进行操作、帮助证明软件功能或发现软件缺陷的一种说明，最终形成文档。

2.软件测试用例包含的内容

• 用例ID
• 模块
• 标题
• 前置条件（本模块的前置模块、外在网络、服务等环境是否正常）
• 测试步骤
• 测试数据
• 预期结果（参照需求文档）
• 优先级（在资源有限时，测试用例执行的先后顺序）

3.作用

• 降低测试人员交换成本
• 用于评估测试工作量，提前准备数据，分配任务，把控进度
• 便于回归测试

面试题

 测试用例一般包含哪些内容？

首先是ID，模板，标题

然后是前置条件，测试步骤，测试数据，预期结果

最后还有优先条件

九、测试用例设计方法

应用场景

黑盒测试的测试用例是无法穷尽的，我们需要科学的方法帮我们把无限变为有限 

 最常见的8种测试用例的设计方法

• 等价类
• 边界值
• 判定表
• 因果图
• 正交法
• 场景法
• 流程图
• 错误推测法

1.等价类【重点】

也叫等价类划分法

1.1 概念

把程序的输入域分成若干部分（子集），然后选取少数代表性数据作为测试用例

1.2应用重点

在需求中把功能对应的条件找出来，满足条件为有效等价类，不满足条件为无效等价类

划分时，自己互不相交，且子集合并后是整个集合 

举例

需求：QQ账号输入，6~10位自然数

1.需求分析：把条件找出来

A:6~10位

B:自然数

2.划分等价类

输入项	有效等价位	编号	无效等价类	编号
QQ账号	6~10位	1	小于6位	2
			大于10位	3
	自然数	4	字母	4
			汉字	5
			特殊符号	6

3.尝试设计测试用例

编号	测试数据	覆盖等价类	说明
1	66668888	1,4	合法输入
2	12345	2,4	非法输入
3	aaabbbcccddd	3,4	非法输入
4	听君衣一席话如听一席话	1,5	非法输入
5	@#！123	1,7	非法输入

 面试题

什么是有效等价类？什么是无效等价类？[1]

满足需求，满足功能具体条件的等价类是有效等价类 

反之，不满足需求，不满足功能和具体条件的等价类就是无效等价类

2.边界值【重点】

输入项的多数错误都发生在各种条件判断的边界上，如果边界附近的取值没问题，那么其他取值导致的bug的概率较小

2.1边界值

• 内点：取值范围的点
• 上点：取值范围边上的点 如[6,10]和（6,10）的上点都是6和10
•  离点：离边界最近的点，[6,10]的离点是5,11；（6,10）的离点是7,9

2.2应用重点

• 边界值法是对等价类法的重要补充
• 找出临界点

3.判定表【重点】

3.1 概念

判定表，也叫决策表，他可以把复杂的逻辑关系和各种条件组合的情况表达清楚

3.2 判断表的组成元素

判定表由条件桩、条件项、动作桩、动作项组成

• 条件桩：被测对象的所有输入条件
• 条件项：被测对象的输入条件的取值
• 动作桩：被测对象所有可能采取的动作/结果
• 动作项：在各个条件项的组合下，被测对象所采取的动作/结果  

4.因果图

 4.1概念

因果图是通过分析数日条件之间的关系以及输入和输出之间的关系，在转化成判定表，从而设计测试用例的方法

5.正交法

 也叫正交试验分解法

5.1 概念

是一种古希腊就有的实现设计方法，基于数学概率学知识，设计最经济的实现路径

6.场景法

6.1适用范围说明

• 等价类＋边界值，适合单一输入条件的功能，如输入QQ号，输入密码等
• 判定表，使用有组合条件输入的功能，如：判断三好学生，判断是否允许主被叫等
• 多数功能涉及业务流，需要通过多个操作步骤来实现，这就需要用到场景法，如登录，ATM取款，微信发红包 

6.2应用重点

需要找出基本流和备选流

• 基本流：主流正确的操作流程（只有一个）
• 备选流:其他操作流程（可以有多个）

测试用例说明

场景1：基本流

场景2：基本流、备选流1

场景3：基本流、备选流1、备选流2

场景4：基本流、备选流3

场景5：基本流、备选流3、备选流1

场景6：基本流、备选流3、备选流2、备选流1

场景7：基本流、备选流4

场景8：基本流、备选流3、备选流4

说明

场景法只验证业务流程，不验证单一功能

一般先用等价类/边界值/判定表对单个功能进行验证，通过后，在用场景法进行流程验证

7.流程图法【重点】

7.1应用场景（需要能看懂流程图）

当功能的业务逻辑和实现步骤较多较复杂的时候，可以借助画流程图的方式去辅助分析应用场景

表示程序流程时，最关注的点就是这个步骤对应的操作（长方形）和程序所做的判断 （菱形）

 画图工具

visio:属于微软的office系列，但不在office套件中，需要单独安装

8.错误推断法（需要依赖大量经验）

8.1应用场景

测试人员使用经验或直觉去发现程序的错误

问题：有经验的老测试，是如何使用错误推断法

如，开发人员在开发新功能时

• 基于对开发人员的了解，感觉这个开发编程不严谨，容易在边界判断上出错
• 旧数据的兼容问题，如开发了手机号＋验证码登录的新方式，旧的账号密码这种关联功能容易出错
• 异常场景考虑不全面，如空值的处理问题，弱网问题，性能问题

面试题

黑盒测试的用例设计方法有哪些？ 

• 有等价类，边界值，判定表，场景法，流程图都是我经常用的
• 除此之外还有因果图，正交法，错误推断法，这几类我用的就比较少了

十、软件缺陷与缺陷管理

1.软件缺陷的概述

概念：软件的毛病，可能是UI界面/功能/兼容/易用性/性能等各个方面的问题，包括已发现的和未发现的

1.1 业内对bug的通俗理解

• 需求文档要求的功能，未实现
• 需求文档虽未明确提及但应该实现的功能，未实现
• 需求文档未提到的功能，实现了
• 软件难以理解/不宜使用/运行缓慢或（从测试人员角度看）用户认为不好

概括的说：实际与预期不一致

1.2 缺陷产生的原因

• 需求原因：文档错误/有疏漏
• 编码原因： 设计有误/编码错误
• 其他原因：时间紧，沟通问题，立项的错误

 13.描述一个缺陷的要素

• ID：唯一性
• 模块
• 缺陷标题：见名知意
• 严重程度（背）
  严重：主要功能不能用，crash，闪退、无法启动
  一般：次要功能不可以，边界/异常未进行处理
  微小：UI问题，易用性问题，建议
• 优先级
  高：阻塞问题，影响测试人员继续测试，需要立刻修复
  中：正常流程，本次迭代上线前修复即可
  低：可以延期到下个版本解决
• 复现步骤
• 预期结果
• 实际结果
• 缺陷类型：代码错误、界面错误，兼容问题，易用性错误，性能问题，安全问题
• 缺陷状态
  新建状态
  已经指派
  已修复（已解决）/拒绝/延期
  关闭

2.缺陷报告

2.1 概念

一个记录缺陷的文档

2.1 缺陷报告的组成

缺陷描述的全部内容，还有测试人员，测试日期，解决文员，解决时间，解决方案

功能验证表（不好管理）

只需要在测试用例的基础上，加上测试结果，测试人员，测试日期，解决人员，解决日期，解决方案等

3.禅道

背景

略

禅道的工作流

测试用例管理介绍

步骤：

1.编写用例：测试-->用例 -->创建用例

2.用例评审：导出-->线下进行评审

3.执行测试用例

说明：

基于互联网产品的迭代节奏，一般更倾向于直接用Excel来管理测试用例，或者思维导图管理测试点（而不写用例）