Link http://www.ltesting.net/ceshi/ceshijishu/csyl/2012/1126/205743.html

　　前言：

　　之前刚从华为出来写的一篇文章，拿出来和大家分享下，可能被测对象不同，所面临的问题也会不同，通讯行业，测试周期长，往往一个版本测试一两个月很正常，版本质量要求非常高，测试结束准则也非常严格，每轮测试必须统计 bug 数、以及 bug 收敛趋势;而在互联网行业，测试周期很短，因为互联网行业发展飞速，如果一个需求从开始设计到最终上线发布很长的话，就会处于被动失利的地位。所以在互联网行业测试分析设计体系还不是显现的那么明显，可能这个也做了，但是用的时间不会太多。以下文章可以参考下。

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

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

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

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

Link http://www.ltesting.net/ceshi/ceshijishu/csyl/2012/1126/205743.html