按照我的方法,
开发脚本时 无需考虑 哪些功能点应该合成一个case,因为脚本的设计不依赖于case ,
如某一Action 设计时,读取数据驱动字段,
如果 录入数据不为0,则录入数据,
如果该记录有提示,则执行验证 ...
下面说的什么我没看懂，但是上面说的开发脚本无需考虑功能点的结合，这点我不是很同意，我们做功能测试多数都是结合业务流来做的，这样的话一个脚本下来一般都是多个操作，而单独测一个功能的话还是很少就是登录也要带上个退出，单独测一个功能点，感觉有点像是性能测试吧，做做并发什么的，看看某些典型操作的响应时间。。。
呵呵，我也刚学测试····喷下口水 sdlkfj2 原帖由 lovelovecat 于 2007-6-10 22:38 发表 http://bbs.51testing.com/images/common/back.gif
"自动化测试的每个用例的起始页面和退出页面一般都是同一个页面，从哪里开始，在哪里结束。" 这是为什么呀
这样是为了保证每次测试的初始环境是一样的 原帖由 huangcm 于 2007-2-5 13:01 发表 http://bbs.51testing.com/images/common/back.gif
经过我几天来的研究，我觉得从自动化测试用例来说，与手动区别还是不大的，beginnl说的这点很赞同：
自动化测试的每个用例测到的会有好几个功能点。
手工测试的每个用例测的可能就是具体的一个功能点。
但 ...
我也来谈谈感受,如上所说,针对每个action(我叫它基础action),考虑到它会被调用到的情景,加入不同的判断和验证,的确是比较好的框架结构,我当初也是这样做的.但是后来越来越不大对劲,因为某个基础action的前提环境可能是多样化的,比如说大概有10种,但是你编写大部分基础action的时候可能也只想到了7,8种,如果你已经把这些基础action副本应用到脚本中,组合成一个个用例后,会逐渐发现可能还有几种情况没有考虑到,而这时候的维护量是相当大的,而且组合基础用例不如直接写脚本那样条理清晰,一目了然,如果任意一个脚本中多了个判断什么的,可能还要找半天.所以说,我觉得是比较理想化的,还不如直接写的方便.
个人意见,仅供参考
很实用的贴子.
很实用的贴子.希望能看到更多更好的贴
顶 学习 mark~~ 对,这个问题,才是我们一直在思考的问题,真希望以后多看到, 台困惑了 顶一下 :) !我觉得设计自动化用例的时候，我们是否可以借用其他行业所说的“模块化设计”；我们可以单独分别为登陆、增加、删除、修改设计用例，然后只要组装起来就可以正常使用了！本人的观点而以 这帖子不错。主题很有用，讨论很深入。受益了~~ 转一篇资料：
转自：http://blog.chinaunix.net/u/21908/showart_258297.html
针对自动化测试用例的要求(requirement of test case for autotest
一，目的明确，有具体的输入输出
Purpose
以前的目的
Verify if the CDR is right about user order tvod program
修改后
Verify that while TVOD ordered from EPG CDR record created correctly
Input data and out put data shall be described clearly
二，有明确的步骤和检查点
Step
1.MC sigon
2.Enter 'TVOD' at EPG
3.Select one TVOD program
4.Order the tvod program
5.Check the cdr that build by AC
/opt/utoss/accountcenter/chargedata/online/succ
1.Enter 'TVOD' at EPG
2.Select a TVOD program
3.Order the tvod program
4.Open cdr (file) which exists on AC under
/opt/utoss/accountcenter/chargedata/online/succ
5.Check the value pending after tag "7/" matches the service ID
Clear steps and check point
三，准备要求是数据的准备
Precondition
1.OSS is normal
2.Billing of TVOD had config at OSS
3.Have one MC
4.VSLR/PSC/EPG/USC/AC is normal
1 Find or create IPTV subscriber refer to TC IDxxxx1, give UserID
2.Find a TVOD from OSS refer to TC IDxxxx2
3.Get "ServiceID" from "Service" table on OSS db by giving UserID
4.Install new subscriber on MC refer to TC IDxxxx3 or sign onMC refer to TC IDxxxx4
Not environment preparation, it should be detail data preparation to meet this test case needs. (it’s better to refer to test case ID, if it’s too difficult, at least give the test case set path.)
四，预期结果必须细化
Expected Result
1.User can order the tvod program
2.AC can write the cdr after user order the tvod program
/opt/utoss/server/accountcenter/chargedata/online/succ/
3.Every tag of the cdr is right
1. AccountCenter can write the cdr after user order the TVOD program, there should be a record about the user order the TVOD
2. Check specified field 7 of the cdr, it should eauql to the serviceid of the user
Clearly describe the expected result which matched the output data descript in “Test Purpose”
case 2:
Purpose
NMS support browse chassis inventory inside CO
Verify that chassis inventory shall be browsed on NMS CO Physical View, and chassis id from inventory is matched with chassis id from blade of the chassis
1. Login NMS
2. Open one physical view
3. Browse chassis inventory inside CO
4. Check the result and compare these data with real information
Step
1. Login NMS
2. Open one real CO's s physical view.
3. Browse chassis inventory on CO physical view, select any one chassis, get its ChassisID (SRS or HLD must provide enough information such as “look and view” or operation flow, comments by Norten)
4. Browse blade inventory on CO physical view, select any one blade of selected chassis, get its BladeIP
5. Telnet on the selected blade, get chassis id from /usr/local/rss/chassis_id file
6. Compare the chassis id from inventory with chassis id from blade
Precondition
Master Chassis Manager run normally
NMS run normally
Some NE run normally
At least one real CO and NE is running or create a real CO
Expected Result
1. NMS support to browse chassis inventory inside CO
2. User can check chassisPhysicalID information.
1. NMS support to browse chassis inventory inside CO
2. The chassis id from inventory is matched with chassis id from blade.
(Notice: The chassis id from inventory is in Hex format, the chassis id from blade is in Dec format) 就一句话:VBS要有类的继承和多态就好了~~~ 留个脚印 这篇帖子讨论的还是比较深入，希望更多的大牛参与讨论 很精彩！！！ 原帖由 yzbin097 于 2007-12-29 15:40 发表 http://bbs.51testing.com/images/common/back.gif
:) !我觉得设计自动化用例的时候，我们是否可以借用其他行业所说的“模块化设计”；我们可以单独分别为登陆、增加、删除、修改设计用例，然后只要组装起来就可以正常使用了！本人的观点而以
我在实际的自动化测试中，应用的也是模块化设计，感觉前期的模块化设计投入较大，但是后期的使用效果还是很明显，维护成本也相对可控。 模块化设计 对最初设计的是否 合理全面 要求很高，一旦设计不合理，对后面的使用也是有很大风险的。
