最近在和学生讲测试用例的编写，在讲测试用例编写之前重点讲了测试需求的分解，可能大家刚接触测试，没有认识到测试需求的重要性，所以想写点东西说明一下，刘Sir我会从下面几点谈谈我的看法。
一、会分解测试需求就会测试
我经常告诉学生，会分解测试需求就会写测试。
首先，我们先复习一下软件测试的概念，IEEE软件工程标准术语：使用人工或自动手段，来运行或测试某个系统的过程。其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
其次，我们分析一下我们测试过程：用户需求à需求规格说明书的需求à分解后的测试需求à测试用例à执行用例发现bugà测试结束之后的测试评估。
结合这二条来看，我们遇到了3个需求的概念：用户需求、开发需求或项目需求、测试需求。其实测试概念中提到的“规定的需求”，说大一点是用户需求、说细一点就是测试需求，分解测试需求就是将项目需求逐步细化的过程， 从概念细化到可操作的点。所以分解测试需求是测试的第一步，会分解，分解的越细、越到位，对后面的测试越有利。会分解测试需求就会测试。
二、从分解测试需求开始熟悉项目
测试人员在需求阶段，要了解需求、对需求进行分解，得出测试需求，编写测试计划/测试方案。我们经常说对项目越熟悉，对业务越熟悉，对我们测试越有利。那我们怎么样熟悉项目，从分解测试需求开始。
但有学生经常问我，项目没有《需求规格说明书》怎么办，不知道怎么样开展测试工作。其实是可以的，你可以了解市面上同一类型产品的需求、可以问用户、可以参加开发的讨论会、评审大会等，先列功能大纲、再逐个模块、逐个功能点分析出测试需求。不过你真的做能到这一步，你会比需求人员做的更细，恭喜你，你有成了行业专家的潜质。
三、分解测试需求可以发现需求分析、项目设计方面考虑不足（重点啊）
其实这句话才是重点啊，根据瀑布模型大家都知道，测试成本随着产品逐步交付而放大，假如需求分析、设计阶段的一些问题没有被发现，等到编码阶段完成提交测试后才发现了一些问题，而这些问题只能通过更改设计来修复的话，那么不论是测试还是开发的成本就被无形中放大了好几倍，项目的如期交付的风险会很大。
再根据二八原理，80%的缺陷，在分解测试需求阶段就可以找出来。
四、请大家加大对测试需求分析的投入
整个的测试分析阶段是为后续的测试用例设计做准备的。前期准备工作不充分，后期的工作也就无法保证。引用《易经》中的元亨利贞的思想，分解测试需求就是测试的“元”，请大家一定要重视测试需求的分解，加大投入。
获取测试需求也是测试的核心能力之一，请大家引起重视。