Kun

Kun

IT学徒、技术民工、斜杠青年,机器人爱好者、摄影爱好 PS、PR、LR、达芬奇潜在学习者


共 212 篇文章


​ 把一些前后端概念性比较强的理念放在这里,本篇涉及测试

有多少软件测试类型呢?

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

每个测试类型都有自己的特点、优势和劣势。

下面是软件测试的通用类型列表

  • 功能测试类型:

    • 单元测试(Unit testing)
    • 集成测试(Integration testing)
    • 系统测试(System testing)
    • 健全性测试(Sanity testing)
    • 冒烟测试(Smoke testing)
    • 接口测试(Interface testing)
    • 回归测试(Regression testing)
    • Beta/验收测试(Beta/Acceptance testing)
  • 非功能测试类型:

    • 性能测试(Performance Testing)
    • 负载测试(Load testing)
    • 压力测试(Stress testing)
    • 容量测试(Volume testing)
    • 安全测试(Security testing)
    • 兼容性测试(Compatibility testing)
    • 安装测试(Install testing)
    • 恢复测试(Recovery testing)
    • 可靠性测试(Reliability testing)
    • 可用性测试(Usability testing)
    • 一致性测试(Compliance testing)
    • 本地化测试(Localization testing)

https://bobi.ink/2019/07/10/typeof-testing/

A/B测试

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

Alpha测试

Alpha测试这是软件工程中很常见的测试类型。它的目标就是尽可能地在发布到市场或交付给用户之前找出所有的问题和缺陷

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

一般大型的软件项目都有规范化的软件版本周期:

  • Pre-alpha: 有时候软件会在Alpha或Beta版本前先发布Pre-alpha版本, 相比Alpha和Beta,这是一个功能不完整的版本
  • Alpha: Alpha版本功能还没完善,需要进一步测试。Alpha版本通常会发送到开发软件的组织或某群体中的软件测试者进行内部测试。
  • Beta: 一般Beta版本会包含所有功能,但可能又有一些Bug,需要调试反馈。 Beta版本是软件最早对外公开的软件版本,由公众(通常为公司外的第三方开发者和业余玩家)参与测试。
  • Release Candidate(rc): 发布候选版本,如果没有出现问题则可发布成为正式的版本。这个版本包含完整且比较稳定的功能

验收测试

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

这是测试的最后阶段,在验收测试之后,软件将投入生产环境. 所以它也叫用户验收测试(UAT)

举个例子,验收测试就相当于收快递, 包裹是软件、你就是客户,是验收方,如果货物不符合你的要求,是要退货的。

临时测试

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

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

可访问性测试

可访问性测试的目的是确定软件或应用程序是否可供残疾人使用。残疾是指聋人,色盲,智障人士,失明者,老年人和其他残疾人群体。这里会执行各种检查,例如针对视觉残疾的字体大小测试,针对色盲的颜色和对比度测试等等。

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

Beta测试

上文Alpha测试已经提及Beta测试, Beta测试是一种正式的软件测试类型,在将产品发布到市场或者实际最终用户之前,由客户在真实的应用环境中执行

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

通常,此类测试由最终用户或其他人完成。这是在将应用发布作为商业用途之前完成的最终测试。通常,发布的软件或产品的Beta版本仅限于特定区域中的特定数量的用户。 所以最终用户实际使用软件后会将一些问题反馈给公司。公司可以在全面发布之前采取必要的措施。

Beta测试在正式版本之前也可能会迭代进行多次.

后端测试

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

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

浏览器兼容测试

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

浏览器兼容测试是前端开发者绕不开的坑。

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

为了抚平浏览器之间的差异,我们会使用各种特性检测工具(Modernizr), 还有各种polyfill(CSS Normaliz, polyfill/shim, css-autoprefixer);

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

如果你觉得我的文章对你有帮助的话,希望可以推荐和交流一下。欢迎關注和 Star 本博客或者关注我的 Github