软件测试基础

一、软件测试简介

• 软件：控制计算机硬件的工具，程序+数据+文档
• 软件测试：使用技术手段验证软件是否满足使用需求
• 目的：减少软件缺陷，保障软件质量

软件的分类

• 按层次划分（系统软件和应用软件）
• 按组织划分（商业软件和开源软件）
• 按结构划分（单机软件和分布式软件）

缺陷：所有不满足需求或超出需求的都是缺陷

• 1.软件未实现产品说明书要求的功能
• 2.软件出现了产品说明书指明不应该出现的功能
• 3.软件实现了产品说明书未提到的功能
• 4.软件未实现产品说明书虽未明确提及但应该实现的目标
• 5.软件难以理解、不易使用、运行缓慢或者（从测试的角度看）最终用户会认为不好

正向思维

出发点：是自己确信产品是能够正常工作的评价一个程序和系统的特性和能力，并确定它是否达到期望的结果，软件测试就是以此为目的的任何行为。

反向思维

• 出发点：测试是为发现错误而执行一个程序或者系统的过程
• 测试是为了证明程序有错，而不是证明程序无错误
• 一个好的测试用例在于它能发现以前未发现的错误
• 一个成功的测试是发现了以前未发现的错误的测试

EEE定义的测试

• 在规定条件下运行系统或构件的过程：观察和记录结果，并对系统或构件的某些方面给出评价
• 分析软件项目的过程：检测现有状况和所需状况之间的不同，并评估软件项目的特征

广义软件测试定义

• 软件测试是对软件形成过程中的所有工作产品（包括程序以及相关文档）进行测试，而不仅仅是对程序的运行进行测试
• 确认（Validation）：通过检查和提供客观证据来证实特定目的的功能或应用是否已经实现（简：证实功能是否实现）
• 验证（Verification）：通过检查和提供客观证据来证实指定的需求是否满足

软件测试的目的

• 以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷，保证各种错误和缺陷得以修复，避免软件发布后由于潜在的软件错误和缺陷造成的隐患所带来的商业风险
• 同时利用测试过程中得到的测试结果和测试信息，作为后续项目开发和测试过程改进的重要输入，避免在将来的项目开发和测试中重复同样的错误
• 采用更加高效的测试管理手段，提高软件测试的效率和软件产品的质量

测试和调试的区别：在主体、目标、方法和思路上各不相同

软件危机和软件工程

软件危机 是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象

软件工程包括两方面的内容：

• 软件开发技术：软件开发方法学、软件工具和软件工程环境
• 软件项目管理：软件质量、项目估算、进度控制、人员组织、配置管理、项目计划

引起软件危机的主要问题是软件质量问题，软件工程主要解决的就是软件质量问题，软件测试是软件质量管理体系中一个非常重要的手段

Dos命令

1.测试主流技术

• 功能测试:验证程序的功能是否满足需求
• 自动化测试：使用代码或者工具代替手工，对项目进行测试
• 接口测试：使用代码或者工具对服务端提供的接口进行测试
• 性能测试：模拟多人使用软件，查找服务器缺陷

2.测试分类

2.1按测试阶段划分

• 单元测试：针对源代码进行测试，其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。
• 集成测试：接口测试，针对模块间访问地址进行测试，集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统
• 确认测试（功能是否实现）
• 系统测试：对整个系统进行测试包括功能、兼容、文档测试等，并最终满足用户的所有需求
• 验收测试：内测和公测，使用不同人群来发掘项目缺陷。一般供求双方。

一般有三种验收测试的主体。

• α测试：软件的开发商自己进行的交付前的测试
• β测试：软件的需求方自己的测试
• γ测试：第三方的软件测试

2.2按代码可见度划分

• 黑盒测试：UI功能可见
• 灰盒测试：部分源代码可见
• 白盒测试：全部代码可见

2.3按照代码运行划分

静态测试

指不实际运行被测对象，而只是静态地检查程序代码、界面或文档中可能存在错误的过程

• 代码测试：主要测试代码是否符合相应的标准和规范
• 界面测试：主要测试软件的实际界面与需求中的说明是否相符
• 文档测试：主要测试用户手册和需求说明是否真正符合用户的实际需求

动态测试

指实际运行被测对象，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。所以我们判断一个测试属于动态测试还是静态测试，唯一的标准就是看是否运行程序

2.4按照软件特性划分

功能测试：是黑盒测试的一方面，它检查实际软件的功能是否符合用户的需求

• 逻辑功能测试
• 界面测试
• 易用性测试
• 安装/卸载测试
• 兼容性测试

性能测试

• 功能的另一个指标，主要关注软件中的某一功能在指定的时间、空间条件下，是否使用正常

• 软件的性能包括很多方面，主要有时间性能和空间性能两种

安全性测试

验证安装在系统内的保护机制能否在实际应用中对系统进行保护，使之不被非法入侵，不受各种因素的干扰

2.5 按照测试技术划分

黑盒测试

通过软件的外部表现来发现其缺陷和错误。黑盒测试法把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试，他只是检查程序是否按照需求规格说明书的规定正常实现

白盒测试

通过对程序内部结构的分析、检测来寻找问题。白盒测试可以把程序看成装在一个透明的盒子里，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。白盒测试又称结构测试

灰盒测试

介于白盒测试与黑盒测试之间的测试。灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态

2.6按照测试运行主体划分

手工测试（功能测试）

自动化测试：利用工具软件，或者编写代码的方式，测试被测的软件系统

其他测试

回归测试

是指对软件的新版本测试时，重复执行之前某一个重要版本的所有测试用例

目的：

• 验证之前版本产生的所有缺陷已全部被修复
• 确认修复这些缺陷没有引发新的缺陷

冒烟测试

是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。也叫可测性测试

随机测试

是指测试人员基于经验和直觉的测试，发现一些边缘性的错误

猴子测试

把自己当成不懂产品的笨蛋或者小动物，随便乱点，没有任何的主管意识和想法参与进来，让一些意想不到的操作造成错误的结果

3.模型：衡量一个优秀软件的维度

4.测试流程、测试用例

• 用例：客户使用的案例
• 测试用例：为测试项目而设计的执行文档
• 测试用例的作用：防止漏测、实施测试的标准

5.软件的生命周期

软件生命周期也叫软件开发过程模型、软件生命周期模型。在软件开发的几十年实践中，人们总结了很多软件开发模型用来描述和表示一个复杂的开发过程，也展示出软件从无到有再到消亡的过程。

软件测试流程

• 获取测试需求
• 编写测试计划
• 制定测试方案
• 开发与设计测试用例
• 执行测试
• 提交缺陷报告
• 测试分析与评审
• 提交测试总结
• 准备下一版本测试

5.1 瀑布模型

瀑布模型是描述软件生产到消亡的过程模型图，该模型目前实际工作中已不常用，但是该模型是其他模型的鼻祖。

瀑布模型的优点：

1. 每个阶段比较清楚，并且有相对应的文档产生。
2. 当前一个阶段完成后，才开始后面的阶段（一次性的）。

瀑布模型的缺点：

1. 发现问题的时机比较晚，失去提前纠错的机会。
2. 测试介入比较晚。

适应场景：

适用于需求不易发生改变的大项目。

快速原型

应用领域越来越多。

原型：就是一个模型。可以模拟操作、简单运行。

典型应用和工具：Axure（工作原理：制作原型）

增量模型：该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。

5.2敏捷开发模型

能够适用需求的变化，并且能够给出快速的响应。

1）V模型

• V模型的作用：主要描述测试、开发之间的对应关系。
• V模型是瀑布模型的变种，反应测试活动与需求分析、产品设计之间的关系。
• V模型从左到右，描述了开发与测试过程之间的阶段对应关系。

• V模型的优点：每个阶段比较清楚，测试过程由底层（代码）到高层（应用）测试过程。

• V模型的缺点：不适用于需求的更改。

2）W模型

W模型，简称“双V”模型，即以开发主导的一个“V”，和以测试主导的另一个“V”构成，为了克服V模型的缺点，引入了W模型。

W模型的优点：

• 测试介入时间早，能够及时发现问题，降低修复成本。
• 测试伴随整个软件生产周期，除了测试软件之外，还需要验证文档。

W模型的缺点：

• 该模型应用起来复杂度高（具备计算机技能、业务能力、管理能力、测试素质）

3）H模型

H模型将测试活动完全独立出来，形成了一个完全独立的流程，将测试准备活动和测试执行活动清晰地体现出来

H模型揭示了一个原理：软件测试是一个独立的流程！

H模型指出软件测试要尽早准备，尽早执行；只要某个测试达到准备就绪点，测试执行活动就可以开展，并且不同的测试活动可按照某个次序先后进行，也可以反复进行

4）X模型

X模型也是对V模型的改进，X模型提出针对单独的程序片段进行相互分离的编码和测试，此后通过频繁的交接，通过集成最终合成为可执行的程序

X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试吗，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误

测试过程（工作独立性）

A：研发团队内部的测试岗位

B：企业内部的独立于研发部门的测试岗位

C：专门的测试外包公司的岗位

D：开发人员自己测试

测试独立性由高到低排序：C>B>A>D

5.3迭代模型

迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他元素，强调开发的深入

在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：需求分析、设计、实施和测试工作流程

迭代过程具有以下优点：

• 降低了在一个增量上的开支风险。
• 降低了产品无法按照既定进度进入市场的风险。
• 加快了整个开发工作的进度。
• 迭代过程这种模式使适应需求的变化会更容易些。

5.4螺旋模型

1. 螺旋模型：是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。

   • 引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。
   • 螺旋模型更适合大型的昂贵的系统级的软件应用

二、软件测试过程

尽早测试

• 测试人员早期参与软件项目
• 尽早的开展测试执行工作

全面测试

• 对软件的所有产品进行全面的测试
• 软件开发及测试人员（有时包括用户）全面的参与到测试工作中

全过程测试

• 测试人员要充分关注开发过程
• 测试人员要对测试的全过程进行全程的跟踪

独立的、迭代的测试

• 测试活动是独立的
• 测试活动应该是循环往复、不断的进行

三、测试方法

1.黑盒测试用例

1.1等价类划分法

• 等价类边界法关注单个输入类条件的测试

案例

重点：

• 正向用例：一条尽可能覆盖多条
• 逆向用例：每一条数据，都是一条单独用例

1.2边界值分析法：

解决边界限制问题 边界范围说明

• 上点 ： 边界上的点（红色）
• 离点 ： 离边界最近的点（黄色）
• 内点 ： 范围内的点（蓝色）

• 有关范围限制，最多7条用例（暂时未优化）
• 边界值能解决位数限制问题，但不能解决类型问题（结合等价类）

步骤：

• 明确需求
• 确定有效和无效等价类
• 确定边界范围
• 提取数据编写用例

优化（7点优化5点）

重点：开内闭外（开区间选包含的点，闭区间选不包含的点）

优化策略

• 结论：7个优化成5个点
• 上点：必选（不考虑区间开闭）
• 内点：必选（建议选择中间范围）
• 离点：开内闭外（考虑开闭区间，开区间选择内部离点，闭区间选择外部离点）

总结

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

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

1.3因果图法

• 原因和结果的关系

  1. 恒等：原因A成立，结果B一定成立
  2. 非：原因A成立时，结果B一定不成立
  3. 或：原因A,B,C三者只要有一个成立，结果D就一定成立
  4. 与：原因A,B,C都成立时，结果D才会成立

原因之间的约束

• 假如原因成立用1表示，不成立用0表示。
• 互斥(eclusive)。也就是A+B+C≤1
• 包含(include)。3≥A+B+C≥1
• 唯一(only)。A+B+C=1
• 要求(request)。原因A成立，要求B一定先成立

结果之间的约束

屏蔽(mask)。结果之间会出现A结果，B结果一定不出现。当你收到注册成功的提示，就一定不会收到数据填写错误的提示

案例

1.4判定表法

• 考虑输入条件之间的各种组合、输入条件与输入结果之间有相互制约关系的测试
• 一种以表格形式表达多条件逻辑判断的工具

组成部分：

1. 条件桩：所有条件
2. 动作桩：所有结果
3. 条件项：针对条件桩的取值
4. 动作项：针对动作桩的取值

条件	是否关机、是否欠费
操作	是否允许主被呼叫

书写步骤：

1. 列出所有条件和动作桩
2. 填写条件和动作桩中的项目
3. 简化判定表

注意：如果出现“-“代表此选项不影响最终结果。

规则：

• 判定表中贯穿条件项和动作项的一列就是一条规则
• 假设有n个条件，每个条件的取值有0和1，全组合有2的n次方种规则

案例：

• 正确的账号密码登录成功
• 用户名和密码为空：提示用户名或密码不能为空
• 用户名输入错误：提示用户名或密码错误，用户名和密码清空
• 用户名正确，密码错误，提示：密码错误，用户名保留，密码清空

生成判定表如下图

1.5场景法

• 流程图：使用标准图形和箭头来表达程序或业务的走向，visio工具

场景1：输入正确手机号 --->输入正确验证码

场景2：输入错误的手机号 --->输入正确的邮箱--->输入正确验证码

场景3：输入错误的手机号 --->输入错误的邮箱 --->报错L

场景4：输入正确的手机号 --->输入错误的验证码 --->报错M

1.6 错误推测法

• 定义：通过经验推测系统可能出现的问题
• 思想：根据经验列举可能出现问题的清单，根据清单分析问题可能原因，推测发现缺陷
• 场景：时间紧，根据类似经验找出易出错模块重点测试，或者对之前问题出现较多模块再次测试

1.7正交试验法

核心概念：

• 影响试验结果的——试验因素（因子）、因素
• 每一个因素的不同取值（状况）——水平

1.8 功能图法

1.9测试大纲法

特点：1. 着眼于需求。进行详细的需求分析，将其转化为思维导图（树形结构）

   2. 无需用例设计。一般从根节点开始分析，到叶节点为止。这样一条路径就是一条测试用例
   3. 一般用于快速的测试和过程记录。用例一般进行后补

1.10方法选择

三、软件缺陷

• 软件使用中存在的任何问题都是软件的缺陷

缺陷的判定标准

• 软件未实现需求（规格）说明书中明确要求的功能 --- 没有做
• 软件出现了需求（规格）说明书中指明不应该出现的错误 --- 做错了
• 软件实现的功能超出需求（规格）说明书指明的范围 --- 做多了
• 软件未实现需求（规格）说明书虽未明确指明但应该实现的需求 --- 没做完
• 软件难以理解，不易使用，运行缓慢，用户体验不好 --- 不完美

1. 缺陷的属性

1.1缺陷类型

注意：需求分析、设计阶段，文档类型的缺陷多；集成测试阶段，一般接口类型的缺陷多；系统测试阶段，功能、界面类型的缺陷多。验收测试阶段，更多的关注性能缺陷；实施过程，可能会遇到一些软件包的缺陷。

1.2缺陷的严重程度

注意：结合缺陷的影响，结合软件的具体功能（业务或者流程）

1.3缺陷的修复优先级

注意：优先级的衡量，一般可以根据测试测试的软件系统的全业务流程划分，软件的基本功能的缺陷，优先级高，甚至需要立即解决。软件的备选流、基本功能测试中的反向测试的内容，优先级较低，甚至有些可改可不改

1.4缺陷的状态

2.产生原因阶段

1. 需求阶段：需求描述不易理解，有歧义、错误等。
2. 设计阶段：设计文档存在错误或者缺陷。
3. 编码阶段：代码出现错误（语法、单词、标点符号等）。
4. 运行系统：软硬件系统本身故障导致软件缺陷。
5. 故障解决阶段：对于系统不熟悉修复问题时引入新bug。

缺陷的生命周期

• 发现缺陷。由测试人员。开发也能知道自己哪里写错了，但不会广而告之
• 提交缺陷。由测试人员。开发更不可能提交bug
• 确认缺陷。一般由测试主管、或质量保证（QA）、由产品经理进行确认
• 分配缺陷。经确认后，有效的缺陷会指派给相关人员进行处理。一般由谁确认的缺陷，就由谁分配。分配的对象可能是开发、也可能是UI、也可可能是产品经理
• 修复缺陷。主要由开发修复，也有可能是产品经理修复问题，也有可能是UI修复问题
• 验证缺陷。测试去验证缺陷有没有修复成功
• 关闭缺陷。只能说测试人员进行。否则出了问题，测试人员一律不背锅

问题: 你认为上述生命周期的阶段中，哪个阶段出现问题的比例最高？

• 需求阶段，出现问题比例高。
• 需求阶段文档编写不完善、需求容易发生变化等都是造成bug的根本原因。

3.缺陷报告的核心内容

• 缺陷的标题 --- 描述缺陷的核心问题 ---> 错误问题的结论+【现象】
• 缺陷的预置条件 --- 缺陷产生的前提 ---> 和测试用例的预置条件一样
• 缺陷的复现步骤 --- 复现缺陷的过程 ---> 和测试用例的测试步骤基本一致（含测试数据）
• 缺陷的预期结果 --- 希望得到的结果 ---> 和测试用例的预期结果一致
• 缺陷的实际结果 --- 实际得到的结果 ---> 实际的错误问题描述（结论+错误现象）
• 缺陷的必要附件 --- 图片、日志等信息（证据）---> 方便开发判定问题出现的具体位置

3.1缺陷报告的其他要素

缺陷的编号：能够唯一的表示一个缺陷

缺陷的状态：描述缺陷生命周期的过程

• 新建（new）：表示缺陷的产生
• 打开（open）：表示开发确认通过
• 拒绝（rejected）：表示开发确认不通过
• 进行中（inprogress）：表示开发正在修复缺陷
• 已修复（fixed）：表示开发已经修复完成
• 延迟修复（delay/postpone）：表示开发延迟修复
• 测试通过（closed）：表示测试通过，已关闭
• 测试不通过（reopen/open）：表示测试不通过，重新打开

缺陷的所属模块：类似于用例的所属项目，描述缺陷产生的模块范围

缺陷的优先级：告诉开发当前缺陷修改的先后次序（p1）priority

• urgent priority：最高优先级
• veryhigh prioity：次高优先级
• high prioity：高优先级
• mediun prioity：中优先级
• low prioity：低优先级

缺陷的严重级：告诉产品当前缺陷对于整个产品的破坏程度（和优先级一一对应）（s1）serious

• critical：致命的破坏
• major：高的破坏性
• medium：中等破坏
• minor：低等破坏
• tiny：微小的破坏

缺陷的类型：描述缺陷主要产生问题的原因

• 功能问题
• UI问题
• 兼容性问题
• 易用性问题
• 架构问题
• 安全问题

由此引出的问题：作为测试人员，一般什么时候提交缺陷报告？能否可以直接口头传达不写缺陷报告？

• 执行测试用例，并且失败的时候，就立即停止执行马上提交bug。
• 不能，防止忘记之后无法保留证据。

4.缺陷的跟踪流程

4.1相关问题

问题：开发能否直接关闭缺陷？

• 不能，因为留存证据，即使报错了，开发只能拒绝，不能关闭。

编写缺陷报告规范

• 可复现：确保当前发现的bug能够复现。
• 唯一性：确保一个缺陷报告中上报一个问题。
• 规范性：遵循公司规定的报bug的要求。

编写缺陷报告的注意事项

• 确保上报的bug是准确的。
• 描述尽可能简洁易懂具体。
• 不能使用感情色彩的词语。
• 不能使用模棱两可的词汇。
• 不能使用人称代词。

面试题：在实际测试中如果出现不可复现的bug怎么办？

• 经过多次复现后，还是没有出现，此时在本地记录当前的问题
• 回顾当时操作的流程及测试环境的配置要求，确认是否由于操作失误或者环境临时故障引起
• 请开发协助（自己）查找当前测试模块是否有对应的日志信息（日志的位置可以问开发）
• 再考虑更换一套环境查看是否能够复现上述问题
• 在后续的版本中测试，此时需要关注当时测试该功能时是否还出现上述的问题
• 在后续版本还出现过，需要开发协助打印日志进行分析定位，同时测试需要提交bug

4.2缺陷管理工具-禅道

管理缺陷 管理用例