如果将整个测试体系看成一个国家的话，那么测试分析与设计的过程就是立法的过程，而最终产出的测试方案/点/用例就是一国之法律，每一个测试公民都应该在测试过程中按照这些法律来开展工作。既然是立法，那么就应该从立法动议开始考虑
一、分析测试需求
正如在立法的时候要向各人大机构收集立法建议一样，前期需要对于测试设计进行需求的收集和分析。测试需求的主要来自于开发设计类需求、用户应用类需求和测试经验类需求三方面。
开发设计类需求。
主要包括产品包需求、设计需求、设计规格、产品的软硬件架构等等。事实上，开发设计类需求仅仅是客户需求在开发层面上的一个映像，并非客户需求的本像，因此在收集到这些需求的同时，不仅要关心开发设计类需求文档本身，更应该关注其隐藏的客户实际需求，将其分析透彻，保证测试设计是贴近客户而不是贴近开发，体现端到端的测试设计理念。
比如用户需要做一个烟囱，但开发人员把图纸拿反了，设计成了挖口井。如果测试设计贴近开发的话，那是绝对发现不了这个巨大的错误；如果直接看到的是用户的需求，就能很容易就能找到这其中的阴差阳错。当然，这仅是一个例子，但是在现实中，开发出来的特性不能满足用户需求而被迫返工的事实是存在的，所以在建立测试之法的时候，我们必须要求收集到的动议是最原始需求的反映。
用户应用类需求
这主要包括一些重要的用户实际组网等等，这些都是直接来源于用户的内容，所以可以直接纳入到我们的测试设计中来。
经验类需求
在测试立法的过程中需要将以往的经验固化到文档上形成固定的典型组网、典型应用、典型场景等等。
值得注意的是，经验并不是因循守旧，而应该根据当前技术的发展推陈出新，不断更新再不断固化。比如，早期大家对于STP的理解还停留在STP/RSTP，当时的组网不能满足后续MSTP测试的需求，这就需要在原有组网的基础上设计出新的组网，形成新的经验。
对这三类测试需求分析清楚了，产品“需要测试什么”基本就非常清晰了。接下来，则要根据需求分析分门别类地进行详细设计，也就是要解决“如何测试”的问题，启动真正的设计立法工作。
二、设计测试方案/测试点/测试用例
经过前期的测试需求收集和分析，我们会根据测试对象和范围的不同，把测试设计工作分成三类：特性测试设计、组合测试设计、应用测试设计。特性测试设计主要是针对单个特性进行的设计；组合测试设计主要是将多个相关特性组合起来进行的设计；应用测试设计是根据用户应用而来的专项设计。需要指出的是，实际上组合测试设计和应用测试设计很类似，后者是针对特定用户环境的组合测试设计，也就是说应用测试设计是更加贴近用户实际应用的组合测试设计，无需根据自己的经验再去优化组网，最好按照某用户环境进行1：1的设计。
无论测试设计工作是哪一类，最终体现到实际操作中的内容就是测试方案、测试点、测试用例，即测试的规则。
测试方案
测试方案是对测试活动的总体分析和规划，除了要进行测试对象分析以外，每一个测试方案中都应该包括网络拓扑、网络配置、流量模型。
特性测试方案是最基础的一类，主要用于描述某个单一特性的测试方法和过程。由于特性测试方案主要用于产品功能尚未稳定的测试活动，覆盖产品开发早期阶段，那么势必、存在实际产品物料缺乏的问题，所以在设计特性测试方案时，一定要采用尽可能简单的网络拓扑，避免设计过于复杂；相应的，产品开发早期版本仍然处于功能验证阶段，所以特性测试方案的网络配置应该以被测特性为核心进行配置，避免过多过复杂组合；而流量模型应该采用轻载连续流量比较合适。
