软件测试分类: 你需要知道的不同类型测试

1. 按测试对象划分: 界面测试, 可靠性测试, 容错性测试, 文档测试, 兼容性测试, 易用性测试(用户体验测试), 安装卸载测试, 安全性测试, 性能测试, 内存泄露测试
2. 按是否查看代码划分: 黑盒测试, 白盒测试, 灰盒测试
3. 按开发阶段划分: 单元测试, 集成测试, 系统测试, 验收测试
4. 按测试实施组织划分: α, β, 第三方测试
5. 按是否运行代码划分: 静态测试, 动态测试
6. 按是否手工执行划分: 手工测试, 自动化测试
7. 按测试地域划分: 本地化测试, 国际化测试

一. 按测试对象进行划分

1. 界面测试

我们平时在使用网站/APP时, 直接通过肉眼看到的页面就是界面, 用户是通过界面和软件之间进行交互的, 界面设计的好坏, 直接影响了用户对软件的印象; 而界面的设计是由 UI (User interface - 用户界面)设计师画出来的, 然后前端程序员照着 UI 的设计稿进行制作, 因此, 界面测试又可称为 UI 测试.

那么, 界面测试/UI测试具体要测试那些内容?

1. 测试软件界面元素的完整性, 正确性, 一致性, 友好性; 在 UI 设计稿上, 对于每个界面元素的尺寸, 位置, 效果, 都有明确的标识, 要保证和 UI 设计稿一模一样.
2. 软件界面的排版布局要合理, 要站在用户的角度去考虑, 字体的设计, 图片的展示等, 不合理的地方可以向 UI 设计师进行反馈.
3. 测试界面的自适应性, 界面适应不同的页面大小, 界面必须功能完整, 文字完整, 图片完整, 不出现叠加, 消失, 功能无法使用的情况; PC端和移动端之间最大的区别就是屏幕的尺寸不同, 如果对移动端使用PC端显示的界面, 很明显尺寸上是不匹配的, 很可能会导致页面显示错乱！
4. 界面的控件功能正常, 控件就是页面上看到的最小化的图型 (对话框, 滚动条, 各类按钮…), 按钮的有效状态和 失效状态是否可以区分(比如: 有效状态, 按钮高亮; 无效状态: 按钮置灰, 不能进行点击操作)
5. 界面设计 (颜色, 布局) 考虑当下时事; 比如一些 特殊的纪念日/节日, 根据其意义/氛围进行界面设计.

2. 可靠性测试

可靠性是指软件正常运行的能力, 可靠性通常是用百分之来表示的, 即

可靠性 = 正常运行时间 / (正常运行时间 + 非正常运行时间) \ 100%
百分比越高, 可靠性越强, 反之就越低.

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

可用性指标一般要求达到 4 个或 5 个 “9”, 即 99.99% 或者 99.999%

如果可用性达到 99.99%, 对于一个全年不间断 (7*24的方式) 运行的系统, 意味着全年 (252600min) 不能正常工作的时间只有 52min, 不到一个小时; 如果可用性达到 99.999%, 意味着全年不能正常工作的时间只有 5min; 不同的应用系统, 可用性的要求是不一样的, 非实时性的信息系统或一般网站要求都很低, 99% 和 99.5% 就可以了, 但是军事系统, 要求则很高.

那么, 可靠性怎么去测试呢?

首先我们要知道, 这里涉及到性能测试, 只依靠人工测试是不现实的, 可以借助一些工具, 编写一些脚本, 让这些脚本自动运行, 我们只需要看最后运行出来的报告, 然后总结结果即可, 可以先让软件运行 24 小时, 通过脚本将出现故障的时间记下来, 去计算百分比; 然后是 7 * 24 小时, 一个月, 三个月, 六个月, 一年…

3. 容错性

系统发生异常, 或者由于用户的错误操作导致软件系统发生错误, 软件自我消化掉错误, 或者进行修改/修复, 不让客户感知到系统内部的情况, 就叫做系统的容错性.

容错性测试包含以下方面:

• 输入异常数据或进行异常操作, 以检验系统的保护性; 如果系统的容错性好, 系统只给出提示或内部消化掉, 而不会导致系统出错甚至崩溃; 比如数据级测试, 校验测试, 环境容错性测试, 界面容错性测试
• 灾难恢复性测试, 通过各种手段, 让软件强制性地发生故障, 然后验证系统已保存的用户数据是否丢失, 系统和数据是否能尽快恢复; 比如重要的数据库服务器部署的地点发生了地震, 海啸等, 这种情况下数据之所以能很快的恢复, 是因为数据可能备份存储到了若干台其他的服务器对应的数据库当中, 每个服务器都部署在不同的地点, 当灾难发生时, 就可以快速恢复数据保证正常的使用.

常见的容错性说明

1. 数据的容错性

比如: 取款机输入小于100的取款数目, 我们知道取款机中只能取出能被100整除的数目.
一般取款机在遇到这个问题的时候, 都会弹出温馨提示 “请修改你的取款金额之类的信息”; 此时我们只需要点击确定, 修改取款金额即可.
其实在提款机出现这个提示之前, 也就是我们输入非整百的金额, 并点击取款按钮的时候, 这个数据已经在软件系统中走了一圈, 引发了异常; 只不过表现的形式不是报异常, 而是提示你重新输入整百的取款金额.
简单来说就是我们的输入已经触发了异常, 但是系统并没有报出异常, 而是给予正确的提示, 这就已经是处理了异常这种行为, 就是容错性的体现.

2. 校验容错性

在搜索某些关键词的时候, 在前后加上空格, 系统会进行自动化过滤(将前后的空格移除掉); 还有校验忽略大小写字母, 主要体现在验证码环节, 在内部验证的时候, 自动的将我门将输入的字母进行转换了, 然后, 再去跟验证码进行比较.

3. 界面容错性

界面的容错性, 体现在复杂操作的提示, 有的时候, 软件的操作有些复杂, 导致有些用户就搞不清楚应该操做哪一步了, 此时, 就需要软件界面给予下一步的操作提示, 以免用户操作错误.
界面容错性, 就是在用户进行一些复杂/危险/有风险的操作时, 给予正确的提示, 一定程度上避免用户在不知情的情况做出错误操作.

4. 环境容错性

环境的容错性, 主要体现于软件所在环境发生故障的时候, 具有备用的处理方案, 可以让用户无感知切换, 环境的故障, 主要体现于: 网络, 电源, 硬件环境, 软件的部署环境.

比如淘宝的秒杀价活动, 这种情况下的用户的请求是非常多的, 如果软件所在环境发生故障, 导致用户无法进行操作, 那么就会给淘宝造成巨大的损失, 因此, 对于环境要有各种各样的备用方案, 以面对突发情况的发生, 在环境发生故障的时候, 运维感知到之后, 立马就给你切换成备用方案, 这个切换的过程, 是用户感知不到的.

总的来说这些容错性都是对于软件系统发生故障的时候, 具有备用的处理方案, 使得用户在无感知的情况完成对应的操作.

4. 文档测试

文档测试就是针对与软件开发相关的文档所进行的测试.

国家有关计算机软件产品开发文件编制指南中共有14 种文件, 可分为3 大类。
\1. 开发文件: 可行性研究报告, 软件需求说明书, 数据要求说明书, 概要设计说明书, 详细设计说明书(技术文档, 记录每一个代码的模块如何实现), 数据库设计说明书, 模块开发卷宗, 开发文件的作用: 提高开发效率, 保证开发的一致性和正确性.
\2. 用户文件: 用户手册, 操作手册, 用户文档的作用：改善易安装性; 改善软件的易学性与易用性; 改善软件可靠性; 降低技术支持成本.
\3. 管理文件: 项目开发计划, 测试计划, 测试分析报告, 开发进度月报, 项目开发总结报告, 管理文件的作用: 复习软件质量, 看开发和测试是否很好的配合完成了工作任务

在实际的测试中, 最常见的是用户文件的测试, 例如: 手册说明书等; 也会有一些公司对需求文档进行测试, 来保证需求文档的质量.

文档测试的关注点：

1. 文档的术语, 因为这是给业内人士看的, 就可以不用把一些东西写的太过于详细, 直接一个专业术语就能带过, 这样能够提升阅读的效率.

2. 文档的完整性, 将一个软件的所有的功能描述完整, 切勿遗漏重要功能！

3. 文档的一致性, 正确性

4. 文档的易用性

5. 兼容性测试

兼容性测试需求是指明确要测试的兼容环境, 考虑软, 硬件的兼容, 就软件兼容来说, 主要考虑以下几个方面:

• 软件系统自身的兼容性, 软件 “向前向后” 的兼容性, 软件开发的新功能, 不能影响旧功能的使用, 同时, 也不能影响后续功能的开发.
• 软件对于数据的兼容性 (特别是用户数据), 在设计功能的时候, 要考虑到用户已有的数据不能受到影响.
• 软件对应用平台的兼容性, 比如: 安装的软件环境 (Windows, iOS, Linux等操作系统), 安装的硬件环境(电脑/手机配置是否能支持软件的运行), APP环境(手机的应用商店等), 如果是网页, 要考虑浏览器的版本…
• 软件对于第三方软件或者第三方软件数据的兼容性, 一个软件的使用不能影响其他软件的正常使用, 就比如京东和微信, 京东付款, 就可以使用微信的, 它们之间肯定是做到软件的兼容和数据的兼容; 京东在付款的时候, 会跳转的微信的支付页面, 这就是软件兼容的体现, 京东是可以使用微信来登录的, 这就是数据的兼容.

兼容性测试是非常耗时的.

6. 易用性测试

许多产品都应用人体工程学的研究成果, 是产品在使用起来更加灵活和, 舒适; 软件产品也始终关注用户体验, 让用户获得舒适, 易用的体验, 针对软件这方面的测试称之为易用性测试.
易用性在ISO25020标准中指容易发现, 容易学习和容易使用, 易用性包含七个要素: 符合标准和规范, 直观性, 一致性, 灵活性, 舒适性, 正确性和实用性.
主要是以下几个方面:

1. 标准性和规范性

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

所以用户界面上的各中信息应该符合规范和习惯, 否则用户使用起来会不舒适, 并得不到用户的认可; 测试人员需要把与标准规范, 习惯不一致的问题报告为缺陷

2. 直观性

用户界面的直观性, 要求软件功能特性易懂, 清晰; 用户界面布局合理, 对操作的响应在用户的预期之中.
比如: 数据统计结果用报表的形式 (条形图, 扇形图等)展示清晰直观; 现在主流的很多搜索引擎和日历的设计也有直观性的特点.

3. 灵活性

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

4. 舒适性

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

总的来说, 软件的设计要符合大众审美, 要见名知意, 使用起来要灵活.

7. 安装卸载的测试

应用的安装和卸载在任何一款APP中都属于最基本功能, 一旦出错, 就属于优先级为紧要 Critical 的缺陷 (严重的缺陷), 主要需要考虑以下方面:

• 软件在不同的安装和卸载方式的情况下
• 应用是否可以在不同的环系统, 版本下安装(安装兼容性)
• 安装或者卸载过程中是否可以手动暂停, 或者取消, 并且后续还可以正常安装和卸载
• 安装所需的内存空间不足的时候, 系统是否有提示
• 是否可以正常的卸载, 以及应用软件的各种卸载方式, 并且如果在执行取消卸载命令之后, 软件可以正常使用(数据恢复).
• 卸载和安装过程中出现环境问题, 软件是否可以正常并且合理的应对, 比如死机, 断电, 断网等情况.

8. 安全测试

安全性是指信息安全, 是指计算机系统或网络保护用户数据隐私, 完整, 保护数据正常传输和抵御黑客, 病毒攻击的能力.
安全性测试属于非功能性测试很重要的一个方面, 系统常见的安全漏洞和威胁如下:

• 输入域(输入框中的内容), 如输入恶性或者带有病毒的脚本或长字符串
• 代码中的安全性问题, 如SQL/XSS注入
• 不安全的数据存储或者传递
• 数据文件, 邮件文件, 系统配置文件等里面有危害系统的信息或者数据
• 有问题的访问控制, 权限分配等
• 假冒ID: 身份欺骗
• 篡改, 对数据的恶意修改, 破坏数据的完整性
• 权限要合理分配, 防止用户看到它不该看到的东西(超出自身权限)

安全性测试的方法有代码评审, 渗透测试, 安全运维等, 常用的静态安全测试工具有 Coverity, IBM, Appscan Source, HPFortify, 常用的动态安全测试有 OWASP的ZAP, HP WebInspect 等; 其中静态安全测试是常用的安全性测试的方法.

9. 性能测试

我们在使用软件的时候有时会碰到软件网页打开时越来越慢, 查询数据时很长时间才显示列表, 软件运行越来越慢等问题, 这些问题都是系统的性能问题引起的.
要解决软件产品的性能问题, 要对产品的性能需求进行分析, 然后基于系统的性能需求和系统架构, 完成性能测试的设计和执行, 最后要进行持续的性能调优; 常见的性能问题如下:

1. 资源泄露, 当我们的软件运行越来越慢, 加载一个页面需要半天的时候, 其原因就是资源泄露.
2. 资源瓶颈, 在不同压力下观察系统是否仍能正常运行, 且各项性能指标满足要求? 当无法满足指标要求或出现异常时, 即判定为瓶颈出现.
3. 线程死锁, 线程阻塞
4. 查询速度慢或效率低
5. 受外部系统影响越来越大
6. 响应速度越来越慢

衡量一个系统性能好坏的关键性指标有:
用户响应时间, 事务平均响应时间(TPS), 吞吐量, 每秒点击次数, 内存和CPU使用率等.

10. 内存泄漏测试

很多软件系统都存在内存泄露的问题, 尤其是缺乏自动垃圾回收机制的 “非托管” 语言编写的程序.
例如:
C, CH, Delphi等, 从用户使用的角度来看, 内存泄露本身不会造成什么危害, 一般用户可能根本不会感觉到内存泄露的存在; 但是内存泄露是会累积的, 只要执行的次数足够多, 最终会耗尽所有可用内存, 使软件的执行越来越慢, 最后停止响应, 可以把这种软件的问题比喻成软件的 “慢性病”.

虽然内存泄露的问题不会一下子要了 “我们的命”, 但是放任不管, 是绝对不行的.
这是一个很重要的bug! 需要我们去重视!

造成内存泄露的原因有很多, 最常见的有以下几种

1. 分配完内存之后忘了回收
2. 程序写法有问题, 造成没办法回收(如死循环造成无法执行到回收步骤)
3. 某些API函数的使用不正确, 造成内存泄露

内存泄漏的检测方法

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

二. 按是否查看代码划分

要注意下面三种形式的测试, 并不会区分哪个好哪个坏, 只要适合当前的业务, 能够保证软件的质量, 就是好的测试方法.

1. 黑盒测试(Black-box Testing)

黑盒测试也称为功能测试, 测试中把被测的软件当成一个黑盒子, 不关心盒子内部的代码实现, 只关心软件的输入数据和输出数据, 通过一些科学的方法, 常用到的测试方法有, 等价类, 边界值, 因果图, 场景法, 错误猜测法等, 向测试系统发起测试数据, 关注测试执行结果和预期结果是否一致.

黑盒测试的优点

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

黑盒测试的缺点是不可能覆盖所有代码.

2. 白盒测试(White-box Testing)

白盒测试又称结构测试, 透明盒测试, 逻辑驱动测试或基于代码的测试; 白盒指的是打开的盒子, 去研究里面的源代码和程序结果, 接口测试也是一种白盒测试.
白盒测试的测试目的是, 通过检查软件内部的逻辑结构, 对软件中的逻辑路径进行覆盖测试, 在程序不同地方设立检查点, .检查程序的状态, 以确定实际运行状态与预期状态是否一致.

白盒测试的优点是关注代码的内部实现, 代码覆盖率高; 缺点是只关注了模块代码的逻辑, 但是将模块组合到一起就可能会出现问题.
白盒测试主要包含六种测试方法:

1. 语句覆盖, 简单来说, 就是把所有行代码都执行一遍, 看看有没有问题, 语句覆盖, 就是要覆盖到所有行的代码.
   但是, 程序是非常讲究逻辑性的, 一个简单的语句覆盖测试是不行的, 还需要搭配其它的测试方法来使用.

2. 判定覆盖, 就是每一个判断语句, 为 true 和 false 都进行验证.

3. 条件覆盖, 就是比如 a > 1 && b == 0, 这种布尔类型的条件, 每个条件下都要进行验证, a>1, a<=1, b=0, b ! = 0.

4. 判定条件覆盖, 就是将条件的两个判定结果 (true和false) 的所有判定组合进行覆盖, 比如:

5. 条件组合覆盖, 就是将多个可以连接起来的条件组合起来验证, 要将所有的组合进行覆盖, 即将 3 中的条件两两组合, 全部验证.
6. 路径覆盖, 将代码执行的每条路径都进行覆盖测试.

其实判定条件覆盖和条件组合覆盖在某种程度上是相似的, 它们都关注于覆盖条件语句的不同结果和组合情况, 但它们在覆盖的粒度和策略上存在一些区别.

判定条件覆盖更关注于每个判定条件的不同结果, 包括逻辑运算符的不同组合和布尔表达式的真假结果, 它确保每个判定条件的每个可能结果都至少执行一次, 以验证逻辑判断的正确性.

条件组合覆盖更加细致, 它要求覆盖每个条件的所有可能组合, 它考虑了不同条件之间的交互作用, 确保测试用例能够覆盖所有可能的条件组合, 这有助于发现条件之间的依赖或冲突, 以及不同组合对程序行为的影响.

尽管两者在目标上存在一些相似之处, 但条件组合覆盖更加细致和全面, 它强调了条件之间的相互作用和组合, 以便更全面地检查程序的逻辑和正确性, 判定条件覆盖可以视为条件组合覆盖的一种较为简化的形式, 它关注于判定条件的不同结果而不涉及所有可能的组合.

冒泡排序测试用例

public static void bubbleSort(int[] array) {
    boolean flag = true;
    for (int i = 0; i < array.length-1; i++) {
        for (int j = 0; j < array.length-1-i; j++) {
            if(array[j] > array[j+1]) {
                swap(array, j, j+1);
                flag = false;
            }
        }
        if(flag) {
            break;
        }
    }
}
private static void swap(int[] array, int i, int j) {
    int tmp = array[i];
    array[i] = array[j];
    array[j] = tmp;
}

我们要针对上面的冒泡排序代码进行测试, 可以从以下方面考虑设计测试用例.

①从参数上进行测试

使用等价类划分法:

有效等价类: 参数是 int 数组

无效等价类: 参数是 float 数组, String 数组, double 数组, 字符串, 集合等

②从代码逻辑上进行测试

这里考虑代码逻辑上的实现, 就涉及到白盒测试了, 可以使用以下方法设计测试用例:

1. 语句覆盖: 确保每个语句都至少执行一次, 这里可以设计一个包含多个元素的乱序数组, 以覆盖排序循环中的每个语句.

• 测试用例1: 空数组作为输入, 例如 []
• 测试用例2: 包含一个元素的数组, 例如 [5]
• 测试用例3: 包含多个元素的乱序数组, 例如 [3, 1, 4, 2, 5]

2. 判定覆盖: 确保每个判定条件的每个可能结果都至少执行一次, 可以设计一个包含两个元素的数组, 一个元素比另一个元素大, 以确保两个分支都被覆盖到.
3. 条件覆盖: 确保每个判定条件的每个子条件都至少执行一次, 对于我们冒泡排序算法中的比较语句, 可以设计一个包含多个元素的数组, 并确保每个元素之间的比较都能够被覆盖到.
4. 判定条件覆盖, 要使得每个条件的每个可能结果都能够被覆盖到.

• 测试用例1: 输入数组为空, 例如 []
• 测试用例1: 输入数组包含两个相等的元素, 例如 [2, 2]
• 测试用例2: 输入数组包含两个不相等的元素, 例如 [3, 1], [7, 8]

5. 条件组合覆盖, 考虑每个条件的所有可能组合.

• 测试用例2: 输入数组包含两个相等的元素且不需要交换例, 如 [5, 5]
• 测试用例3: 输入数组包含两个不相等的元素且需要交换, 例如 [3, 1]
• 测试用例4: 输入数组包含两个不相等的元素且不需要交换, 例如 [1, 3]

6. 路径覆盖: 确保覆盖每个可能的路径, 对于冒泡排序算法, 可能的路径包括循环内部的比较和交换操作, 以及循环的执行次数.

• 路径1: 输入数组为空, 测试用例: 输入数组为空, []
• 路径2: 输入数组包含一个元素, 测试用例: 输入的数组包含一个元素, [5]
• 路径3: 输入数组包含多个元素且需要交换, 测试用例: 输入数组包含多个元素, 其中存在需要交换的元素, [3, 1, 4, 2, 5]
• 路径4: 输入数组包含多个元素且不需要交换, 测试用例: 输入数组包含多个元素, 其中元素已经按升序排列, [1, 2, 3, 4, 5]
• 路径5: 输入数组包含多个元素且需要多次交换, 测试用例: 输入数组包含多个元素, 需要多次交换才能完成排序, [5, 1, 4, 2, 3]

③从代码性能上面进行测试

测试算法在大规模数据集上的性能, 生成一个包含大量元素的数组, 并记录排序所需的时间; 考虑时间复杂度和空间复杂度等.

④错误处理

测试算法对于不符合要求的输入数据的处理方式, 例如, 当传入的参数为空或无效时, 算法应该如何处理并返回适当的错误或异常.

进行接口测试

这里只进行简单的介绍, 我们要知道, 接口至少由请求地址(url), 请求方法(get/post), 请求参数(入参和出参)组成, 可以使用一些工具针对接口进行测试, 比如可以使用postman, 它是谷歌的一款接口测试插件, 它使用简单, 支持用例管理, 支持get, post, 文件上传, 响应验证, 变量管理, 环境参数管理等功能, 可以批量运行, 并支持用例导出, 导入.

3. 灰盒测试(Gray-Box Testing)

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

三. 按开发阶段划分

测试金字塔

这个金字塔, 越靠近顶部, 就越接近用户层(应用层); 越靠近底部, 就越接近代码层.
另外, 越靠近低层, 测试效率越高; 定位问题就越容易, 而且, 测试独立性越高(代码的耦合性越低).
越靠近顶层, 就越接近用户层, 而用户操作的是一个个功能模块的集成体, 操作起来, 功能的耦合性就很强, 所以, 出现问题, 想要定位问题也是较为不易.

1. 单元测试(Unit Tests)

单元测试是对软件组成单元进行测试, 其目的是检验软件基本组成单位的正确性, 测试的对象是软件设计的最小单位: 模块, 又称为模块测试.

• 测试阶段: 编码后或者编码前 (TDD - Test Driven Development - 测试驱动开发)
• 测试对象: 最小模块 (一个接口方法, 单一功能的模块)
• 测试人员: 白盒测试工程师或开发工程师
• 测试依据: 代码和注释+详细设计文档
• 测试方法: 白盒测试
• 测试内容: 模块接口测试, 局部数据结构测试 (局部变量测试), 路径测试, 错误处理测试 (try catch), 边界测试 (for, while, 测试是否存在越界问题)

要注意单元测试是白盒测试, 但是白盒测试不是单元测试.

2. 集成测试(Integration Testing)

集成测试也称联合测试(联调), 组装测试, 将程序模块采用适当的集成策略组装起来, 对系统的接口及集成后的功能进行正确性检测的测试工作.
集成主要目的是检查软件单位之间的接口是否正确.

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

3. 系统测试(System Testing)

将软件系统看成是一个系统的测试, 包括对功能, 性能以及软件所运行的软硬件环境进行测试,.

新买手机都会有一个合格标签, 在出厂前手机厂会所某型号的手机上的所有功能全部测试一遍, 包括手机硬件本身, 手机上自带的APP.

其实就是在对软件系统进行全面的功能和非功能测试.

• 测试阶段: 集成测试通过之后
• 测试对象: 整个系统 (软, 硬件)
• 测试人员: 黑盒测试工程师
• 测试依据: 需求规格说明文档
• 测试方法: 黑盒测试
• 测试内容: 功能, 界面, 可靠性, 容错性, 易用性, 可移植性, 兼容性, 安全性, 性能, 安装卸载等.

4. 回归测试(regression testing)

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

自动回归测试将大幅降低系统测试, 维护升级等阶段的成本; 在整个软件的过程中占有很大的工作量比重, 软件开发的各个阶段都会运行多次回归测试.

5. 冒烟测试(Smoke Testing)

在软件开发完成后, 要对软件的基础功能和核心流程进行测试, 只有测试通过后, 才可以进入正式的测试环境.
反之, 测试不通过, 则测试人员是有权利打回项目, 让开发人员进行修改, 直到冒烟测试成功.
也就是说, 冒烟测试就是先验证软件的核心功能是否能正常工作, 如果核心功能可以正常工作, 就可以测试软件的其它功能了, 反之, 如果核心功不能正常工作, 也就没法展开后续的测试了.

5. 验收测试(Acceptance Testing)

验收测试是部署软件之前的最后一个测试操作, 它是技术测试室的最后一个阶段, 也叫做交付测试, 验收测试的目的是保证软件的准备就绪, 按照项目合同, 任务书, 双方约定的验收依据文档, 向软件的购买者展示该软件的原始的需求.

• 测试阶段: 系统测试之后
• 测试对象: 整体软件系统
• 测试人员: 主要是最终用户或者需求方.
• 测试依据: 用户需求, 验收标准
• 测试方法: 黑盒测试
• 测试内容: 同系统测试(功能…各类文档等)

四. 按测试实施组织

1. α测试(Alpha Testing)

α测试是由一个用户在开发环境下进行的测试, 也可以是公司内部的用户在模拟实际操作环境下进行的测试, α测试的目的是评价软件产品的FLURPS(即功能, 局域化, 可使用性, 可靠性, 性能和支持).

2. β测试(Beta Testing)

Beta测试是一种验收测试, Beta测试由软件的最终用户们在一个或多个场所进行.

3. α测试与β测试的区别

1. 测试的场所不同: Alpha测试是指把用户请到开发方的场所来测试, 而beta测试是指在一个或多个用户的场所进行的测试.
2. Alpha测试的环境是受开发方控制的, 用户的数量相对比较少, 时间比较集中; beta测试的环境是不受开发方控制的, 用户数量相对比较多, 时间不集中.
3. alpha测试先于beta测试执行, 通用的软件产品需要较大规模的beta测试, 测试周期比较长.

4. 第三方测试

介于开发方和用户方之间的组织的测试, 该测试是有第三方测评机构来进行的, 严格按照软件行业的标准规范进行测试的, 就类似于国家指定的食品安全标准, 它都是有规定指标的, 测试行业也是存在这样的指标的.

五. 按照代码是否运行划分

1. 静态测试(Static testing)

所谓静态测试 (static testing) 就是不实际运行被测软件, 而只是静态地检查程序代码, 界面或文档中可能存在的错误的过程; 不以测试数据的执行进行, 而是对测试对象的分析过程, 仅通过分析或检查源程序的设计, 内部结构, 逻辑, 代码风格和规格等来检查程序的正确性.

2. 动态测试(Dynamic testing)

动态测试 (dynamic testing), 指的是实际运行被测程序, 输入相应的测试数据, 检查实际输出结果和预期结果是否相符的过程, 所以判断一个测试属于动态测试还是静态的, 唯一的标准就是看是否运行程序.
大多数软件测试工作都属于动态测试.

五. 按是否手工划分

1. 手工测试(Manual testing)

手工测试就是由人去一个一个的输入用例, 然后观察结果, 和机器测试相对应, 属于比较原始但是必须的一个步骤。
优点: 自动化无法替代探索性测试, 发散思维结果的测试, 就是说手工测试很灵活.
缺点: 执行效率慢, 量大易错.

1. 自动化测试(Automation Testing)

就是按照人为预设条件下运行系统或应用程序, 评估运行结果, 预先条件应包括正常条件和异常条件; 简单说, 自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程.
自动化测试比如: 功能测试自动化, 性能测试自动化, 安全测试自动化.
自动化测试按照测试对象来分, 还可以分为接口测试, UI测试等.
接口测试的 ROI (产出投入比) 要比UI测试高.

自动化实施步骤：

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

六. 按测试地域划分

软件国际化是在软件设计和文档开发过程中, 使得功能和代码设计能处理多种语言和文化习俗, 使创建不同语言版本时, 不需要重新设计源程序代码的软件工程方法, 就是说软件具有很强的通用性.

国际化测试和本地化测试

国际化测试

软件的国际化和软件的本地化是开发面向全球不同地区用户使用的软件系统的两个过程, 而本地化测试和国际化测试则是针对这类软件产品进行的测试, 由于软件的全球化普及, 还有软件外包行业的兴起, 软件的本地化和国际化测试俨然成为了一个独特的测试专门领域.
本地化和国际化测试与其它类型的测试存在很多不同之处, 下面是本地化和国际化测试的一些要点:

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

软件本地化和国际化测试是一个综合了翻译行业和软件测试行业的测试类型, 它要求测试人员具备一定的翻译能力, 语言文化, 同时具备测试人员的基本技能.

本地化测试

之前所有介绍的都是基于本地化进行测试的.