5. 具备了部分基础测试输出工件，如测试计划等。

　　6. 测试管理少量涉及，但控制手段不明显，无很好的风险规避手段。

　　7. 介入了基础的BUG管理机制，但是对BUG的控制手段软弱造成遗失。

　　8. 在整个软件开发过程中，测试已经成为一个概念重要，实施力度过于软弱的参与环节。

　　属于该阶段的，尚未分化的测试个体已经具备了少量的服务能力，测试和调试的分离意味着测试任务已经被单独剥离出来，交付给更具备专业能力的人处理。该阶段已经出现了对BUG进行管理的意识，这意味着很大程度上项目

　　组或者测试个体可以在一定程度上对已经发现的BUG作微弱的控制，所以在这个阶段不应该对软件构成的质量抱有多大的幻想，我们只要知道这只是一个简单的开始。

　　可持续集成阶段（Ⅲ级）

　　测试成熟度的可持续集成阶段主要表现为以下特征：

　　1. 测试集成到项目的各个迭代阶段中，已经不再体现为编码后测试。

　　2. 测试切入了需求阶段、设计阶段，并且针对这两个阶段产生了独立的正式技术复审手段。

　　3. 已经有专门的机构负责，相应的体系被建立，大部分测试角色职责定义清晰，投入资源相对稳定。

　　4. 对测试的各个阶段工件输出做出了限定，并且根据项目的历次迭代制订了测试发布后基线。

　　5. 测试管理中已经介入风险管理制度，具备一定的规避手段。

　　6. 使用了部分测试工具和启用了专门的BUG管理工具（仅限于收集管理）

　　7. 测试的领域大部分限定于黑盒阶段。

　　8. 有了正规技术培训的活动。

　　9. 考察和评审基础数据匮乏，无法实施测试度量。

　　该阶段正式分化了独立的测试个体或者测试团队，他们已经具备了一定的服务能力，大部分执行的测试项目都采用了迭代思想，并且在任何一次迭代的开始都会产出一份经过仔细确认的执行风险列表。测试已经不再表现为单纯的

　　编码测试方式，软件开发中包含的大部分核心过程都已经被监管（有限的），表现为不同的测试的执行方式。BUG有专门的管理工具收集，比如运用了某些商业数据库。初步产生了自动化测试概念，但是由于本身条件的制约，

　　导致测试个体或者测试团队不能更进一步的深入概念中，测试依然以黑盒测试为执行主体。