---

🔎根据测试对象划分

界面测试

界面测试(简称UI测试)
指按照界面的需求(一般是UI设计稿)和界面的设计规则
对我们软件界面所展示的全部内容进行测试和检查

界面测试一般包括

• 验证界面内容显示的完整性, 一致性, 准确性, 友好性
  (例如界面内容对屏幕大小的自适应, 换行, 内容是否全部清晰展示)

• 验证整个界面布局和排版是否合理, 不同板块字体的设计, 图片的展示是否符合需求

• 对界面不同控件的测试
  (例如对话框, 文本框, 滚动条, 选项按钮等是否可以正常使用. 有效和无效的状态是否设计合理)

• 界面的布局和色调符合当下的发展
  (例如汶川地震的日子, 界面是否应呈现黑白色展示)

可靠性测试

可靠性即可用性
指系统正常运行的能力或程度, 一般用正常向客户提供软件服务的时间占总时间的百分比表示

可靠性 = 正常运行时间 / (正常运行时间 + 非正常运行时间) * 100%

系统非正常运行的时间可能是由于硬件, 软件, 网络故障或任何其他因素(断电, 地震, 火灾…)造成的, 这些因素能让系统停止工作, 或者连续中断不能访问, 或者性能急剧下降导致不能使用软件现有的服务

可靠性指标一般要求达到
(1)
4个9 --> 99.99%
(2)
5个9 --> 99.999%

• 对于一个全年不间断(7 * 24 h)运行的系统, 全年时间为252600 min
  • 如果可用性达到99.99%, 意味着全年不能正常工作的时间只有52 min
  • 如果可用性达到99.999%, 意味着全年不能正常工作的时间只有5 min

容错性测试

容错性测试
指系统能够处理异常, 由于用户的错误操作而不至于系统崩溃, 从而提高系统的可用性

容错性测试一般包括

• 输入异常数据或进行异常操作, 以校验系统的保护性. 如果系统的容错性较好, 系统只给出提示或内部消化掉, 而不会导致系统出错甚至崩溃
  (例如数据级测试, 校验测试, 环境容错性测试, 界面容错性测试)

• 灾难恢复性测试
  (例如通过各种手段, 让软件强制性地发生故障, 然后验证系统已保存的用户数据是否丢失, 系统和数据能否尽快恢复)

文档测试

文档测试
指检验样品用户文档的完整性, 正确性, 一致性, 易理解性, 易浏览性

文档一般可分为

• 开发文件
  (例如可行性研究报告, 软件需求说明书, 数据要求说明书, 概要设计说明书, 详细设计说明书, 数据库设计说明书, 模块开发卷宗)

• 用户文件
  (例如用户手册, 操作手册)

  • 用户文档的作用
    (改善易安装性, 改善软件的易学性与易用性, 改善软件可靠性, 降低技术支持成本)

• 管理文件
  (例如项目开发计划, 测试计划, 测试分析报告, 开发进度月报, 项目开发总结报告)

文档测试的关注点
(1)
文档的术语
(2)
文档的正确性
(3)
文档的完整性
(4)
文档的一致性
(5)
文档的易用性

兼容性测试

兼容性测试
指明确要测试的兼容环境, 考虑软, 硬件的兼容

对于软件的兼容性, 一般要考虑

• 系统自身的兼容版本, 用户已有数据的兼容
  (数据兼容是重中之重. 对于用户来说, 数据是最有价值的)

• 测试与应用环境的兼容
  (与操作系统, 应用平台, 浏览器的兼容…)

• 测试与第三方系统以及第三方数据的兼容性

对于环境(操作系统, 应用平台)兼容性的测试不仅仅局限在操作系统, 浏览器这两个因素
还包括
(1)
32位, 64位的CPU
(2)
支持不同的Internet连接速度

对于IOS 和 Android这两个平台, 还要区分手机和平板, 考虑不同的型号(屏幕尺寸, 分辨率…)

易用性测试

易用性
指容易发现, 容易学习和容易使用

易用性包含七个要素

• 符合标准和规范

• 直观性

• 一致性

• 灵活性

• 舒适性

• 正确性

• 实用性

符合标准和规范

对于现有的软件运行平台, 通常其UI 标准已经不知不觉地被确立了, 成为大家的共识
多数用户已经习惯并且接受了这些标准和规范, 或者说已经认同了这些信息所代表的含义
(例如安装软件的界面外观, 在什么场合使用恰当的对话框…)

直观性

要求软件功能特性清晰, 易懂. 用户界面布局合理, 对操作的响应在用户的预期之中, 对操作的响应在用户的预期之中
(例如数据统计结果用报表的形式(条形图, 扇形图…)展示清晰直观)

灵活性

软件可以有不同的选项以满足不同使用习惯的用户来完成相同的功能
但是灵活性的设计要把握好度, 不然可能由于太多的用户状态和方式的选择, 增加了软件设计的复杂性和程序实现的难度
(例如手机键盘有九宫格和全键盘, 还支持手写, 满足了不同用户的需求)

舒适性

主要强调界面友好, 美观, 操作过程顺畅, 色彩运用恰当, 按钮的立体感…
(例如左手鼠标的设置给习惯用左手的人带来了便利, 也为右手十分劳累时提供了另一种途径)

安装卸载测试

安装卸载测试主要考虑

• 软件不同的安装和卸载方式
• 应用是否可以在不同系统, 版本下安装(安装兼容性)
• 安装或卸载过程种是否可以手动暂停, 或者取消
• 安装空间不足时否系统是否会提示
• 是否可以正常的卸载, 以及应用软件的各种卸载方式
• 卸载和安装过程中出现环境问题, 软件是否可以正常并且合理的应对
  (例如死机, 断电, 断网…)

安全性测试

安全性
指信息安全, 即计算机系统或网络保护用户数据隐私, 完整, 保护数据正常传输和抵御黑客, 病毒攻击的能力

系统常见的安全漏洞和威胁包括

• 输入域
  (例如输入恶性或者带有病毒的脚本或长字符串)
• 代码中的安全问题
  (例如SQL注入, XML注入…)
• 不安全的数据存储或者传递
• 数据文件, 邮件文件, 系统配置文件等里面有危害系统的信息或数据
• 有问题的访问控制, 权限分配等
• 假冒ID
  (例如身份欺骗)
• 篡改, 对数据的恶意修改, 破坏数据的完整性

安全性测试的方法有代码评审, 渗透测试, 安全运维等

常用的静态安全测试工具有
(1)Coverity (2)IBM Appscan Source (3)HPFortify…
常用的动态安全测试工具有
(1)OWASP 的ZAP (2)HP WebInspect

其中静态安全测试是常用的安全性测试的方法

性能测试

在使用软件时有时会碰到软件网页打开越来越慢, 查询数据需要很长时间才显示列表, 软件运行越来越慢等问题
这些问题都是系统的性能问题引起的

常见的性能问题包括

• 资源泄漏
• 资源瓶颈
• 线程死锁
• 线程阻塞
• 查询速度慢或效率低
• 受外部系统系统影响越来越大

衡量一个系统性能好坏的关键指标包括

• 响应时间
• 吞吐量
• 每秒点击次数
• 内存和CPU 使用率

内存泄漏测试

从用户使用的角度来看, 内存泄漏本身不会造成什么危害
一般用户可能不会感觉到内存泄漏的存在
但是内存泄漏是会累积的, 只要执行的次数足够多, 最终会耗尽所有可用内存, 使软件的执行越来越慢, 最后停止响应

造成内存泄漏的原因包括

• 分配内存后忘记回收
• 程序有问题, 造成无法回收
  (例如死循环造成无法执行到回收步骤…)
• 某些API 函数的不正确使用, 造成内存泄漏

内存泄漏的检测方法

• 人工静态法: 代码走读, 人工查找未被回收的内存
• 自动工具法: 借助相应测试内存泄漏的工具, 如Visual Leak Detector, 记录每次内存的分配, 清楚的告诉用户内存是如何泄漏的

🔎根据是否查看代码划分

黑盒测试

黑盒测试(又称为数据驱动测试)
指完全不考虑程序逻辑和内部结构的情况下
检查系统功能是否按照需求规格说明书的规定正常使用
是否能适当的接收输入数据从而输出正确的结果, 满足规范需求

黑盒测试的优点

• 不需要了解程序内部的代码及实现, 不关注软件内部的实现
• 从用户角度出发设计测试用例, 很容易的知道用户会用到哪些功能, 会遇到哪些问题, 锻炼测试人员的产品思维
• 测试用例基于软件需求开发文档, 不容易遗漏软件需求文档中需要测试的功能

黑盒测试的缺点

• 不可能覆盖所有的代码

白盒测试

白盒测试(又称为结构测试或逻辑测试)
一般用于分析程序的内部结构, 针对程序的逻辑结构设计测试用例进行测试

白盒测试的目的
通过检查软件内部的逻辑结构, 对软件中的逻辑路径进行覆盖测试
在程序不同地方设立检查点, 检查程序的状态, 以确定实际运行状态与预期状态是否一致

白盒测试主要包括六种测试方法

• 语句覆盖
• 判定覆盖
• 条件覆盖
• 判定条件覆盖
• 条件组合覆盖
• 路径覆盖

灰盒测试

灰盒测试
介于黑盒测试与白盒测试之间的一种测试
多用于集成阶段测试, 不仅关注输入, 输出的正确性. 同时也关注程序内部的情况

🔎根据开发阶段划分

单元测试

单元测试(又称为模块测试)
指对软件的基本组成单元进行测试

单元测试的目的
检验软件基本组成单位的正确性

单元测试
测试阶段	编码前或编码后
测试对象	模块(软件设计的最小单位)
测试人员	白盒测试工程师或开发工程师
测试依据	代码, 注释, 详细的设计文档
测试方法	白盒测试
测试内容	模块接口测试, 局部数据结构测试, 路径测试, 错误处理测试, 边界测试

集成测试

集成测试(又称联合测试(联调), 组装测试)
指将程序模块采用适当的集成策略组装起来, 对系统的接口及集成后的功能进行正确性检测的测试工作

集成测试的目的
检查软件单位之间的接口是否正确

集成测试
测试阶段	一般在单元测试之后进行
测试对象	模块之间的接口
测试人员	白盒测试工程师或开发工程师
测试依据	单元测试的模块 + 概要设计文档
测试方法	黑盒测试 + 白盒测试
测试内容	模块之间数据传输, 模块之间功能冲突, 模块组装功能正确性, 全局数据结构, 单模块缺陷对系统的影响

系统测试

系统测试
指对整个系统的测试. 将硬件, 软件, 操作人员看作一个整体, 检验它是否有不符合系统说明书的地方
包括对功能, 性能以及软件所运行的软硬件环境进行测试

系统测试
测试阶段	集成测试通过之后
测试对象	整个系统(软, 硬件)
测试人员	黑盒测试工程师
测试依据	需求规格说明书
测试方法	黑盒测试
测试内容	功能, 界面, 可靠性, 易用性, 性能, 兼容性, 安全性…

回归测试

回归测试
指修改了原有的代码之后, 重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误

回归测试在整个软件测试过程中占有很大的工作量比重, 软件开发的各个阶段都会进行多次回归测试

冒烟测试

冒烟测试
测试阶段	正式进行系统测试之前执行
测试对象	每一个新编译的需要正式测试的软件版本

回归测试和冒烟测试都属于系统测试

验收测试

验收测试(又称为交付测试)
是部署软件之前的最后一个测试操作

验收测试的目的
确保软件准备就绪, 按照项目合同, 任务书, 双方约定的验收依据文档, 向软件购买者展示该软件系统满足原始需求

验收测试
测试阶段	系统测试通过之后
测试对象	整个系统(软, 硬件)
测试人员	主要是最终用户或需求方
测试依据	用户需求, 验收标准
测试方法	黑盒测试
测试内容	功能, 界面, 可靠性, 易用性, 性能, 兼容性, 安全性…

🔎根据实施组织划分

α测试

α测试
指由一个用户在开发环境下进行的测试
也可以是公司内部的用户在模拟实际操作环境下进行的测试

α测试的目的
评价软件产品的FLURPS(功能, 局域化, 可使用性, 可靠性, 性能和支持)

大型通用软件
在正式发布之前, 通常需要执行α测试和β测试

α测试不能由程序员或测试员完成

β测试

β测试
是一种验收测试

β测试由软件的最终用户在一个或多个场所进行测试

α测试和β测试的区别
(1)
α测试是指把用户请到开发方的场所来进行测试
β测试是指在一个或多个用户的场所进行的测试

(2)
α测试的环境是受开发方控制的, 用户的数量相对较少, 时间比较集中
β测试的环境是不受开发方控制的, 用户数量相对较多, 时间不集中

(3)
α测试先于β测试执行

第三方测试

介于开发方和用户之间的测试

🔎根据是否运行划分

静态测试

静态测试
指不实际运行被测软件, 而只是静态地检查程序代码, 界面或文档中可能存在的错误的过程
仅通过分析或检查源程序的设计, 内部结构, 逻辑, 代码风格和规格等来检查程序的正确性

动态测试

动态测试
指实际运行被测程序, 输入对应的测试数据, 检查实际输出结果和预期结果是否相符的过程

大多数软件测试都属于动态测试

🔎根据是否手工划分

手工测试

手工测试
指由人去一个一个的输入用例, 然后观察结果, 和机器测试相对应
属于比较原始但是必须的步骤

手工测试
优点	能够探索性的测试, 发散思维结果的测试(自动化测试无法完成类似功能)
缺点	执行效率慢, 量大易错

自动化测试

自动化测试
指在预设条件下运行系统或应用程序, 评估运行结果. 预先条件应包含正常条件和异常条件
(就是将以人为驱动的测试行为转化为机器执行的一种过程)

自动化测试的步骤
(1)
完成功能测试, 版本基本稳定
(2)
根据项目特性, 选择适合项目的自动化工具, 并搭建环境
(3)
提取手工测试的测试用例转化为自动化测试的测试用例
(4)
通过工具, 代码实现自动化的构造输入, 自动检测输出结果是否符合预期
(5)
生成自动测试报告
(6)
持续改进, 优化脚本

🔎根据地域划分

国际化测试

国际化测试
指测试软件的国际化支持能力, 发现软件的国际化的潜在问题, 保证软件在世界不同区域中都能正常运行

本地化测试

本地化测试
本地化	将软件版本语言进行更改(例如将Windows的英文改成中文就是本地化)
测试对象	软件的本地化版本
测试目的	测试特定目标区域设置的软件本地化质量
测试环境	在本地化的操作系统上安装本地化的软件
测试方法	基本功能测试, 安装卸载测试

---

本地化测试与国际化测试的要点

本地化测试与国际化测试的要点
(1)	本地化后的软件在外观上与原来版本是否存在很大差异, 外观是否整齐, 不走样
(2)	是否对所有界面元素都进行了本地化处理(包括对话框, 菜单, 工具栏, 状态栏, 提示信息, 日志…)
(3)	在不同的屏幕分辨率下界面是否正常显示
(4)	是否存在不同的字体大小, 字体设置是否恰当
(5)	日期, 数字格式, 货币等是否可能适应不同国家的文化习俗(例如中文是年月日, 英文是月日年)
(6)	排序的方式是否考虑了不同语言的特点(例如中文按照第一个的汉语拼音顺序排序, 而英文按照首字母排序)
(7)	在不同的国家采用不同的度量单位, 软件是否能适应和转换
(8)	软件是否在不同类型的硬件上正常运行, 特别是在当地市场上销售的硬件
(9)	软件是否能在WIndows 或其他操作系统的当地版本上正常运行
(10)	联机帮助和文档是否已经翻译, 翻译后的链接是否正常. 正文翻译是否正确, 恰当, 是否有语法错误