3.5版本包含以下功能：

• 模型更新检查：

模型更新检查能够识别必要的模型更新，从而决定是否重新探索模型。对于特定的machine，如果模型源代码，cord脚本或者模型工程中引用的其他输入文件发生改变，Spec Explorer会开始一次新的探索；否则将会使用已有的探索结果用于显示，测试代码生成或者用户定制处理。Spec Explorer也添加了一个按钮用于强制重新探索。

• 多machine处理：

Spec Explorer加入了对多machine的支持，现在用户可以方便的选定多个machine并进行模型探索，测试代码生成或者用户定制处理的工作。

• cord上下文菜单：

Spec Explorer对cord脚本加入了"”Go To Definition“这个菜单项，用户可以方便的通过这个菜单项或者快捷键F12导航到相应的cord配置定义或者是machine定义。

以下是最新版本的链接：

Spec Explorer主页

Release Notes

论坛

英文blog

MSDN文档

Spec Explorer 2010 3.5只能在Visual Studio 2010 professional版或以上版本使用，您可以通过这里得到Visual Studio 2010的90天试用版。

欢迎您提出宝贵的意见和建议！

3.4版本包含以下功能：

• 动态遍历：

动态遍历提供了一种新的测试用例生成机制，用户可以定制遍历策略，并且在测试运行时对探索结果进行遍历并同时调用相应的测试方法。

• 验证性能改进：

Cord脚本的验证过程性能有了明显改进

• 部分探索结果呈现：

新版中用户点击Stop按钮或者探索过程超过了配置的时限，Spec Explorer会显示截止目前的探索结果

• 基于多个namespace / type的模型构建：

新版中模型构建不再只能基于单个namespace / type，改为基于一个逗号分隔的namespace / type 名称列表进行构建

• 基于完全限定名的静态Action调用：

静态Action调用被加入了完全限定名的支持，在新版中使用者可以使用不同类型的同名静态Action

• SpecExplorer.exe加入脚本验证任务：

脚本验证任务被加入SpecExplorer.exe

以下是最新版本的链接：

Spec Explorer主页

Release Notes

论坛

英文blog

MSDN文档

Spec Explorer 2010 3.4只能在Visual Studio 2010 professional版或以上版本使用，您可以通过这里得到Visual Studio 2010的90天试用版。

希望您能够喜欢我们最新的Spec Explorer版本，也欢迎您提出宝贵的意见和建议，让我们能够在未来发布更好的产品。

Spec Explorer 2010包含了新的功能，持续改进的文档，以及多于100个bug的修正。

3.3版本包含以下功能：

• 实时测试

实时测试功能让用户可以直接使用模型进行测试，而无需生成测试代码。Action的选择将由适配器和待测系统共同决定。

• 状态搜索

用户可以在探索结果图上搜索状态，从一定程度上解决了模型难以调试的问题。

• probe记录

probe的值将会被生成到测试代码中，用户可以通过观察测试日志中的probe信息分析测试过程，解决了之前只有状态ID难以分析的问题。

• 测试方法定制

通过使用新的定制开关，用户可以选择生成测试方法的返回值，返回类型甚至声称静态测试方法。该功能使得Spec Explorer可以生成适用于更多测试平台的代码，而非局限于Visual Studio的测试环境。

另外，我们也发布了Spec Explorer的UML扩展包，支持通过一个Sequence Diagram进行基于模型的测试。

以下是最新版本的链接：

Spec Explorer主页

Release Notes

论坛

英文blog

MSDN文档

Spec Explorer 2010 3.3只能在Visual Studio 2010 professional版或以上版本使用，您可以通过这里得到Visual Studio 2010的90天试用版。

希望您能够喜欢我们最新的Spec Explorer版本，也欢迎您提出宝贵的意见和建议，让我们能够在未来发布更好的产品。

新的Spec Explorer较前一版本又新增和改善了一些功能，改进了文档，并修正了超过110个bug。新版Spec Explorer运行在Visual Studio 2010 Professional及以上版本。

新功能概述：

• New Model Wizard

新的建模向导将旧有的基本解决方案(Spec Explorer Base Solution)模板和模型工程（Spec Explorer Model Project）模板进行了整合，使用者可以更方便的新建和添加Spec Explorer工程。

• Choice API

Choice API对建模待测试系统的非确定性行为进行了更好的支持。使用者不再需要把一个Action拆分成调用和返回两个方法，而是在一个方法内部通过使用Choice API对待测试系统可能存在多个响应的情况进行建模。

• SpecExplorer.exe

新的SpecExplorer.exe将支持最新的探索结果格式，并对用户定制的Post-Exploration任务扩展进行了支持。

• Improved Documentation

Spec Explorer的文档持续更新中，在3.2中尤其更新了Cord脚本语言的描述。

Spec Explorer可以从微软DevLabs的主页进行下载。

浏览最新的Release Notes获得更详细的关于安装，功能和已知问题的信息。
更多的信息请浏览Spec Explorer论坛，团队博客（中文/英文），和MSDN在线帮助

需要注意的是，Spec Explorer 2010 3.2版本只能运行在Visual Studio 2010的发行版本上，而不能运行于Visual Studio2010的Beta 1, Beta 2和Release Candidate版本，以及Visual Studio 2008的任何版本。Visual Studio 2010的90天试用版可以下载。

课程1

课程2

课程3

课程4

屏幕截图可能不够清晰，我们以后将用更高清晰度的录像代替，希望大家理解

Spec Explorer 2010 3.1版本是基于Visual Studio 2010 RC的，这一版本较前一版本拥有更强大的功能，并修正了超过220个bug。

特别需要注意的是建模属性和建模类都进行了重命名，新的命名将更为准确和清晰。如果用户继续使用过期的旧属性名和类名（例如Microsoft.Modeling.Contracts类），Spec Explorer会产生警告信息。

新增功能概述：

• Flexible test naming and attributes
  3.1版本引入了新的Cord开关，用于更好的控制测试用例的名称与属性，从而生成基于不同测试框架的测试代码。用户甚至可以使用系统的环境变量或者Spec Explorer的内置变量来给这些开关赋值。
• Bounded repetition machine
  新的Cord引入了一种新的machine，用于表示重复特定次数范围内的行为。
• New project creation
  新的Spec Explorer工程创建模板可以创建一个简单的模型工程，该工程可以被添加到已有的解决方案中或者独立成为一个解决方案。
• Construct tag and switch completion
  Cord目前支持Construct声明和开关声明的自动完成。
• F1 Help
  在Spec Explorer的任何一个窗口中按下F1键，Visual Studio 2010内置的帮助系统都会显示出相应的帮助信息。
• Help integration
  Spec Explorer的文档与Visual Studio 2010的帮助管理器整合，同时支持在线MSDN帮助和本地帮助。
• Exploration progress
  Spec Explorer改进了探索过程中的进度显示。
• User-customized post processing
  用户可定制Post-Exploration的任务，基于当前探索结果生成报表，报告等自己关心的信息。

Spec Explorer 3.1可以从微软DevLabs的Spec Explorer主页下载
浏览最新的Release Notes获得更详细的关于安装，功能和已知问题的信息。
更多的信息请浏览Spec Explorer论坛，团队博客（中文/英文），和MSDN在线帮助

当Spec Explorer对状态空间进行探索或者生成测试代码时，探索结果将被存在一个扩展名为seexpl的文件中，这个文件实际上是一些表示探索结果的xml文件的zip包。seexpl文件的内容在Visual Studio里面会显示为状态图，以SMB2 sample（安装Spec Explorer以后sample也随之安装）为例，TestSuite这个machine的探索结果如下图所示：

除了使用Visual Studio打开seexpl文件外，用户可以用自己的程序来打开。这里需要用到Microsoft.SpecExplorer.ObjectModel这个assembly。

让我们来实现一个输出探索结果统计信息（比如覆盖的需求，action的序列等等）的小程序。首先，创建一个console应用程序并把ObjectModel加到引用中。

对象模型就包含在Microsoft.SpecExplorer.ObjectModel这个命名空间中。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

using Microsoft.SpecExplorer.ObjectModel;

namespace TransitionSystemDemo
{
    class Program
    {
      ...

最上层表示探索结果的对象被称为transition system，这个名字来源于探索被表示为一组状态以及所有状态之间的迁移（其标签即为action）。transition system这一对象可以被一个叫做TransitionSystemLoader的类加载，代码示例如下：

static void Main(string[] args)
{
    if (args.Length != 1)
    {
        Console.WriteLine("usage: transitionsystemdemo <pathtoseexpl>");
        Environment.Exit(1);
    }
    try
    {
        var loader = new ExplorationResultLoader(args[0]);
        TransitionSystem tsys = loader.LoadTransitionSystem();
        Process(tsys);
    }
    catch (Exception e)
    {
        Console.WriteLine("failed: " + e.Message);
        Environment.Exit(2);
    }
}

Process这个方法将稍后定义。我们首先看看怎么通过一个方法调用输出transition system的统计信息。在这里我们用到LINQ来方便的计算所有被覆盖或者假定被覆盖的需求列表。

static void PrintStatistics(TransitionSystem tsys)
{
    Console.WriteLine("{0} states ({1} initial), {2} steps",
        tsys.States.Length, tsys.InitialStates.Length, tsys.Transitions.Length);
    var captured =
        tsys.Transitions.Aggregate(
                new string[0] as IEnumerable<string>,
                (cs, tr) => cs.Concat(tr.CapturedRequirements).Concat(tr.AssumeCapturedRequirements))
                .Distinct()
                .OrderBy(x => x);
    Console.WriteLine("captured: ");
    foreach (var req in captured)
        Console.WriteLine("  " + req);
}

transition system有三个基本的属性，可用于遍历：

• States：transition system中所有状态的数组。数组中的每一个元素是一个表示状态的对象，含有诸如状态类型，状态标签等信息。
• InitialStates：transition system中所有初始状态的数组。如果该transition system表示的是一组测试，则每一个测试用例都会有一个初始状态。
• Transitions：transition system中所有状态迁移的数组。数组中的每一个元素是一个表示状态前一的对象，含有诸如源状态，目标状态，需求覆盖等信息。

对SMB2 sample的TestSuite探索结果运行上述程序，结果如下：

计算需求非常的容易，现在让我们来计算action的序列，这一部分会稍微复杂一些：

• 我们的程序需要处理任意的transition system，则可能会遇到有环的情况。我们将通过一旦发现环就立刻停止遍历来实现。
• transition system是可能包含分支（同一源状态存在多个状态迁移）的，即便是已经分拆成测试用例的transition system。我们将以一种类似cord语法的形式生成序列，比方说action A到达某个状态，而该状态之后B和C都被允许，则我们生成A;(B|C)的形式。

代码如下：

static void PrintPatterns(TransitionSystem tsys)
{
    foreach (var stateLabel in tsys.InitialStates)
    {
        Console.WriteLine("Starting in state {0}:", stateLabel);
        Console.WriteLine(ToPattern(tsys, new HashSet<State>(), GetState(tsys, stateLabel)));
    }
}

static string ToPattern(TransitionSystem tsys, HashSet<State> visiting, State state)
{
    if (state.RepresentativeState != null)
        // skip intermediate state
      return ToPattern(tsys, visiting, GetState(tsys, state.RepresentativeState));
    if (visiting.Contains(state))
        // Stop at cycle
        return "";
    visiting.Add(state);
    // compute successor
    var successors = GetSuccessors(tsys, state).Select(tr => ToPattern(tsys, visiting, tr)).ToArray();
    visiting.Remove(state);
    if (successors.Length == 0)
        // end state
        return "";
    else if (successors.Length == 1)
        return successors[0];
    else
        return "(" + string.Join("|\r\n", successors) + ")";
}

static string ToPattern(TransitionSystem tsys, HashSet<State> visiting, Transition tr)
{
    var continuation = ToPattern(tsys, visiting, GetState(tsys, tr.Target));
    if (continuation != "")
        return tr.Action.Text + ";\r\n" + continuation;
    else
        return tr.Action.Text;
}

static State GetState(TransitionSystem tsys, string stateLabel)
{
    return tsys.States.First(state => state.Label == stateLabel);
}

static IEnumerable<Transition> GetSuccessors(TransitionSystem tsys, State state)
{
    return tsys.Transitions.Where(tr => tr.Source == state.Label);
}

• 每一个状态都有一个RepresentativeState的属性。这个属性和symbolic transition system有关，symbolic的相关内容超出了本篇博客的范畴，我们将在之后的文章中进行解释。只需要记住，当我们访问一个含有RepresentativeState的状态时，我们跳过该状态，并从RepresentativeState继续遍历。
• 我们记录已经访问过的状态，所以可以方便的发现环。
• 我们使用tr.Action.Text来输出action，这个信息和我们在Visual Studio里面显示的action标签是一样的。但是我们必须明白，一个action对象不仅仅是标签那么简单，它含有更多的信息，只是我们这里不会用到。
• 计算状态和状态迁移时，我们搜索了transition system多次，这种方法很低效。实际的程序中，用户可能更愿意缓存这些信息。

在transition system中，还有好多可利用的东西我们没有在这里展示。最酷的或许就是所有有关action和action参数的信息都可以直接被转变为反射信息和LINQ表达式，这样一个用户就可以写出基于transition system的测试执行器。我们会在以后的博客中继续介绍。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

using Microsoft.SpecExplorer.ObjectModel;

namespace TransitionSystemDemo
{
    class Program
    {
        static void Main(string[] args)
        {
            if (args.Length != 1)
            {
                Console.WriteLine("usage: transitionsystemdemo <pathtoseexpl>");
                Environment.Exit(1);
            }
            try
            {
                var loader = new ExplorationResultLoader(args[0]);
                TransitionSystem tsys = loader.LoadTransitionSystem();
                Process(tsys);
            }
            catch (Exception e)
            {
                Console.WriteLine("failed: " + e.Message);
                Environment.Exit(2);
            }
        }

        static void Process(TransitionSystem tsys)
        {
            PrintStatistics(tsys);
            PrintPatterns(tsys);          
        }

        static void PrintStatistics(TransitionSystem tsys)
        {
            Console.WriteLine("{0} states ({1} initial), {2} steps",
                tsys.States.Length, tsys.InitialStates.Length, tsys.Transitions.Length);
            var captured =
                tsys.Transitions.Aggregate(
                        new string[0] as IEnumerable<string>,
                        (cs, tr) => cs.Concat(tr.CapturedRequirements).Concat(tr.AssumeCapturedRequirements))
                        .Distinct()
                        .OrderBy(x => x);
            Console.WriteLine("captured: ");
            foreach (var req in captured)
                Console.WriteLine("  " + req);
        }

        static void PrintPatterns(TransitionSystem tsys)
        {
            foreach (var stateLabel in tsys.InitialStates)
            {
                Console.WriteLine("Starting in state {0}:", stateLabel);
                Console.WriteLine(ToPattern(tsys, new HashSet<State>(), GetState(tsys, stateLabel)));
            }
        }

        static string ToPattern(TransitionSystem tsys, HashSet<State> visiting, State state)
        {
            if (state.RepresentativeState != null)
                // skip intermediate state
              return ToPattern(tsys, visiting, GetState(tsys, state.RepresentativeState));
            if (visiting.Contains(state))
                // Stop at cycle
                return "";
            visiting.Add(state);
            // compute successor
            var successors = GetSuccessors(tsys, state).Select(tr => ToPattern(tsys, visiting, tr)).ToArray();
            visiting.Remove(state);
            if (successors.Length == 0)
                // end state
                return "";
            else if (successors.Length == 1)
                return successors[0];
            else
                return "(" + string.Join("|\r\n", successors) + ")";
        }

        static string ToPattern(TransitionSystem tsys, HashSet<State> visiting, Transition tr)
        {
            var continuation = ToPattern(tsys, visiting, GetState(tsys, tr.Target));
            if (continuation != "")
                return tr.Action.Text + ";\r\n" + continuation;
            else
                return tr.Action.Text;
        }

        static State GetState(TransitionSystem tsys, string stateLabel)
        {
            return tsys.States.First(state => state.Label == stateLabel);
        }

        static IEnumerable<Transition> GetSuccessors(TransitionSystem tsys, State state)
        {
            return tsys.Transitions.Where(tr => tr.Source == state.Label);
        }

    }
}

Spec Explorer的基础解决方案向导（Visual Studio File菜单->New->Project->Visual C#->Spec Explorer Base Solution）在第二步对几种模型进行了简述，并让用户进行选择：

所以在这里和大家探讨一下在什么情况下选择哪种模型。

大家可能还记得在之前的一篇博客中，我们讲到了两种连接测试用例与待测系统的方式：直接连接和适配器连接。如果你决定使用后者，那么适配器本身的设计决定了你选择静态模型还是实例模型。一个静态的适配器可以被用来控制一个基于实例的待测系统，反之亦然。考虑到测试适配器只是整个测试体系中的一个组件，所以这里进行选择的基本原理和设计任何一个面向对象的组件的基本原理是一致的。注意这里并不是一个是或者否的决定，静态和基于实例的Action可以共存于同一个适配器中。

Cord脚本中Action的声明被用于连接测试用例与待测系统或者适配器。总的来说，如果你的测试用例是调用待测系统或者适配器的静态方法，那么Action就应该是静态的；如果调用的是待测系统或者适配器的实例化方法，那么Action就是基于实例的。所以选择静态模型还是实例模型的决策权并不在建模者，而在于待测系统或者适配器的设计者。当然，两者可以是扮演不同角色的同一个人。

基于实例的Action意味着模型调用某一对象的方法，该对象不仅仅在模型探索阶段存在，在测试运行阶段也是存在的。所以该对象必须是之前某个步骤的输出，如果一个方法创建了一个没有返回的对象，那么显然这一对象不能在模型的后续步骤中被用到。

Spec Explorer允许把基于实例的Action与静态的模型方法进行对应（反过来亦可）。虽然一般来说不推荐这么做，因为基于实例的Action对应基于实例的模型方法，静态Action对应静态模型方法是很自然的设计，但是有时建模者不同意待测系统或适配器的设计，而希望用另一种模型设计。我们的目标是尽可能在满足需求的基础上让用户模型更为简单并更容易维护。

直接连接是指将待测系统实现中的方法和事件直接声明成Cord配置中的Action（既可以依次声明也可以使用"action all"提取所有公用方法），这样生成的测试代码会直接调用待测系统的方法，并期待待测系统的事件。这种连接只能被运用于测试托管代码实现的系统，并且要求待测系统提供的API足够进行测试。

测试适配器是则是位于测试用例和待测系统之间的一层。当创建测试适配器时，Cord配置文件中的Action并不是待测系统的方法和事件，而是适配器中的方法与事件；那么生成的测试代码也调用适配器中的方法，期待适配器发起的事件。适配器的作用是把这些方法调用转换为待测系统的方法调用。当待测系统是非托管代码实现，或者测试用例与待测系统需要远程通信，或者存在一个中间层用于抽象模型和测试（比如控制待测系统的用户界面）时，这种连接被广泛运用。适配器由于避免了对托管测试代码的依赖，从而极大的增加了spec Explorer的适用范围。

模型开发者与适配器或者待测系统的实现者基于Action的接口规范打成一致，即可并行工作。接口实现只要在需要运行生成的测试代码时能够执行即可。对于模型开发者来说，他们可以先把Action声明成abstract，即可在没有适配器或者待测系统实现的情况下进行建模。