如果你的产品或者项目是数据相关，这里我个人使用的一种TestPlan和Case的分类方式，

1. 数据的正确性(Data Correctness)
1. 数据的正确性包括来源的正确性（比如对比数据库），数据计算后的正确性（针对数据取出后有加工的情况）
2. 数据的显示(UI)
1. 数据描述信息的准确性
3. 数据显示的逻辑(UI Logic)
1. 数据的排序、搜索及其它相应的操作

Stores|DBTables用于比较SQL Fetching Data与Stored/Golden Data之间的差异。Stored/Golden Data可以由scrīpt改写，实现动态变化，但是SQL Fetching Data却不可以。

TestComplete未开放此处的接口不知道有何考虑，但从使用者的角度而言十分不方便。比如我有这样一个测试用例：“比较clone数据是否存在不一致？”。由于每次测试时clone数据都是新的，或者说ID变化了，所以很难通过SQL去定位这个新加入的数据，当然可以通过排序选出最新，但是终归不完美。

对于测试数据库，我们不妨借个无关紧要的地方存储新生成的ID。这样SQL便可以读取变换中的ID。当然这种方法仅限于满足以下条件：

1. 你可以控制测试数据库，或者存在某个Table可以放入这样的信息（上例中的ID）
2. 当你生成新数据之后，你可以从某处(UI,DB,...)得到需要的信息（上例中的ID）

如果满足了这样的条件并且需要更改SQL实现比较的时候便可以借助测试数据库实现动态的变化。

XPath的[\d+]其实是相对于其父亲节点的位置

换句话而言, /html/div[4] 其实是/html/(div[4]) 而不是(/html/div)[4]

默认安装目录一般会位于Program Files (x86)下，这个会导致链接oracle数据库的时候无法识别TNS Service Name，因为oracle把"()"作为特殊字符。

  var  w1;
  var  item1;
  w1 = Aliases.xxxx;
  item1 = w1.wItems.Item("xxxx");
  var  w2;
  var item2;
  w2 = Aliases.yyyy;
  item2 = w2.wItems.Item("yyyy");

  var x1 = w1.ScreenLeft + item1.TextBounds.Left + item1.TextBounds.Width / 2;

  var y1 = w1.ScreenTop + item1.TextBounds.Top + item1.TextBounds.Height / 2;

 

  var x2 = w2.ScreenLeft + item2.TextBounds.Left + item2.TextBounds.Width / 2;

  var y2 = w2.ScreenTop + item2.TextBounds.Top + item2.TextBounds.Height / 2;

  Sys.Desktop.MouseDown(VK_LBUTTON, x1, y1);

  Delay(500);

  Sys.Desktop.MouseX = x2;

  Sys.Desktop.MouseY = y2;

  Delay(500);

  Sys.Desktop.MouseUp(VK_LBUTTON, x2, y2);

盲人摸象，各有各的说法。测试类型就是这么一头大象，而我们则是其中的某类“盲人”。从程序是否需要执行的角度来看，有静态有动态。从代码是否对测试者透明的角度来说，有黑盒有白盒。从测试流程上而言，则有unit testing, smoke testing, feature testing/function testing, end 2 end testing, regression testing，还有鉴于公司和职位特殊性我接触比较少的integration testing, system testing和L&P testing，另外还有屡建奇功的ad hoc testing。
前两个分类角度，其区分很明显，刚刚接触测试的人其实也很容易想明白。而流程上的分类，如果没有在测试岗位工作一段时间的话，个人感觉其实很难明白分类的背后原因以及它们的存在价值。这里我把对熟悉的几种类型整理了一下，如果有理解的偏差，大家一起探讨。

顺带一提的是，流程上的分类，我个人觉得也可以理解为测试目的（motivation）上的分类，它们尽管都有保证质量的大前提，但是实现的价值是不一样的。

熟悉的几种基于流程分类测试类型：

unit testing （单元测试）：

实例：一个积木（团圆出品）搭建的城门，每块积木质量的好吗？

开发往往是建积木完了搭积木的过程，而每一块积木建好后就需要测试，这一测试往往都是白盒测试，而这一测试阶段一般是开发人员直接介入的，也有部分公司会投入具有编程经验的测试工程师在其中以期取得更好的测试效果。它的测试目的，其实就是积木本身质量的检测，还无直接关乎积木搭出来的作品的效果。

smoke testing （烟盒测试）：

实例：一个积木搭建的城门，搭建好后，吹口气，倒了吗？

刚接触时，觉得这个名字很有意思，并未理解其背后含义，只是朦朦胧胧感觉这是测试前的测试。其实烟盒测试最早应该源于管道测试或电子产品测试，前者是通烟以检查泄露，后者则是通电以检查引起电路起火冒烟的短路。从这一术语来龙来讲，烟盒测试就是最基本的检查，是测试前的基本测试。对于软件测试，它往往是对整个产品由代码编译形成新版本可执行程序之后的一次基本检查，以便后期测试工作的展开。比如图形化的计算器程序，那么起码你双击程序的图标之后，计算器界面就应该出来了，至于数目加起来对不对，我就不管了。但其实对于软件测试而言，smoke testing的程度往往取决于测试者自己的判断，并未框定。所以我们明白它的目的即可，为了以后测试成功展开而进行的测试。

feature testing/function testing （功能测试）：

实例：一个积木搭建的城门，搭建好后，它是个城门吗？

这个是我接触最多的一类测试，却也可能是我最难界定的一类测试。从字面理解，其实它便是实现主体功能测试的一个阶段。但真正理解它，可能还要结合后面的回归测试来说，因为它的测试目的，只是为了确保当前这个项目所提出的一些功能的测试，而不包含原有平台或者说原来项目所涉及的各种功能。从一个侧面来理解，它的测试很有可能针对的是版本控制系统里的一个branch编译后的可执行程序。

end 2 end testing (端端测试---个人翻译的术语，仅为理解）：

实例：用建好的城门，连上其它人建好的护城河等等等等，能变实实在在的城堡么？

一个积木搭成的城堡，它的搭建往往不是由积木与积木直接搭建而成，而是由基于积木搭成的一个个小功能模块组成，譬如城门，譬如护城河...而端端测试正是为了把这些小功能模块最终互相接上而进行的测试。它存在的时间往往介于功能测试和回归测试之间。它的测试目的为的就是看看各个功能模块是否连通。

regression testing （回归测试)：

实例：一个积木搭成的城堡，你给它换了个城门，一它还是个城门吗？二它影响了城堡的其它地方吗？

无论从英文还是中文字面上去理解这种测试，一开始似乎都不会很清晰，其实它说白了也是功能上的测试，但区别于功能测试，它是对既有功能的测试。好的产品服务一般都会有后续的版本更新，这便给了回归测试诞生的可能性，新的更新除了符合它标注的新功能外，有没有给老的其余功能带来影响。回归测试的目的便在于此。

ad hoc testing （随机测试）：

实例：一个积木搭成的城堡，你随便的挑个细节查查看。

随机测试字面上很好理解，就是随机进行的测试，无指定目的的测试，测到哪儿是哪儿。但是随机测试找的问题往往是以上任何一种测试方式难以发现的，比如说，当你浏览了一个页面之后，你又手工输入URL进了另一个与该页面无直接关联的页面，发现该页面工作不正常，这种测试用例在以上的任何一种测试类型中都不可能出现，但却是有可能存在的问题，背后原因可以是原来两个页面背后不同的开发小组碰巧用了同一个cookielet来实现不同的功能。所以随机测试的目的可以说其实就是没有目的，但对于有经验的测试者来说，他们的随机测试往往相当高效，背后应该存在一些用例的设计模式，可惜测试领域还没有类似GOF出品的针对测试用例的设计模式。

（下期节目预告：我所接触过的自动化工具）

作为一年实习和一年正式工作的软件测试工程师，终于在理论和实践上都有了一些积累，现在开通此处blog专为记录我的测试历程。