自动化测试Case管理框架开发一

需求与目标：
在大多数针对UI的软件自动化测试中，通常要设计到Case的管理问题。当你已有一个实现了的并经过完整测试的测试实例(Test Case)时，如果下面两件事情发生了变化，那么你会采取什么样的应对策略呢？1. 目标程序的操作逻辑发生变化，如按钮的移动或是删除；2. Test Case底层实现框架发生变化，如有了新的功能更强大的框架但是与原来的框架不兼容。当我们在考虑应对策略的时候，主要是从项目时间和迁移代价上出发。对于问题1，目标程序的操作逻辑变化，毫无疑问你的Test Case逻辑也必须跟着变化，这好比软件的需求发生变化，软件也需要变化一样。而对于问题2，我们有多种策略来处理这样的问题。策略一、重写Case，在Test Case规模较小的情况下这种方法可能比较实用，而且我也相信大多数人都在使用这样的策略，但是随之而来的是Test Case的稳定性和项目时间进度问题，很难保证说迁移后的Test Case能完整的符合测试需求，因此这也导致了我们不在非不得已的情况下是不会随意迁移底层平台的，但是这样又同样产生了覆盖率的问题。原有的底层平台无法应付某些特殊的场景，就会导致我们的Case遗漏问题。策略二、封装并建立自己的测试框架，这种策略也是目前比较流行和实用的方法，通过对业务逻辑的抽象和封装，从而产生模块化的Case组件，一旦底层发生变化我们只要修改底层的这些Case组件就能很好的适应变化。这样的方法在实现上确是比重写要好很多，而且也适应大规模的Test Case。但是这种方法依然存在问题，硬编码和缺乏灵活的测试数据是大问题。首先我们的Test Case都是用代码写，没修改一次都要编译一遍；只有简单的几组测试数据支持测试过程，面对框架级迁移依然是很困难。策略三、使用测试工具，目前已有很多工具可以用于辅助测试，比如行为录制回放，生成测试脚本等，这样工具的好处就是不需要书写Test Case代码就可以进行测试，而不好的地方就是可控性和适应性太差，覆盖率和稳定性也很难保证，如更换了不同的分辨率就可能导致Case的失败。
当我们在对Test Case设计过程进行分析的时候，我们发现对于Test Case来说测试逻辑是最重要的，也是具有抽象独立性的，也就是说软件的操作步骤(这里我们提到的所有测试都是针对有UI界面的软件)。任何软件操作步骤在某一版本都是固定的，而且即使不同版本也有很多相同的地方。而底层的实现平台是最为不重要的，有很多优秀的平台不断的出现，他们可能擅长于解决某一方面的问题。那么是否能有一种方法即能保存这些测试逻辑，又能不被平台所限制呢？那就是Case Management Framework。
当初，我在设计这个框架的时候就非常注重对测试逻辑的保护。因为我发现测试逻辑是基本不变的东西，如何使底层实现来适应测试逻辑是Case Management Framework(简称CMF)主要解决的问题。

分析与设计：
如何去保护测试逻辑，我们需要两样东西：脚本与控件查找方式。任何的测试逻辑都是由一系列的行为动作构成的，这些的动作可以通过一组抽象的脚本语句来描述，所以我们先需要抽象出适合的脚本。对于任何行为动作最终我们都要落实到控件操作上，那么如何根据给定的信息查找控件就是关键的方法。所幸的是，对于所有优秀的底层框架都会提供这样一个功能即根据给定的信息查找目标控件。那么有了这样两个工具之后，我们就有了明确的目标来设计CMF。抽象一套脚本语句，设计查找接口。在进入实际的设计和开发之前，我们还需要考虑一件事情，所有的工具都是有缺陷的，CMF也是一样不肯能覆盖到所有的测试情景。那么我们就需要一种方法来扩展它，那就是客户代码扩展，即Case code。Case code具有的好处是其强大的灵活性和可调试性，它可以弥补CMF遗漏的或过于复杂的情景。那么这样CMF又多了一项工作，那就是兼容运行脚本Case和Code Case。

那么，我对CMF的基本前期分析和设计就是这样，在下一篇中我讲谈到实现设计和其中遇到的问题。