PEX的全称是(Program EXploration)，是一款在.NET下可应用的自动化白盒测试工具，来自于微软研究院。PEX通过分析代码来自动生成测试用例。对于程序里面的每一行代码，PEX都会尽可能地生成合适的输入值来达到提高覆盖率的目标。同时PEX还会分析代码中的分支，生成覆盖更多分支的测试代码（输入数据）；PEX在执行代码的同时会监控和分析代码的控制流和数据流，了解程序的行为。每运行完单一个测试以后，PEX会选择一条在前面的测试中没有覆盖到的路径，并且尝试执行它。这一切都是约束求解算法来实现的，官方文档中提到的是一个叫Z3的约束求解器。因为PEX了解被测代码内部结构和行为，所以它不是一个简单地输入随机参数的黑盒测试工具。PEX不会尝试枚举所有可能的输入，事实上也不可能枚举完所有的可能输入。
这里说的边界不是说测试中常常看到的边界值，而是说明哪些事情应该是一个单元测试应该做的，哪些是单元测试不应该做的。 如果“单元测试”里面出现了以下的情况，那么它就不是一个单元测试应该做的 需要跟数据库打交道 访问了网络 跟文件系统有交互 它不能像你其他的单元测试那样运行 你必须要经过一些特殊的配置才能使它运行起来 但是不是说如果测试代码里面包含以上行为就不是一个好的测试；相反，这些行为对于测试来说都是非常有意义的。但是，我们需要把这些测试和“真正的”单元测试区分开来，那些真正的单元测试可以“独立”地运行，而不会依赖于其他外部的组件。这样的单元测试才是真正的对被测软件的测试，而不是对数据库是否连同并且运行正常，或者是网络环境是否良好的检测。这就是所谓的“正交性”。 这样做的好处是，单元测试不需要访问数据库，这样测试运行的速度会更加快；使得单元测试更加健壮，因为它与其他系统之间的耦合度降低了！
作为自动化测试的一种脚本技术，数据驱动技术在10几年前已经有人提出，并且沿用到现在。Nunit作为C#开发下的一种常用的单元测试框架，也是被广泛使用。但是对于单元测试，很多时候都是硬编码，虽然说用Nunit编写单元测试代码是挺廉价的，但是为什么不让自己的工作更加轻松，脚本更加灵活呢？ 我把单元测试的数据放到单独的XML文件里面，测试运行的时候就读取XML数据然后进行测试。由于我想做一个轻量级的单元测试，所以并没有把很多判断控制的语句写到一个单元测试里面，而是把有不同行为的测试写到一个脚本里面。例如期望结果都是成功的一类测试就写到一个脚本，包含同样错误的测试就写到另外一个脚本，尽管这样看起来并不是很高明，但是对于我的工作来说这是足够的了。
