前言
在之前的《软件测试笔记(一)什么是软件测试-定义、类型、方法?》中也曾经提高过测试的种类非常多,不同的术语往往让新人或者入行不久的测试人员望而生畏,对于开发也是同样的。这里推荐一个比较好的参考资料《ISTQB认证的测试人员基础水平教学大纲》,里面就包含了比较全面的测试术语还有测试方法。
在逐条介绍测试类型之前,让我们再次默念一遍软件测试的定义,对软件的功能进行评估,以确定所开发的软件是否满足规定的要求,通过发现缺陷,解决缺陷,来生产出高质量的产品的过程。
测试类型
1.手工测试
手工测试是通过手工测试软件,执行测试用例来发现缺陷的过程。通常测试人员是以最终用户的视角,并确保所有功能都按照需求客户需求实现。
2.自动化测试
自动化测试是使用自动化工具,测试框架来测试软件的过程。在这个过程中,自动化工具会自动执行测试脚本并生成结果。一些最流行的自动化测试工具是test complete、selenium webdriver等。
3.静态测试
在软件测试中也称为验证。验证是检查文档和文件的静态方法。验证是一个过程,以确保我们创建的产品是否是正确的,即验证我们的需求。这里包括的活动有检查、审查、演练。
4.动态测试
同样也是也是一种验证, 测试真实产品的动态过程。同样也是以确保我们创建的产品是否是正确的。其中涉及的活动是测试应用程序。不同于上面的静态测试,而是更侧重于产品的功能。
5.白盒测试
又称玻璃盒、透明盒、结构测试。白盒测试是基于应用程序内部的代码结构。在白盒测试中,是以系统的内部视角,以及需要相应的编程技巧来设计测试用例。这种测试通常在单元测试级别进行。
6.基于代码结构的测试
请参考白盒测试。
7.玻璃盒测试
请参考白盒测试。
8.透明盒测试
请参考白盒测试。
9.语句覆盖测试
语句覆盖测试是一种白盒测试技术,用于验证代码中的每个语句是否至少执行一次。通常可以用语句覆盖率来检测单元测试的完成度。
10.决策覆盖测试/分支覆盖测试
决策覆盖测试/分支覆盖测试:决策覆盖或分支覆盖测试是一种白盒测试技术,用于验证每个可能的分支至少执行一次。通常也可以用决策覆盖测试/分支覆盖测试率来检测单元测试的完成度。
11.路径测试
路径覆盖测试是一种白盒测试技术,用于验证程序的所有路径至少执行一次。通常也可以用路径覆盖测试率来检测单元测试的完成度。
12.变异测试
变异测试是一种白盒测试,它改变(变异)源代码中的某些语句,并验证测试是否能够找到错误。
13.循环测试
循环测试是一种白盒测试技术,用于验证不同类型的循环,如简单循环、嵌套循环、连接循环和非结构化循环。
14.黑测试
也称为基于设计文档的行为/规范/输入输出测试。黑盒测试是一种软件测试方法,在这种方法中,测试人员在不查看内部代码结构的情况下评估软件的功能。
15.基于设计行为/规范/输入输出的测试
请参考黑盒测试。
16.灰盒测试
灰盒测试是介于黑盒和白盒测试之间的一种测试。测试人员需要访问开发设计文档,接口文档,从而来设计和执行相应的测试用例。
17.功能测试
简单地说,系统本身的功能其实就是一种功能测试。验证软件应用程序的每个功能是否按照需求文档中的规定运行。通过提供适当的输入来测试所有功能,以验证实际输出是否与预期输出匹配。它属于黑盒测试的范围,测试人员不必关心应用程序的源代码。
18.非功能性测试
简单地说,系统性能如何就是非功能性测试。非功能性测试是指软件的性能、负载、压力、可扩展性、安全性、兼容性等各个方面,主要关注的是提高用户体验系统对请求的响应速度。
19.单元测试
前面的白盒测试也提到了单元测试。单元测试是为了检查源代码的各个模块是否正常工作。即由开发人员在开发人员的环境中分别测试应用程序的每个单元。它也可以称之为模块测试或组件测试。
20.模块测试
请参考单元测试。
21.组件测试
请参考单元测试。
22.集成测试
集成测试是测试多个模块之间的连接或数据传输的过程。又称为I&T (Integration Testing)测试或流测试。按照测试顺序,又分为自上而下法、自下而上法和夹心法(自上而下和自下而上相结合)。
23.大爆炸集成测试(Big bang Integration Testing)
在完成单个模块测试后,将所有单元模块整体合并,并进行功能验证。
24.自上而下的集成测试
首先测试高级模块,然后测试低级模块,最后将低级模块集成到高级模块,以确保系统按预期工作。如果模块未准备好进行集成测试,则可以用虚构(临时)模块代替。
25.自下而上的集成测试
不同于自上而下的集成测试,测试是自下而上进行的。首先测试底层模块,然后测试高层模块,最后将高层模块集成到低层,以确保系统按预期工作。驱动程序用作集成测试的临时模块。
26.混合集成测试
混合集成测试是自顶向下和自下而上集成测试的结合。
27.系统测试
通常来说这是一个黑盒测试。测试完整的应用程序这也称为端到端的测试。确保软件在目标系统中可以正常工作。验证对不同的系统输入,同时检查所需的输出。测试用户对应用程序的体验。
28.端到端测试
请参考系统测试。
29.验收测试
这是由最终用户和测试人员一起完成的,以验证应用程序的功能。验收测试成功后。为确定应用程序是否按要求开发而进行的正式测试。它允许客户接受或拒绝申请。验收测试的类型有alpha、beta和gamma。
30.Alpha测试
Alpha测试由内部开发人员(开发软件的人员)和测试人员完成。有时,Alpha测试是由客户或外包团队在开发人员或测试人员在场的情况下完成的。
31.Beta测试
在产品交付前,由有限数量的最终用户测试完成。通常是在客户的环境中完成的测试。
32.Gamma测试
Gamma测试是在软件已经准备好按照指定的需求发布时完成的。同样的也是在客户的环境中完成。内部测试活动则完全不参与。
33.等价划分法(等价类划分法)测试
等价划分也称为等价类划分。在等价划分中,软件的输入被划分为期望表现相似的组,因此可以将相似的输入归类。在测试中,从每个组中选择一个输入来设计测试用例。
34.决策表(因果表)测试
这种测试技术适用于输入之间具有逻辑关系的功能。在决策表技术中,我们处理输入的组合。为了识别带有决策表的测试用例,我们可以看它是否使用有条件的输入和操作结果作为输出。
35.状态转换测试
当应用程序为相同的输入提供不同的输出时,我们可以应用这个方法,这取决于在以前的状态中发生了什么。该测试的难点就是挑选出可以覆盖不同系统转换的应用程序的测试输入。
36.穷举测试
使用所有有效和无效的输入和先决条件测试所有功能称为穷举测试。但是通常来说这种测试情况非常少。
37.全匹配测试
全匹配测试方法是用所有可能的输入参数值组合来测试应用程序,类似于穷举测试。
38.正面测试
它是为了确定系统应该做什么。它有助于检查应用程序是否符合要求。
39.负面测试
它是为了确定系统不应该做什么。它有助于从软件中发现缺陷。
40.用例测试
用例测试是在用例文档的帮助下进行的。它是用来帮助完成系统测试。
41.场景(用户画像)测试
场景测试是一种基于场景(用户画像)的软件测试技术。它涉及将业务需求转换为特定的测试场景,以便更好地理解和实现系统测试。一个设计良好的情景应该是合理的、可信的、复杂的,并且其结果易于评估。
42.文档测试
文档测试是为了验证文档化的文本,比如需求、测试计划、跟踪矩阵、测试用例。
43.性能测试
非常重要的测试类型,这类测试确定或验证被测系统或应用程序的速度、可伸缩性和/或稳定性特征。性能是指实现满足项目或产品性能目标的响应时间、吞吐量和资源利用率级别。
44.负载测试
验证系统/应用程序是否能够处理预期数量的事务,并验证系统/应用程序在正常和峰值负载条件下的行为。
45.浸泡测试
在高负载下长时间运行系统以识别性能问题称为浸泡测试。
46.耐久性测试
请参考浸泡测试。
47.稳定性测试
请参考浸泡测试。
48.寿命测试
请参考浸泡试验。
49.健壮性测试
健壮性测试是为了验证应用程序的健壮性而进行的一种测试。不同于浸泡测试,它不需要有特别高的负载。
50.可靠性测试
对应用程序进行长时间的连续测试,以验证应用程序的稳定性
51.可伸缩性测试
可伸缩性测试是一种非功能性测试。它是为了确定被测应用程序如何随着工作负载的增加而动态的扩展。
52.并发测试
并发测试是指多个用户同时访问应用程序,以确保系统的稳定性。这主要用于识别死锁问题。
53.破坏性测试
破坏性测试是一种测试技术,其目的是通过持续测试直到应用程序崩溃来验证应用程序的健壮性。
54.恢复测试
执行恢复测试是为了确定系统崩溃或硬件故障后系统恢复的速度。它属于非功能性测试。
55.容量测试
验证系统/应用程序是否能够处理大量数据。
56.漏洞测试
识别应用程序中的漏洞或弱点的测试过程。
57.漏洞测试
识别应用程序中的漏洞或弱点的测试过程。
58.随机测试
它是一种非正式的测试类型。测试人员在不遵循任何文档和测试设计技术的情况下随机测试应用程序。如果被测应用程序中的测试人员的知识非常丰富,则可以主要执行此测试。测试人员在没有任何测试用例或业务需求文档的情况下随机测试应用程序。
59.探索性测试
通常,这个测试过程将由领域专家执行。他们仅仅通过探索应用程序的功能来执行测试,而不了解需求。
60.猴子测试
故意对应用程序执行异常操作,就像是让一个猴子随意敲击键盘,以验证应用程序的稳定性。
61.大猩猩测试
大猩猩测试是由测试人员完成的,有时开发人员也会与测试人员携手合作。它包括反复测试系统以测试系统的健壮性。
62.重新测试
确保在早期版本中发现并发布的缺陷在当前版本中得到修复或不被修复。
63.回归测试
对一个已经测试过的程序在修改后进行的重复测试,以发现由于被测试的软件或其他相关或不相关的软件组件的变化而引入或发现的任何缺陷。它区别于重新测试的是它不仅关注缺陷本身还关注修复缺陷带来的新的影响。
64.健全性测试
健全性测试往往在发布阶段进行,以检查应用程序的主要功能,而不必深入。有时由于发布时间限制,无法对构建进行严格的回归测试,而健全测试则通过检查主要功能来完成这一部分。
65.冒烟测试
冒烟测试是为了确保构建的产品是否可测试。检查关键功能不起作用或关键错误尚未修复时,从而使用最少的时间来简单地测试整个应用程序。
66.动态测试
涉及对代码的执行和调试。它用预期的结果验证输出。
67.可用性测试
验证应用程序是否对用户友好,用户使用是否流畅。一个好的应用程序应该是自我探索的,并且不需要培训就可以来使用它。
68.可访问性测试
可访问性测试是可用性测试的一个子集。它是针对于残疾人(如视觉障碍、身体障碍、听力障碍、认知障碍、学习障碍)如何容易地使用一个系统/应用程序。
69.兼容性测试
在不同的环境组件组合中部署并检查应用程序是否按预期工作。通常互联网的产品需要测试在不同的浏览器和设备是否可以正常访问。
70.跨浏览器测试
跨浏览器测试是一种非功能性测试,是兼容性测试的一部分,它帮助我们确保我们的网站或web应用程序在各种web浏览器中按预期工作。
71.浏览器兼容性测试
请参考跨浏览器测试。
72.配置测试
配置测试是使用每个受支持的硬件和软件配置测试应用程序的过程,以确定应用程序是否可以正常工作而不出现任何问题。通常在程序发布的时候,都会有个最低配置要求。作为测试人员,需要测试不同配置条件下系统/应用程序的表现。
73.全球化测试
全球化是软件应用程序的设计的一个部分,目的是让它可以在不做任何更改的情况下适应不同的语言和地区。全球化测试则是针对于这部分的测试。
74.国际化测试
请参考全球化测试。
75.本地化测试
本地化是通过添加特定于本地化的组件(语言包),使全球化软件适应特定区域或语言的过程。通常会检查文字内容和系统样式内容。
76.安全测试
对于互联网公司来说,安全测试是一个非常重要的测试类型。安全测试是一个确定系统是否按预期保护数据和维护功能的过程。
77.渗透测试
渗透测试是一种安全测试。它为了评估系统的安全性。
78.模糊测试
模糊测试是安全测试的一种,用于识别应用程序中的编码错误和安全漏洞。通过向系统输入大量随机数据,试图使其崩溃,以确定应用程序中是否有任何中断。
79.数据库测试
数据库测试是为了验证UI(用户界面)中的数据是否与数据库中存储的数据匹配。它包括检查数据库的模式(schema)、表、触发器等。
80.后端测试
其包含了数据库测试,同时还包括了服务器的测试,后台服务的测试等。
81.桶(bucket)测试
桶(bucket)测试是一种将应用程序的两个版本进行比较以确定哪个版本性能更好的方法。
82.A/B测试
类似于桶测试。
83.区分(Split)测试
类似于桶测试。
84.图形用户界面测试
图形用户界面测试是测试应用程序和最终用户之间的界面。测试人员主要关注的是外观元素如字体和颜色是否符合设计规范。
85.UI测试
在UI测试中,测试人员的目标是测试GUI和命令行界面(CLIs),同样参考图形用户界面测试。
86.接口测试
执行接口测试以评估两个预期模块是否传递数据并相互正确通信。
87.API测试
API代表应用程序编程接口。API测试是一种软件测试,包括使用postman等工具测试API。
88.敏捷测试
敏捷测试是一种包含以下敏捷软件开发方法原理的测试。在这种敏捷测试中,测试是在持续发展的项目的整个生命周期中进行的,而不是局限于特定的阶段。
89.安装测试
检查应用程序安装/卸载是否成功,安装后是否按预期工作,卸载后是否删除所有不需要的文件。
90.正式测试
测试人员通过预先计划好的程序和适当的文档来测试应用程序的过程。
91.试运行测试
试运行测试是指公司为了获得客户的信任而在实时运行条件下进行的测试。
92.前向兼容性测试
前向兼容性测试是为了验证被测应用程序是否按照软件当前版本的更高版本的预期工作。
93.向后兼容性测试
向后兼容性测试是为了验证被测应用程序是否按照软件当前版本的早期版本的预期工作。
94.向下兼容性测试
请参考向后兼容性测试。
95.合规性测试
合规性测试是一种非功能性测试,用于验证软件是否符合一组定义的标准。
96.依赖性测试
依赖性测试是检查应用程序对应用程序正常运行的前提条件、初始状态和配置的需求。
97.众包测试(Crowdsourced testing)
众包测试是由一个由质量保证专家组成的社区通过一个在线平台进行的。
98.ETL测试
ETL(extract,transform,load)测试包括验证从源到目的地的数据移动,验证源和目的地的数据量,验证数据提取、转换,以及验证表关系。
99.数据仓库测试
请参阅ETL测试。
100.故障注入测试
故障注入测试是为了提高测试覆盖率而在代码中有意引入故障的测试技术。
101.故障转移测试
用于验证系统在服务器故障期间能够分配额外资源,并将处理部分任务传输到备份系统
102.组队测试
类似于组队开发的模式,通常有一个熟悉单元模块的测试和一个不熟悉该单元模块的测试,组队进行测试。
103.基于风险的测试
确定最有可能导致故障的模块或功能,通常可以由开发和产品高阶使用人员给出相关的风险测试范围,然后测试这些功能。
结语
上面列举了我所了解到的一些测试的种类,希望可以帮助大家抛开专业术语,了解其真实的测试内容。随着软件产品的多样化和测试技术的进步,上面列举的103种测试方法,肯定还有继续扩充的机会。如果大伙有什么补充请在留言回复。