14-测试分类

X-musk

已于 2023-10-03 09:53:36 修改

阅读量285

点赞数 1

分类专栏：测试文章标签：测试

于 2023-07-30 22:35:49 首次发布

本文链接：https://blog.csdn.net/WWXDwrn/article/details/131704101

版权

测试专栏收录该内容

17 篇文章 0 订阅

订阅专栏

①黑盒测试(Black-box Testing)

②白盒测试(White-box Testing)

③灰盒测试(Gray-Box Testing)

3.按开发阶段划分

①单元测试(Unit Tests)

②集成测试(Integration Testing)

③系统测试(System Testing)

④回归测试(regression testing)

⑤冒烟测试(Smoke Testing)——系统测试之前完成

⑥验收测试(Acceptance Testing)——系统测试之后完成

①静态测试(Static testing)

②动态测试(Dynamic testing)

6.按是否手工划分

①手工测试(Manual testing)

②自动化测试(Automation Testing)

7.按测试地域划分

①国际化测试

②本地化测试

1.按照测试对象划分

①界面测试

软件只是一种工具，软件与人的信息交流是通过界面来进行的，界面是软件与用户交流的最直接的一层，界面的设计决定了用户对设计的软件的第一印象。界面如同人的面孔，具有吸引用户的直接优势，设计合理的界面能给用户带来轻松愉悦的感受。

而界面的设计是由 UI（User Interface - 用户界面）设计师画出来的，然后前端程序员照着 UI 的设计稿进行制作，因此，界面测试又可称为 UI 测试。

界面测试（简称UI测试)，指按照界面的需求（一般是UI设计稿）和界面的设计规则，对软件界面所展示的全部内容进行测试和检查，一般包括如下内容：

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

常见的界面错误有哪些？

重叠，截断，文字不合理自动换行等。

②可靠性测试

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

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

百分比越高，可靠性越强，反之就越低。

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

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

如果可用性达到99.99%，对于一个全年不间断（7*24的方式）运行的系统，意味着全年（252600min)不能正常工作的时间只有52min，不到一个小时。
如果可用性达到99.999%，意味着全年不能正常工作的时间只有5min。

不同的应用系统，可用性的要求是不一样的，非实时性的信息系统或一般网站要求都很低，99%和 99.5%就可以了，但是军事系统，要求则很高。

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

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

③容错性测试

容错性测试是指系统能够处理自身异常、用户的错误操作，（软件能够自我消化掉错误、进行修复，不让用户感知到系统内部的情况）而不至于系统崩溃，从而能够提高系统的可用性。

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

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

常见的容错性说明

【1】数据的容错性

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

【2】校验容错性

在搜索某些关键词的时候，在前后加上空格，系统会进行自动化过滤(将前后的空格移除掉)。

还有校验忽略大小写字母，主要体现在验证码环节，在内部验证的时候，自动将输入的字母进行转换了，然后，再去跟验证码进行比较。

【3】界面容错性

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

【4】环境容错性

环境的容错性，主要体现于软件所在环境发生故障的时候，具有备用的处理方案，可以让用户无感知切换。

环境的故障，主要体现于：网络、电源、硬件环境、软件的部署环境。

比如淘宝的秒杀价活动，这种情况下的用户的请求是非常多的，如果软件所在环境发生故障，导致用户无法进行操作，那么就会给淘宝造成巨大的损失。

因此，对于环境要有各种各样的备用方案，以面对突发情况的发生。在环境发生故障的时候，运维感知到之后，立马就给你切换成备用方案，这个切换的过程，是用户感知不到的。

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

④文档测试

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

国家有关计算机软件产品开发文件编制指南中共有14 种文件，可分为3 大类。

开发文件：1）可行性研究报告、2）软件需求说明书、3）数据要求说明书、4）概要设计说明书、5）详细设计说明书（技术文档：记录每一个代码的模块如何实现），6）数据库设计说明书、7）模块开发卷宗。开发文件的作用：提高开发效率，保证开发的一致性和正确性。
用户文件：8）用户手册、9）操作手册。用户文件的作用：改善易安装性，改善软件的易学性与易用性，改善软件可靠性，降低技术支持成本。
管理文件：10）项目开发计划、11）测试计划、12）测试分析报告、13）开发进度月报、14）项目开发总结报告。管理文件的作用：复习软件质量，看开发和测试是否很好的配合完成了工作任务。

在实际的测试中，最常见的是用户文件的测试。例如：手册说明书等。

也会有一些公司对需求文档进行测试，来保证需求文档的质量。

去公司后，接触最多的文件是

测试文件：总结了许许多多的测试技巧、测试方法。
开发文件
产品文件

文档测试的关注点：

文档的术语。因为这是给业内人士看的，就可以不用把一些东西写的太过于详细，直接一个专业术语就能带过，这样能够提升阅读的效率。
文档的正确性。
文档的完整性。将一个软件的所有的功能描述完整，切勿遗漏重要功能！
文档的一致性。
文档的易用性。

⑤兼容性测试

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

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

对于环境（操作系统，应用平台，浏览器）兼容性的测试还包括以下：

32 位，64位CPU；
手机平台Android ，iOS，Windows Phone；
支持不同的Internet连接速度。
对于iOS和Android两个平台，还要区分手机和平板电脑，考虑不同的型号（屏幕尺寸，分辨率等）。

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

⑥易用性测试

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

易用性在ISO25020标准中指容易发现、容易学习和容易使用。

易用性包含七个要素：符合标准和规范、直观性、一致性、灵活性、舒适性、正确性和实用性。

主要讨论以下几个方面：

a.标准性和规范性

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

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

b.直观性

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

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

c.灵活性

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

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

d.舒适性

舒适性主要强调界面友好、美观、操作过程顺畅、色彩用运恰当、按钮的立体感等。

例如：左手鼠标的设置给习惯用左手的人带来了便利，也为右手十分劳累时提供了另一种途径。

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

⑦安装卸载测试

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

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

⑧安全测试

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

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

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

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

常用的静态安全测试工具有 Coverity、IBM、Appscan Source、HPFortify。

常用的动态安全测试有 OWASP的ZAP、HP WebInspect 等。

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

⑨性能测试

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

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

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

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

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

⑩内存泄漏测试

很多软件系统都存在内存泄露的问题，尤其是缺乏自动垃圾回收机制的 “非托管” 语言编写的程序。例如：C、CH、Delphi等。

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

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

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

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

内存泄漏的检测方法：

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

2.按是否查看代码划分

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

①黑盒测试(Black-box Testing)

黑盒测试也称为功能测试，测试中把被测的软件当成一个黑盒子，不关心盒子内部的代码实现，只注重软件的功能、只关心软件的输入数据和输出数据。

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

通过一些科学的方法，向测试系统发起测试数据，关注测试执行结果和预期结果是否一致。

黑盒测试用例设计方法有：

等价类，边界值，因果图，场景法，错误猜测法等。

黑盒测试的优点：

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

黑盒测试的缺点：

是不可能覆盖所有代码，代码覆盖率较低。

②白盒测试(White-box Testing)

白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。它一般用来分析程序的内部结构，针对程序的逻辑结构来设计测试用例进行测试。白盒指的是打开的盒子，去研究里面的源代码和程序结果，接口测试也是一种白盒测试。

白盒测试的测试目的是：

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

白盒测试的优点：

关注代码的内部实现，代码覆盖率高。

白盒测试的缺点：

只关注了模块代码的逻辑，但是将模块组合到一起就可能会出现问题。

关注代码逻辑，对业务功能有一定漏洞。

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

语句覆盖。覆盖到所有行的代码，把所有行代码都执行一遍，看看有没有问题。但是，程序是非常讲究逻辑性的，一个简单的语句覆盖测试是不行的，还需要搭配其它的测试方法来使用。
判定覆盖。就是每一个判断语句，为 true 和 false 都进行验证。
条件覆盖。就是比如 a > 1 && b == 0，这种布尔类型的条件，每个条件下都要进行验证，a>1，a<=1，b=0，b ! = 0。
判定条件覆盖。就是将条件的两个判定结果 (true和false) 的所有判定组合进行覆盖。
条件组合覆盖。就是将多个可以连接起来的条件组合起来验证，要将所有的组合进行覆盖，即将 3 中的条件两两组合，全部验证。
路径覆盖。将代码执行的每条路径都进行覆盖测试。

判定条件覆盖 VS 条件组合覆盖

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

判定条件覆盖更关注于每个判定条件的不同结果，包括逻辑运算符的不同组合和布尔表达式的真假结果，它确保每个判定条件的每个可能结果都至少执行一次，以验证逻辑判断的正确性。
条件组合覆盖更加细致，它要求覆盖每个条件的所有可能组合，它考虑了不同条件之间的交互作用，确保测试用例能够覆盖所有可能的条件组合，这有助于发现条件之间的依赖或冲突，以及不同组合对程序行为的影响。

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

冒泡排序测试用例
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;
}
我们要针对上面的冒泡排序代码进行测试，可以从以下方面考虑设计测试用例。

1）从参数上进行测试

使用等价类划分法:

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

2）从代码逻辑上进行测试

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

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

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

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

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

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

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

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

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

3）从代码性能上面进行测试

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

4）错误处理

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

进行接口测试

这里只进行简单的介绍，我们要知道，接口至少由请求地址(url)，请求方法(get/post)，请求参数(入参和出参)组成。

可以使用一些工具针对接口进行测试，比如可以使用postman，它是谷歌的一款接口测试插件，它使用简单，支持用例管理，支持get、post、文件上传、响应验证、变量管理、环境参数管理等功能，可以批量运行，并支持用例导出、导入。

③灰盒测试(Gray-Box Testing)

灰盒测试，是介于白盒测试与黑盒测试之间的一种测试。

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

3.按开发阶段划分

测试金字塔

越靠近顶部，就越接近用户层（应用层）；越靠近底部，就越接近代码层。
越靠近顶层，就越接近用户层，而用户操作的是一个个功能模块的集成体，操作起来功能的耦合性就很强，所以出现问题，想要定位问题也是较为不易，排查问题成本高。
越靠近底层，测试效率越高，定位问题就越容易，测试独立性越高，代码的耦合性越低。

①单元测试(Unit Tests)

单元测试是对软件组成单元进行测试，其目的是检验软件基本组成单位的正确性。

测试的对象是软件设计的最小单位：模块，又称为模块测试。

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

要注意单元测试是白盒测试，但是白盒测试不是单元测试。

Java如何进行单元测试？

Junit
TestNG

②集成测试(Integration Testing)

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

集成主要目的是检查软件单位之间的接口是否正确。

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

③系统测试(System Testing)

新买手机都会有一个合格标签，在出厂前手机厂会所某型号的手机上的所有功能全部测试一遍。

包括手机硬件本身，手机上自带的APP。

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

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

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

④回归测试(regression testing)

接着上边的美颜功能不可用的例子，拿去维修点进行了维修，拿到手机后第一件事情是先看美颜功能修好了没有，第二事情就是看看手机的其它常用功能是否正常。

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

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

随着系统的庞大，回归测试的成本越来越大，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。

⑤冒烟测试(Smoke Testing)——系统测试之前完成

需求讲解->
梳理测试点（设计测试用例）【包含冒烟测试用例（测试点属于本次测试主流程）】开发人员先测试->
评审测试用例-（包含了冒烟测试）>
测试（先执行冒烟测试用例，若通过，再执行正式的测试；若不通过，打回给开发人员重新测试）->
项目上线

冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件主要功能和核心流程正常，在正式进行系统测试之前执行。

一般在开发人员开发完毕后，（开发人员也需要执行冒烟测试用例）提交给测试人员来进行测试时，先进行冒烟测试，保证基本功能正常，不阻碍后续的测试。

如果冒烟测试通过，则测试人员开始进行正式的系统测试；如果不通过，则测试人员可以让开发人员重新修复代码直到冒烟测试通过，再开始进行系统测试。

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

⑥验收测试(Acceptance Testing)——系统测试之后完成

买到新手机，一般会有7天包退，一个月包换，我们会尽量在7天内把手机的所有功能都试一遍。

验收测试是部署软件之前的最后一个测试操作，是产品上线之前最后一个测试流程。它是技术测试的最后一个阶段，也称为交付测试。

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

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

4.按测试实施组织

①α测试(Alpha Testing)

手机出厂前最后一次测试，开发和测试人员不参与。

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

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

大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试。

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

②β测试(Beta Testing)

新手机购买回来，参与测试的人是购买者，使用的场所及环境已不再是手面厂商的环境及场所。

Beta测试是一种验收测试。

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

α测试与β测试的区别

环境： alpha测试是在公司内部进行测试，受开发方控制，指把用户请到开发方的场所来测试；而beta测试环境是不确定的，不受开发方控制，是指在一个或多个用户的场所进行的测试。
测试人员类型：alpha测试人员是公司内部人员；而beta测试人员是用户。
测试人员数量：alpha测试人员数量较少；而beta测试人员数量较多。
阶段：alpha测试相当于内测，而beta测试相当于公测；alpha测试先于beta测试执行。
测试时间：alpha测试周期较短；而beta测试周期较长。