vrs75 2005-9-8 21:56
一个测试设计的例子
F_BRC_5查询测试设计
（草案）
本文以F_BRC_5广播查询为例，描述了测试设计文档的结构和内容。为清晰介绍测试覆盖度描述了客户满意和功能需求两种视角的关系以及常用的灰盒测试方法要点。
1. 客户满意与功能需求
评价软件产品质量经典的理论认为需要两方面：“满足功能”和“适于使用”，分别从功能需求和客户满意的角度描述软件产品质量的程度好坏。在CMMI体系中，与测试相关的两个不同的过程域PA：Verification和Validation，即是从两方面提出测试应该达到的成熟度。
不同的目的可能使用同样的测试手段。比如验证测试，验证需求的测试属于Verification，以客户角度的验证测试（比如验收测试）则属于Validation。这里隐含了以测试目的划分PA的思想，一般理解的测试方法论（比如功能测试或性能测试等分类方法）可以既属于Verification又属于Validation。
上图简单表示某些活动的层次结构，彩色线条表示了不同的方法论可以被不同的目的所采纳，而不同的方法论也可能有相同的操作层面，大多数情况下这种“复用”很常见，比如跨学科的研究方法常常是基本一致的。
有人认为功能需求是需求开发人员目睹的客户需求的某个时刻的截面，如果以河流来比喻客户需求的不断变化，那么可能是这样：
不过事实上还没这么简单，客户满意往往不仅仅是一条河流，从市场角度考虑，每个个体都可能是潜在的顾客，那将是N条河流的混合，也许用璀璨的星空来比喻合适一些，而需求开发人员则是某个时刻看星星的角色（别是白天哦）：
由于产品不可能满足所有潜在客户的需求，甚至不可能满足特定客户连续时间内的需求，只得用更多的产品或产品系列争取覆盖更多目标。所以某个产品可能完全符合功能需求及设计需求等，但却可能是不适于客户使用的，所以客户满意和功能需求是两个截然不同的角度，某种理想条件下，功能需求是客户满意特定时刻经过需求开发所塑造的一个近似值。
2. 灰盒测试：
灰盒测试的方法是相对白盒和黑盒测试方法而言的，从测试目的策略回顾一下这两种方法。
黑盒测试基于功能需求，白盒测试基于设计需求（设计和实现可以理解为设计需求），它们验证是否与对应的需求保持一致，这里有个显著的特点：方法本身所具有的特征（输入）与测试目的是完全吻合的，而且是显而易见的，不需要附加验证（比如为什么黑盒测试可以保持与功能需求一致？为什么白盒测试可以保持与设计需求一致？），这是因为测试方法的主要输入边界条件正好和测试目的所要求的内容是一样的，那么如果用白盒方法来验证功能需求呢？
在上图中描述了设计需求相对功能需求所产生的漂移，除了两者重合部分之外，还有未实现的功能需求和增加的设计需求，而未实现的需求显然是设计实现的缺陷，增加部分虽然不是功能需求所要求的，却必须包括在测试需求里面。如果用白盒方法来验证功能需求，那么必须先保证设计需求与功能需求的一致性。在这里，可以看到测试方法本身特征并不总能覆盖所有的测试目的，实践中一般通过增加其他测试方法来弥补可能产生遗漏的环节，比如在验证设计需求与功能需求的一致性时增加黑盒方法，例如设计评审（有趣的是往往黑盒与白盒在不同环节共存，某个环节使用了黑盒方法，常常另一个环节使用白盒是最合理的）。
这种测试方法一般习惯称之为灰盒测试，典型的两环节例子如下图：
多环节的灰盒测试在实践中也非常多，一般经验规律是至少各出现一次黑盒和白盒的方法，但并不一定如此。
3. 测试需求分析：
F_BRC_5: 广播的查询(Query Broadcast)
对广播的查询包括：
1. 对指定速率广播的查询；入口在系统的CM主菜单中“查询广播”，同时菜单中指定速率，结果以表格方式显示所有满足条件的广播对象列表。结果直接显示。结果集不需要过滤功能，支持按广播名称，广播起始节点名称，广播节点名称排序。
2. 对指定广播点网元上的广播查询；入口在拓扑图中的节点对象的右键菜单中。结果以表格方式显示所有满足条件的广播对象列表。结果直接显示。结果集不需要过滤功能，支持按广播名称，广播起始节点名称，广播节点名称排序。如果所选节点不是广播节点，则不出现广播查询选项。
广播的综合查询界面上的查询条件可以包括:
1. 广播名称；
2. 速率；
3. 广播节点；
4. 节点保护（是/否）；
5. 副广播节点；
6. 广播状态；
其中4，5连动。
广播对象的列表中显示的信息包括：
1. 广播名称；
2. 广播速率；
3. 广播起始节点名称(NE显示名称)；（当存在广播节点保护时，如果信号源节点不可见，则表示为“不可见”）。
4. 广播节点名称（NE显示名称）；
5. 广播节点保护（副广播节点名称）；
6. 广播分支数量（作为Leg的连接对象数量）；
7. 广播状态。
8. 广播的服务客户
上面是复制的F_BRC_5需求文档内容，在设计和实现环节还可能增加一些由开发人员所创造的“需求”，可能有明确的设计文档说明，也可能是业界默认标准，或者是隐含的内容；这些“需求”里面有一部分实际是对功能需求的完善，属于功能需求的有机组成部分，比如速率，那么有那些速率需要列入考虑范围呢？在这个功能需求文档中并没有说清楚，可以理解为隐含需求，即使没有显式说明也不会引起歧义---这部分需求应该被补充过来。
还有一些属于满足功能但以一种特定的方式满足，这些可以在做功能测试中忽略，但其他测试比如相关到界面易用性测试上可能是缺陷，或在性能测试中是瓶颈等等。
仅从功能需求角度考虑，以下图作为对功能需求忽略部分的弥补，并构成测试需求基本集合：（此图缺陷是无副广播节点及其联动，但多了按广播客户查询）
测试需求列表：
l 入口1测试需求：如上1，从中剥离其他输入、查询和查询结果（排序）功能，仅测试是否可以从指定菜单进入；
l 入口2测试需求：如上2，从中剥离其他输入、查询和查询结果（排序）功能，仅测试是否可以从右键进入，节点按照等价类分两组并在两组中以简单随机采样各选取10个节点测试右键功能；
l 查询录入测试需求：包括需求文档中的6种+广播客户，以及原型图的对每个数据类型的解释，其中广播保护为2种选择的逻辑值，广播速率为7种选择的组合枚举值，广播状态为4种组合枚举值；该测试的输出设为SQL语句（原因后面详述）；
l SQL执行测试需求：略；
l SQL查询显示测试需求：表格方式、直接显示、不需要过滤等（详见需求文档）；
l 排序功能测试需求：如上；
这里重点分析查询录入和SQL执行功能，其他功能与此相关性比较弱，基本属于单一模块所以测试用例覆盖业务难度不大，按照需求直接写测试用例集即可，不再详述。
4. 查询录入和SQL执行的测试设计：
虽然这里区分成两个测试需求使得问题简单化了，但往往实践中会很容易理解为这样的测试需求：录入一些查询条件，得到一些输出结果，然后验证这些结果与需求的吻合程度。那么显然就困难了许多，如果试图完整覆盖业务需求更是无法实现。
这里使用了上面提到的灰盒测试方法（但与上节例子稍有差别），掌握这种方法的精髓就可以在实践中灵活使用。
上节例子是以功能需求和设计需求描述的，目标物是吻合产品需求，对应于需求分析阶段和设计实现两个阶段；而这里的目标物是根据查询条件查询数据库，对应于生成SQL语句阶段和到数据库根据SQL查询两个阶段，这里的例子更细一些，但都是分两个阶段，尽管阶段划分的标准不一样。
如图：
、
在黑盒方法中根据查询条件在LOG中检查是否SQL的WHERE子句与查询条件一致，这个是可以比较容易覆盖所有可能的业务逻辑的，稍后继续详述；
在白盒方式中需要检查该SQL语句时候与业务需求吻合、是否合法、是否能被正确解释，由于SQL语句本身的特点，也很容易验证，甚至可以缺省理解为无须测试，如果不担心测试策略的严密性的话。
至于SQL语句到数据库里面的执行及其结果，尚无哪家数据库厂商请大家吃饭，可以忽略。
5. 查询条件生成WHERE子句的测试设计：
这里实际上依然是个灰盒测试例子：
WHERE子句是个逻辑值，基本构成是这样的：
（条件1）and（条件2）and（条件3）……and（条件n）
显然AND子句与需求的吻合在这种逻辑判别式上是简单而且容易的；
而现在得到的不再是组合条件测试用例的设计，只需要针对分立的各个条件进行测试用例设计即可，这样数量级就大大减少，可以完成覆盖所有的业务逻辑。
广播名称、广播节点、副广播节点、广播客户虽然是字符型，但现在仅需要验证是否被正确传递到WHERE子句的IN（‘name’）即可，可以按照边界值方法生成20-50个用例，比如null、space、N长的字符串……等等；
广播速率、节点保护、广播状态属于组合枚举类型，因最多才7个枚举值，直接穷举即可，对于广播速率测试用例为128个，广播状态为16个，节点保护为2个（逻辑值，无组合）。
6. 最后
值得说明的是，这个例子中与SQL语句和逻辑判定式为研究对象的，多数情况下测试目标未必是这些简单的类型，那么这时就需要在做白盒测试时深入了解产品需求，了解设计实现时所采用的方法，并据此进行分析。如果输入输出有较复杂的逻辑关系，可以采用判定图予以列举，一般情况下判定图每一纵列可以代表一条测试用例，而且有限条测试用例可以完全覆盖所有业务逻辑，是效率最高的，不过也是最费时间的。
200x-10-11
mengkuen2010 2007-8-31 09:14
sdlkfj3
lenovo1217 2007-9-6 12:54
感谢共享1
感谢共享1
changlang530 2007-9-7 09:30
感谢共享1
dabeixiong 2007-9-29 00:54
图看不到啊。。。看来还得下载。。。
muyang327 2007-9-30 12:16
:)