测试类型大汇总(45 类)
Hello,大家好,工作之余就测试种类做了一下汇总和整理,以平白的语言叙述了出来,不妥之处还请大家指出来,共同进步。
我涉及到的有单元测试、端到端测试和冒烟测试。
首先是测试总的来说可以分为两大类:功能测试和非功能测试。
功能测试类型包括:单元测试、集成测试、系统测试、健全性测试、冒烟测试、接口测试、回归测试、Beta/验收测试。
非功能性测试类型包括:性能测试、负载测试、压力测试、容量测试、安全测试、恢复测试、可靠性测试、可用性测试、一致性测试、本地化测试。
0)A/B测试(A/B Testing)
就是准备两个(A/B)或者两个以上的版本,让不同的用户随机去访问这些版本,收集各版本的用户体验数据和业务数据。最后分析、评估出最好的版本
1)Alpha测试
这是软件工程中很常见的测试类型。目标就是尽可能地在发布到市场或者交付给用户之前找出所有的问题和缺陷。该测试一般是在开发的末端且在Beta测试之前进行,在这个测试过程中可能会驱动开发者进行一些小的设计变动,一般是在开发者网站进行,即只对开发者或者内部用户开放,一般可以为此类测试创建内部的虚拟用户环境。
Pre-alpha:有时候软件会在Alpha或者Beta版本前会发布该测试,相比前两者,这是个功能不完整的版本。
Alpha:版本功能还没有完善,需要进一步测试,该版本通常会发送到开发软件的分组织或者某群体中的软件测试者进行内部测试。
Beta:该版本会包含所有的功能,但是可能又有一些bug,需要调试反馈,Beta版本是软件最早的对外公开的软件版本,由公众(通常是公司外的第三方开发者和业余玩家)参与测试。
Release Candidate(rc): 发布候选版本,如果没有出现问题则可以发布成为正式的版本。这个版本包含完整并且比较稳定的功能。
2)验收测试
通常都是部署软件之前的最后一个测试操作,也称为交付测试,由最终客户执行,他们会验证端到端的系统流程是否符合业务需求,以及功能是否满足最终用户的需求。只有当所有的特性和功能按照期望的运行,客户才会接受软件。这是测试的最后阶段,在验收测试之后,软件将投入生产环境,所以它也叫做用户验收测试。举例来说,验收测试就是相当于收快递,包裹是软件、你就是客户,是验收方,货物不符合要求,是要退货的。
3)临时测试
这种测试在临时基础上进行的,有时候也称为随机测试,即没有参考任何测试用例、没有针对该测试的任何计划和文档。它的目的就是通过执行随意的流程或者或任意的功能来找出应用的缺陷和问题,它可以由项目的任何人来执行尽管没有测试用例很难识别缺陷,但是有些时候会发现无法使用现有的测试用例来识别,也就是说它是随机性的,没有事先任何的测试计划。
4)可访问性测试 它是为了确定软件或者应用程序是否可供残疾人使用。残疾人指的是聋人、色盲、智障人士、失明者、老年人和其他残疾人群体,这里会执行各种检查,比如针对视觉残疾的字体大小测试,针对色盲的颜色和对比度测试等等。5)Beta测试 它是一种正式的软件测试类型,在将产品发布作为商业用途之前完成的最终测试,通常,发布的软件或者产品的Beta版本仅仅限于特定区域的特定数量的用户,所以最终用户实际使用软件后会将一些问题反馈给公司,公司可以在全面发布之前采取必要的措施。
6)后端测试
前端应用输入的数据,一般都会存储在数据库,所以针对数据库的这类测试称为数据可测试或者后端测试,市面上有不同的数据库,所以该测试会涉及表结构、模式、存储过程以及数据结构等。后端测试一般不会涉及GUI,通过后端测试可以发现一些数据库问题,比如数据丢失、死锁、数据损坏。这些问题在生产环境之前进行修复至关重要。
7)浏览器兼容测试
这是兼容性测试的子类型,由测试团队执行,主要针对的是Web应用,用于确保软件可以在不同的浏览器或者操作系统中运行,或者验证Web应用程序是否能在浏览器的所有版本上运行,以确定应用最终兼容的范围。
8)后向兼容测试
适用于验证新开发或更新的软件是否能在就版本环境运行比如向后兼容的测试会检查新的软件是否能正确的处理旧版本软件创建的问及那格式,比如新版的office是否可以打开旧版本创建的文件同理也可以检查新版本是否可以兼容旧版本创建的数据表、数据文件、数据结构、配置文件。总则:任何软件更新应该在先前版本基础之上良好运行。
9)黑盒测试
它不考虑软件的内部系统设计,它基于需求和功能进行测试,只关心系统的输入和输出以及功能流程。换句话说该测试只是从用户的角度出发针对软件界面、功能以及外部结构进行测试,而不考虑程序内部逻辑结构,黑盒测试下面还有很对哦种类,例如集成测试、系统测试、大部分非功能性测试。
10)边界值测试
边界值测试,是测试应用处于边界条件的行为。很多边界开发者是很难考虑周到的,所以才有一个专门的测试类型来验证这种情况,边界值测试检查应用处于边界值时是否存在缺陷,边界值测试通常用于测试不同范围的数字,每个范围都有一个上下边界,就是针对这些边界值进行测试。比如数字范围是1-500,那么边界值就是在这些值上进行验证:0、1、2、499、500、501.
11)分支测试
是白盒子测试的子类型,在单元测试中实施,顾名思义,表示测试要覆盖程序代码的各种条件分支,避免遗漏缺陷,是单元测试覆盖率的一个指标之一。
12)比较测试
是将产品的优点和弱点与旧版本或者同类进行比较,比如IM会和微信作比较
13)兼容性测试
这是一个大类,用于验证应用在不同环境、web服务器、硬件、网络条件下的行为。兼容性测试确保软件可以在不同的配置、不同的数据库、不同的浏览器以及他们不同的版本下运行。
14)组件测试
一般也称为模块测试,一般是由开发者在完成单元测试后执行。将多个功能组合起来作为单一的整体进行测试,目的是发现多个功能在相互连接起来后的缺陷。组件测试可大可小。大的可以到几个单独的页面、模块、子系统的组合。比如将多个页面组合起来,测试他们流程跳转,就属于组件测试。
15)端到端测试
也是一种黑盒测试类型,类似于系统测试,端到端测试在线模拟的、完整的、真实应用环境下模拟真实用户对应用进行测试,比如应用会和数据库交互、会使用网络通信、或者在适当的情况下其他硬件、应用、系统进行交互,端到端指的是从一个端点到另一个端点的意思,所以端到端测试重点是用于测试模块和模块之间的协调性。当应用是分布式系统或者需要其他外部系统协同时,端到端测试扮演着非常重要的角色。它可以全面检查以确保软件在不同平台和环境中能准确地交互,该测试有以下目的: 确保应用可以和外部系统之间良好的协调,对于前端来说,是确保页面和后端之间的良好协调。 检查从原系统到目标系统的所有系统流 从最终用户角度验证需求 识别异构环境中的问题 我们工作中就是使用ECU-TEST测试软件去检查Ibox上的车载app是否存在异常,主要的范围是测试车载软件的性能,是否可以正常打开,数据是否加载得出来,触发的事件后台有没有记录,与后台能不能正常通信等。
16)等价划分 一种黑盒测试的测试技术,通过等价划分,可以将所有的输入数据合理地划分为多个分组,只需在每个分组中取一个数据作为测试的输入条件,这样可以实现用少量的代表性的测试数据取得较好的测试结果,所以这个测试的目的是:在不导致缺陷的前提下,移除指定分组中重复的用例,简化测试的工作。比如一个程序接受-10到10之间的值,使用等价分区方法可以划分为三个组,0、负值、正值。接下来的测试只需要从这三个分组中取一个成员进行测试,不需要每个成员都测试一遍。17)实例测试 实时测试,包含着实时场景还涉及基于测试人员经验的场景。18)探索测试 类似于Ad-Hoc测试,探索性测试是由测试团队进行的非正式测试。目的是探索应用并查找应用中存在的缺陷,在测试期间有一定几率发现重大甚至可能导致系统故障的缺陷。探索性测试期间,最好跟踪记录好测试的流程、以及开始该流程之前的活动记录,方便复现bug。19)功能性测试 是一个大类,又称为行为测试,功能测试会忽略内部实现而关注组件的输出,目的是验证是否符合需求,这是一种面向功能需求的黑盒测试类型,它是相对于非功能测试而言的,功能测试需要关注功能或者业务,需要业务耦合程度高,非功能测试则是通用的,比如压力测试、负载测试等,这些都有通用的工具来支持,不需要很少定制化操作。20)GUI测试 目的是根据业务需求验证GUI,在详细设计文档和GUI模型中一般会提到应用期望的GUI。 常见的包括测试屏幕上显示的按钮和输入字段的大小、表格中所有文本、表格或内容的对齐规则等等。21)大猩猩测试 指的是由测试人员执行的测试类型,有时也由开发人员执行,大猩猩测试中,对模块中的一个模块或者功能进行了彻底和严格的测试,改测试会对一个功能或者模块进行重复"上百次"的测试,人类根本受不了,所以说是又称为令人沮丧的测试 目的是检查应用程序的稳健性。22)乐观路线测试 乐观路线测试的目标是在正常流程上成功测试应用。它不会考虑各种负面或者异常情况。重点只是关注于验证应用在有效和合法输入条件下能生成期望的输出。比如银行付款,只考虑账户有钱的正常状态。23)增量集成测试 增量集成测试是一种自下而上的测试方法,即在添加新功能时立即集成应用程序进行连续测试。应用程序功能和模块应该足够独立,以便单独测试。通常由程序员或者测试人员完成。24)安装卸载测试 安装和卸载测试时在不同硬件或者软件环境下的不同操作系统上进行完整/部分的安装、升级、卸载、回滚等测试,常用于桌面端应用。25)集成测试 是指将所有的模块集成之后,验证合并后的功能。模块通常是代码模块、单个应用、网络上的客户端和服务器应用等等 集成测试一般在单元测试之后,所以单元测试时集成测试的基础,没有进行单元测试的集成测试是不靠谱的。所以最简单的形式是:把两个已经测试过的单元组成一个组件,测试他们之间的接口,也就是说集成测试在单元测试的基础之上,将单元测试中独立的单元合并起来,验证他们的协调性,合并后的组件又是一个新的单元,这样逐步合并测试,最终形成完整的应用程序。这种类型的测试常用于B/S软件和分布式系统。26)负载测试 这是一种非功能性测试,负载测试的目的是检查系统可以承受多少负载而不会降低性能,或者是说最大工作负载是多少负载测试有助于查找特定负载系统下最大容量以及导致软件性能下降的任何原因,可以使用JMeter、LoadRunner、WebLoad、Silk执行程序等工具执行负载测试。 负载测试经常和性能测试、压力测试、稳定性测试等联系在了一起,上图中的TPS(Transation Per Second)指的是每秒钟系统可以处理的交易或者事务的数量;Server Resource指的是系统资源占有。 性能测试主要是位于a-b之间,在系统测试初期就会规划一个预期目标,比如给定资源Ax,a点就是性能期望值。也就是说在给定固定资源Ax的情况下,如果TPS可以达到a点甚至更高,就说明系统性能达到或者好于预期,通过性能测试可以验证系统的处理能力有没有达到预期。 负载测试:位于b-c之间。对系统不断增加并发请求,直到系统的某项或者多项指标达到安全的临界值,比如c,这个c就是所谓的最大负载量,后面再增加请求压力,系统的处理能力不但不能提高,反倒会下降,通过压力测试可以得出系统的最大安全负载值。 压力测试可以得出系统最大的安全负载值。 压力测试位于c-d之间,在超过安全负载的情况下,继续对系统增加压力,直到达到崩溃点,即上图的d通过夜里测试可以得出系统的最大承受能力 稳定性测试,位于a-d之间,在a、b、c、d不同的点(代表特定的硬件、软件和网络环境),让系统运行一段较长的时间,检测系统在不同条件下的系统运行的稳定性。27)猴子测试 是由测试人员进行的,即把自己当成猴子,在没有任何知识背景或者理解应用的前提下,随意输入和操作。目标是通过随机输入数据来检查应用程序是否崩溃,猴子是随机执行的,没有测试用例,也没有必要了解全部功能。28)变异测试(可变性测试) 是一种白盒测试,这是一种和单元测试反着来的测试类型。通常单元测试是通过测试用例来验证代码是否可靠,而编译测试是反过来,它首先是更改其中一个程序的源代码,再跑单元测试,如果单元测试可以通过则可能说明测试用例没有效果,或者测试用例没有覆盖到这处代码的变异。所以说变异测试可以反过来验证你的测试用例是否有效。还有就是可以帮助我们找出一些无法被当前测试所防止的潜在错误。29)悲观测试 和乐观测试相反,它要求测试者要具有打破常规的思绪,考虑各种情况,使用各种邪恶的、不怀好意、不合法的操作来测试系统,悲观测试会使用不正确的数据、无效的数据进行输入来验证,它来验证系统是否可以识别异常情况并且按照预期进行。30)非功能性测试 每一个大型组织都会有一个独立的团队,通常称为非功能测试(NFT)或者性能团队。其涉及测试肺功能的需求有负载测试、压力测试、安全性、容量、恢复测试等。NFT的目标是确保软件或者应用程序的响应时间是否满足业务需求。例如在加载任何页面或者系统都不应该花费太多的时间并且在负载峰值期间应该维持良好的运行状态31)性能测试 这个术语常常和压力和负载测试,性能测试主要是用于检查系统是否满足性能需求,会使用不同的性能和负载工具来执行此测试。 性能测试这个范围比较大,广义上的性能测试包括上文提到的负载测试、压力测试、稳定性测试、容量测试等,狭义的性能测试指的是在特定资源条件下,测试系统能否达到期望值,也就是基线测试(Baseline Test). 基线测试:在给定的资源下,测试最佳的性能,用作后续测量的参考基线。注意基线测试和基准测试是有区别的这么理解,基准是你想达到的,比如100短跑的世界纪录,基线是你的成绩。 负载测试:在预期峰值的生产负载下测量系统的性能。 稳定性测试:在指定负载下,长时间测量系统的稳定性 压力测试:测试极端条件下的系统性能32)恢复测试 用于验证应用或者系统中崩溃或者灾难中恢复的程度,确定系统是否能够在灾难发生后继续运行。比如应用通过网络电缆接收数据,突然断开网络的链接过一段时间再去连上网线,系统应该恢复由于网络线缆拔出而丢失连接的数据。33)回归测试 在修改任意模块或者功能后,将应用作为一个整体进行测试,称为回归测试。目的就是验证在软件原有的功能变动后是否保持完整性。有观点认为回归测试就是回归测试,是指重复之前的全部或者部分相同的测试工作,其实是有点道理的,而且因为局部修改而牵动全身的意外在平时开发中并不少见,这种意外性就是回归测试的存在的目的。 因为在回归测试中很难覆盖所有的的系统,通常最好是使用自动化测试工具进行这类测试,比如每次修改完代码,跑单元测试来确保不影响其他软件单元。34)基于风险的测试 在该测试中,功能或者需求将根据其优先级进行测试。基于风险的测试会优先测试高度关键的功能,因为这些功能对业务影响最大或者故障概率非常高,。而优先级由业务需求决定,因此一旦为所有功能设置了优先级,则应该首先执行高优先级功能,然后再去执行低优先级功能,低优先级功能可以在时间充裕时测试或者不测试。 基于风险测试应该在“不够时间来测试整个应用,但是又要按时交付软件”的情况下执行,通常还需要客户和高级管理层的讨论和批准之后才进行。35)完整性测试 完整性测试用于确定一个新的软件版本是否可以开始正式的测试,如果一个应该在一开始使用时就崩溃,那么就说明系统还是不够稳定,没有必要进行下一步测试,这种情况应该给开发,以免浪费时间。 在软件设计阶段,测试就会编写冒烟测试用例; 开发团队在提交版本给测试之前会自己跑一下冒烟测试用例,检查一下没有重大意义的,影响测试进程的bug,如果有则退回开发。 如果通过了完整性测试,则进行冒烟测试,如果没有通过冒烟测试也会立即打回开发。顺利通过完整性测试和冒烟测试之后才会进入正式测试阶段。 目的之一就是为了降低测试团队的工作负担36)安全性测试 这也是一个庞大的学科,而且知识每天都在更新,所以安全测试一般由特殊的安全团队执行,他们以各种黑客手段进行渗透测试。 安全测试旨在确保应用或者网站免受内部和外部威胁的侵害,这个测试包括预防恶意程序、病毒;检验授权和身份验证过程的安全性。他还会检查软件对任何黑客攻击和恶意程序的反应方式,以及在遭到黑客攻击后如何维护软件以保护数据安全。37)冒烟测试 冒烟测试,每当开发团队提交新的构建的时候,软件测试团队就会首先验证构建,并不确保不存在重大问题,如果存在重大的问题会直接打回开发团队。 如何通俗的理解冒烟测试呢?这个属于硬件或者硬件组件进行更改或者修复后,直接给设备加电,如果没有冒烟,则该组件就通过了测试。举个例子,给三星Note7加电,如果没有爆炸,就通过冒烟测试。测试团队在确保构建稳定后才会进一步执行详细的测试。冒烟测试会检查构建中是否存在中断缺陷,这将阻止测试团队进一步详细测试。即如果测试人员发现主要功能不能工作,他们会拒绝这次构建,并且退回给开发团队。冒烟测试一般会在回归测试或者其他详细测试之前进行。38)静态测试 静态测试有点类似于代码review,在不执行任何代码的情况下执行(也就是不运行应用),它涉对可交付成果审查(inspection)、review和演练(walkthrough).比如检查代码语法、命名约定、项目组织。 静态测试不仅适用于代码,也适用于测试用例、测试计划和设计文档。如果在静态测试阶段发现缺陷,可以将缺陷成本降到最低。比如在设计阶段就发现问题,相比到开发阶段甚至到生产环境出现问题要好解决。 以前端为例,静态测试可能包括: 使用Lint工具对程序进行规范检查,相关的工具有ESLint、TSLint、Stylint等,甚至Typescript这些类型检查也可以归到这个范畴。代码审查,有一些问题是无法通过Lint工具覆盖的,比如代码逻辑、异常捕获、项目组织、内存泄漏等等,这些需要人工走审查。检查代码是否与设计一致,是否符合软件需求、概要和详细设计,不仅可以看出代码问题,也可以反过来更早发现需求或者设计是否正确。39)压力测试 通过压力测试,模拟系统收到超过其规格的压力时失败的方式和时间,找出系统的崩溃点。这个测试在高负载情况下执行的,例如存取超过容量限制的数据、执行复杂的数据库查询、连续暴力输入到系统加载到数据。40)系统测试 系统测试在完整的系统测试上进行测试,也就是说系统测试一般都在集成测试之后进行,集成测试之后系统成为了一个整体,整个系统测试是在这个基础上、在真实运行环境验证系统是否符合业务需求。这是一种黑盒测试类型的,基于总体需求规范,涵盖系统的所有组合部分。 系统测试其实不是一个具体的测试技术,而是一个测试阶段。这个阶段会有很多种测试,一般包括:功能测试、非功能测试’归类一下系统测试的目的: 确保应用可以作为一个整体良好的运行、确保符合业务需求、确保在真实情况下可以良好的运行,比如进行一些非功能测试,验证系统的健壮性。其实系统测试和端到端测试类似,可以对比看下: 端到端测试一般针对被测应用本身的以及其依赖的的其它系统。重点关注前端、后端以及中间件之间的处理流程测试类型包含功能测试和非功能测试。41)单元测试 测试独立的软件单元或者模块可以称为单元测试,通常是由开发者完成,不是测试人员完成,因为他需要详细了解内部程序设计和代码。 单元测试是和开发者最为密切的测试类型,它的测试对象是软件单元,软件单元可以是一个函数/方法、一个类或者一个GUI组件等。 这是一种白盒测试,所以要求开发者自己进行,因为只有开发者才知道单元的内部实现,单元测试一般会用测试覆盖率来验证单元测试的完成度。 主要是将逻辑出现的各个异常在测试的过程中全方位覆盖,保证100%的覆盖率42)可用性测试 可用性测试用来检测应用的用户友好程度。它会验证新用户可以轻松理解应用流程,如果用户陷入麻烦,测试人员要记录好并提供帮助。可以认为可用性测试是在检查系统的导航性。43)漏洞测试 其涉及识别软件、硬件和网络中的漏洞。如果漏洞容易受到攻击,或者容易受到病毒和蠕虫感染,黑客或者恶意程序就会控制系统。44)容量测试 非功能测试,会检查应用在遇到大量数据的系统行为和响应时间,这种大量数据可能会影响系统的性能处理和处理时间的速度。45)白盒测试 也称为玻璃盒测试、结构测试、逻辑驱动测试或者是基于代码的测试,基于应用程序代码的内部逻辑。即测试人员应该知道内部软件和代码是如何工作的,对所有的逻辑路径进行覆盖测试,其中,单元测试和静态测试就是典型的白盒测试,基本上白盒测试可以等同于单元测试。逻辑路径包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖等 这只是测试的一部分,实际上有超过100种的测试类型,但是并非所有的测试类型都会被所有项目使用。总的来说就是依据实际的需求来。
上一篇: 应用程序软件开发的可用性原则是什么?
下一篇: 应用程序测试策略
推荐阅读
-
35 岁实现财务*,腾讯程序员手握2300万提前退休?-1000万房产、1000万腾讯股票、加上300万的现金,一共2300万的财产。有网友算了一笔账,假设1000万的房产用于自住,剩下1300万资产按照平均税后20-50万不等进行计算,大约花上26-60年左右的时间才能赚到这笔钱。也就是说,普通人可能奋斗一辈子,才能赚到这笔钱。在很多人还在为中年危机而惶惶不可终日的时候,有的人的35岁,就已经安全着陆,试问哪个打工人不羡慕?但问题是有这样财富积累必然有像样的实力做靠山。没有人可以不劳而获。 看到这里,肯定有人说,那么对于普通人来说,卷可能真就成了唯一的出路。但是卷也有轻松的卷,“偷懒”的卷法,对于程序员而言,刨除掉一时无法改掉的开会传统占用的大部分时间,如何把有限的时间和精力放在真正重要的架构设计、需求设计上,而不是重复的造*,编码、改bug、手动测试。因此在科技改变生活的今天,学会使用AI工具成为程序员们的必备技能。 以全栈式全自动的软件开发工具飞算SoFlu软件机器人为例,作为全球首款面向微服务架构设计和最佳实践的软件机器人,SoFlu软件机器人改变了原来手工编码的作业模式,通过可视化拖拽方式以及参数配置就能实现等同于编写复杂代码的业务逻辑,在设计业务逻辑时就完成了微服务应用开发,做到“业务即图,图即代码”,实现“软件开发,十倍提效”。 而作为飞算SoFlu软件机器人的一个重要组成部分,FuncGPT(慧函数)支持所有类型函数创建。通过自然语言描述Java函数需求,实时生成高质量、高可读性的Java函数代码。生成代码可直接复制到IDEA,或一键导入Java全自动开发工具函数库。 FuncGPT(慧函数)具有五大核心能力: ● 自然语言:通过自然语言即可生成函数,降低软件开发门槛。 ● 秒级函数开发:全自动秒级开发函数,秒级完成,效率千倍提升。 ● 一站式函数开发应用:函数生成即可直接应用,效率、安全有保障。 ● 质量可靠:生成的函数代码符合业界规范、具备良好的可读性,符合最优解。 ● 灵活生成:可以根据开发人员的具体需求生成并支持调整和修改。 以“将文件流转换为File对象”这个需求为例,以下是FuncGPT(慧函数)秒级生成的代码: / 类名:FileConverter // 函数名:convertStreamToFile // 函数功能:将文件流转换为File对象 // POM依赖包:无 import java.io.File; import java.io.FileOutputStream; import java.io.IOException; import java.io.InputStream; public class FileConverter { /** * 将文件流转换为File对象 * @param inputStream 文件流 * @param filePath 文件路径 * @param fileName 文件名 * @return 转换后的File对象 * @throws IOException 如果发生I/O异常 */ public static File convertStreamToFile(InputStream inputStream, String filePath, String fileName) throws IOException { File file = new File(filePath + File.separator + fileName); // 创建File对象 try (FileOutputStream outputStream = new FileOutputStream(file)) { // 创建文件输出流 byte buffer = new byte[1024]; int bytesRead; while ((bytesRead = inputStream.read(buffer)) != -1) { // 从文件流读取数据并写入文件 outputStream.write(buffer, 0, bytesRead); } } return file; // 返回转换后的File对象 } } // 函数示例 // 将文件流转换为File对象示例 // 入参:inputStream,文件流 // 入参:filePath,文件路径 // 入参:fileName,文件名 // 出参:file,转换后的File对象 // 调用示例: // InputStream inputStream = new FileInputStream("example.txt"); // String filePath = "C:\\Users\\User\\Documents"; // String fileName = "example.txt"; // File file = FileConverter.convertStreamToFile(inputStream, filePath, fileName); // System.out.println(file.getAbsolutePath); // 输出结果:例如,将文件流转换为File对象后,文件的绝对路径为:C:\Users\User\Documents\example.txt // 则输出结果为:C:\Users\User\Documents\example.txt 通过分析,不难发现以上代码:
-
测试类型大汇总(45 类)
-
aps是什么意思_不同的富士APS-C画幅微单区别在哪里,档次是怎么划分的?-X-A系列原本指的是富士的入门级微单,最大的特点是没有使用富士X-Trans™CMOS 传感器,目前在售的有两款,分别是XA5和XA7。 富士(FUJIFILM)X-A5/XA5 15-45套机 富士(FUJIFILM)X-A7/XA7 15-45套机 目前这两款相机都处于历史最低价附近,XA5套机2699元,XA7套机3999元。XA5就是一个标准的入门级相机,定位就是时尚小巧自拍,在2699这个价位不要对它的性能有太多的奢求。 XA7价格来到了3999元,这就很有意思了,富士把入门型的相机价格推到了4000元,并且提供了自拍翻转屏和4K30P视频录制,这样一款相机就很有性价比了。 XE3是老款的中端相机,价格和入门级的XA7是一样的,都是3999元,这两款相机如何做选择呢?XE3有着更多的按键意味着更好的操控,但屏幕不是自拍翻转屏所以这点不如XA7好用。 要注意的是XE3用的是富士独有的X-Trans™CMOS III传感器,XA7是普通的2400万像素传感器,你可以理解为X-Trans才是富士的精髓。 富士(FUJIFILM)X-E3 15-45套机 当然,买新不买旧,XA7的新功能和自拍翻转屏可能会更适合你。 XT200是富士专门针对vlog市场推出的相机,其实之前的XA7也可以拍摄vlog,但XT200是富士官方宣传中的第一款vlog相机。数码防抖+3.5mm 麦克风口+自拍翻转屏+无裁切4K30P,这些都是XT200的优势,但这款相机也是普通的2400万像素传感器,没有用富士独有的X-Trans,可能是从价格角度考虑做了阉割吧。 富士(FUJIFILM)X-T200/XT200 微单相机 Vlog相机 富士XT30是我认为富士性价比最高的微单照相机,注意我说的是照相机。理由很简单,因为从拍照角度来看XT30和XTXT3几乎没有明显差距,主要是操控差了一些、视频性能大幅削弱,但好歹也是个有着双波轮+曝光补偿波轮+快门速度波轮的相机,操控方面不会太差的。视频方面也有着超采4K 30P的规格,支持F-log输出。 可以这么说,如果你只拍照,那么XT30是富士微单中性价比最高的,视频方面XT30也不差,只不过没有专业的10bit和4K60P而已。 富士(FUJIFILM)X-T30/XT30 15-45套机 XT3和XT4得放在一起说,这两款相机其实都挺好,420 10bit 4K60P的专业视频模式基本代表了APS-C画幅的上限水平。XT4还提升了电池续航增加了五轴防抖,配上富士独特的胶片滤镜,不管是拍照还是拍视频都非常优秀。 不要觉得这两款相机贵,同价位里能做到4K60P的微单也就是M43画幅的GGHGH5S,最便宜的G9机身也要7000多,这APS-C画幅的XT3机身接近8000也算合理价格范围内。除此之外的4K60P机身只有13998的松下S5和15999的佳能R6了。 富士(FUJIFILM)X-T3/XT3 1855套机 富士(FUJIFILM)X-T4/XT4 微单相机 套机(18-55mm) B站更新4K视频投稿后有很多人想拍摄4K升格,在很长一段时间里富士XT3和XT4是最优选,毕竟兼顾视频和拍照,对焦也还算能用。 X-Pro3和X-Pro2这两款微单可以算是旁轴相机,是富士官方意义上的旗舰级相机。从用料做工操控按键角度来说的确是旗舰级别,但视频性能方面只有4K30P,价格却比XT3还贵,可能这就是旁轴情怀带来的溢价吧。 富士(FUJIFILM)X-Pro3 微单相机 机身 黑色 我在之前的文章里提过很多次,有一些相机属于如果你想买你压根不会看测评,如果你犹豫那么这款相机不适合你,为什么这么说,因为有一些比较小众的相机可能在性能上并不好,但独特的外形、操控、体积、传承赋予了它独特的定位。譬如富士X-Pro系列微单就是旁轴的电子化,理光GR传承大师的扫街理念,尼康DF的外形源自胶片时代的相机,这些相机就不是针对大多数消费者的,定位就是小众。所以我说喜欢就买,不要考虑什么性能规格。 X100系列相机是一款不可换镜头的等效35mm旁轴数码相机,从外形看就是经典的复古造型。这两款相机和X-Pro3一样,如果你喜欢那就买,别犹豫, 你在市场上找不到同类型的其他数码相机,徕卡Q是28mm,索尼RX1R系列是35mm但外形不够复古,X100系列就是独特的你没有其他选择。 那么X100F和X100V该如何选择呢?X100F的镜头很一般甚至算不上好,如果我没记错的话和初代的X100是同款镜头,X100V的镜头是全新制作的很棒,X100V的机身性能也和XTX-Pro3差不多。 富士(FUJIFILM)X100F 数码相机 旁轴 2430万像素 富士(FUJIFILM)X100V 数码相机 旁轴 2610万像素 还是那句话,这两款相机也是那种如果你喜欢那就毫不犹豫下单的类型,而且这两款相机也没有竞品。 以前不推荐富士的原因是原厂镜头太贵,现在唯卓仕给富士出了四款可以自动对焦的大光圈镜头,覆盖35到130mm的焦段,可以基本满足人像摄影爱好者的需求。拍风景的话国产很多镜头厂商都有富士卡口的手动镜头可以选择,从这个角度来说富士微单就非常值得入手了。 和友商竞品相比:
-
【Netty】「萌新入门」(七)ByteBuf 的性能优化-堆内存的分配和释放都是由 Java 虚拟机自动管理的,这意味着它们可以快速地被分配和释放,但是也会产生一些开销。 直接内存需要手动分配和释放,因为它由操作系统管理,这使得分配和释放的速度更快,但是也需要更多的系统资源。 另外,直接内存可以映射到本地文件中,这对于需要频繁读写文件的应用程序非常有用。 此外,直接内存还可以避免在使用 NIO 进行网络传输时发生数据拷贝的情况。在使用传统的 I/O 时,数据必须先从文件或网络中读取到堆内存中,然后再从堆内存中复制到直接缓冲区中,最后再通过 SocketChannel 发送到网络中。而使用直接缓冲区时,数据可以直接从文件或网络中读取到直接缓冲区中,并且可以直接从直接缓冲区中发送到网络中,避免了不必要的数据拷贝和内存分配。 通过 ByteBufAllocator.DEFAULT.directBuffer 方法来创建基于直接内存的 ByteBuf: ByteBuf directBuf = ByteBufAllocator.DEFAULT.directBuffer(16); 通过 ByteBufAllocator.DEFAULT.heapBuffer 方法来创建基于堆内存的 ByteBuf: ByteBuf heapBuf = ByteBufAllocator.DEFAULT.heapBuffer(16); 注意: 直接内存是一种特殊的内存分配方式,可以通过在堆外申请内存来避免 JVM 堆内存的限制,从而提高读写性能和降低 GC 压力。但是,直接内存的创建和销毁代价昂贵,因此需要慎重使用。 此外,由于直接内存不受 JVM 垃圾回收的管理,我们需要主动释放这部分内存,否则会造成内存泄漏。通常情况下,可以使用 ByteBuffer.clear 方法来释放直接内存中的数据,或者使用 ByteBuffer.cleaner 方法来手动释放直接内存空间。 测试代码: public static void testCreateByteBuf { ByteBuf buf = ByteBufAllocator.DEFAULT.buffer(16); System.out.println(buf.getClass); ByteBuf heapBuf = ByteBufAllocator.DEFAULT.heapBuffer(16); System.out.println(heapBuf.getClass); ByteBuf directBuf = ByteBufAllocator.DEFAULT.directBuffer(16); System.out.println(directBuf.getClass); } 运行结果: class io.netty.buffer.PooledUnsafeDirectByteBuf class io.netty.buffer.PooledUnsafeHeapByteBuf class io.netty.buffer.PooledUnsafeDirectByteBuf 池化技术 在 Netty 中,池化技术指的是通过对象池来重用已经创建的对象,从而避免了频繁地创建和销毁对象,这种技术可以提高系统的性能和可伸缩性。 通过设置 VM options,来决定池化功能是否开启: -Dio.netty.allocator.type={unpooled|pooled} 在 Netty 4.1 版本以后,非 Android 平台默认启用池化实现,Android 平台启用非池化实现; 这里我们使用非池化功能进行测试,依旧使用的是上面的测试代码 testCreateByteBuf,运行结果如下所示: class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf 可以看到,ByteBuf 类由 PooledUnsafeDirectByteBuf 变成了 UnpooledUnsafeDirectByteBuf; 在没有池化的情况下,每次使用都需要创建新的 ByteBuf 实例,这个操作会涉及到内存的分配和初始化,如果是直接内存则代价更为昂贵,而且频繁的内存分配也可能导致内存碎片问题,增加 GC 压力。 使用池化技术可以避免频繁内存分配带来的开销,并且重用池中的 ByteBuf 实例,减少了内存占用和内存碎片问题。另外,池化技术还可以采用类似 jemalloc 的内存分配算法,进一步提升分配效率。 在高并发环境下,池化技术的优点更加明显,因为内存的分配和释放都是比较耗时的操作,频繁的内存分配和释放会导致系统性能下降,甚至可能出现内存溢出的风险。使用池化技术可以将内存分配和释放的操作集中到预先分配的池中,从而有效地降低系统的内存开销和风险。 内存释放 当在 Netty 中使用 ByteBuf 来处理数据时,需要特别注意内存回收问题。 Netty 提供了不同类型的 ByteBuf 实现,包括堆内存(JVM 内存)实现 UnpooledHeapByteBuf 和堆外内存(直接内存)实现 UnpooledDirectByteBuf,以及池化技术实现的 PooledByteBuf 及其子类。 UnpooledHeapByteBuf:通过 Java 的垃圾回收机制来自动回收内存; UnpooledDirectByteBuf:由于 JVM 的垃圾回收机制无法管理这些内存,因此需要手动调用 release 方法来释放内存; PooledByteBuf:使用了池化机制,需要更复杂的规则来回收内存; 由于池化技术的特殊性质,释放 PooledByteBuf 对象所使用的内存并不是立即被回收的,而是被放入一个内存池中,待下次分配内存时再次使用。因此,释放 PooledByteBuf 对象的内存可能会延迟到后续的某个时间点。为了避免内存泄漏和占用过多内存,我们需要根据实际情况来设置池化技术的相关参数,以便及时回收内存; Netty 采用了引用计数法来控制 ByteBuf 对象的内存回收,在博文 「源码解析」ByteBuf 的引用计数机制 中将会通过解读源码的形式对 ByteBuf 的引用计数法进行深入理解; 每个 ByteBuf 对象被创建时,都会初始化为1,表示该对象的初始计数为1。 在使用 ByteBuf 对象过程中,如果当前 handler 已经使用完该对象,需要通过调用 release 方法将计数减1,当计数为0时,底层内存会被回收,该对象也就被销毁了。此时即使 ByteBuf 对象还在,其各个方法均无法正常使用。 但是,如果当前 handler 还需要继续使用该对象,可以通过调用 retain 方法将计数加1,这样即使其他 handler 已经调用了 release 方法,该对象的内存仍然不会被回收。这种机制可以有效地避免了内存泄漏和意外访问已经释放的内存的情况。 一般来说,应该尽可能地保证 retain 和 release 方法成对出现,以确保计数正确。