【IT168 技术文章】 

     测试分析设计体系，一个最主要的目的就是使测试工作前移，加强测试需求分析阶段的活动，在软件分析设计阶段就介入测试，使得一些设计方面的缺陷和不足被早期的发现。降低了项目的成本。

    大家都知道，测试成本随着产品逐步交付而放大，假如需求分析、设计阶段的一些问题没有被发现，等到编码阶段完成提交测试后才发现了一些问题，而这些问题只能通过更改设计来修复的话，那么不论是测试还是开发的成本就被无形中放大了好几倍，项目的如期交付的风险会很大。就拿我的经历来说，以前的公司规模比较小，多数情况下测试工作都是在编码阶段结束或者马上结束才介入的，存在前期投入不足的问题，没有足够的人力和时间做测试需求分析，有时候在测试什么都不是十分清楚的情况下才开展测试设计工作，对被测试对象都不是十分清楚的情况下就着手测试的，在测试的过程中才慢慢的了解了被测系统，导致发现的bug数不是一个正常的曲线（刚开始bug数很多，几个版本后，bug数趋于收敛的趋势，到最后bug数很少，没有严重、致命的bug），而是刚开始很少，到后期越来越多的趋势，而且很多隐藏比较深的bug也是在软件快要交付的时候才被发现，甚至在网上暴露（发布后），这样的情况下，往往在规定的时间测试无法正常结束，项目也就不能按时交付。那么不论是开发还是测试的成本都很高。

    测试分析设计体系强调的就是测试需求分析阶段活动，这个阶段要求有足够的资源保证完成测试需求分析相关任务，也就是资源保证，一方面要求有经验的人员投入，一方面要有资料的资源，这个阶段投入的是测试部们里面的有经验的专家或者骨干，或者是系统组成员，通过系统组成员的经验，充分和开发人员、设计人员进行交流，运用一些工程方法，输出我们测试需要的的测试内容，同时在测试需求分析过程中，会发现需求或者设计规格错误或者不合理的或有遗漏的地方，应及时提出问题，督促开发人员、设计人员进行修改，避免这些问题遗漏到代码中，在测试执行阶段才发现。另外，要求测试部成员投入的一个原因是在设计需求、设计规格或者客户需求不明确的情况下，通过测试需求分析相关的活动，尽可能获取完整的信息，现实中，经常遇到这种情况，如果直接进行用例设计，测试完备性无法保证，此时更要加强测试需求分析阶段工作，只有弄懂测试的原始需求才能开展测试设计工作，清楚我们所要测试的系统是在什么环境、场景下运行的，测试设计中就能更逼真的模拟被测对象实际运行的场景，构造一些测试场景，使得测试做的更加充分，如何获取这些需求也是测试的核心能力之一。

    一句话：整个的测试分析阶段是为后续的测试用例设计做准备的。前期准备工作不充分，后期的工作也就无法保证。