导言

当下，各种新的技术层出不群，测试方法也在发生着很大的变化。过去对测试的划分可能已经有些不合适，例如单元测试、集成测试、发布测试从流程维度进行了划分，但逐渐让测试人员迷失在具体的测试技术中，而逐渐忽略了为什么做？如何做？

分类

分类概念

我更愿意从目标维度上进行顶层划分，分为两类测试：需求满足性测试与健壮性测试。在没有具体按这个分类时，很多人也是按这个来思考的，但对它明确提出概念后会有很多不同，会衍生出很多新工具的需求。名字可以带来额外的能力。

分类带来的认知提升

例如，从单元测试工具来说，国内研发的几个单元测试工具基本都具有手动测试用例设计与自动测试用例生成的功能，但工具厂商却不能有充分的概念来说明为什么需要一个用例自动生成的功能，仅仅是用户为了偷懒想要更高的结构覆盖率。
按新的分来来解释，单元测试工具可以支持两类测试，需求满足性测试与健壮性测试。在两类不同测试下，操作与交互都会有很大区别。在需求满足性测试中，输入主要是被测代码与低级需求，输出是用例、用例执行结果、需求与用例的追踪关系。而健壮性测试中，不需要关注低级需求，只关注与被测源码结构，产生更多的边界数据，触发出代码异常。针对单元测试中的健壮性测试来说，输入是被测代码，输出是用例数据与对应的异常描述以及代码结构覆盖率。从输入、输出来看，这两个测试被集成在一个工具中其实并不是那么恰当，因为几乎只有输入中的被测代码是共同的，其他几乎都不同。
在几乎每一个过程中，都伴随着需求满足性测试与健壮性测试。例如针对一个需求分析文档来说，如果执行文档测试，确保文档质量，那么也可以按需求满足性测试与健壮性测试进行划分。需求满足性测试将主要验证需求是否充分描述了客户的需求，而健壮性测试则验证该文档针对不同人员，是否可以达到可理解、易理解以及理解是否一致。从这些维度划分以后，会对文档测试提出很多相关规范，格式、章节组织等。
以上例子可能都是描述了某个阶段的测试，那么针对某个技术来说，这种划分是否有意义。自动化测试技术是当前比较流行的测试概念，如果分为需求满足性测试与健壮性测试，会发生什么？会演化出两个不同的技术体系，一个用于将手动执行的用例自动化，一个用于自动化探索新用例，这两者的实现方式、交互方式都几乎会完全不同。

技术储备

不同的测试分类下，技术储备是完全不同的。需求满足性测试，更加强调的是项目管理整体流程的规范化，数据的可追踪性。健壮性测试分类下，更偏重于智能技术分析，基于源码、环境理解，自主对被测程序进行理解，分析被测程序中的不足。当未来某一天，可以通过形式化方法充分描述需求，那么需求满足性测试与健壮性测试将不再进行区分，并且是健壮性测试包含满足性测试。

对测试人员发展的启示

现在市场中还存在大量的功能测试工程师岗位，从分类上来说，这一类工程师主要服务于需求满足性测试。对于这一类测试工程师，按需求满足性测试未来应该具备两个技能，系统规范与自动化测试。系统规范指针对某个标准的理解与应用，例如CMMI标准。需求满足性测试将是在某个标准规范下，实施自动化测试的过程。对于健壮性测试来说，要求非常高的理论与研发技能，属于开发领域的主要工作，对于测试人员来说，需要具备多平台系统的运维能力，未来能够将不同智能分析系统部署到不同的系统下，并进行集成。
真心希望，本文能够为测试人员的未来规划提供一些帮助。