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

作为开发同学，一些基本的测试岗位相关知识还是很有必要了解一下，免的某些同学在工作中和测试同学斗嘴、打架、群殴等以及被测试鄙视….。

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

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

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

功能测试和非功能测试

按测试的目，分为功能测试和非功能测试，单元测试是功能测试里的一种，每种测试的名称和内容如下：

一个软件除了基本功能之外，还有很多功能之外的特性，这些叫非功能需求，或者服务质量需求。然而，若没有软件的基本功能，这些特性都将无从表现出来，因此，我们要在软件开发的适当阶段——基本功能完成后再来做这些非功能测试，非功能测试有如下这些

其他分类下的测试

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

另一些测试名称则是说明不同的测试方法

单元测试

对于开发来讲，最最常用和熟悉的还是单元测试，怎样才算一个好的单元测试？单元测试应该准确、快速地保证程序基本模块的正确性。下面是验证单元测试好坏的一系列标准：

单元测试应该在最基本的功能/参数上验证程序的正确性。
单元测试必须由最熟悉代码的人（程序的作者）来写。
单元测试过后，机器状态保持不变。如果单元测试创建了临时的文件或目录，应该在Teardown(拆卸)阶段删掉。如果单元测试在数据库中创建或修改了记录，那么也许要删除或恢复这些记录，或者每一个单元测试使用一个新的数据库，这样可以保证单元测试不受以前单元测试实例的干扰。
单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）。
单元测试应该产生可重复、一致的结果。
独立性—单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。
单元测试应该覆盖所有代码路径。
单元测试应该集成到自动化测试的框架中。
单元测试必须和产品代码一起保存和维护。

然并卵！都说国内很多程序员是不写单元测试的，甚至从来都不写，笔者当年做Java的时候也没写过几次（捂脸）。

回归测试

在单元测试的基础上，我们就能够建立关于这一模块的回归测试（Regression Test）。Regress：return to a worse or less developed state，是倒退、退化、退步的意思。在软件项目中，如果一个模块或功能以前是正常工作的，但是在一个新的构建中出了问题，那么这个模块就出现了一个“退步”（Regression），从正常工作的状态退化到不正常工作的状态。在一个模块的功能逐步完成的同时，与此功能有关的测试用例也同样在完善中。一旦有关的测试用例通过，我们就得到了此模块的功能基准线（Baseline），一个模块的所有单元测试就是这个模块最初的Baseline。

针对一个Bug Fix，我们也要做Regression(海退) Test。目的是：

验证新的代码的却改正了缺陷。
同时要验证新的代码有没有破坏模块的现有功能，有没有Regression

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

探索性测试

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

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

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

场景/集成/系统测试

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

应该什么时候做集成测试呢？是不是越早越好？原则上是当一个模块稳定的时候，就可以把它集成到系统中，和整个系统一起进行测试。在模块本身稳定之前就提早做集成测试，可能会报告出很多Bug，但是这些由于提早测试而发现的Bug，有点像汽车司机在等待绿灯时不耐烦而拼命地按喇叭——也就是说，有点像噪音。我们还是要等到适当的时机再开始进行集成测试。

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

制定测试计划
设计与编写测试用例
实施测试
BUG跟踪
测试报告与总结
其他测试工程活动

很多测试工作并不是说，有了测试工程师，把测试相关的全部事情扔给他们就完事了，需要开发和测试配合，共同完成某些测试任务，软件测试也不仅仅是为了发现bug然后提给开发，测试=质量保障，提升质量相关的都是测试工程师需要关注和负责的，软件测试的目标是帮助项目打造用户喜欢的产品。

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