说起来人生第一家互联网公司，教会了我蛮多的东西，虽然比较杂。如运维、测试、实施、开发等。基本上那个时候，哪里有需要，哪里就有我。
之前曾写过这么一篇文章论单元测试之重要性
这篇文章的背景是我处于创业公司的时期，那个时候做的比较杂，由于前后端一起做，功能越来越多，bug也就越来越多。最后发现因为赶着发布周期，不得不快，快的我们连单元测试以及自测都懒得弄。最后发布前，经理测试了一下，发现了一堆bug。于是我们周末加班改bug。
持续了一段时间后，觉得老这样也不行，于是就开始写单元测试。还别说，因为写了单元测试后，bug率果然下降很多，bug率下降很多后，虽然也有一些bug，但并不是很重要，可以慢慢改。总而言之，我们不用周末来加班了，可以有一个美好的双休。
之前我的领导是R哥，后来变成了D姐。D姐教我如何写测试用例。
根据测试用例，然后界面上进行操作，这样的测试通常叫功能性测试。
测试有很多种，功能测试是测试人员最基本的，也是最基础的。
测试分类如下:
黑盒测试——不是基于内部代码和设计的知识，而是基于需求和功能。
白盒测试——基于应用程序的内部逻辑的知识，通过语句，分支，路径和条件的覆盖率。
单元测试——测试中的最小单位，测试特殊的功能或代码模块。由于需要对内部代码和设计的详细知识，该测试一般由开发者完成而不是由测试人员完成。该测试的容易程度同代码设计的好坏直接相关。
增量型的集成测试——随着新功能的增加，不断的对应用程序进行测试。在程序的所有部分完成之前，需要一个应用程序的各个部分之间能够相对独立的进行工作。这类型测试可以有开发者或测试者完成
集成测试——测试应用程序结合的部分来确定它们的功能结合到一起是正确的。在这里‘部分’的概念可能是代码模块，独立的应用程序，在网络上的客户端和服务器断程序等等。这类型测试典型的是于客户/服务器和分布式系统相关。
功能测试——是一种黑盒测试，同应用程序的功能需求紧密相关。这类型测试应当有测试人员来完成。这并不意味着开发人员在发布版本之前就不需要检查他们的代码。
端到端测试——同系统测试类似，包括模拟现实世界对一个完整的应用环境进行测试。例如同数据库进行交互、使用网络通信，或者其他的软件、硬件和系统进行交互。
理智测试——这是一种典型的原始测试，其目的是要确定一个新的软件版本在一些主要的测试努力下表现的足够好并且可以接受。例如：如果一个新软件每五分钟宕机一次，使系统执行速度极其缓慢，或者破坏系统数据，那么该软件就处于不够‘理智’状态，必须保证在当前状态下进行进一步测试。
回归测试——在软件或环境被修改后进行的再测试。可能很难确定我们需要进行多少的再测试，尤其接近到开发过程的末期。自动测试工具可能会有很大的帮助。
可接受性测试——基于最终用户的规格进行的最后测试。或者基于最终用户在一定的时间范围内的测试。
负荷测试——在高负荷条件下进行的测试。
压力测试——该术语通常同负荷测试和性能测试是可交换的。也可用于描述这样一些测试如：在不正常的负荷状态下，过分的重复某些动作或输入情况下进行的系统功能测试。
性能测试——该术语通常同负荷测试和压力测试是可交换的。理想的性能测试是定义在需求文档或QA测试计划中的。
安装和反安装测试——测试完全、部分或升级的安装/反安装过程。
恢复测试——测试当出现崩溃，硬件错误或其他灾难性问题时，系统的表现情况。
安全性测试——测试系统对于内部和外部非法入侵、故意损坏时的表现情况。可能需要复杂的测试技术。
兼容性测试——测试系统在不同的平台/硬件/操作系统/网络上的表现情况。
ALPHA测试——在开发进行结束的时候进行的测试。针对测试的结果可能还会进行一些小的设计更改。这类测试典型的是由用户进行的，而不是由开发者或测试人员进行的。