函数可变参数
简单来说, 测试框架是对一个被测试产品操作的一个封装和抽象.
比如说一个创建用户的界面, 测试框架封装了具体的ＵＩ操作，向上提供了一个接口 createUser(userData).
这样调用者就不需去关心具体的页面导航, 输入数据, 提交表单这些繁琐的操作, 一个调用就创建好了用户.

假如我们已经确定要提供CreateUser这样一个接口, 那么接下来的问题是, userData应该是什么样的? 一般来说, 这里有三种选择
1) 用参数序列. 比如
createUser(name, age, phoneHome, phoneOffice)
这种方法简单直接, 适合简单的数据,大量的数据就不太合适了. 而且VBS不支持变长参数序列, 后续版本如果要增加参数那就简直是恶梦.

2) 用Map/Dictionary
用Dictionary解决了上面的问题. 即能描述复杂数据, 且不会出现增加参数导致接口变化的问题. 比如
Set map = CreateObject("Scripting.Dictionary")
map("name") = "Jack"
map("age")=21
map("phone") = Array("12334", "22223")
createUser(map)

Dictionary完全能解决问题, 就是"卖相不太好". 它显得有点啰嗦. 一个调用竟然要写5行代码.对于我这样的完美主义者来说很难接受.

于是某些聪明人想出了新的主意, 就是用字符串来描述这个Dictionary结构. 参见 http://www.advancedqtp.com/knowl ... ptional-parameters/
这个方法很棒, 我也一度使用过这个方法, 但是它的问题是描述能力有限. 对于比较复杂数据结构就无能为力了. 最终, 有了下面的方案三.

3) 基于字符串解释器
本质上, 此方案同2), 只是字符串的数据描述能力得到了大幅的加强,  能够描述更为复杂的数据结构. 比如上面例子里的参数可以描述为下面的字符串.
"{name=Jack; age=21; phone=[12334, 22223]}".
看 到这样的字符串, 你一定想起了另外一个大名鼎鼎的东东"JSON", 没错. 这个方案语法部分借鉴了JSON, 不过根据QTP测试框架开发的实际, 大幅简化了. 只支持Map/Array/String三种类型. 你不用担心其描述能力, 根据我的实践, 这三种类型的组合可以满足绝大部分要求了.

所以最终版本的创建用户调用就像下面的样子. 看上去是不是好很多呢 :-)

createUser(PM( "name=Jack; age=21; phone=[12334, 22223]"))
' PM means parse map

关于TestData
其 实这个字符串的引用范围不仅仅是解决"函数可变参数". 在某一个方向上, 它为DataDriven Test里的TestData提供了一个通用的解决方法(另为一个方向是QTP的datatable). (题外话: Manager和boss都喜欢DataDriven这样的概念 ).

比如我现在开发的测试框架. 它提供了一个针对所有Input Data Screen(Edit Page, Wizard)的统一调用接口. 像下面的样子.
ScreenGo(screenName, screenDescription)
可以想见, screenDescription会是很复杂的, 必须需要字符串解释器这样的工具.

总的来说, 这个工具增强了测试框架对输入数据的处理能力, 更设计出更简单易用的接口. 所以我共享出来, 希望能对你有帮助.
[attach]67778[/attach]

关于解释器本身
这是一个递归下降的程序, 阅读起来并不难. 而且注释良好.
其语法描述如下.

map :      {}      {members} members :      pair      pair; members pair :      NULL # NULL means nothing. NULL will be ignored, e.g "a=1;;b=2"      string = value #string will be trimmed array :      []      [elements] elements:      NULL # NULL means nothing. NULL will be ignored, e.g "abc,,def"      value      value, elements value :       NULL # ""       string       map       ary string :      char chars char      normal # any char but not \ [ ] { } ; , =      \[      \]      \{      \}      \=      \;      \,      \\      \s # (32)      \t # (9)      \n # (10)      \r # (13)

注: 本文同时发布在QTP讨论区 http://bbs.51testing.com/thread-371986-1-1.html

出现的问题
FTA的schd project是我对TA反思后的第一个项目。本来以为经过前段时间充分的总结，这个项目不会有什么问题。但是项目结束后发现，最大的问题是架构部分代码（非测试逻辑本身的代码）竟然有多次重构。

理想情况下，在开发过程中，对系统核心部分的重构应该是很少的，因为这种重构的风险非常大。FTA是一个比较小的项目，所以还能控制不出问题。如果项目比较大，或者test suite比较多，情况就不好说了。

分析原因
1）testcase定义和执行流程一开始就考虑不成熟。
framework里关于如何执行testcase部分进行了多次重构。部分原因是framework并不全是我设计，还要兼容已有的系统，所以存在束手束脚的地方。也有部分原因是我对执行过程的考虑不成熟。

总的来说，这个问题可以通过通用框架TAS的成熟在一定程度上解决。

2）开始阶段考虑的testcase种类太少
因为开始阶段考虑的testcase种类太少，所以随着新的testcase的加入，不得不修改已有的架构来适应新的需求。比如library会进一步的细分，test parameter的格式定义。。。

如何提高
将来需要注意增强分析阶段的能力。特别是在系统还未成形，只是脑袋里的一个模型的时候，如何在其基础上进行分析，判断，进化出更好的架构。这种分析的步骤是这样的
   a）细致的问题分析
   b）把实际的问题转化为脑袋里运行的“程序模型”（借助纸和笔）
   c）在这个运行过程中，找出已有架构不满足当前运行要求的地方
   d）在这个运行过程中，综合已有testcase，发现需要共享的library

进行积极的预判。在开始阶段，可能所有人都不明白到底要自动化多少caes。对于设计者来说，要从case重要性和自动化可能性的角度判断未来可能会自动化的case，并在设计之初就在一定程度上把他们考虑进去。

即使如此，我还是要再次明确”考虑得少“并不是一个绝对的错误。前面已有文章反思考虑得太多会引起的问题。所 以，这是一个需要小心平衡的事情。这需要更多的经验积累才能达到做一个项目的过程中“即不会出现overdesign，也不会频繁的重构已有的代码”

做FTA项目收获蛮多，大多数想法都在TAS里实现了。还有一些觉得重要的零散的东西，记录于下。

• 在分析testcase的时候，把所有的元素分成测试参数，测试逻辑和测试环境。
• 用关键词加相应的数据来描述一个testcase
• 把测试准备和测试验证点分成不同的方法来实现
• 把不同的验证点分成不同的方法来实现
• 每一个testcase有一个setup和clean方法来处理对环境的准备和清理
• Testcase要薄，把实际的访问代码放在library层
• 如何兼容非data-driven的testcase

如果选定了要自动化的目标，--通常来说是一个data-driven的case集合，下一步就是要考虑如何实现的问题。

首先从软件架构来说，自动化测试项目不算复杂，对于大多数情况，一个自动化测试项目的实现由三个主要部分构成

• 自动化测试框架
• TA testcase
• Library

 

自动化测试框架

测试框架提供了testcase的管理，测试任务的管理，测试报告的生成等内容。取决于自动化测试项目的大小，可以从提供最简单的testcase管理和运行的小框架，到基于数据库，包含内容丰富的报表的大框架。

可以看到，测试框架提供的功能和具体的testcase无关。所以，寻找/提供一个通用的测试框架是可能的，用这个框架来管理某一个产品所有的自动化测试用例。

 

Test Automation TestCase

自动化测试用例(TA testcase)包含了实现测试逻辑的代码。

在实现测试用例的时候，有一个技巧。那就是自动化测试用例的抽象层次和datadriven testcase的抽象层次保持一致。首先试图用关键词加相应的数据来描述一个testcase，然后在testcase里提供一个能够解释这些关键词和数据的“解释器”。

在实现测试用例的时候，我个人的经验是要尽量维持testcase这一层的代码比较“薄”。最好只有描述了测试逻辑本身的代码，减少访问实际的底层设施的代码。这样的好处

    1）是提高了底层代码的通用性，

    2）是在测试逻辑不变的情况下，访问GUI的代码在未来变化的可能性比较大，把访问GUI的代码放在Library层，可以维持testcase代码的稳定性

 

Library

library提供了访问测试产品本身，或者其他一些基础设施的API，比如访问DB，remote server, etc.

Data-driven test has two major parts, one is a number of sets of data, and the other,  a test logic. One set of data here is called a test case, and all the test cases form. a test suite.

Data-Driven test are considered one kind of the most suitable test to be automated. This is because Data-driven test have two special characteristics, which make it able to achieve a high mark in terms of input-output ratio, relative to none-data-driven test.

The first one is that all the test cases can be automated once the test logic has been implemented and at least one test case is able to run with it, because one test logic serves for all test cases.

The second one is, the execution of one test case is absolutely independent to another. That is to say, theoretically, if running a test case multiple times, the test result of a test case is always the same no matter in what a order it is executed..

As nearly all datat-driven testcaes shares those characteristics, to implement a framework to deal with the common things is meaningful. This is exactly why TAS(TestAutomationSystem) is invented. 

====================================================
数据驱动测试有两个主要部分构成，一个是一套数据集，另外就是测试逻辑。一套数据在这里叫做一个testcase，而所有的数据一起构成一个testsuite。

数据驱动测试被认为是最适合自动化的测试之一，这是因为数据驱动测试有两个重要特性，使得它能具有较高的 投入产出比。

第一个特点是，一旦成功自动化一个testcae，那么所有的testcae都能被自动化起来。因为所有的testcae都使用同一个测试测试逻辑。

第二个特点是，每一个testcase的执行是和另外的testcae完全独立的。理论上，在多次运行同一个testcaes，无论它是以什么样的顺序运行，结果都应该是一样的。

因为几乎所有数据驱动的测试都具有这样的性质，实现一个自动化框架来处理这些公共部分是有意义的。这也就是TAS产生的原因。

========================================
tas 1.1 released.

1. simplify create_everything.py
2. more robust in executing testtask, adding exception handling
3. other improvements