持续集成一直同自动化测试相关联。这在马丁福勒的文章或更早期Steven McConnell对日构建和冒烟测试的相关实践描述中都有提及。而且在企业持续集成的领域中，我们会考虑很多种类型的自动化测试和手工测试。尽管如些，很多团队在测试方面还是比较弱。很常见的一个版本发布场景就是：某个团队完成一个版本后，手工测试一下基本功能就发布了。而其中的某一部分总是出错，而新功能也只做了少量测试。如果团队在测试方面比较成熟的话，他们能很快发现问题或缺陷，从而在生产率和信心方面都会有所增加。
目前，大多数团队或多或少都会有某种形式的自动化测试。比如一小撮单元测试套件或一些脚本化的测试，用于确保软件的基本功能是可以工作的。这些基本的自动化回归测试能够较早及比较容易地发现那些基本功能性问题。入门级的团队 通常刚刚开始习惯于做这种自动化测试。
为了达到新手级成熟度，应该有一套快速测试在每次构建时都运行。这些测试给团队增加了信心：软件基本上在任何时间都能工作。测试一旦失败，开发团队会得到即时通知，从而在他们忘记这个问题的上下文之前就有机会去修复这些失败的测试。因此，对于这一级别来说，对测试失败通知的响应是非常重要的：如果一个团队测试失败却不响应的话，那它应该低于测试成熟度的入门级。
中级成熟度的团队会在这些同快速构建同时执行的测试的基础之上，扩大测试范围。企业持续集成的成熟测试是以多种多样的测试集合为特性的。一个中级团队不仅有快速测试和手工测试，而且还有自动化的功能测试。中级团队常常让持续集成系统同时运行一些静态源代码分析。静态分析可能不是每次都运行，但一定会周期性运行。而且一旦产生了某种严重的静态质量问题的话，一定修复之后才能发布。
进阶级成熟度是以“完整测试”为标志的。每种测试都提供其所能提供的最大价值。单元测试覆盖了系统中所有复杂代码与逻辑。功能测试覆盖了系统中所有的重要功能。也会有边界测试和随机测试。同时，还要频繁运行静态代码分析，并补充以工具支持的运行时分析和安全扫描来发现那些可能因测试不足或无法测试而遗漏的问题。测试可能被分配在多种系统下运行，以使能并行执行，从而提供快速的反馈。达到进阶级需要相当大的投入，然而对于那些缺陷的成本很高且需要能够保持高速前进的团队来说，对是非常重要的。假如没有这类需求的话，一般来说，中级可能是一个更适当的目标。
在极端的情况下（也就是疯狂级成熟度），某些团队追求100％的测试覆盖率。尽管100%测试覆盖率的定义在变化，但它反映出至少每行代码都被测试覆盖到。在某些软件中，存在一个收益递减的点，在这一点上，对某行代码的自动化测试的价值要小对写测试的成本。追求100%的测试覆盖率意味着团队会做一些浪费的测试，然而其目的有可能是阻止因某些测试很有价值但很难写而不写测试找藉口。满足并保持100%的测试覆盖率可能也是一个自豪感与动力的源泉。对于进阶级团队来说，如果曾经发现的确错过了一些非常重要的测试的话，要求100%的测试覆盖也未尚不可。但对于大多数团队来说，简直可以说是变态啦。
