调测工具VcTester攻略之
敏捷开发方式下调测组织过程
作者：网际游民，成稿于2010年2月
关于本系列文章
本系列文章罗列如下：
《调测工具VcTester攻略之：搭建敏捷开发环境》
《调测工具VcTester攻略之：使用快捷编辑功能》
《调测工具VcTester攻略之：快速定位问题》
《调测工具VcTester攻略之：敏捷开发方式下调测组织过程》
《调测工具VcTester攻略之：脚本驱动API测试》
《调测工具VcTester攻略之：使用脚本桩构造数据驱动测试》
撰写本系列文章时得到ezTester技术专家Sundy多次帮助，在此谨表感谢！
说明：下文涉及端到端测试设计的内容摘自ezTester培训材料，概念既非本人提出，不少内容还原文照抄，见谅。
VcTester的测试用例组织形式
与其它测试工具类似，VcTester也提供测试工程、测试集与测试用例管理功能，这3者构成树状结构，其中测试集下既可挂若干测试用例，也可挂测试集。
VcTester的测试组织形式与常规工具稍有不同，主要是为了适应敏捷开发模式，引入一些差异化特色。下面我先举例说明测试集与测试用例的嵌套使用方法，编写如下脚本：
运行上述脚本后，测试用例树显示如下：
TestSet1、TestSet2是测试集，Test1与Test2是测试用例，这些测试集与测试用例都定义了setUp与tearDown函数。运行用例Test1，打印信息如下：
不难看出，VcTester测试用例具有嵌套组装的功能，Test1挂在TestSet2之下，而TestSet2又挂在TestSet1之下，所以，运行Test1之前，TestSet2的setUp函数先运行，而运行TestSet2的setUp运行之前，TestSet1的setUp先运行，tearDown的调用顺序正好相反，也是嵌套的。
对比其它测试框架，我们分析VcTester的用例组织方式具有如下特点：
1. 测试集不只用作测试用例的集合，还兼具构造测试运行环境的功能，setUp常用于构造运行环境，而tearDown则用于复原运行环境。
2. 各个测试用例运行时是独立的，并不与其它用例相关联。如上例，运行Test1时，先按TestSet1与TestSet2定义先构造测试运行环境，运行结束恢复运行环境，而运行Test2时，同样也按TestSet1与TestSet2定义先构造测试运行环境，运行结束恢复运行环境。但静态的用例定义，可与其它用例共享同一运行环境，如上例Test1与Test2在同等配置的测试环境下运行（都是通过TestSet1与TestSet2构造环境及恢复环境）。
上述特点让VcTester组织测试过程更具灵活性，比如，如果我们不定义某用例所归属的测试集的setUp与tearDown函数，这时测试集仅用作测试用例的集合，用例组织回归于传统用法。另外，一个测试用例容纳的测试脚本可多可少，按如下方式可实现一次构造测试环境，运行多项测试：
但为什么共享同一测试环境的多个用例要独立构造环境，并在使用完毕立即恢复呢？如上例运行Test1后运行Test2，要独立构造与恢复环境共做两次，而不是只做一次。这恐怕与VcTester中用例定义更新后自动运行的特性有关，每个用例独立修改，独立运行，所以要独立构造与恢复运行环境。
端到端测试设计
“端到端方式测试设计”是与“隔离方式测试设计”相对的一个概念，依据传统的测试理念，单元测试中被测对象应该被隔离，然后再实施测试，如IPL公司对单元测试的定义是：
The unit test is the lowest level of testing performed during software development, where individual units of software are tested in isolation from other parts of a program.
第4代白盒测试方法拓展了测试设计理念，发展出一种端到端的测试设计模式，即，这种测试设计方法要求你无须按隔离的眼光看待被测单元，而是从应用角度设计用例，由应用层的测试脚本驱动着底下各个层次的功能代码，发起并完成各项测试。
在隔离模式下，你关注一个被测单元，要在它的上层构造测试驱动，在它的下层构造测试桩，即，保持被测单元是真实的，它的上层与下层都是模拟的。
在端到端模式下，你关注工作对象的整体，大部分测试设计接近于真实应用（还有小部分是内部调测场景下用例设计，后面还会讲到），在最高层用脚本发起调测，然后借助脚本桩在各层函数调用时插入一些观察控制点（即PCO点），在各PCO点再微调测试运行环境，构造出各式各样运行环境，另外，PCO点也用于观察、判断当前测试结果是否预期。
为什么会有端到端测试设计模式？回顾一下我在《调测工具VcTester攻略之：快速定位问题》中提到的一句话：
在深度敏捷下，你写脚本首先是为了展示功能，用脚本生成配置数据、用脚本发起功能展示，然后，当你还有余力时，把这样的脚本转化测试用例。
敏捷的精髓在于确保产品“随时可展示”，而非“为测试而测试”。我个人并不认同TDD三条军规（参见Object Mentor公司UncleBob的“The three rules of TDD”）所要求的，编写任何产品代码之前必须先写用例，与其遵循测试驱动开发（Test Driven Development），还不如遵循“应用场景驱动开发”（use-case driven development）。我想，第4代白盒测试方法提倡的应用场景驱动，与它的调试即测试、持续测试、在线测试等理念是一脉相承。应用场景驱动也就是前面我们提到为展示功能而编写调测脚本，这样的脚本设计必然是端到端形式的。
端到端测试设计具有强烈的实用主义特色，如果按照隔离方式设计用例，每个细小被关注的测试对象都要模拟它的上下层，那要消耗多大的精力。端到端测试设计则不然，通常是一个测试驱动造就数个乃至数十个测试用例，测试设计异常高效，另外还解决了CppUnit测试设计中普遍存在的“行为依赖风险”（参见ThoughtWorks李晓的《不要把Mock当作你的设计利器》一文）。
当然，端到端测试设计比隔离方式粒度要粗一些，针对某些关键代码，或高复杂度代码，仍不妨采用隔离方式实施深入测试。此外，值得一提的是，端到端测试设计模式并不具备广泛适应性，必须借助脚本桩才可实施。
理解了场景驱动开发与端到端测试设计，现在不难理解为什么VcTester的测试集要支持setUp与tearDown定义，它的测试集是用来描述一个个调试或测试的应用场景的。
区分三类调测场景
测试设计具有明显层次性，端到端测试场景处于中间层次，更高一个层次是“客户化测试场景”，比方针对某类客户，提供一种组网形式，针对另一类客户提供另一种组网，配置有较大差别，就构成不同测试场景。客户化测试场景是针对产品层面而言的，有时我们也把不同测试类别划作此类，比如：冒烟测试场景，产品初验测试场景等，这些都属于产品层面的测试场景。
端到端调测场景则以开发者个体为单位，关注自身工作对象（产出代码）的使用场景。如果你工作的代码是一个库模块，你的端到端调测场景就是该库模块的接口调用，如果你当前工作对象是整个产品，这时，端到端测试场景与上一层“客户化测试场景”重合。
端到端的下一层是内部调测场景，以开发者个体为单位，凡不属端到端的都归到这一类。内部调测场景有一个特点，它的运行环境是假设出来的，即，被测对象的上层或下层不是真实应用情况，是模拟出来的。因为是假设的，它的上下层依赖关系容易发生变迁，所以，内部调测场景下的用例更容易产生行为依赖风险。典型的内部调测场景有两种：一是针对某个复杂功能开展专项测试，二是为迭代需要或验证需要，临时分解出来的中间应用场景。前者比较容易理解，后者要解释一下。
迭代开发比较强调工作步骤分解，将一个大任务分解成若干个小任务，每个小任务在各轮迭代中完成，每轮迭代的工作量尽量均匀（只是尽量，不是强制），而且要求可展示、可验证，为达到这个目标，开发中我们会假定一些中间场景，比如在某服务系统的后台进行复位前台的操作，我们可以假定一个中间场景，前台收到后台复位指令，打印一条信息表示收到指令了，构造这种场景是为了验证通信系统是否正常。如果一步实现后台复位前台的功能，迭代步幅太大，我们先验证通信环节，然后在下一次迭代验证真实的复位。还有一些中间场景是为测试目的设置，比如某项功能比较复杂，我们在该功能的中间步骤添加验证环节，这也会产生假想的中间应用场景。
我们依据上述三类场景，有层次的组织测试设计。客户化测试场景体现为阶段性测试任务中，在版本机中，它往往独占一个根目录，比如独立一个目录“冒烟测试”，或“A类用户初验测试”等。客户化测试场景下的用例通常由多人共同完成、共同维护。端到端调测场景与内部调测场景是私有的，归开发者或测试者个人所有，由他个人承担维护工作，一般来说，端到端调测场景下的用例较多，内部调测场景下的用例较少，前者所占比例越高，你的测试集越容易维护。
在VcTester集成环境中，一个典型的测试用例树组织如下：
其中“冒烟测试”与“A类用户初验测试”是项目分派到你头上的测试设计任务（你是参与者之一），其它是自己独立维护的用例。
相关文章：
《调测工具VcTester攻略--敏捷开发方式下调测组织过程》
《调测工具VcTester攻略--使用脚本桩构造数据驱动测试》
4094
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
