但是在写了这篇文章后，因为工作原因没有用实践去验证文章里的思想，直到今天才有时间来温习以前的教训。今天来按实际来做时，发现了一个问题——用什么方式来划分test level service function 的颗粒呢？打个比方来说，我要写一个测试函数，实现以下功能：我要测试的是登录一个系统，打开一个页面，然后新建一条记录。因为还有其他的测试函数，肯定与这个函数有相同的代码部分，比如登录就是显而易见，但是还有一些代码肯定也是重复，而且是隐藏的，那么用什么方法把它们挖掘出来，细分的原则是什么？我实在想不清楚，需要大家的指点．文章里的一些内容取自别人的帖子或与同行的交流，所以只能算是半原创．
以下只是测试框架的一点设想，需要以后修改；这套方案的最终结果是实现测试自动化，但是因为目前人力、实力有限，只能逐步完善设想中的功能；最终的目的是要实现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，还是保留独立？运行起来有依赖关系,倾向于合并成一个Case，合并的好处是运行方便，但是出错时要再区分是那个小Case的错误;分开的话，就相反，运行不方便，但出错时比较明确哪个错了。 如果A是建10万个用户，要花1小时的时间，那你还会放在一块嘛，肯定是倾向分开成小Case，不然B出错了，你还得再重头跑ABCD，测试人员会气死的！所以运行麻烦、容易出错、时间较长的小case，还是保持独立，只要跟测试人员写好说明文档，让他们知道正确的运行方法，就可以了 如果合成一个case，我应该把它放到哪个suite里呢 因为它横跨了几个页面，都是测试点，不好划分啊。放在那个Suite里啊，那都可以啊，或者你想独立一个suite也可以啊，无所谓的，只要你运行结果有正确记录，不会漏掉丢失就可以了。 测试环境可以通过重新导入数据来恢复，这样就可以将一部分运行时间长、但是又有依赖关系的Test 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次才算收回成本，因此不可寄予自动化测试过高期望。
文章来源于领测软件测试网 https://www.ltesting.net/