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

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

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

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

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