测试分类详解

文章目录
一、按开发阶段划分
1.单元测试
2.集成测试
3.系统测试
4.验收测试
二、按测试对象划分
1.界面
2.可靠性
3.业务
4.容错性
5.文档测试
6.兼容性测试
7.易用性测试
8.安装卸载
9.安全性
10.性能
11.内存泄漏
三、按照实施组织划分
1.α测试
2.β测试
3.第三方测试
四、按是否运行划分
1.静态测试
2.动态测试
五、按是否手工去划分
1.手工测试
2.自动化测试
六、按照是否查看代码去划分
1.黑盒测试
2.白盒测试
3.灰盒测试
七、按地域测试划分
一、按开发阶段划分
测试金字塔理论：
投入相同的人力和精力，越往上层，它的产出越低；越往上层，定位问题越困难；越往上层，测试效率越低。因为单元测试的话，只需要测试某一个类中的其中一个方法，而在UI界面层的话，测试时要进行页面的渲染、数据库的开启等，会消耗时间，测试效率更低。

1.单元测试
对程序的一个单元进行测试，这个单元可能是一个类，也可能是一个方法。对于单元测试，在实际工作中有这样一个场景：
此时有开发人员A和开发人员B，开发人员A开发的是同一个系统中的登录功能，开发人员B开发的是同一个系统中的注册功能。
但是有可能测试登录功能没有开发完全，就会影响到登录功能的测试。那要怎么办呢？测试中有个名词叫“打桩”，它模拟用户的注册功能，然后再用来测试登录功能。

1.单元测试的阶段：开发前(TTD，Test——Driven——Development，测试驱动开发)，先写测试脚本，此时没有代码，就会抛异常，直到开发人员按照该脚本进行开发到没有异常抛出为止。开发后，此时有代码进行测试了，就对代码进行单元测试。

2.单元测试的对象：单元模块。可能是个类，可能是个方法。

3.单元测试的人员：白盒测试工程师或开发工程师。

4.单元测试的依据：代码+注释+详细设计文档

5.单元测试的方法：白盒测试。(看代码)

6.单元测试的内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试。

(1)模块接口测试：关注输入输出，输入参数的数量，类型，类型的排列顺序，输出是否符合接口设计文档。
(2)局部数据结构测试：对于一个类中有很多的变量，当有全局变量时，要跟踪该全局变量的值的变化是否正常，不正常就认为是错误的。
(3)路径测试：如：代码中有if、else语句，switch语句，构成不同的代码路径。因此要测试是不是每一条的代码路径都会执行到，包括if、else、switch中的多种case和default情况。
(4)错误处理测试：因为代码中肯定有try、catch、finally捕捉异常的代码，因此我们要故意的去抛出异常，检验是否该异常能被try、catch捕获到。
(5)边界测试：for、while都会涉及到边界，此时就需要检验边界的情况。

在IDEA中如何进行单元测试？
1.因为是对项目的代码进行测试，因此是maven的项目，有pom.xml的配置文件。先引入junit中的4.11版本的依赖。
2.下载插件：在setting中下载pliguis_junit
3.创建相应的单元测试类：按ctrl+shift+T。选择的是Junit4，可以创建单元测试类。
4.单元测试类当中去写每一个方法的单元测试代码，该单元测试类在test目录底下。如：测试数据库的插入操作，可以直接使用项目代码中原有的类，对数据库的插入进行测试。
如果对不需要测试的方法，可以在该方法的上面加上注释：@Ignore 。如果要求在注释了Test方法执行之前要执行某个方法，可以创建一个方法，然后再在方法前加注释：@Before。相应地，创建一个方法在Test注释的方法后执行，在新创建的方法前加注释：@After

简历上可以写：项目测试：对图片服务器系统的图片查询功能，图片上传功能，图片删除功能结合Junit分别做了单元测试。

2.集成测试
集成：按照一定的策略(逻辑)组合单元模块形成一个功能模块。
测试阶段：单元测试之后；
测试方法：灰盒测试
测试人员：开发工程师，白盒测试工程师
测试依据：概要设计文档，详细设计文档
测试内容：接口之间数据的传输，全局数据结构，模块组装的功能的正确性，单个功能模块缺陷对整体的影响，模块和模块之间的功能冲突。

3.系统测试
测试阶段：集成测试之后；
测试方法：黑盒测试方法；
测试人员：黑盒测试工程师；
测试依据：需求文档；
测试内容：功能，界面，易用性，性能，安全性，兼容性，可靠性

系统测试中还包含回归测试和冒烟测试：
回归测试：在系统中引入新的代码后进行回归测试。测试场景：增加新功能的时候，修改BUG；回归测试的策略很重要：评估回归测试的范围(难点)，自动化测试。
冒烟测试：对系统的主要功能和核心的流程进行测试；评判系统是否进入正式的测试环节的依据——准入原则。在是否介入产品的正式测试的基础是冒烟测试通过的情况下，如果冒烟测试都不通过，则没必要进行正式测试，等开发人员把核心功能实现好后才开始进行测试。
冒烟测试的测试用例叫——提测用例：数量很少，主要针对本次迭代的主要功能和系统的核心流程进行测试用例的设计。

4.验收测试
客户(甲方) 按照用户的需求对系统进行测试；
测试人员：客户
测试内容：和系统测试一致，文档测试(软件设计文档，功能设计文档，用户使用手册，详细功能使用文档等)

二、按测试对象划分
1.界面
用户是通过界面和软件之间进行交互的，界面设计的好坏，直接影响了用户对软件的印象。界面测试==UI测试。
(1) 测试软件界面元素完整性，正确性，一致性。
(2) 软件界面排版布局合理，字体，颜色
(3) 测试界面的自适应性，界面适应不同页面的大小(文字没有重叠，消失，功能都在，可以正常使用，图片清晰排版合理)。在手机、平板、电脑屏幕中的排版可以随意切换过程中，功能完整，文字完整，图片完整，不出现叠加，消失，功能无法使用的情况。
(4) 界面的控件功能正常，(对话框滚动条，按钮) 。按钮的有效状态和失效状态是可以区分的。(有效高亮，无效置灰不能点击)。
(5) 界面设计(颜色，布局)，比如说有不好的事发生，就会将界面的颜色置为灰色。

界面中常见的错误：
(1) 不合适的快捷键

(2) 文字的丢失

(3) 截断

(4) 文字的自动换行

(5) 重叠

(6) 重复的快捷键

2.可靠性
可靠性是指软件正常运行的能力，软件正常运行的时间和总体运行的时间的百分比。
可靠性 = 软件正常运行的时间/(非正常运行的时间+正常运行的时间)

影响软件可靠性的因素：网络、软件环境(安装)、硬件环境、软件自身环境的异常。当然，如果公司计算可靠性，里面的非正常运行的时间如果是用户自身的原因，就不纳入进去。

不同的软件对可靠性的要求不一样，非实时性软件可靠性，要求一般为 99.99%，或99.95%，特殊的软件对可靠性的要求高，达到99.999%，如军事系统。虽然看起来相差不大，但实际上差的时间是天差地别。99.99%大约不正常运行的时间是52min，而99.999%大约不正常运行的时间是5min

如何去测试软件的可靠性？
一周记录一次，出现故障的时间记下来，去计算百分比。

3.业务
是测试人员把系统各个模块串接起来运行、模拟真实用户实际的工作流程，满足用户需求定义的功能来进行测试的过程。
查看邮件：
登录网站-输入用户名、密码登录-进入收件箱-查到邮件-点击打开-查阅-关闭邮件-退出邮箱-关闭网站

业务测试关注需求和用户。

4.容错性
系统发生异常，或者由于错误操作导致软件系统发生错误，软件自我消化掉错误，或者进行修改，不让客户感知，叫做系统的容错性。

(1) 常见的容错性的处理
数据容错性：假设只能输入整百的，此时在取款机输入小于100的钱数，就报出个温馨提示；时间，不能有超过24时的；年月日中，二月份30天，其它月份32天的，都是错误的。

校验容错性：前后空格(自动化过滤)；校验大小写字母(验证码，自动转化大小写)；同一个表格或者文件前后信息的校验(身份证，学号，自动前后校验)

界面容错性：复杂操作的提示；危险操作的警告提示；危险按钮的屏蔽

环境容错性：软件所在的环境发生故障，软件有备用方案，可以让用户无感知切换。(网络，电，硬件环境，环境部署的软件环境)

(2)灾难恢复性测试
人为让系统发生故障，看系统自身，对于用户数据的存储和回复是否快速。

5.文档测试
软件开发的相关的文档的测试。因为文档一般是给用户看的，弄得太复杂用户看不懂。因此文档的术语、完整性、一致性、正确性、易用性都有要求。

6.兼容性测试
(1) 软件自身的兼容性
软件向前向后的兼容性，软件开发的新功能不能影响旧功能的使用，不能够影响后续功能的开发。
(2) 软件对于数据的兼容性
设计功能的时候，要考虑用户已有的数据。
(3) 软件对应用平台的兼容性(安装的软件环境，硬件环境，app，浏览器等)
(4) 软件对于第三方软件或者第三方软件数据的兼容性

7.易用性测试
用户体验测试
(1) 符合标准和规范
安装软件的界面，有标识：有：用户信息提示符号(提示)、警告信息提示符(警告)、严重错误提示符号(严重错误)。

(2) 直观性
用户期望的操作在用户可见的范围内
(3) 灵活性
键盘：九宫格，全键盘，手写，拼音
(4) 舒适性
(5) 实用性

8.安装卸载
(1) 不同的安装卸载途径，安装卸载软件正常。下载途径如：appstore，安装包，第三方，命令行。
(2) 安装或者卸载过程中是否暂停，暂停后继续还可以正常安装和卸载。
(3) 安装过程中空间不足，有提示
(4) 正常卸载软件，如果卸载取消了，那么软件还可以正常使用(数据恢复)。
(5) 安装卸载过程中出现异常，软件可以正常处理(断电，网络连接异常等)

9.安全性
安全性指信息安全，软件保护用户的数据，隐私，以及数据传输过程中的安全性。
(1)防止病毒侵入和黑客攻击。
(2)输入域，能够检测带病毒的字符串或者文件。
(3)防止输入注入，XSS/SQL注入。
SQL注入：如：Insert into Student values(‘Robert’);Drop Table Students; ?')。这是一个完整的SQL语句，但是在SQL中会将它拆分为两个语句，最终导致执行错误。
XSS注入：比如说病毒想打乱浏览器的布局，就会在里面贴入一些html标签，导致整个布局打乱。
(4)权限分配要合理
(5)传输文件/数据，防止拦截。
对于付费，保密的文件进行测试，防止会被半路截取信息。
在上传文件的时候，防止上传有病毒的文件。假设此时要上传的文件是.jpg，因此一般检测的时候检测的是后缀，认为是.jpg就没有问题了。但是木马病毒的后缀也可能是.jpg，因此我们不能单单检查后缀，还要检查名字的信息，一般木马病毒的名字都是乱码的。
防止上传过大的文件或者下载过大的文件。不能不做检测就直接把文件下载或上传，可能会直接导致系统崩溃。
(6)防止爬虫，爬取信息
(7)防止黑客攻击

安全性测试：静态测试的代码走读，工具检查。

10.性能
系统性能问题的表现：资源泄漏；资源分配不均衡；线程死锁；查询速度越来越慢；响应越来越慢。
性能指标：TPS(每秒事务处理量)，点击率(每秒HTTP请求数)，吞吐量(系统在单位时间内处理的信息量)，响应时间（3/5/10），CPU和资源利用率(内存、磁盘、网络带宽、耗电量)。

为什么要进行性能测试？
(1) 希望用户能够有很好的体验，系统能够快速地响应用户的需求
(2) 系统能够处理预期的用户负载
(3) 系统能够处理预期的事务数量

11.内存泄漏
内存泄漏产生的原因：
1.程序中写的有问题，没法回收内存。
2.API函数使用不准确，无法回收内存。
3.分配内存后，忘记回收内存。

因此要检查代码是否资源泄漏：静态测试的人工检查，工具检查。

三、按照实施组织划分
1.α测试
用户到开发环境下测试；
优点：测试过程中发现的问题可以及时反馈给开发人员，及时得到解决。
缺点：用户在开发环境下，容易受到开发人员和测试人员的影响。

2.β测试
用户在真实的环境下进行测试，测试环境的地域不受限制。
测试的结果跟接近用户实际使用情况的反馈。

β测试在α测试之后才进行的。
β测试与α测试的对比：
1.地域不一样，α测试是在开发环境下，β测试是在用户实际使用环境下。
2.时间的集中程度也不一样，α测试的时间相对比较集中，β测试的时间相对比较分散。

3.第三方测试
由软件的第三方测评机构进行测试。它们是按照标准去进行测试的，而上面的两个测试是不按标准进行测试的。

四、按是否运行划分
1.静态测试
ISO25010 静态质量标准

Funcitonal Suitablity（功能适用性）：从代码的功能上去检查，看代码是否符合用户的需求。

Performance Efficiency（性能效率）：是否满足用户对系统性能的需求。Time Behaviour(时间响应方面的表现)、Resource Utilization(资源的利用率)、Capacity(容量)

Compatibility（兼容性）：比如手机app，在不同的手机型号和不同的系统来看是否能够适应。

Usability（易用性、用户体验性）

Reliablity（可靠性）。Fault Tolerance（容错性），Recoverability：当我们的系统由于外部的环境和用户的误操作，引起了系统内部的不可控的一些错误时，系统内部能够很好地处理这些异常，让用户无感知有错误，由系统内部自身来处理了。

Security（安全性）
Maintainability（维护性）

Portability（可移植性）：在不同的平台上可以正常使用

2.动态测试
写测试用例，运行程序，对系统进行测试，查看分析系统的输出是否符合预期。

五、按是否手工去划分
1.手工测试
手工测试：设计测试用例，运行程序，一步一步手动执行测试用例，对系统进行测试。
优点：测试时比较灵活，可以根据不同的情况进行测试用例的修改和完善。因此自动化测试永远也替代不了手工测试。
缺陷：量大时容易出错，因为人的精力是有限的。并且效率比较低。

2.自动化测试
自动化测试：把手工测试的测试用例转化成自动化脚本，让机器去执行脚本。给定预先设计好的条件和结果的预判去执行。缺陷：不能按照实际情况去改变。

自动化现在分为：接口自动化、性能自动化、web自动化、app自动化。对应的自动化工具有：django、RobertFrameWork、unittest、selenium、appium、Macaca(阿里巴巴的)

自动化的意义：解放双手，提高测试效率，在公司中代码量非常大的时候，用自动化脚本去测试是非常方便的。

判断自动化脚本的价值：自动化脚本的使用率，使用率越高越有价值。

什么项目适合于使用自动化脚本测试？
答：对于项目开发的周期比较长，不停的迭代。(2)适用于需求比较稳定的项目。如果不停地改项目的功能，那么自动化测试的脚本也需要修改。

六、按照是否查看代码去划分
1.黑盒测试
测试的时候只关心输入和输出，而不去看功能的内部逻辑、代码的具体实现。

黑盒测试的测试用例的设计方法：等价类、边界值、需求分析法、场景法、因果图、正交设计法、错误猜测法。

2.白盒测试
对程序的内部的逻辑，结构，功能进行的测试。单元测试就是白盒测试。

白盒测试的测试用例的设计方法：语句覆盖法、逻辑覆盖法、循环覆盖法。
其中的逻辑覆盖法：路径覆盖，判定覆盖，判定组合覆盖，条件覆盖。
路径覆盖就是if、else里面的每一条代码都要走到。
判定覆盖就是：比如有if、else语句的判定，也要走到。
判定组合覆盖是：if(A&&B)中，A为假B为真、A为真B为假、A为假B为假、A为真B为真 的组合都要测试到。
条件覆盖：在判定组合覆盖的基础上，对不同组合的条件中的代码进行测试。

3.灰盒测试
介于白盒和黑盒测试之间，既要关心输入和输出，又要关心程序内部的逻辑结构。

七、按地域测试划分
国际化测试 和 本地化测试。

软件国际化：就是开发一款软件的时候运用了一种工程技术，可以使得软件技术使用不同国家的语言和当地的风俗习惯而不用修改软件的源码。

国际化测试是为了能够实现本地化测试，而本地化测试是为了能够软件实现国际化。

软件的国际化和软件的本地化是开发面向全球不同地区用户使用的软件系统的两个过程。而本地化测试和国际化测试则是针对这类软件产品进行的测试。由于软件的全球化普及，还有软件外包行业的兴起，软件的本地化和国际化测试俨然成为了一个独特的测试专门领域。

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

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