如何设计异常测试用例
如何设计异常测试用例
09-10-12 &匿名提问 发布
单元测试的对象是软件设计的最小单位——模块。单元测试的依据是详细设描述，单元测试应对模块内所有重要的控制路径设计测试用例，以便发现模块内部的错误。单元测试多采用白盒测试技术，系统内多个模块可以并行地进行测试。单元测试任务　　单元测试任务包括：1 模块接口测试；2 模块局部数据结构测试；3 模块边界条件测试；4 模块中所有独立执行通路测试；5 模块的各条错误处理通路测试。　　模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下，其他测试才有意义。测试接口正确与否应该考虑下列因素：　　1 输入的实际参数与形式参数的个数是否相同；　　2 输入的实际参数与形式参数的属性是否匹配；　　3 输入的实际参数与形式参数的量纲是否一致；　　4 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同；　　5 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配；　　6调用其他模块时所给实际参数的量纲是否与被调模块的形参量纲一致；　　7 调用预定义函数时所用参数的个数、属性和次序是否正确；　　8 是否存在与当前入口点无关的参数引用；　　9 是否修改了只读型参数；　　10 对全程变量的定义各模块是否一致；　　11是否把某些约束作为参数传递。　　如果模块内包括外部输入输出，还应该考虑下列因素：　　1 文件属性是否正确；　　2 OPEN/CLOSE语句是否正确；　　3 格式说明与输入输出语句是否匹配；　　4缓冲区大小与记录长度是否匹配；　　5文件使用前是否已经打开；　　6是否处理了文件尾；　　7是否处理了输入/输出错误；　　8输出信息中是否有文字性错误；　　检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源，应仔细设计测试用例，力求发现下面几类错误：　　1 不合适或不相容的类型说明；　　2变量无初值；　　3变量初始化或省缺值有错；　　4不正确的变量名（拼错或不正确地截断）； 　　5出现上溢、下溢和地址异常。　　除了局部数据结构外，如果可能，单元测试时还应该查清全局数据（例如FORTRAN的公用区）对模块的影响。　　在模块中应对每一条独立执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术。计算中常见的错误包括：　　1 误解或用错了算符优先级；　　2混合类型运算；　　3变量初值错；　　4精度不够；　　5表达式符号错。　　比较判断与控制流常常紧密相关，测试用例还应致力于发现下列错误： 　　1不同数据类型的对象之间进行比较；　　2错误地使用逻辑运算符或优先级；　　3因计算机表示的局限性，期望理论上相等而实际上不相等的两个量相等；　　4比较运算或变量出错；　　5循环终止条件或不可能出现；　　6迭代发散时不能退出；　　7错误地修改了循环变量。　　一个好的设计应能预见各种出错条件，并预设各种出错处理通路，出错处理通路同样需要认真测试，测试应着重检查下列问题：　　1输出的出错信息难以理解；　　2记录的错误与实际遇到的错误不相符；　　3在程序自定义的出错处理段运行之前，系统已介入；　　4异常处理不当；　　5错误陈述中未能提供足够的定位出错信息。　　边界条件测试是单元测试中最后，也是最重要的一项任务。众的周知，软件经常在边界上失效，采用边界值分析技术，针对边界值及其左、右设计测试用例，很有可能发现新的错误。单元测试过程　　一般认为单元测试应紧接在编码之后，当源程序编制完成并通过复审和编译检查，便可开始单元测试。测试用例的设计应与复审工作相结合，根据设计信息选取测试数据，将增大发现上述各类错误的可能性。在确定测试用例的同时，应给出期望结果。　　应为测试模块开发一个驱动模块（driver）和（或）若干个桩模块（stub）,下图显示了一般单元测试的环境。驱动模块在大多数场合称为“主程序”，它接收测试数据并将这些数据传递到被测试模块，被测试模块被调用后，“主程序”打印“进入-退出”消息。　　驱动模块和桩模块是测试使用的软件，而不是软件产品的组成部分，但它需要一定的开发费用。若驱动和桩模块比较简单，实际开销相对低些。遗憾的是，仅用简单的驱动模块和桩模块不能完成某些模块的测试任务，这些模块的单元测试只能采用下面讨论的综合测试方法。　　提高模块的内聚度可简化单元测试，如果每个模块只能完成一个，所需测试用例数目将显著减少，模块中的错误也更容易发现。
请登录后再发表评论!
以下内容为转载你要的宏在文章后半部分有教怎么做 不过只看后半部分可能不太好理解 最好从头看完自从泰坦创造了世界留下了守护者龙以及雅丽达发明了游戏机并推出了第一款游戏《Pong》之后，已经经过了很长时间。让游戏中的角色说话，在很长一段时间之中曾经是游戏制作人梦寐以求的技术。技术发展的脚步滚滚向前，文字、形象、声音终于三位一体地登场，塑造游戏角色的空间被瞬间放大了若干倍，游戏人物的表现力与电影名星站到了一条起跑线上，天才的游戏制作人们为之欣喜若狂。而且这三个塑造角色性格、特征的手段在可以预见的将来都将伴随着游戏行业不会有任何改变——直到全新的输出设备技术能让我们闻到远方飘来软泥怪味道的那一天。当然，解决了“怎么说”的问题之后，“说什么”才是体现人物性格的关键所在，也是软技术含量最高的部分。那个彬彬有礼的家伙会说“邦德，詹姆斯•邦德。”那个胸怀七星的肌肉男会说：“你已经死了。”麻宫雅典娜会说“对不起”八神庵会说“哈哈哈哈哈哈！”由此还可以上溯到你一生无法忘记的滴滴撒了地、加加不鲁根等等人民群众耳熟能详的名人名言醒世警句。那么现在，作为盗贼的你，还能容忍被赋予冷血般残忍的时候一言不发？作为圣骑士的你，还能容忍为他人牺牲的时候保持神圣的沉默权利？作为法师的你，还能容忍做面包的时候竟然不唠唠叨叨？等等！我知道你想说什么，自从wow被发现有宏命令以来，“我对XXX使用了恢复术，将在y秒后治疗xxx-xxxHP”这样的宏已经烂遍了大街，成为raid之中众人深痛恶之的垃圾信息供应商。这一类简单的宏除了令人厌恶的持久重复之外并没有带来太多的可能性，以至于不管是忧伤的暗影箭，还是气势磅礴的烈焰冲击，都只能在令人窒息的安静中进行。是时候改变这一切了，稍微复杂些的宏编写，将让我们拥有全新的空间展示角色个性，同时又可以避免重复为队友带来困扰。现在就开始，拥有自己的台词，结束在wow跑龙套的生涯。————例1 不会打扰队友的随机发言————*所有【】符号框起来的都是注释内容，勿写入宏里面。【1】 /script ayj1=&夜幕之下，没有怜悯的影子&;ayj2=&谁又能逃得掉，那股暗淡的哀伤&;suiji=random(10)【2】 /script if suiji==1 then SendChatMessage(ayj1) else if suiji==2 then SendChatMessage(ayj2)end【3】 /施放 暗影箭(等级 9)这是一个在网上可以找到的例子。关于第【1】行，我们要理解【=】等号的含义。编程中的等号与“等于”这个概念完全不相干，你可以理解【=】是一个装罐机，【ayj1=”夜幕之下，没有怜悯的影子”】就是把后面一段引号之间的内容，装进了一个标签为ayj1的罐头里（如你所想，ayj1正是暗影箭1的缩写），这个罐头我们将在稍后使用。中间的三个【;】属于必要格式，用来分隔三个相对独立的语句。同时我们使用了一个random命令，【suiji=random(10)】就意味着我们让系统产生一个1~10之间的随机数，并把这个数装进标为【suiji】的罐头里。第【2】行，【If XXX then YYY else ZZZ】的句式，是用来判断XXX是否成立，如果成立则执行YYY动作，如果不成立则执行ZZZ动作。这个【==】是连续两个等号，代表真正的“等于”的意义。【if suiji==1 then SendChatMessage(ayj1)】翻译成中文就是，让系统察看suiji这个罐头里面的东西是不是“等于1”，如果是，就SendChatMessage——让人物说出——ayj1这个罐头里面的内容。SendChatMessage命令请注意严格按此大小写拼写。当然，由于suiji罐头里面有可能装1~10之间的任何一个数，所以suiji很可能不会==1，于是执行下一步【else if suiji==2 then SendChatMessage（ayj2）end】，这里再次判断suiji是否“等于2”，如果等于2，人物将说出ayj2里面的内容。如果不“等于2”就结束这个语句。至于最后的end，必须和if配对出现，就像括号的左边和右边一样锁定中间的内容，说来话长，只需稍微试验几次就可以理解。至于最后的【3】行，记得同时打开宏编辑窗口和技能书，让光标停留在编辑宏状态，再按住shift点击技能书上的技能图标，系统会自动帮你写上这一行。这个三行的宏工作原理就是这样的：每运行一次，将把一个新的随机数装进suiji罐头，如果那个随机数是3~10，就没什么特别的事情，只是发出一个暗影箭，如果随机数恰好等于1，则人物会说出一句话，等于2说出另外一句话。把这个宏拉进技能栏，代替以前的暗影箭吧。一团团暗影箭在放出，人物在大部分时间里会保持安静，只是偶尔——各10%的情况下，会说出“夜幕之下，没有怜悯的影子”，或者“谁又能逃得掉，那股暗淡的哀伤”这样的句子来。想象一下在决斗中，当你以一发夜幕状态的瞬发暗影箭，或是气定神闲之后的炎爆决定胜负，再幽幽地给补上这么一句，全场是否会为之安静片刻呢？在raid中，你还可以调整第【1】行中【suiji=random(10)】那个数字10到30、40，这将更适合长时间大型raid环境。例1只是一个简单应用，用来让大家理解这一系列宏会用到的主要命令，实际上一旦你开始写自己的语录，你就会遇到这样几个问题：1、经试验发现，一个语句中的汉字太多，也会固定造成出错，这对创造力来说是无法容忍的限制。2、宏栏设定了256个字符的上限，换算成中文不过128个字还含标点，当你准备的发言字数稍微一多，加上语句编写的必要字符，就非常不够用了，让创作激情大打折扣。3、你可能会希望给一个技能准备2句以上的发言，当你准备的发言超过3句之后，例1中的第【2】行将变得非常晦涩绵长，而且要把能够运行的4句发言宏扩充到5句更是几乎不可能写正确。这一切问题将在下一期的例子中得到解决，我们将得到一个没有边界的创作空间，你可以为一个技能准备20句发言，只要你能够写得够精彩。或者你不满足于随机数的不确定性，希望精确地每隔若干次技能说一句话，或者按照一定顺序说出你准备的发言等等都可以实现。并且我们将看到在发言中引入对方ID、职业，让发言更具表现力的方法。请用今天的例子小试牛刀，再积蓄起你的创造力，从下一周开始，每个人将因为那些台词而无法忘记你！——隔壁王二原创——转载请注明出处————原载于《电脑商情报》——————第二期——————上回我们接触了台词宏的初步知识以及关键的编写思路。同时面临了三个问题，1、单句允许含有的汉字太少；2、每个宏允许的字符数太少；3、需要找到更简洁的编写方法。本期我们将首先解决字数限制问题。曾经有一些方法可以扩展宏字数，但1.7版之后似已不可用了。目前仅有某些大型插件可以提供超级长的宏，可惜不是每个人都愿意为了吹吹风在家里装台涡轮风扇发动机配八叶对转螺旋桨。实际上经多次试验我们发现，宏世界的罐头们保鲜能力是很强的。只要不退出wow，罐头里的内容将永远保存在内存里供随时调用。因此对字数限制，就有了这样的解决方法，以作者实际使用的宏为例：————例2 解决字数限制与引入ID————【新建第一个宏命名为  储存】【1】 /script zh1=&大阿图因宙半人马阿尔法星系中枢位面TS32行星泰坦世界风狼座投影面坐标 ID=%t 目标锁定完毕 召唤系统预热开始…&;【2】 /script zh2=&跨行星传送系统标定目标ID=%t erro31！目标性别无法判定… 切换至人妖类通道适配器 预计927毫秒后准备就绪…&;【3】 /script zh3=&跨行星传送系统标定目标ID=%t erro45！目标智力水平未达到行星团联合会教科文组织要求标准… 无法传送…请智力超标单位协助…正在盗取客户端参数修改权限…&【新建第二个宏命名为 召唤】【1】 /script z=random(3)【2】 /script if z==1 then SendChatMessage(zh1) end【3】 /script if z==2 then SendChatMessage(zh2) end【4】 /script if z==3 then SendChatMessage(zh3, ”party”) end【5】 /施放 召唤仪式显然用例1的方法我们无法做出这么多字数的台词，但现在我们制作了两个宏，一个专门用来储存发言内容，一个是执行语句，于是台词字数得到了无限扩展——虽然每一个限制了256字符，但只要需要，你可以写若干个储存宏。每次出家旅行杀人越货之前，登录wow之后，只需要把所有的储存宏执行一次，就可以完美保障你全天的台词需求:D例2的【储存】宏每一行都出现了一个【%t】，这个标识在任何情况下，都会被替代成为你选中目标的ID。比起例1，例2【召唤】宏显得更加简单明快并且很容易扩展，对五、六句台词的随机判断都可以很容易地写出来。得益于【储存】宏已经将三句话分别装在了zh1、zh2、zh3三个罐头。【召唤】宏只需要将z牌罐头装进1~3的随机数，再加上简单的判断，我们准备好的3段台词就会分别出现。假设你选定了一位叫做李渔村的玩家，而正好Z随机到了“2”——人物将会说出的台词就是【跨行星传送系统标定目标ID=李渔村 erro31！目标性别无法判定… 切换至人妖类通道适配器 预计927毫秒后准备就绪…】另外，【召唤】宏第【4】行与其他行有所不同，多出来的【,”party”】意味着这段话将对小队说出，【,”raid”】向全团，【,”guild”】自然是工会。你可以试着在所有SendChatMessage命令后面都加上这个参数看看效果。————例3 如何引入职业————【新建宏  储存2】【1】 /script ayj1=&夜幕之下，没有怜悯的影子&;【2】 /script ayj2=&谁又能逃得掉，那股暗淡的哀伤&;【3】 /script ayj3=&我放出一团流星雨落在你的头上，你会看见，前途黑茫茫&;【4】 /script cr1=&失去与得到，那是宇宙的规则。&;cr2=&比死亡更恐怖的……是缠绕&;cr3=&要知道你的处境！&;【5】 / script jsqA=0;jsqB=0【新建宏  缠绕】【1】 /script ZY=UnitClass(&target&);z=random(3)【2】 /script if z==1 then SendChatMessage(cr1) end【3】 /script if z==2 then SendChatMessage(cr2) end【4】 /script if z==3 then SendChatMessage(cr3..ZY) end/施放 死亡缠绕(等级 3)【储存2】里面的【1、2、3】行列和【4】行，展示了两种效果完全相同的储存方式，只是【4】行更节省字数一些。【5】行暂时放在那里，我们将在例4例5用到。关键在【缠绕】宏的【1】行，【ZY=UnitClass(&target&)】我们先用一个UnitClass命令，求得职业名称。求得谁的职业名称呢？是【(&target&)】——你正选定的目标。求得的这个名称将成为字符，被装进标为【ZY】的罐头里面。然后是【缠绕】宏的第【4】行，注意【SendChatMessage(cr3..ZY)】就巧妙在中间的那两个英文句号，其意义是让人物先说出【cr3】罐头的内容，然后紧接着——关键就是紧接着，没有换行、没有空格——说出【ZY】罐头里面的字符。于是当你选定一个盗贼，发出死亡缠绕——或者你愿意的任何一个技能——的瞬间，人物会说出“要知道你的处境！盗贼”这样惊人的语句来。如果你像黑夜一样长期混迹于BWL，你就会知道这是奥巴桑的台词，如果你像作者一样抵制大型副本，你就会觉得这句台词特别有见义勇为的气魄……再次提醒，Raid期间务必将【z=random(3)】的3改到20以上以免打扰队友。然后，还记得我们提到过的法师的唠叨吗？————例4按照顺序发言以及适度沉默————【1】 /script if jsqA==10 then jsqA=1 else jsqA=jsqA+1【2】 /script if jsqA==1 then SendChatMessage(zmb1)if jsqA==2 then SendChatMessage(zmb2)if jsqA==3 then SendChatMessage(zmb3) end【3】 /施放 造食术首先我们已经在【储存2】里面让jsqA（也就是计数器A）存了一个数字0在里面。所以前几次运行的时候，实际上执行了 【jsqA=jsqA+1】，这个语句意味着先把【jsqA】罐头的数字取出，加上1，再存回【jsqA】。就像图书馆的图书，每次回到图书馆都会增加一笔借阅记录一样，第【1】行每运行一次，【jsqA】都会累加1依次成为【2、3、4……】。直到它成为10的那一次，【if jsqA==10 then jsqA=1】就会发挥作用，让它再次变回1，实现了【jsqA】在1~10之间依序循环，而不像先前例子那样出随机数。第【2】行就好理解了，实际上只是把例2、例3中分行写的语句用英文分号分开，代替分行而已。可以用来节省宝贵的字数。例4的运行结果是，头3次做面包，会连续说出3句话，然后沉默7次，周而复始。你可以调整【if jsqA==10 then jsqA=1】当中的10改变沉默与说话的频率。如果设定为3就会每次都发言了。当然别忘了在储存宏里面定义【zmb1、2、3】的内容，可以参考这样：zmb1=”我真傻，真的，我单知道玩家没有食吃，会找法师要；我却不知道会有那么多”;zmb2=”我一大早起来出了门只见玩家满地都是，唯独没有法师了。大家都说，完了，怕是改弱了”;zmb3=”现在看果然是改弱了，%t，可怜我还在这里做面包呢……”——如此反复，你能想象在旁边等你做面包的人是什么表情吗？最后是一个综合了我们这两期宏知识的完美例子。——例5  随机并顺序着——【1】 /script sj=random(10);if jsqB==3 then jsqB=1 else if sj==1 then jsqB=jsqB+1end【2】 /script if jsqB==1 and sj==1 then SendChatMessage(ayj1)if jsqB==2 and sj==1 then SendChatMessage(ayj2)if jsqB==3 and sj==1 then SendChatMessage(ayj3) end【3】 /施放 暗影箭其中【2】行的【if AAA and BBB then CCC】意味着AAA与BBB要同时成立，才会执行CCC——任中一个不成立都不执行CCC。因此这里实现了用1~10的随机数【sj】来控制所有语句，【if sj==1 then jsqB=jsqB+1】决定了 【jsqB】只有10%的概率累加。【if jsqB==3 and sj==1 then SendChatMessage(ayj3)】决定了人物只有10%的概率说话。因此不但由随机数决定是否发言，而且能保证每次发言按照一定的顺序不重复地进行。最后的最后，这么费力编写出来的宏可千万别丢了，记得时常备份才是。“通用宏”保存在：World of Warcraft\WTF\Account\你的帐号\ macros-cache.txt“某角色专用宏”保存在：World of Warcraft\WTF\Account\你的帐号\你的服务器\某角色ID\ macros-cache.txt一些注意事项：1、把宏的图标拖到动作栏上即可使用，最好在按键设置里设置快捷键。2、储存功能的宏必须先于执行功能的宏运行，否则尽管执行宏编些毫无错误，系统也会毫不犹豫地报错。出错之后首先检查运行顺序和两种宏当中罐头名称的一致。3、务必确保所有命令的大小写正确，以及在语句中使用英文标点。中文标点会被看作中文字处理，只能在引号之间作为字符内容使用。4、CWOW只支持中文法术名称。系统不会对错误的法术名称报错，只是不执行。Shift+鼠标点击技能标签，将自动输入正确的施法语句。自1.7版本之后，不提供技能等级系统将自动施放最高等级的技能。5、每一段【/】之后的语句应当写在同一行中，注意不要有多余的回车。有时候太长的语句会被自动换行，上一行露出一段空白，那只是显示问题。最好在txt文件中编辑完成后粘贴入wow调试。6、一个宏执行多个动作几近邪道，1.10版之后似乎便不可行。——————附送一些异常简单又异常实用的宏——/施放 真言术 盾/script TargetUnit(&player&)选定友方目标则给目标盾，选定敌方或不选定目标则给自己盾，因为不需手动切换，在决斗中非常有用。/script UseContainerItem(1,1)/script TargetUnit(&player&)这是根据同样原理，给友方或自己绷带，需要将绷带放在1号包1号位置，请试验之。/script TargetUnit(&player&);CastPetAction(4);TargetLastEnemy();术士地狱犬不必改变目标就可以对自己吞噬魔法的宏。/script UseInventoryItem(17)使用副手装备栏物品的宏，其意义在于通过宏可以对副手物品的使用动作设置快捷键。把17改为13、14即为两个饰品栏物品。————————————————————全文7000字的宏教程到此终于结束了，深夜中作者回想起当年看他人编写传奇外挂脚本的情景，一切游戏的乐趣，终究还是取决于游戏的人在寻找什么乐趣吧。wow和那么多其他游戏在那里，不管你扮演的是游戏中的角色，还是现实中真正的你自己。文字的可能性和文字本身的力量，从来没有像今天一样被扩充到如此大的程度。发挥你的创造力和真正的游戏精神吧，请相信我，从你键盘下流淌出来的创意，从你人物口中说出的话语，将比对面那个总是通宵刷装备一身花花绿绿的家伙，更让人印象深刻。——你仍然有保持沉默的权利，但你所说的，终将使你与众不同。——隔壁王二原创　原载于《电脑商情报》　转载请保持全贴完整————其他作品《其实你不是跑龙套的——wow台词宏深入研究》nga  mop《天下生意出我辈——王二给您侃网游与广告学理论》nga  mop《用三个艺术指导网游命名事业》nga  mop《上天入地 眼开八荒 网游ID纵横谈》nga  mop《2016 E3大展报道 十年后的世界游戏格局综述》nga  mop获奖小说节选《永恒之树的战争诗篇》《墨尔基阿德思的无尽旅程》文艺视频《痛苦系术士全教程 墨尔基阿德思的无尽唠叨》《痛苦与快乐的终结 墨尔基阿德思的奇异旅程》见blog  ——
有插件能突破字数限制，做出超长的宏那就是SuperMacro我这里有一个，你可以下载了杀毒后试试。&BR/&附件：&a href=&/browse/download.php?path=/22/36/50/.7362723.zip&filename=supermacro3_14a.zip& target=&_blank&&supermacro3_14a.zip&/a&
请登录后再发表评论!
我以下说的内容都来自，文章中的方法主要针对金融系统，不知道和您的系统特点是否一致，建议您自己看下全文~       当前案例设计人员对异常案例设计方法没有形成统一认识，业内也很少有相关介绍，在项目中以藏案例设计全凭案例设计人员的素质和经验。下面介绍三种已经在实践中应用的方法：常识设计法、规则设计法和系统设计法，并给出相应的异常案例设计实例。1 常识设计法对立寻找是指基于常识进行反向寻找，找出不符合常识的条件或关系；然后进行抽取，得出异常测试案例设计标准；最后根据异常测试案例标准，进行异常案例编制。1.1 实例1) 栏位只能输入数值的测试基于常识可知1、2、3等等都是数值，进行常识对立寻找，可知a、bb等字母都是数值的对立面，可提取异常案例标准：该栏位不允许输入字母。根据这条标准，设计人员可以设计输入字母的异常案例。另外，数值的对立面有很多，比如*、#等字符也是非数值，也可设计这样的异常案例。测试常识对立寻找的越多，异常测试案例就可以设计的越多。2) 输入字符串的测试基于常识可知对于字符串输入时其长度不能超过字符串定义时的最大长度，进行常识对立的寻找，可知字符串超过定义的最大长度即为常识对立。设计人员可根据此条标准来进行超长字符串输入的异常案例。3) 边界值的测试针对边界值测试理论，知道每个数据都需考虑大于、等于、小于三种边界情况。举例来说，某金融系统要求给子公司拨款时最少不能少于10元，最大不能超过300000元，根据边界值测试理论可设计拨款9元、300001元的异常案例，以考察系统控制的正确性。4) 身份证号的测试对于存在身份证号的测试，身份证号只有15位或18位是一种尝试，只要是非15位和18位的号码都不是正确的身份证，是常识的对立。可以据此提炼标准，设计长度不符合常识的身份证测试异常案例。2 规则设计法规则设计法是一种较高阶的测试案例设计方法，是指测试人员依据业务规定、业务制度、业务知识等进行案例设计的方法。该方法基于业务理解，根据业务理解提炼出相应的业务规则，案例设计人员可根据业务规则转化为异常测试案例设计标准，进行有效的异常测试案例设计。业务知识获取是指案例设计者从业务制度、业务规范、业务传统等获得尽可能多的业务相关知识。知识的获取可能是海量的，所以要从中寻找筛选适合的业务规则。业务规则提炼是指案例设计者基于获知的业务知识提炼出适合的规则。有了规则，就可导出异常测试案例标准，设计异常案例。在这个过程中，知识的获取是基础，业务规则的提炼是关键。2.1 实例1) 交易时间规则的测试金融系统都有明确的交易时间规定，比如有7×24小时、5×12小时交易支持的，根据不同的业务交易时间规定，提炼出交易时间规则。例如当前各个银行为客户股票买卖而设立的第三方资金存管系统都有这样的交易时间规定：上午9：30~11：30，下午13：00~15：00。案例设计人员可以设计在9：00前、11：30后、13：00前、15：00后客户发起业务的案例，验证系统是否可以控制非交易时间的交易。2) 交易权限的测试金融系统对交易权限有严格规定，比如业务规定对于现金类交易只有现金柜员才可以操作，主管柜员、普通柜员都无此权限，可提炼业务规则“只有现金柜员可做现金类交易”，推导出异常案例设计标准，即非现金柜员不允许做现金交易。据此，可以设计主管柜员、普通柜员执行现金交易，以验证系统是否对交易权限进行了合理的限制。3) 客户办理业务前提的测试客户来银行办理业务通常有前提要求，如办理存款业务时，必须在银行开立一个账户；客户进行网上银行交易时，必须先成为网银签约客户。可根据业务知识提炼规则，如“只有网银签约客户才可以进行网上交易”。设计未签约客户网上交易的异常案例，判断系统是否可准确识别。3 系统设计法系统设计法是指案例设计人员依据系统概要设计、详细设计、开发方案等和系统设计相关的逻辑和知识进行案例设计的方法。该方法对案例设计人员要求很高，案例设计人员要对系统的逻辑处理、设计思路、系统结构等有很清楚的了解。基于对系统的理解和分析，从系统处理逻辑中提炼出相应的系统设计规则来指导案例设计。系统知识获取是指案例设计人员从系统开发方案、设计文档、接口规范、数据库设计等获知系统相关设计逻辑和处理规范。系统处理规则是指系统在功能处理是必须严格执行的逻辑规范；案例设计人员基于获知的系统知识提炼出符合系统设计规范的规则，是系统运行时必须严格遵循的处理规则。根据这些规则，提炼异常案例设计标准，依据标准设计相应的异常案例。3.1 实例1) 系统账号类的测试金融系统中往往会设计各种各样的账号，比如储蓄账号、保证金账号、证券账号等，这些账号的设计规范和逻辑依据各个系统自身设计来确定。以建行第三方存管系统为例，客户的保证金账号按照4位8888+3位券商编号+8位券商开户序号+1位校验码进行设计。可以提炼如下规则：保证金账号必须为16位；保证金账号组成必须为8888+三位券商编号+8位券商开户序号+1位校验码。比如针对第一条规则，可以提炼“只要长度不是16位的账号就一定不是保证金账号”的标准。在案例设计时可以设计14位或17位或2位的账号，验证系统是否有相应的错误的提示。2) 系统接口的测试金融系统的服务渠道很多，系统之间接口比较复杂，可从接口规范中进行系统知识获知。仍以建行第三方存管系统为例，建行保证金转账业务可在柜台办理，也可通过网银、电话银行、手机银行办理。从接口设计文档中提炼如下规则：保证金转账时必须输入保证金账号、保证金密码、转账金额；保证金账号必须为系统存在的账号；转账金额输入必须符合规范。比如据此可推导出异常案例设计标准；不是系统存在的保证金账号就不允许转账。根据该标准，可以设计非法保证金账号进行转账，也可以设计已经销户的保证金账号进行转账，验证系统是否正确进行了控制。3) 系统响应时间的测试金融系统对系统响应时间有明确的设计和逻辑规定，比如前台柜员提交交易后不可能无限制的等待，如果超过一定时间限制，系统要提示柜员交易超时，请重新发送或其他相应信息。例如前台发起交易后响应时间设计为30秒，如果后台30秒没有响应，则前台要超时报错；如果前台无响应或退出或出现其他处理情况，则认为系统设计不合理，存在缺陷。同一系统前后台调用超时、不同系统调用超时、同一系统不同模块间调用超时都是测试案例设计需要关注的内容，超时后系统的处理也是重点要关注的内容。以测试ATM系统客户转账交易为例，假如系统中逻辑设定客户转账后45秒要有下一步操作，如果客户无操作，系统要将卡锁定，并在ATM屏幕给出提示。据此推导出ATM转账后45秒内不进行活动则要锁卡的标准。可以设计超过45秒等待时间的异常案例，看系统是否可以正确锁卡。4) 系统异常状态的测试金融系统在某一模块或相关联系统状态异常时的设计也是案例设计人员需要关注的，比如同一系统某一环节或模块状态异常导致不能交易时系统的处理，或跨系统交易中关联系统状态不正常导致不能交易时系统的处理都是测试要掌握的内容。例如建行的重要客户系统，如果总中心状态不正常，则当天不允许业务签到，任何发起的交易都要禁止。案例设计人员提炼出“总中心状态只有正常时，才可以业务签到、办理交易”的规则，推导异常案例设计标准“总中心状态不正常不可以办理业务”。由此设计总中心为签退、日终时、批量备份等各种状态时进行业务签到或发起交易的异常案例，测试系统是否可以有效响应。4 小结系统设计法要求案例设计人员对系统设计和逻辑处理非常了解，设计人员要有一定的开发背景和知识，明确哪些内容可以提取规则，哪些内容需要测试关注。对案例设计人员要求很高，在实际操作过程中往往会存在系统开发文档不全或无法获知的情况，此时设计人员必须要研读代码进行系统知识获取。由此设计的异常案例质量较高，只要发现缺陷，一般都是严重或致命的，值得有条件的案例设计人员一试。需要说明的是此种案例设计要考虑测试实施时的难易程度，某些异常场景可能无法模拟，需要在案例设计时有所关注。
请登录后再发表评论!