养生
modernizr(不知道测试什么?这些是你需要知道的软件测试类型和常识)

我们作为测试人员了解很多种不同的软件测试类型,例如功能测试(Functional Test)、非功能测试、自动测试、敏捷测试、以及它们的各种子类型. 尽管在我们的测试过程中会接触很多种测试类型, 或者听说过某些测试类型,但是很少人敢说精通所有的测试类型.

不同的软件测试类型

功能测试类型:

集成测试(Integration testing)

健全性测试(Sanity testing)

接口测试(Interface testing)

Beta/验收测试(Beta/Acceptance testing)

性能测试(Performance Testing)

压力测试(Stress testing)

安全测试(Security testing)

安装测试(Install testing)

可靠性测试(Reliability testing)

一致性测试(Compliance testing)

来看看这些测试类型的细节

0) A/B测试(A/B Testing)

顾名思义, A/B测试就是准备两个(A/B)或两个以上的版本,让不同的用户来随机访问这些版本,收集各群组的用户体验数据和业务数据,最后分析、评估出最好版本,正式采用。如上图,谷歌使用A/B测试来决定导航应该是红色还是蓝色。


1) Alpha测试(Alpha Testing)

Alpha测试一般在开发的末段且在Beta测试之前进行。在这个测试过程中可能会驱动开发者进行一些小(minor)的设计变动. Alpha测试一般在开发者网站进行,即只对开发者或内部用户开放,一般可以为此类测试创建内部虚拟的用户环境。

Pre-alpha: 有时候软件会在Alpha或Beta版本前先发布Pre-alpha版本, 相比Alpha和Beta,这是一个功能不完整的版本

Beta: 一般Beta版本会包含所有功能,但可能又有一些Bug,需要调试反馈。 Beta版本是软件最早对外公开的软件版本,由公众(通常为公司外的第三方开发者和业余玩家)参与测试。

举一个典型的例子, iOS13的发布计划:

June 17: iOS 13 beta 2 launched for developers

July 3: iOS 13 developer beta 3 launch with some new features

Early September 2019: iOS 13 Golden Master (final dev beta) # -> 九月初,该发最终Beta版本了,相当于进入RC阶段了

复制代码

验收测试通常是部署软件之前的最后一个测试操作, 也称为交付测试, 由最终客户执行,他们会验证端到端(end to end)的系统流程是否符合业务需求,以及功能是否是满足最终用户的需求。只有当所有的特性和功能按照期望的运行,客户才会接受软件

Ad-hoc中文应该理解为临时的意思。顾名思义,这种测试是在临时基础上进行的, 有时候也称为随机测试。即没有参考测试用例、没有针对该测试的任何计划和文档。Ad-hoc测试的目的就是通过执行随意的流程或任意的功能来找出应用的缺陷和问题

Ad-hoc测试一种非正式的方法,可以由项目中的任何人执行。尽管没有测试用例很难识别缺陷,但是有些时候在Ad-hoc测试期间发现的缺陷可能无法使用现有的测试用例来识别, 也就是说它一般用来发现‘意外’的缺陷.


4) 可访问性测试(Accessibility Testing)

不同平台、不同应用类型对可访问性支持情况不太一样,比如iOS相比其他操作系统则更重视可访问, 而国外比国内更重视可访问性。

5) Beta测试(Beta Testing)

执行Beta测试目的是确保软件或产品中没有重大故障,并且满足最终用户的业务需求。当客户接受软件时,Beta测试才算通过。

前端应用输入的数据,一般都会存储在数据库,所以针对数据库的这类测试称为数据库测试或者后端测试. 市面有不同的数据库,如SQL Server,MySQL和Oracle等。数据库测试会涉及表结构,模式,存储过程,数据结构等。

后端测试一般不会涉及GUI,测试人员通过某些手段直接连接到数据库,从而可以容易地运行一些数据库请求来验证数据。通过后端测试可以发现一些数据库问题,比如数据丢失、死锁、数据损坏。这些问题在系统投入生产环境之前进行修复至关重要


7) 浏览器兼容测试(Browser Compatibility Testing)

这是兼容性测试的子类型,由测试团队执行. 浏览器兼容测试主要针对Web应用,用于确保软件可以在不同浏览器或操作系统中运行; 或者验证Web应用程序是否支持在浏览器的所有版本上运行, 以确定应用最终兼容的范围.

我们有很多策略来应对浏览器兼容性,比如渐进增强或者优雅降级, 还有制定浏览器兼容规范;

当然为了测试跨浏览器兼容性,还要一些辅助工具,例如BrowserStack, 对于我们这些小团队,只能下一堆Portable(Portable浏览器运行时相互隔离的, 所以不会存在配置文件等冲突问题) 浏览器,手工测试了。

向后兼容测试, 用于验证新开发或更新的软件是否能在旧版本的环境中运行。

同理也可以检查新版本是否可以兼容旧版本软件创建的数据表、数据文件、数据结构、配置文件。


9) 黑盒测试(Black Box Testing)

换句话说黑盒测试从用户的角度出发针对软件界面、功能及外部结构进行测试,而不考虑程序内部逻辑结构.

关于黑盒测试的优缺点以及测试类型可以看这里

边界值测试, 测试应用处于边界条件(boundary level)的行为。很多边界条件开发者是很难考虑周到的,所以才有一个专门的测试类型来验证这种情况

比如数字范围为1-500, 那么边界值测试会在这些值上进行验证: 0、1、2、499、500、501

这是白盒测试的子类型,在单元测试中实施. 顾名思义,分支测试表示测试要覆盖程序代码的各种条件分支, 避免遗漏缺陷。分支覆盖是单元测试覆盖率的一个指标之一

比较测试,将产品的优点和弱点与旧版本或者同类(竞品)产品进行比较.

还有一种比较典型的例子就是和行业的领导者比较,比如我们做IM的,会经常和微信比较: '你这个应用的启动速度怎么比微信慢这么多?'

这是一个大类, 兼容性测试用于验证应用在不同环境、web服务器、硬件、网络条件下的行为。兼容性测试确保软件可以在不同的配置、不同的数据库、不同的浏览器,以及它们不同的版本下运行。兼容性测试由测试团队实施

组件测试(此组件非GUI组件, 取组合测试可能更好理解一点),一般也称为模块测试(Module Testing), 一般由开发者在完成单元测试后执行。组件测试将多个功能组合起来作为单一的整体进行测试,目的是发现多个功能在相互连接起来之后的缺陷。

端到端测试也是一种黑盒测试类型,类似于系统测试. 端到端测试在模拟的、完整的、真实应用环境下模拟真实用户对应用进行测试,比如应用会和数据库交互、会使用网络通信、或者在适当的情况下和其他硬件、应用、系统进行交互. 端到端是指从一个端点到另一个端点的意思,所以端到端测试重点用于测试模块和模块之间的协调性。

确保应用可以和外部系统之间良好的协调。对于前端来说,是确保页面和后端之间良好协调

从最终用户角度验证需求识别异构环境中的问题

因为和系统测试很相似,所以它们也被经常拿来比较

等价划分, 这是一种黑盒测试的测试技术. 通过等价划分,可以将所有的输入数据合理地划分为多个分组,我们只需在每个分组中取一个数据作为测试的输入条件, 这样可以实现用少量代表性的测试数据取得较好的测试结果.

比如一个程序应用接受-10到+10之间的值,使用等价分区方法可以划分为三个分组: 0、负值、正值. 接下来的测试只需从这个三个分组中取一个成员进行测试, 而不需要-10到+10每个成员都测试一遍.

It means real-time testing. Example testing includes the real-time scenario, it also involves the scenarios based on the experience of the testers.

这里不是特别能理解这个测试类型,所以贴上原文。知道的告诉我呀

探索性测试有点类似于Ad-Hoc测试. 探索性测试是由测试团队进行的非正式测试。此测试的目的是探索应用并查找应用中存在的缺陷。像探险一样,在测试期间是有一定几率发现的重大、甚至可能导致系统故障的缺陷.

探索测试不需要任何文档和测试用例.

功能测试是一个大类, 又称为行为测试, 功能测试会忽略内部实现而关注组件的输出,目的是验证是否符合需求,这是一种面向功能需求的黑盒测试类型。关于功能测试的细节请看这里


20) GUI测试(Graphical User Interface (GUI) Testing)

常见的GUI测试包括测试屏幕上显示的按钮和输入字段的大小、表格中所有文本、表格或内容的对齐规则等等. 如果团队有UI设计规范,还会验证是否符合设计规范

大猩猩测试是由测试人员执行的测试类型,有时也由开发人员执行。在大猩猩测试中,对模块中的一个模块或功能进行了彻底和严格的测试。原文没有说出大猩猩测试的精髓,大猩猩测试会对一个功能或模块进行重复‘上百次’的测试, 人类根本受不了这样子的测试方式,所以大猩猩测试的另一个别名是‘令人沮丧的测试(Frustrating Testing)’


22) 乐观路线测试(Happy Path Testing)


23) 增量集成测试(Incremental Integration Testing)


24) 安装卸载测试(Install/Uninstall Testing)


25) 集成测试(Integration Testing)

集成测试一般在单元测试之后,所以单元测试是集成测试的基础,没有进行单元测试的集成测试是不靠谱的。所以最简单的形式是:'把两个已经测试过的单元组合成一个组件,测试它们之间的接口'。也就是说集成测试在单元测试的基础之上,将单元测试中独立的单元合并起来,验证它们的协调性, 合并后的组件又是一个新的‘单元’,这样逐步合并测试,最终形成完整的应用程序。


26) 负载测试(Load Testing)

负载测试有助于查找特定负载下系统的最大容量以及导致软件性能下降的任何原因。可以使用JMeter,LoadRunner,WebLoad,Silk执行程序等工具执行负载测试。

性能测试. 主要位于a-b之间. 在系统设计初期就会规划一个预期目标, 比如给定资源Ax,a点就是性能期望值。也就是说在给定固定资源Ax的情况下,如果TPS可以达到a点甚至更高,就说明系统性能达到或者好于预期. 通过性能测试可以验证系统的处理能力有没有达到预期

压力测试. 位于c-d之间。在超过安全负载的情况下,继续对系统增加压力,直到达到崩溃点, 即上图的d. 通过压力测试可以得出系统的最大承受能力

另外也推荐阅读<<大型网站技术架构>>这本书

猴子测试是由测试人员进行的,即把自己当成猴子,在没有任何知识背景或者理解应用前提下,随意输入和操作。


28) 变异测试(Mutation Testing)

通常单元测试的思路是通过测试用例来验证代码是否有效可靠,而变异测试是反过来. 它首先更改其中一个程序的源代码,再跑单元测试,如果单元测试通过则可能说明测试用例没有效果,或者测试用例没有覆盖到这处代码变异.


29) 悲观测试(Negative Testing)


30) 非功能测试(Non-Functional Testing)

非功能性测试涉及测试非功能性需求,如负载测试、压力测试、安全性、容量,恢复测试等等. NFT测试的目标是确保软件或应用程序的响应时间是否满足业务需求。


31) 性能测试(Performance Testing)

性能测试这个范围比较大,广义上的性能测试包括了上文提到的负载测试、压力测试、稳定性测试、容量测试等等。狭义的性能测试则是指在特定资源条件下,测试系统能否达到期望值, 也就是基线测试(baseline Test).

基线测试(baseline Test): 在给定的资源下,测试最佳的性能,用作后续测量的参考‘基线’。注意基线测试和基准测试是有区别的, 这么理解,基准是你想达到的,比如100短跑世界纪录,基线是你的成绩。

稳定性测试(Endurance Test): 在指定负载下,长时间测量系统的稳定性


32) 恢复测试(Recovery Testing)

比如应用通过网络电缆接收数据,突然断开了网络电缆的连接, 过一段时间,再插上网线, 系统应该开始恢复由于网络电缆拔出而丢失连接的数据

在修改任意模块或者功能后,将应用作为一个整体进行测试,称为回归测试。回归测试的目的就是验证在软件原有的功能变动后是否保持完整性.

因为在回归测试中很难覆盖所有系统,通常最好使用自动化测试工具进行这些类测试。比如每次修改完代码,跑单元测试来确保不影响确保其他软件单元。

在基于风险的测试中,功能或需求将根据其优先级进行测试。基于风险的测试会优先测试高度关键的功能,因为这些功能对业务影响最大或者故障概率非常高. 而优先级由业务需求决定,因此一旦为所有功能设置了优先级,则应该首先执行高优先级功能或测试用例,然后再执行低优先级功能。 低优先级功能可以在时间充裕时测试,或者不测试。


35) 完整性测试(Sanity Testing)

在软件设计阶段,测试团队就会为编写冒烟测试用例;

将版本提交给测试团队后,测试团队就会先跑一下完整性测试,检查一下有没有重大的,影响测试进程的bug,如果有则退回开发

顺利通过完整性测试和冒烟测试之后才会进入正式测试阶段。


36) 安全测试(Security Testing)

安全测试旨在确保应用或网站免受内部和外部威胁的侵害。这个测试包括预防恶意程序、病毒; 检验授权和身份验证过程的安全性。


37) 冒烟测试(Smoke Testing)

如何通俗地理解冒烟测试呢?这个属于来源于硬件行业,对一个硬件或硬件组件进行更改或修复后,直接给设备加电。如果没有冒烟,则该组件就通过了测试。举个例子,给三星Note7加电,如果没爆炸,就说明通过了‘冒烟测试’(感觉当手机测试者不容易,容易有生命危险)?

冒烟测试一般在回归测试或其他详细测试之前进行

静态测试有点类似于代码Review,在不执行任何代码的情况下执行(也就是不运行应用),它涉及对可交付成果审查(inspection)、review和演练(walkthrough). 比如检查代码语法、命名约定、项目组织。

举前端的例子,静态测试可能包括:

代码Review。有一些问题是无法通过Lint工具覆盖的,比如代码逻辑、异常捕获、项目组织、内存泄露等等,这些需要人工进行走查Review


39) 压力测试(Stress Testing)


40) 系统测试(System Testing)

系统测试其实不是一个具体的测试技术,而是一个测试阶段。 这个阶段会进行很多种测试,一般公司的测试团队的工作就集中在这一块。 一般包含:

各种非功能测试:例如恢复测试、性能测试、压力测试、安全测试等等。

确保应用作为一个整体可以良好地运行.

确保应用在真实的环境可以良好地运行。比如进行一些非功能测试,验证系统的健壮性

测试独立的软件单元或模块称为单元测试。它通常由开发者完成,而不是由测试人员完成,因为它需要详细了解内部程序设计和代码。

这是一种白盒测试,所以要求由开发者自己进行,因为只有开发者才知道单元的内部实现。单元测试一般会使用测试覆盖率来验证单元测试的完成度.

可用性测试用于检测应用的用户友好程度(User-friendliness). 它会验证新用户受可以轻松理解应用流程,如果用户陷入麻烦,测试人员要记录好并提供帮助。可以认为可用性测试是在检查系统的导航性(navigation)

漏洞测试,涉及识别软件、硬件和网络中的漏洞。如果漏洞容易受到攻击,或者容易受到病毒和蠕虫感染,黑客或恶意程序就可以控制系统。


44) 容量测试(Volume Testing)


45) 白盒测试(White Box Testing)

逻辑路径包括语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖等等.

总结

关于软件测试还有其他疑问,或是想要免费领取测试学习资料、工具、面试宝典、面试技巧等资料,都可私信留言。

关注软件测试郑老师,你将学到更多专业技术、软件测试干货和更多职场技能。


顶一下()     踩一下()

热门推荐

发表评论
0评