我们常常听说的一些测试专业术语,比如白盒,黑盒,单元测试,笔者在前几年对测试也仅仅停留在这个两个词汇上,更多的就不得而知了。后来在一家做跨境电商的公司学到了一些新术语,也见到了测试岗位的一些日常,比如冒烟测试,测试用例(TC),回归测试,接口测试以及偶尔和我吵架等等。
白盒黑盒测试是按测试设计方法分类的,是指软件测试设计的方法,而不是软件测试的方法,注意这个区别。
黑盒测试是行为测试,即从软件的行为而不是内部结构触发来设计测试,也就是在软件上到处点点等。白盒指的是在设计测试的过程中,设计者可以“看”到软件系统的内部结构,并使用软件的内部结构和知识来选择测试数据及具体的测试方法。
<人力资源/>
按测试的目,分为功能测试和非功能测试,单元测试是功能测试里的一种,每种测试的名称和内容如下:
一个软件除了基本功能之外,还有很多功能之外的特性,这些叫非功能需求,或者服务质量需求。然而,若没有软件的基本功能,这些特性都将无从表现出来,因此,我们要在软件开发的适当阶段,基本功能完成后再来做这些非功能测试,非功能测试有如下这些
其他分类下的测试
<人力资源/>
在开发软件的过程中,不少测试起着“烽火台”的作用,它们告诉我们软件开发的流程是否顺畅,比如冒烟测试是指测试不通过不能进行下一步工作,是一种基本验证测试,据说是从硬件设计行业流传过来的说法。当年设计电路板的时候,很多情况下,新的电路板一插上电源就冒起白烟,烧坏了。如果插上电源后没有冒的烟,那就是通过了“冒的烟测试”,可以进一步测试电路板的功能了。还有验证构建是否通过基本测试以及全面考核某方面的功能的验收测试。
另一些测试名称则是说明不同的测试方法
单元测试
<人力资源/>
对于开发来讲,最最常用和熟悉的还是单元测试,怎样才算一个好的单元测试?单元测试应该准确,快速地保证程序基本模块的正确性。下面是验证单元测试好坏的一系列标准:
单元测试应该在最基本的功能/参数上验证程序的正确性。
单元测试必须由最熟悉代码的人(程序的作者)来写。
单元测试过后,机器状态保持不变。如果单元测试创建了临时的文件或目录,应该在拆卸(拆卸)阶段删掉。如果单元测试在数据库中创建或修改了记录,那么也许要删除或恢复这些记录,或者每一个单元测试使用一个新的数据库,这样可以保证单元测试不受以前单元测试实例的干扰。
然并卵!都说国内很多程序员是不写单元测试的,甚至从来都不写,笔者当年做Java的时候也没写过几次(捂脸)。
回归测试
<人力资源/>在单元测试的基础上,我们就能够建立关于这一模块的回归测试(回归测试).Regress:回到糟糕或欠发达国家,是倒退,退化,退步的意思。在软件项目中,如果一个模块或功能以前是正常工作的,但是在一个新的构建中出了问题,那么这个模块就出现了一个“退”步(回归),从正常工作的状态退化到不正常工作的状态。在一个模块的功能逐步完成的同时,与此功能有关的测试用例也同样在完善中。一旦有关的测试用例通过,我们就得到了此模块的功能基准线(基线),一个模块的所有单元测试就是这个模块最初的基线。
