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

　一. 按测试对象进行划分

　　1. 界面测试

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

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

　　测试软件界面元素的完整性, 正确性, 一致性, 友好性; 在 UI 设计稿上, 对于每个界面元素的尺寸, 位置, 效果, 都有明确的标识, 要保证和 UI 设计稿一模一样.

　　软件界面的排版布局要合理, 要站在用户的角度去考虑, 字体的设计, 图片的展示等, 不合理的地方可以向 UI 设计师进行反馈.

　　测试界面的自适应性, 界面适应不同的页面大小, 界面必须功能完整, 文字完整, 图片完整, 不出现叠加, 消失, 功能无法使用的情况; PC端和移动端之间最大的区别就是屏幕的尺寸不同, 如果对移动端使用PC端显示的界面, 很明显尺寸上是不匹配的, 很可能会导致页面显示错乱！

　　界面的控件功能正常, 控件就是页面上看到的最小化的图型 (对话框, 滚动条, 各类按钮…), 按钮的有效状态和 失效状态是否可以区分(比如: 有效状态, 按钮高亮; 无效状态: 按钮置灰, 不能进行点击操作)

　　界面设计 (颜色, 布局) 考虑当下时事; 比如一些 特殊的纪念日/节日, 根据其意义/氛围进行界面设计.

　　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）管理文件: 项目开发计划, 测试计划, 测试分析报告, 开发进度月报, 项目开发总结报告, 管理文件的作用: 复习软件质量, 看开发和测试是否很好的配合完成了工作任务

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

　　文档测试的关注点：

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

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

　　· 文档的一致性, 正确性

　　· 文档的易用性

　　5. 兼容性测试

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

　　软件系统自身的兼容性, 软件 “向前向后” 的兼容性, 软件开发的新功能, 不能影响旧功能的使用, 同时, 也不能影响后续功能的开发.

　　软件对于数据的兼容性 (特别是用户数据), 在设计功能的时候, 要考虑到用户已有的数据不能受到影响.

　　软件对应用平台的兼容性, 比如: 安装的软件环境 (Windows, iOS, Linux等操作系统), 安装的硬件环境(电脑/手机配置是否能支持软件的运行), APP环境(手机的应用商店等), 如果是网页, 要考虑浏览器的版本…

　　软件对于第三方软件或者第三方软件数据的兼容性, 一个软件的使用不能影响其他软件的正常使用, 就比如京东和微信, 京东付款, 就可以使用微信的, 它们之间肯定是做到软件的兼容和数据的兼容; 京东在付款的时候, 会跳转的微信的支付页面, 这就是软件兼容的体现, 京东是可以使用微信来登录的, 这就是数据的兼容.

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

　　6. 易用性测试

　　许多产品都应用人体工程学的研究成果, 是产品在使用起来更加灵活和, 舒适; 软件产品也始终关注用户体验, 让用户获得舒适, 易用的体验, 针对软件这方面的测试称之为易用性测试.

　　易用性在ISO25020标准中指容易发现, 容易学习和容易使用, 易用性包含七个要素: 符合标准和规范, 直观性, 一致性, 灵活性, 舒适性, 正确性和实用性.

　　主要是以下几个方面:

　　· 标准性和规范性

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

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

　　· 直观性

　　用户界面的直观性, 要求软件功能特性易懂, 清晰; 用户界面布局合理, 对操作的响应在用户的预期之中.

　　比如: 数据统计结果用报表的形式 (条形图, 扇形图等)展示清晰直观; 现在主流的很多搜索引擎和日历的设计也有直观性的特点.

　　· 灵活性

　　软件可以有不同的选项, 用来满足不同使用习惯的用户来完成相同的功能, 但是灵活性的设计要把握好度, 不然可能由于太多的用户状态和方式的选择, 增加了软件设计的复杂性, 和程序实现的难度.

　　例如: 手机键盘有九宫格和全键盘, 还支持手写, 满足了不同用户的需求

　　· 舒适性

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

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

　　7. 安装卸载的测试

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

　　· 软件在不同的安装和卸载方式的情况下

　　· 应用是否可以在不同的环系统, 版本下安装(安装兼容性)

　　· 安装或者卸载过程中是否可以手动暂停, 或者取消, 并且后续还可以正常安装和卸载

　　· 安装所需的内存空间不足的时候, 系统是否有提示

　　· 是否可以正常的卸载, 以及应用软件的各种卸载方式, 并且如果在执行取消卸载命令之后, 软件可以正常使用(数据恢复).

　　· 卸载和安装过程中出现环境问题, 软件是否可以正常并且合理的应对, 比如死机, 断电, 断网等情况.

　　8. 安全测试

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

　　安全性测试属于非功能性测试很重要的一个方面, 系统常见的安全漏洞和威胁如下:

　　· 输入域(输入框中的内容), 如输入恶性或者带有病毒的脚本或长字符串

　　· 代码中的安全性问题, 如SQL/XSS注入

　　· 不安全的数据存储或者传递

　　· 数据文件, 邮件文件, 系统配置文件等里面有危害系统的信息或者数据

　　· 有问题的访问控制, 权限分配等

　　· 假冒ID: 身份欺骗

　　· 篡改, 对数据的恶意修改, 破坏数据的完整性

　　· 权限要合理分配, 防止用户看到它不该看到的东西(超出自身权限)

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

　　9. 性能测试

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

　　要解决软件产品的性能问题, 要对产品的性能需求进行分析, 然后基于系统的性能需求和系统架构, 完成性能测试的设计和执行, 最后要进行持续的性能调优; 常见的性能问题如下:

　　· 资源泄露, 当我们的软件运行越来越慢, 加载一个页面需要半天的时候, 其原因就是资源泄露.

　　· 资源瓶颈, 在不同压力下观察系统是否仍能正常运行, 且各项性能指标满足要求? 当无法满足指标要求或出现异常时, 即判定为瓶颈出现.

　　· 线程死锁, 线程阻塞

　　· 查询速度慢或效率低

　　· 受外部系统影响越来越大

　　· 响应速度越来越慢

　　衡量一个系统性能好坏的关键性指标有:

　　用户响应时间, 事务平均响应时间(TPS), 吞吐量, 每秒点击次数, 内存和CPU使用率等.

　　10. 内存泄漏测试

　　很多软件系统都存在内存泄露的问题, 尤其是缺乏自动垃圾回收机制的 “非托管” 语言编写的程序.

　　例如:

　　C, CH, Delphi等, 从用户使用的角度来看, 内存泄露本身不会造成什么危害, 一般用户可能根本不会感觉到内存泄露的存在; 但是内存泄露是会累积的, 只要执行的次数足够多, 最终会耗尽所有可用内存, 使软件的执行越来越慢, 最后停止响应, 可以把这种软件的问题比喻成软件的 “慢性病”.

　　虽然内存泄露的问题不会一下子要了 “我们的命”, 但是放任不管, 是绝对不行的.

　　这是一个很重要的bug! 需要我们去重视!

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

　　· 分配完内存之后忘了回收

　　· 程序写法有问题, 造成没办法回收(如死循环造成无法执行到回收步骤)

　　· 某些API函数的使用不正确, 造成内存泄露

　　内存泄漏的检测方法

　　人工静态法: 代码走读, 人工查找未被回收的内存.

　　自动工具法: 借助相应测试内存泄漏的工具, 如 Visual Leak Detector, 记录每次内存分配, 清楚告诉用户内存是如何泄漏的.

　　二. 按是否查看代码划分

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

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

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

　　黑盒测试的优点

　　· 不需要了解程序内部的代码以及实现, 不关注软件内部的实现

　　· 从用户角度出发设计测试用例, 很容易的知道用户会用到哪些功能, 会遇到哪些问题, 锻炼测试人员的产品思

　　· 测试用例是基于软件需求开发文档，不容易遗漏软件需求文档中需要测试的功能。

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

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

　　白盒测试又称结构测试, 透明盒测试, 逻辑驱动测试或基于代码的测试; 白盒指的是打开的盒子, 去研究里面的源代码和程序结果, 接口测试也是一种白盒测试.

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

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

　　白盒测试主要包含六种测试方法:

　　· 语句覆盖, 简单来说, 就是把所有行代码都执行一遍, 看看有没有问题, 语句覆盖, 就是要覆盖到所有行的代码.

　　但是, 程序是非常讲究逻辑性的, 一个简单的语句覆盖测试是不行的, 还需要搭配其它的测试方法来使用.

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

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

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

　　· 条件组合覆盖, 就是将多个可以连接起来的条件组合起来验证, 要将所有的组合进行覆盖, 即将 3 中的条件两两组合, 全部验证.

　　· 路径覆盖, 将代码执行的每条路径都进行覆盖测试.

 

 

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

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

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

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

　　冒泡排序测试用例

　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: 空数组作为输入, 例如 []

　　测试用例2: 包含一个元素的数组, 例如 [5]

　　测试用例3: 包含多个元素的乱序数组, 例如 [3, 1, 4, 2, 5]

　　判定覆盖:确保每个判定条件的每个可能结果都至少执行一次, 可以设计一个包含两个元素的数组, 一个元素比另一个元素大, 以确保两个分支都被覆盖到.

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

　　判定条件覆盖, 要使得每个条件的每个可能结果都能够被覆盖到.

　　·测试用例1: 输入数组为空, 例如 []

　　· 测试用例1: 输入数组包含两个相等的元素, 例如 [2, 2]

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

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

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

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

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

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

　　· 路径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)

　　灰盒测试, 是介于白盒测试与黑盒测试之间的一种测试.

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

 

最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取