一、软件测试分类

按阶段划分

单元测试

• 又称模块测试，针对软件设计的最小单位-程序模块，进行正确性检查的测试。单元测试需要从程序内部结构出发设计测试用例。

集成测试

• 又称组装测试，通常在单元测试的基础上，将所有程序模块进行有序的、递增的测试。重点测试不同模块之间的接口部分。

系统测试

• 把软件项目作为一个整体进行测试。测试的依据是需求说明书。
  • 到了系统测试阶段，软件基本是完成的。

验收测试

站在最终用户的角度来测试

• α测试
  • Alpha是内测版本，通常只在软件开发者内部测试
  • 一般而言，该版本软件的bug较多，普通用户最好不要安装
• β测试
  • Beta是公测版本，是对所有用户开放的测试版本
  • 这一版本通常由软件公司免费发布，用户可以相关的站点下载
  • 通过一些专业爱好者的测试，将结果反馈给开发者，开发者们再进行有针对性的修改
• γ测试
  • Gamma版本，指的是软件版本正式发行的候选版。该版本已经相当成熟了，与即将正式发行的版本相差不多

按是否覆盖源代码

黑盒测试

• 只测试功能，不关注功能的具体实现方式

白盒测试

• 不但要关注功能，还要关注代码是如何实现的

灰盒测试

• 介于黑盒和白盒之间的一种测试（接口测试倾向于灰盒测试）

按是否运行

静态测试

• 不用运行软件，静态的观察软件是否符合预期

动态测试

• 运行软件，在运行过程中测试

按是否自动化

手工测试

• 通过测试工程师手工对软件进行测试

自动化测试

• 通过编写代码，通过程序自动测试软件是否有bug

更多

冒烟测试

• 对软件最基本的流程和功能做一个粗略的测试，看最基本的流程是否能跑通。
• 在测试拿到研发的第一个版本，一般先冒烟

回归测试

• 当修复一个BUG后，把之前的测试用例在新的代码下进行再次测试。（防止拆东墙补西墙）一般是阶段性的进行回归测试

随机测试

• 随机测试主要是对被测软件的一些重要功能进行复测，也包括测试那些当前的测试用例没有覆盖到的部分

探索测试

• 针对一些新项目、新功能或者刚入职熟悉业务，一边了解和学习项目，一边测试项目

二、软件质量模型

• 功能性
  • 适合性
  • 准确性
  • 互操作性
  • 保密安全性
  • 功能性的依从性——功能之间依赖关系是否合理
• 可靠性
  • 成熟性
  • 容错性
  • 易恢复性
  • 可靠性的依从性
• 易用性
  • 易理解性
  • 易学性
  • 易操作性
  • 吸引性
  • 易用性的依从性
• 效率
  • 时间特性
  • 资源利用性
  • 效率依从性
• 维护性
  • 易分析性
  • 易改变性
  • 稳定性
  • 易测试性
  • 维护性的依从性
• 可移植性
  • 适应性
  • 易安装性
  • 共存性
  • 易替换性
  • 可移植性的依从性

三、软件开发过程模型

瀑布模型

• 需求分析
  • 研发分析需求说明书
  • 判断需求的可实现性
• 概要设计
  • 用到具体的技术点
  • 大致模块划分
• 详细设计
  • 详细到可以为编码做支持
  • 类和类的关系、类的设计
  • 函数设计
  • 各个接口的细节
  • 数据库表的关系、字段关系
• 编码
  • 依托于详细设计进行编码操作
• 软件测试
• 软件维护
  • 软件上线后也是需要持续维护的

瀑布模型的特点：

• 线性模型

  • 每一阶段都是按顺序来执行的

• 文档驱动

  • 每个阶段都要产出文档，每次开会都会产出文档

瀑布模型的优缺点：

优点：

1. 开发的各个阶段比较清晰
2. 当前一个阶段完成后，只需关注后续阶段

缺点：

1. 依赖于早期的需求调查，不适应需求的变化
2. 风险往往延至后期才显现出来，容易失去及早纠正的机会

快速原型模型（了解）

• 在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作

快速原型模型的特点

1. 快速的构建软件的原型
2. 支持用户参与

快速原型模型的优缺点

优点：

1. 克服瀑布模型的缺点，更好地满足用户的需求并减少由于软件需求不明确带来的项目开发风险

缺点：

1. 不适合大型系统的开发（适合开发小型的、灵活性高的系统）

螺旋模型（了解）

螺旋模型的特点

1. 引进了风险分析活动

螺旋模型的优缺点

优点：

1. 螺旋模型很大程度上是一种风险驱动的方法体系

缺点：

1. 采用螺旋模型需要人员具有相当丰富的风险评估经验和专业知识

四、测试过程模型

V模型

• V模型是最具有代表意义的测试模型，旨在改进软件开发的效率和效果
• V模型本身是软件开发中瀑布模型的变种，它反映了测试活动与分析和设计的关系
• V模型表明了测试过程中本身存在的不同阶段，从左到右，描述了开发过程和测试过程间的阶段对应关系

V模型的优缺点

优点：

1. 测试V模型即包含了底层测试又包含了高层测试
2. 每个步骤都是文档驱动

缺点：

1. 当需求变更时将会导致阶段反复，返工量非常大，模型灵活性比较低

W模型（认识）

• 测试伴随着整个软件开发周期，并且测试的对象不仅仅是程序，需求和设计同样要测试

double V = W

W模型的优缺点

优点：

1. 强调测试伴随整个软件开发周期，而且测试的对象不仅仅是程序，需求和概要设计同样要测试
2. 更早的介入测试，可以发现开发初期的缺陷，那么可以用更加低的成本进行缺陷修复

缺点：

1. 使用起来技术复杂度高，对于需求和设计的测试要求高，实践起来困难

五、测试用例

测试用例的定义

• Test Case——为特定的目的而设计的一组测试输入，执行条件和预期结果的文档

测试用例八大要素

• 用例编号
• 用例标题
• 测试项目
• 用例级别
• 前置条件
• 测试输入
• 执行步骤
• 预期结果

测试用例模板

六、测试用例设计方法

等价类划分法

等价类概念：在所有测试的数据中，具有某种共同特征的数据子集

等价类分为：

1. 有效等价类：满足需求、符合预期的
2. 无效等价类：不满足需求的

等价类操作步骤：

1. 明确需求
2. 确定有效和无效等价类
3. 编写测试用例

每一条等价类对应一条测试用例

边界值分析法

• 边界范围
  • 确定边界情况（输入或输出等价类的边界）
  • 选取正好等于、刚刚好大于或刚刚好小于边界的值作为测试数据
• 三点
  • 上点：边界上的点（正好等于）
  • 离点：距离上点最近的点（上点在范围内，则离点在范围外；反之亦然）开离内，闭离外
  • 内点：范围内的点

边界值分析操作步骤

1. 明确需求
2. 确定有效和无效等价类
3. 确定边界值
4. 编写测试用例

判定表法

• 有多个输入、有多个输出，输入和输出有组合和依赖关系
• 判断表通常由四个部分组成
  1. 条件桩：列出了系统的所有输入，列出的输入次序无关紧要
  2. 动作桩：列出了系统可能采取的操作，这些操作的排列顺序没有约束
  3. 条件项：列出针对它左列输入的取值，在所有可能情况下的真假值
  4. 动作项：列出在输入项的各种取值情况下应该采取的动作

判定表设计步骤

1. 明确需求
2. 画出判定表
   • 明确条件桩、动作桩
   • 填写条件项，对条件进行全组合
   • 明确每个条件组合对应的动作项
3. 生成测试用例，判定表每条规则对应一条测试用例

因果图法

• 因果图法的核心
  • 因果图的“因”——输入条件
  • 因果图的“果”——输出结果

什么是因果图法

• 用图解的方法表示输入的各种组合关系，写出判定表，从而设计相应的测试用例
• 适用范围：适用于分析程序输入条件的各种组合情况，以及输入与输出之间的依赖关系

因果图法的基本步骤

1. 明确需求
2. 画出因果图
3. 将因果图转换为判定表
4. 根据判定表写测试用例

正交法

在测试时，由于组合量太大，不可能为每一种组合都创建测试用例，如何采用最少的测试用例集合获得最大的测试覆盖——正交排列法

正交排列法：用最小的测试用例集覆盖最大的范围

正交表法设计测试用例

1. 明确需求
2. 画出正交表
   • 明确需求中的因素数与水平数
   • 根据因素数和水平数选取正交表
   • 用需求中的文字代替正交表中的字母
3. 写出测试用例

正交表的一行就代表一条测试用例

场景法

什么是场景法

• 场景法是用流程图描述用户的使用场景，然后通过覆盖流程路径来设计测试用例

场景法的意义

• 用户角度：用户平时使用的不是单个功能，而是多个功能组合起来进行使用
• 测试人员角度：平时测试的都是单个功能点进行测试，容易忽略多个功能的组合测试

场景法设计测试用例步骤

1. 明确需求
2. 画出流程图
3. 编写测试用例
   • 流程中有多少路径对应多少条测试用例

错误推测法

• 错误推测法是指利用直觉和经验推测出出错的可能类型，有针对性列举出程序中所有可能的错误和容易发生错误的情况，它是测试经验丰富的测试人员喜欢使用的一种测试用例设计方法

基本思想

• 基本思想是列举出可能犯的错误或错误易发生的清单，然后根据清单编写测试用例

使用场景

• 项目紧任务急、时间不够，这是就不能按部就班的测试了，根据之前的项目经验，找到之前出错过的类似模块进行重点测试
• 所有正常测试结束后，通过错误推断法再测试一些之前出过问题的模块

七、缺陷管理

软件缺陷的定义

• 软件或者程序中存在的各种问题及错误

软件缺陷的判定标准

1. 软件未达到需求规格说明书标明的功能
2. 软件出现了需求规格书说明不会出现错误的地方
3. 软件的功能超出了需求规格说明书指明的范围
4. 软件没有实现需求规格说明书虽未指明，而应该达到的需求
5. 软件测试人员认为软件难以理解，不易使用，运行速度慢，或者最终用户体验不好

软件缺陷产生的原因

软件缺陷产生是不可避免的，造成软件缺陷产生的原因主要归纳如下：

1. 需求解释、记录或者定义错误
2. 设计文档说明存在错误或者拼写错误
3. 编码说明、程序代码有误
4. 硬件或者软件系统上存在错误

软件缺陷产生的根源

• 需求的变更
• 交流不充分
• 软件的复杂性
• 进度压力

软件缺陷的信息

缺陷的状态

• new：新建状态
• open：打开状态
  • reopen：关闭的缺陷再次出现
• fixed：修复状态
• closed：关闭状态
• rejected：拒绝状态
• postpone：拖延状态

缺陷的严重级别

• critical
• very high
• high
• medium
• low

缺陷处理的优先级

• urgent
• very high
• high
• medium
• low

缺陷类型

• 功能错误
• 界面错误
• 兼容性缺陷

缺陷报告

缺陷报告的重要性

• 错误的缺陷报告会误导开发人员，影响开发人员的效率
• 错误的缺陷报告会影响测试人员自身的声誉

缺陷报告的注意事项

• 缺陷报告本身不能有缺陷
• 尽量确保缺陷可以重现
• 简洁、准确、完整
• 一个缺陷一个报告
• 避免出现模糊的词汇
• 不能有个人感情色彩
• 复现bug过程要详细

缺陷书写规范

• 标题：应保持简短、准确，提供缺陷的本质信息

• 复现步骤：应包含如何使别人能够很容易的复现该缺陷的完整步骤

• 实际结果：是执行复现步骤后软件的现象和产生的行为

• 期望结果：描述应与实际结果的描述方式相同。通常需要列出期望的结果是什么

• 附件：对缺陷描述的补充说明，可以是缺陷症状的截图、测试使用的数据文件

• 其他常见错误

  • 避免使用我、你等人称代词，可以直接使用动词或必要时使用“用户”代替
  • 避免使用情绪化的语言和强调符号
  • 避免使用诸如“似乎”、“看上去可能”等含义模糊的词汇，而需要报告确定的缺陷结果
  • 避免提交不确定的测试问题，自己至少需要重现一次再提交

缺陷处理流程

缺陷跟踪流程

• new新建状态
  • 测试提交一个缺陷，首先就是新建状态
• open打开状态
  • 确认缺陷有效后，为打开状态
• fixed修复状态
  • 由缺陷的处理人，把缺陷处理完成后设置为修复状态
• close关闭状态
  • 验证缺陷修复后，一般由缺陷的发起人设置状态为关闭状态
• reopen重新打开状态
  • 一个已经关闭的缺陷再次出现，就要设置为重新打开状态

八、熟悉项目

熟悉项目的步骤

1. 了解项目的业务特性：项目是用来做什么的？
2. 了解项目的角色与用户：项目是给谁用的？
3. 了解项目的组织架构图：项目包括哪些功能模块？
4. 了解项目的技术栈：项目是使用哪些技术来实现的？

熟悉项目的信息来源

• 项目中已经存在的文档：需求说明书，用户使用手册，测试用例等
• 使用项目的现有环境：开发环境、测试环境、线上环境等
• 询问项目中的其他成员：测试组长/组员，开发人员，产品经理等

项目测试流程

1. 需求评审
2. 编写测试计划与测试方案
3. 测试用例设计与评审
4. 测试执行与BUG跟踪
5. 编写测试报告

需求评审

什么是软件需求？

• 软件需求是指为用户解决某一问题或达到某一目标所需的软件功能

什么是需求评审？

• 项目相关人员就软件需求进行确认和评估的相关活动

需求评审的目的

• 保证需求说明书的完整、准确
• 保证项目团队对需求的理解达成一致

需求评审的形式

• 需求评审会议

需求评审的参与人员

• 产品人员（包括原型图制作的人员）
• 开发人员
• 测试人员

测试人员在需求评审的职责

• 确认自己对需求要有清晰的理解，没有疑惑
• 确认需求文档完整，准确，能够指导后期工作
• 对需求中不合理的地方提出自己的修改建议

编写测试计划

测试计划是什么？

• 是指描述了要进行的测试活动的范围、方法、资源和进度的文档

测试计划的核心内容：

• 明确的测试目标与测试范围
• 执行计划的角色与职责
• 任务的进度安排与资源分配
• 风险评估和应急计划
• 测试的准入/准出标准

编写测试方案

测试方案是什么？

• 是从测试的技术角度分析需求，在方向上明确要怎么测，分析结果重点在于测试策略与技术实现

测试方案的核心内容：

• 测试策略
• 测试环境的规划
• 测试工具的设计和选择

编写测试用例基本要求

测试用例需求来源

1. 需求说明书
2. 产品原型图
3. UI设计图
4. 站在用户的角度，测试软件的可用性

测试用例设计步骤

1. 需求分析
2. 测点拆分
   1. 测试点是测试中需要关注的具体功能点
   2. 测试点的作用是用来拆分需求，辅助编写测试用例
3. 编写测试用例

编写测试用例的原则

1. 能看懂——确保每个用例通俗易懂
2. 能执行——每一个步骤都是能够执行的

测试结果的几种状态说明

• pass——通过
• fail——失败
• block——阻塞
• N/A——忽略

执行测试用例原则

1. 严格按照测试用例书写的步骤执行
2. 失败的用例，及时提交缺陷报告

编写测试报告

测试报告是指把测试的过程和结果写成文档，对发现的问题和缺陷进行分析，为纠正软件存在的质量问题提供依据，同时为软件验收和交付打下基础。

测试报告代表测试工作的里程碑

测试报告的主要内容：

• 测试工作的经过与结果
• 风险评估
• 缺陷汇总与分析
• 测试工作总结与改进

九、非功能测试

非功能测试主要包含：

• 兼容性测试
• 界面测试
• 易用性测试
• 性能测试
• 安全性测试

兼容性测试

兼容性指软件对不同平台、不同环境、不同分辨率的适应能力

应用场景：

什么时候考虑？

• 项目要求在不同的操作系统、不同浏览器、不同的平台、不同分辨率下操作时行为一致

关注点：

• OS
  • 不同的操作系统：Windows、Linux、mac等
  • 相同操作系统不同的版本：win7、win8、win10等
• Browser
  • 不同的浏览器，三大主流——IE、Chrome、Firefox
  • 相同浏览器不同的版本：IE8、IE9、IE11等
  • 其他常用浏览器：搜狗、360
• 分辨率

界面测试

界面测试，或称UI测试，测试用户界面的功能模块的布局是否合理、整体风格是否一致、各个控件的放置位置是否符合客户使用习惯

如何做界面测试？

• 一般情况，直接依据产品原型图以及UI效果图，进行对比验证，确认一致
• 如果没有原型图和UI效果图，可以通过以下几个方面考虑
  • 导航栏
  • 图形
  • 内容
  • 整体界面风格

易用性测试

易用性测试是指用户使用软件时是否感觉方便。简单来说：易学、易懂、易用、吸引人

关注点：

• 项目难易程度
• 适用人群
• 用户的计算机水平

性能测试

性能测试是通过测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试

什么时候考虑性能测试？

• 对软件的性能有要求
• 用户量大的项目

性能测试的目的

• 验证软件系统是否能够达到预期的性能指标
• 发现软件系统中存在的性能瓶颈，以便优化软件
• 验证稳定性：在一个生产的负荷下测试一定时间，评估系统的稳定性是否满足要求

安全性测试

什么时候考虑？

• 功能模块涉及到用户隐私信息，人身、财产安全等情况

关注点：

• 安全性：登陆时密码是否进行加密以及密码是否容易破解
• SQL注入：攻击者把SQL语句作为参数传入web应用程序，最终达到欺骗服务器执行恶意的SQL语句