以下只是测试框架的一点设想，需要以后修改；
这套方案的最终结果是实现测试自动化，但是因为目前人力、实力有限，只能逐步完善设想中的功能；最
终的目的是要实现define the driver——定义驱动测试。
本文的自动化测试以MI公司的QuickTest professional 为例
1定义：
Services function :业务函数
TestCase(测试用例)：是能够从头至尾独立执行的最小测试单元
测试框架的设想
1.1Services Function 的分类及分类原则
Service Function的颗粒大小需求不一，靠自己来掌握，总之应该是尽量少的Service Function满足所有Case
Function的需要
Common level¬——所有项目测试都可以使用的函数，比如验证小数精度、写测试结果到报告等等。
Common level是公用的函数库，不需要经常修改，因此可以编成DLL文件，供所有的测试脚本使用。
使用语法可以这样：
‘------------------------------------
Set object=createobject(“”)
Call object.funciton “”
‘------------------------------------
High level¬——各项目专用的测试用例，是为专门的测试项目而设置的，但是这些Services Function
不能单独作测试，必须配合更高一级的Test level才能使用
Test level¬¬——Test level可以这样理解：是对某一个用户来说，为了完成某项工作和业务，时间从
头至尾相对连续的一组操作。
Test level并不是测试用例，但是它的颗粒大小却决定了其复用程度，因此需要仔细分析每个TestCase
的业务逻辑，将相同的Test Level services function 总结出来。
Test level的组成：
Function
Step ‘测试所要进行的操作
Validation ‘验证测试的结果
Return result ‘返回测试的结果，validation的验证结果也应该通过这一部分的函数写入到result report中
End function
1.2 Test case 和Test suite
Test Case：测试用例。可以这样理解：是一组人为了完成某项工作和业务，时间从头至尾相对连续
的一组操作
Test suite: 是一个相同工作性质的工作部门人员，为了完成某项工作和业务，时间从头至尾相对连
续的一组操作。
Test case和Test suite的意义：
1、大量的Case，肯定是分模块存放的。否则就难以查询和维护、修改。
2、Test Case和Test level \high level service function的互相调用关系可以通过insight sources这个工具来查询。
3、Suite相当于一个Case模块，里面包含很多个Case；比如测试用户管理的，都放在一个Suite里，测试设
备管理的，放在另一个suite里。
1.3TestCase的分类原则
一般复杂Case，要牵扯到好多个模块的功能的，但是要看它的主要测试点是什么，然后按这个测试
点所属模块，来确定这个Case归属哪个模块的。
有依赖关系的Case，是合并成一个Case，还是保留独立？运行起来有依赖关系,倾向于合并成一个C
ase，合并的好处是运行方便，但是出错时要再区分是那个小Case的错误;分开的话，就相反，运行不方便，
但出错时比较明确哪个错了。
如果A是建10万个用户，要花1小时的时间，那你还会放在一块嘛，肯定是倾向分开成小Case，不然
B出错了，你还得再重头跑ABCD，测试人员会气死的！所以运行麻烦、容易出错、时间较长的小case，还
是保持独立，只要跟测试人员写好说明文档，让他们知道正确的运行方法，就可以了
如果合成一个case，我应该把它放到哪个suite里呢 因为它横跨了几个页面，都是测试点，不好划分
啊。放在那个Suite里啊，那都可以啊，或者你想独立一个suite也可以啊，无所谓的，只要你运行结果有正
确记录，不会漏掉丢失就可以了。
测试环境可以通过重新导入数据来恢复，这样就可以将一部分运行时间长、但是又有依赖关系的Te
st case分离出来，避免总是要从开头进行测试。
一个Test suite里的用到的lib和OR都是相同的。
1.4测试用例和Services Function命名规则
类型 名称
Test case 项目名_TC_name
test level services function 项目名_TL_name
high level services function 项目名_HL_name
common level services function CL_name(不应包括项目名，因为此类函数是公用的)
2工作方式
并非所有的测试用例都可以用自动化来完成，因此需要对用例进行挑选，选择合适的用例作为自动化测试用
例。记住！自动化测试的成本是巨大的，一般来说，一个脚本运行6~7次才算收回成本，因此不可寄予自动
化测试过高期望。
2.1选择自动化测试用例
2.1.1不适合自动化测试用例的情况
定制型项目（一次性的）。为客户定制的项目，维护期由客户方承担的，甚至采用的开发语言、运行
环境也是客户特别要求的，即公司在这方面的测试积累就少，这样的项目不适合作自动化测试。
项目周期很短的项目。项目周期很短，测试周期很短，就不值得花精力去投资自动化测试，好不容易
建立起的测试脚本，不能得到重复的利用是不现实的。
业务规则复杂的对象。业务规则复杂的对象，有很多的逻辑关系、运算关系，工具就很难测试。
美观、声音、易用性测试。人的感观方面的：界面的美观、声音的体验、易用性的测试，也只有人
来测试。
测试很少运行。测试很少运行，对自动化测试就是一种浪费。自动化测试就是让它不厌其烦的、反反
复复的运行才有效率。
软件不稳定。软件不稳定，则会由于这些不稳定因素导致自动化测试失败。只有当软件达到相对的稳
定，没有界面性严重错误和中断错误才能开始自动化测试。
涉及物理交互。工具很难完成与物理设备的交互，比如刷卡的测试等。
2.1.2适合自动化测试的情况
自动化测试之所以能在很多大公司实施起来，就是有它适合自动化测试的特点和高的投资回报率。
产品型项目。产品型的项目，每个项目只改进少量的功能，但每个项目必须反反复复的测试那些没有
改动过的功能。这部分测试完全可以让自动化测试来承担， 同时可以把新加入的功能的测试也慢慢地加入到
自动化测试当中。
增量式开发、持续集成项目。由于这种开发模式是频繁的发布新版本进行测试，也就需要频繁的自动化
测试，以便把人从中解脱出来测试新的功能。
能够自动编译、自动发布的系统。要能够完全实现自动化测试，必须具有能够自动化编译，自动化发布
系统进行测试的功能。 当然，不能达到这个要求也可以在手工干预的情况下进行自动化测试。
回归测试。回归测试是自动化测试的强项，它能够很好的验证你是否引入了新的缺陷，老的缺陷是否修
改过来了。在某种程度上可以把自动化测试工具叫做回归测试工具。
多次重复、机械性动作，将烦琐的任务转化为自动化测试。自动化测试最适用于多次重复、机械性动作
，这样的测试对它来说从不会失败。比如要向系统输入大量的相似数据来测试压力和报表。
需要频繁运行测试。在一个项目中需要频繁的运行测试，测试周期按天算，就能最大限度的利用测试脚
本，提高工作效率。
2.2编写Test case和Test level
分析Test Case的业务，将Test Level services function 的颗粒从Test Case中识别出来，尽量做到用少的Service
function来实现测试业务。
2.3搭建测试框架
依据测试框架，在下一节中提到。依次填入测试框架的内容。
2.4执行测试并记录bug
这时就可以开始执行测试。测试结果应该自动被记录在测试报告中，而不应该一遇到BUG就停止——除非必须
