为测试执行立法——浅谈测试设计

所谓测试设计，就是测试执行的法，它规范了测试人员在测试过程中遇到的“测试什么”和“如何测试”的问题，测试设计内容将直接影响到测试的执行以及结果。

 

为测试执行立法——浅谈测试设计

文/吴频

如果将整个测试体系看成一个国家的话，那么测试分析与设计的过程就是立法的过程，而最终产出的测试方案/点/用例就是一国之法律，每一个测试公民都应该在测试过程中按照这些法律来开展工作。既然是立法，那么就应该从立法动议开始考虑

 

一、分析测试需求

    正如在立法的时候要向各人大机构收集立法建议一样，前期需要对于测试设计进行需求的收集和分析。测试需求的主要来自于开发设计类需求、用户应用类需求和测试经验类需求三方面。

• 开发设计类需求

主要包括产品包需求、设计需求、设计规格、产品的软硬件架构等等。事实上，开发设计类需求仅仅是客户需求在开发层面上的一个映像，并非客户需求的本像，因此在收集到这些需求的同时，不仅要关心开发设计类需求文档本身，更应该关注其隐藏的客户实际需求，将其分析透彻，保证测试设计是贴近客户而不是贴近开发，体现端到端的测试设计理念。

比如用户需要做一个烟囱，但开发人员把图纸拿反了，设计成了挖口井。如果测试设计贴近开发的话，那是绝对发现不了这个巨大的错误；如果直接看到的是用户的需求，就能很容易就能找到这其中的阴差阳错。当然，这仅是一个例子，但是在现实中，开发出来的特性不能满足用户需求而被迫返工的事实是存在的，所以在建立测试之法的时候，我们必须要求收集到的动议是最原始需求的反映。

• 用户应用类需求

这主要包括一些重要的用户实际组网等等，这些都是直接来源于用户的内容，所以可以直接纳入到我们的测试设计中来。

• 经验类需求

在测试立法的过程中需要将以往的经验固化到文档上形成固定的典型组网、典型应用、典型场景等等。

值得注意的是，经验并不是因循守旧，而应该根据当前技术的发展推陈出新，不断更新再不断固化。比如，早期大家对于STP的理解还停留在STP/RSTP，当时的组网不能满足后续MSTP测试的需求，这就需要在原有组网的基础上设计出新的组网，形成新的经验。

   

对这三类测试需求分析清楚了，产品“需要测试什么”基本就非常清晰了。接下来，则要根据需求分析分门别类地进行详细设计，也就是要解决“如何测试”的问题，启动真正的设计立法工作。

 二、 设计测试方案/测试点/测试用例

经过前期的测试需求收集和分析，我们会根据测试对象和范围的不同，把测试设计工作分成三类：特性测试设计、组合测试设计、应用测试设计。特性测试设计主要是针对单个特性进行的设计；组合测试设计主要是将多个相关特性组合起来进行的设计；应用测试设计是根据用户应用而来的专项设计。需要指出的是，实际上组合测试设计和应用测试设计很类似，后者是针对特定用户环境的组合测试设计，也就是说应用测试设计是更加贴近用户实际应用的组合测试设计，无需根据自己的经验再去优化组网，最好按照某用户环境进行1:1的设计。

无论测试设计工作是哪一类，最终体现到实际操作中的内容就是测试方案、测试点、测试用例，即测试的规则。

• 测试方案

测试方案是对测试活动的总体分析和规划，除了要进行测试对象分析以外，每一个测试方案中都应该包括网络拓扑、网络配置、流量模型。

特性测试方案是最基础的一类，主要用于描述某个单一特性的测试方法和过程。由于特性测试方案主要用于产品功能尚未稳定的测试活动，覆盖产品开发早期阶段，那么势必、存在实际产品物料缺乏的问题，所以在设计特性测试方案时，一定要采用尽可能简单的网络拓扑，避免设计过于复杂；相应的，产品开发早期版本仍然处于功能验证阶段，所以特性测试方案的网络配置应该以被测特性为核心进行配置，避免过多过复杂组合；而流量模型应该采用轻载连续流量比较合适。

组合/应用测试方案一般用于产品相对稳定的阶段，根据组合/应用的需要，可以按需设计网络拓扑和网络配置。有一点需要指出的是，在组合测试方案中一般都愿意采用重载持续流量模型，而在应用类测试方案设计时，需要验证用户组网，所以流量模型也需要考虑符合用户的实际情况，因为重载持续流量模型并不是在所有的用户组网中都能奏效的，有时候在某些特定的用户分布式网络中，轻载叠加突发流量模型也会出现问题。

•  测试点/用例

测试方案只是对于需要测试的对象进行了整体的分析和分解，接下来则   需要对分析和分解出来的内容进行归纳和整理，这样就形成了测试点。测试点就是测试设计的纲，它是整个设计的灵魂所在。好的测试点应该是测试对象的归纳，测试点安排的顺序是对测试对象剖析的过程，测试点粒度（即测试点包含内容的多少）的选择是对能力基线的严格把握。

由于测试设计人员的思想是千差万别的，所以为了能够得到更加一致的测试点设计，我们采用了测试类型分析法明确了测试点文件的结构，每一个测试点文件中主要包括：配置测试、功能测试、协议一致性测试、性能规格测试、压力测试、异常测试、互操作测试等。而测试点的粒度确实很难统一，所以我们一般按照10个/人天的测试执行效率进行估计和设计，这就需要有丰富测试执行经验。

但是，一个测试点无法详细描述出具体操作的步骤，这便需要测试用例。测试用例设计就是一个将测试点细化到可执行步骤地过程，每一个测试用例都是由执行——〉验证的不停往复。在用例的设计中我们有一些常用的工程方法：边界值法、等价类划分、错误猜测等等。这些无非是扩展我们设计的思路，让测试设计的肉体更加丰满。

 三、  培养设计人员

在测试全流程中，真正执行者都是有血有肉的个体，而这些人所拥有的经验就是流程的活力。所以要充分发挥测试设计流程的活力，就应该让拥有丰富经验、技术级别高的人来主导测试设计的工作。

在H3C的测试体系中，主要有助理测试工程师、测试工程师、测试专家、资深测试专家等。对于一般的测试设计工作，具有良好测试实践的人员（测试工程师）基本可以胜任；而复杂的跨领域的组网测试设计，除了需要测试实践以外，还需要掌握广泛的数据通信技术知识，这就要求测试专家承担该工作；而资深测试专家则要承担各类更加复杂的疑难杂症的测试设计工作（如黑客攻击测试设计）。

为了适应不同层次的测试设计活动，需要相应的培养不同技术等级的测试人员梯队，尽量物尽其用，高技术等级的从事复杂的设计活动，低技术等级的从事简单的设计活动，不具备设计资质的人员则不能参加设计活动。

 

四、测试设计维护

实践是检验真理的唯一标准，测试执行是检验测试设计正确性的最佳手段。测试人员需要将将实践中发现的设计问题，通过跟踪流程反馈到设计团队中，使得前期设计的缺陷漏洞得以修复和完备，这样就会形成一个良性的循环。H3C问题单跟踪流程就提供了一个很好的修复机制，不仅从端到端保证设计修改的正确性，而且中间设置的审核环节保证了修改的质量。

 

测试设计是一个充满创造力的活动，无论是前期的需求分析，还是分析的落实，或是后期对于设计的不断完善。要建立起自己的测试之法，就必须将所有测试设计的活动贯穿到整个测试活动中去，测试执行中体现测试设计的精髓，测试设计吸收测试执行的智慧结晶。