作为一名软件开发人员，除了写代码以外，还必须保证所交付的代码质量，保证代码质量的其中一种办法就是编写单元测试（unit test）。所谓单元测试，顾名思义，单元就是整体的一部分，这里的整体就是整个项目的软件代码，其中的单元自然可以是一个模块或者是一个类等。

单元测试是软件工程师必备的技能之一。但现实中很多软件工程师，经常借口工期时间短、维护成本高等原因忽略单元测试代码。在我看来编写单元测试是一个软件项目的重要组成部分。好的单元测试不但可以节约项目时间而且可以很好的保证软件交付质量。

由于一个软件经常会依赖于底层数据库或公司内的其他服务，又或是公司外部的第三方服务，这会给编写单元测试带来较大的挑战。常规的做法是采用打桩（stub）或者模拟（mock）来应对。打桩和模拟都有对应的工具来支持测试代码实现。

单元测试是针对类、组件、模块的应用各组成部分进行的独立测试。对单个组件的测试，也叫组件测试，典型的组件就是UI组件。对单个模块的测试也叫模块测试。模块与模块间的连接关系一般是通过接口来实现的，所以模块测试一般是针对模块的开放接口进行测试。为了对单个应用的组成部分或整体进行问题验证，就需要进行集成测试（integration test）。所谓的集成是指不同组件或模块的组合，或不同层级间的组合，比如数据访问层和服务层的结合测试，视图层、控制层及服务层的集成测试等。

通常一个一个完整的系统是由多个应用组成的，应用是一个系统的组成部分。应用之间会有一定的依赖关系，比如 A服务会调用B服务的某些接口。经典的场景是移动端APP会利用服务端的API实现相关业务功能，在这种应用场景下，移动APP是客户端，提供API的应用是服务端，客户端和服务端是一个系统的两端，像这种不同端之间集成起来进行的测试叫端到端测试（E2E test）。

对于一个应用或系统来说，既有业务功能相关的部分也有非业务功能的组成部分。针对业务功能的测试叫做功能测试，相对的，针对非功能性的测试，如针对性能的测试叫做性能测试，针对安全的测试叫做安全测试。功能测试、性能测试、安全测试是非功能测试的三个重要方面。功能测试主要是用来验证业务逻辑是否能够正常工作、是否有异常，性能测试主要用来验证系统的稳定性和可靠性，安全测试主要用来保障系统免受黑客攻击或隐私数据泄露等。功能测试往往是以人工的方式进行验证，当然也可以借助一些工具模拟人工测试，性能测试和安全测试一般会借助一定的工具。

除了以上的测试技术外，从测试的方式方法和深度方面又分为黑盒测试和白盒测试。顾名思义，一个应用或系统就像一个被层层包装起来的盒子一样，黑盒测试是隐藏应用代码的实现细节，针对应用的外部表现进行的测试。而白盒测试需要关注代码的实现细节。

除了黑盒测试和白盒测试是针对深度方面来进行的测试外，针对宽度方面也有相关的测试。通常宽度测试方面主要是关注测试涉及的运行过的代码覆盖度，针对代码覆盖度的测试叫做覆盖测试（cover test）。一般的认为测试覆盖率越高越能保证代码的质量。

一个软件产品的研发往往是长生命周期的，需要不断迭代。当前比较流行的项目迭代方式是敏捷项目开发，敏捷项目开发常常以一个sprint作为迭代周期。在每个迭代周期内，都需要对研发的功能及相关的依赖影响部分进行重复测试，常常把这种需要进行重复验证的测试叫做回归测试。

一个应用或系统完成研发并发布上线后，仍然需要测试人员介入，验证是否能正常工作。但一来是由于在生产环境，二来是由于时间限制，通常不会像在研发期间那样进行大规模细粒度的测试。一般是会针对主要的功能和流程进行验证即可。由于这种测试时间比较短，大概在抽一支烟的时间范围内即可完成，所以把这种测试叫做冒烟测试。

对于一个既有的线上应用或系统，当新的功能完成研发后，再次上线往往是会带有一定风险的。一方面从产品角度来讲，不一定能够迎合用户的需求，另一方面从系统的稳定性方面来讲，为了减小新上线功能带来新的问题和影响。经常在应用发布时只开放给一部分特定用户，类似这样的发布往往叫做灰度发布。灰度发布期间相当于是一个阶段的线上测试，这种测试往往也叫灰度测试。如果是针对不同的用户群体，开放了不同的功能，这种测试往往叫做A/B测试。

以上所有测试一般都会针对应用的场景和用例，不管是哪种类型的测试，测试场景和测试用例（test case）很重要。