程序员,软件测试知多少?

图片描述

送给初级程序员的测试认知文程序员

做为开发同窗,一些基本的测试岗位相关知识仍是颇有必要了解一下,免的某些同窗在工做中和测试同窗斗嘴、打架、群殴等以及被测试鄙视....。数据库

咱们经常据说的一些测试专业术语,好比白盒、黑盒、单元测试,相信搞做为程序员的你脱口而出的就是这三个词汇吧,笔者在前几年对测试也仅仅停留在这个两个词汇上,更多的就不得而知了。后来在一家作跨境电商的公司学到了一些新术语,也见到了测试岗位的一些平常,好比冒烟测试、测试用例(TC)、回归测试、接口测试以及偶尔和我吵架等等。微信

白盒黑盒测试是按测试设计方法分类的,是指软件测试设计的方法,而不是软件测试的方法,注意这个区别。框架

黑盒测试是行为测试,即从软件的行为而不是内部结构触发来设计测试,也就是在软件上处处点点等。白盒指的是在设计测试的过程当中,设计者能够“看到”软件系统的内部结构,并使用软件的内部结构和知识来选择测试数据及具体的测试方法。less

功能测试和非功能测试

按测试的目,分为功能测试和非功能测试,单元测试是功能测试里的一种,每种测试的名称和内容以下:
图片描述单元测试

一个软件除了基本功能以外,还有不少功能以外的特性,这些叫非功能需求,或者服务质量需求。然而,若没有软件的基本功能,这些特性都将无从表现出来,所以,咱们要在软件开发的适当阶段——基本功能完成后再来作这些非功能测试,非功能测试有以下这些
图片描述测试

其余分类下的测试

在开发软件的过程当中,很多测试起着“烽火台”的做用,它们告诉咱们软件开发的流程是否顺畅,好比冒烟测试是指测试不经过不能进行下一步工做,是一种基本验证测试,听说是从硬件设计行业流传过来的说法。当年设计电路板的时候,不少状况下,新的电路板一插上电源就冒起白烟,烧坏了。若是插上电源后没有冒烟,那就是经过了“冒烟测试”,能够进一步测试电路板的功能了。还有验证构建是否经过基本测试以及全面考核某方面的功能的验收测试。spa

另外一些测试名称则是说明不一样的测试方法
图片描述设计

单元测试

对于开发来说,最最经常使用和熟悉的仍是单元测试,怎样才算一个好的单元测试?单元测试应该准确、快速地保证程序基本模块的正确性。下面是验证单元测试好坏的一系列标准:3d

  • 单元测试应该在最基本的功能/参数上验证程序的正确性。

  • 单元测试必须由最熟悉代码的人(程序的做者)来写。

  • 单元测试事后,机器状态保持不变。若是单元测试建立了临时的文件或目录,应该在Teardown(拆卸)阶段删掉。若是单元测试在数据库中建立或修改了记录,那么也许要删除或恢复这些记录,或者每个单元测试使用一个新的数据库,这样能够保证单元测试不受之前单元测试实例的干扰。

  • 单元测试要快(一个测试的运行时间是几秒钟,而不是几分钟)。

  • 单元测试应该产生可重复、一致的结果。

  • 独立性—单元测试的运行/经过/失败不依赖于别的测试,能够人为构造数据,以保持单元测试的独立性。

  • 单元测试应该覆盖全部代码路径。

  • 单元测试应该集成到自动化测试的框架中。

  • 单元测试必须和产品代码一块儿保存和维护。

然并卵!都说国内不少程序员是不写单元测试的,甚至历来都不写,笔者当年作Java的时候也没写过几回(捂脸)。

回归测试

在单元测试的基础上,咱们就可以创建关于这一模块的回归测试(Regression Test)。Regress:return to a worse or less developed state,是倒退、退化、退步的意思。在软件项目中,若是一个模块或功能之前是正常工做的,可是在一个新的构建中出了问题,那么这个模块就出现了一个“退步”(Regression),从正常工做的状态退化到不正常工做的状态。在一个模块的功能逐步完成的同时,与此功能有关的测试用例也一样在完善中。一旦有关的测试用例经过,咱们就获得了此模块的功能基准线(Baseline),一个模块的全部单元测试就是这个模块最初的Baseline。

针对一个Bug Fix,咱们也要作Regression(海退) Test。目的是:

  1. 验证新的代码的却改正了缺陷。

  2. 同时要验证新的代码有没有破坏模块的现有功能,有没有Regression

对于“回归测试”中的“回归”,咱们能够将其理解为“回归到之前不正常的状态”。回归测试最好要自动化,由于这样就能够对于每个构建快速运行全部回归测试,以保证尽早发现问题。单元测试是回归测试的基础。在专一于模块基本功能的单元测试以外,还有功能测试——从用户的角度检查功能完成得怎么样。

探索性测试

探索性测试是为了某一个特定目的而进行的测试,且就这一次,之后通常也不会重复测试。在软件工程的实践中,“Ad hoc”大可能是指随机进行的、探索性的测试。

探索式测试的测试流程是不可重复的,由于它的测试都是“特定”测试,无法重复。这一缘由,使得探索式测试不能自动化,就这一点而言,还达不到CMMI二级——可重复级。

做为管理人员来讲,若是太多的小强是在探索式测试中找出来的,那咱们就要看看测试计划是否基于实际的场景,开发人员的代码逻辑是否完善,等等。

场景/集成/系统测试

在软件开发的必定阶段,咱们要对一个软件进行全面和系统的测试,以保证软件的各个模块都能共同工做,各方面均能知足用户的要求。这类测试叫系统/集成测试。这一方法的核心思想是:当用户使用一个软件时,他/她并不会独立使用各个模块,而是把软件做为一个总体来使用。咱们在作场景测试的时候,就须要考虑在现实环境中用户使用软件的流程是怎样的,而后模拟这个流程,看看软件能不能知足用户的需求。这样,才能使软件符合用户的实际需求。

应该何时作集成测试呢?是否是越早越好?原则上是当一个模块稳定的时候,就能够把它集成到系统中,和整个系统一块儿进行测试。在模块自己稳定以前就提前作集成测试,可能会报告出不少Bug,可是这些因为提前测试而发现的Bug,有点像汽车司机在等待绿灯时不耐烦而拼命地按喇叭——也就是说,有点像噪音。咱们仍是要等到适当的时机再开始进行集成测试。

了解完这些概念后,咱们来看看究竟一个测试工程师的职责是怎么样的呢,下面列举一些:

  • 制定测试计划

  • 设计与编写测试用例

  • 实施测试

  • BUG跟踪

  • 测试报告与总结

  • 其余测试工程活动

不少测试工做并非说,有了测试工程师,把测试相关的所有事情扔给他们就完事了,须要开发和测试配合,共同完成某些测试任务,软件测试也不只仅是为了发现bug而后提给开发,测试=质量保障,提高质量相关的都是测试工程师须要关注和负责的,软件测试的目标是帮助项目打造用户喜欢的产品。

文章首发于个人微信公众号,关注可得到每次最新推送
文章首发于个人微信公众号,关注可得到每次最新推送


《构建之法》读书笔记之二

相关文章
相关标签/搜索