SilkPerformer的十一宗罪(下)

SilkPerformer的库函数难以使用。BDL的库函数彷佛由虐待狂精心设计,专门用于折磨人的神经,污染人的双眼。SilkPerformer的函数库的特色是WYGINWYG--所得非所猜。如果哪位老大心理强健,觉得WebFormValueSet()设计得还行,不妨再欣赏一下另外一个函数。比如说,搜索字串。简单?呵呵,Segue的天才程序员们可不这样想。这个函数的signature就足以让每个正常人得心绞痛。
StrSearchDelimited(

out sTarget: string,

in nMaxTarget: number,

in sSource: string,

in sLeftVal: string allownull,

in nLVOccurrence : number,

in sRightVal : string allownull,

in nRVOccurrence : number,

in nFlags: number ): boolean;

Segue难道不知道这个世界上有种东西叫regular expression么?这个问题带出SilkPerformer的又一宗罪:

SilkPerformer的regular expression支持就是一个笑话。首先,BDL支持的regular expression少得可怜,就只有., *, +, $, ^, [a-zA-Z0-9], [^], 和\。公平地讲,这些有限的功能也可解决很多问题。可惜Segue不知道怎么写出一个合格的regular expression引擎。 哪怕在一个10多K的网页里搜索"*\([aA]action|requeset\).*successful"都能花上30分钟。顺便说一句,\(代表grouping,和通行的规则刚好相反。在SilkPerformer里集成一个开源的regular expression引擎又不难。也许Segue觉得开源的质量不如他们自己的代码。
SilkPerformer不支持对HTML DOM 对象的操作。嘿嘿,我没有说错,你也没有听错。虽然SilkPerformer号称Web应用的测试工具,但我们没有任何方法读写DOM。俺能想到的唯一原因是Segue鄙视测试员,觉得做测试的不能处理DOM。要拿到HTML页面某一部分,我们必需使用下面这个让人得脑癌的函数:
WebParseHtmlBoundEx(

out sResult: string,

in nMaxResultLen: number optional,

in sLeftBoundary : string optional,

in nLeftOccurrence : number optional,

in sRightBoundary : string optional,

in nOptions: number optional,

in sFrame: string optional,

out nBytesParsed : number optional);

或者这个:

WebParseTable(

out sResult: string,

in nMaxResultLen : number,

in nTablenNum: number,

in nRow: number,

in nColumn: number,

in nOptions: number optional,

in sFrame: string optional,

out nBytesParsed : numberoptional);

每次看到这些愚蠢的函数,我都禁不住怒从心头起,恶向胆边生。用这种函数编程的测试员们怎么可能不士气低落?怎么可能不怨声载道?怎么可能不自伤身世?怎么可能不问候Segue程序员的上下九族?我们怎么知道要选取哪个frame? 我们怎么知道选取哪个table number? 我们怎么知道什么边界值保证返回我们希望得到的值?怪不得我们不得不依赖SilkPerformer的记录器。怪不得我们的效率如此底下。从这些函数的sigature来看,SilkPerformer内部多半也没有使用DOM解析。稍微复杂点的就要求我们用那些没人理解的边界设置函数。当然,SilkPerformer6.5号称提供DOM解析。当我第一次读SilkPerformer6.5的手册时,眼珠子差点弹出眼眶:要解析一段HTML代码,我他妈得在得到HTML代码前在一个他妈的XML文件里设定解析规则!也就是说,我们不能用诸如getHTML().getDOM().getElementById()这种通行的方法。我们必需告诉SilkPerformer, yo man,I want a fucking table。然后再调用getHTML().getTable()。如果这不叫变态,还有什么叫变态?嗯,俺其实漏说了一点。SilkPerformer提供所谓基于页面的函数(page-based functions)。这些函数让我们能读取诸如link, title,button一类的HTML元素。问题是,我们也就能读取link, title, 和button。Form呢?Table呢?Div呢?Span呢?Options呢?SilkPerformer是不会放弃变态的机会的:我们只需要在递交一个URL申请之前用下面这个白痴函数设定要读取得元素。为什么Segue的程序员会觉得正常人可以使用这些函数,已经成了不解之谜。
WebParseDataBound(

out sResult : string,

in nMaxResultLen : number optional,

in sLeftBoundary : string optional,

in sRightBoundary : string optional,

in nOptions : number optional,

in nDocNum : number optional,

out nBytesParsed : number optional );

SilkPerformer的开发和debugging极其困难。一个复杂的web应用里,HTTP Transaction携带的信息远远超过一个用户关心的东西。Form里大量的隐藏,JavaScript合成的XML,HTTP Header里携带的额外信息,通通暴露在测试员面前。哪怕让记录器录下的一个测试用例勉强可以被重用,我们都要阅读上千行代码,引入几十个变量。新的发布往往让上百个测试用例当调。SilkPerformer还没有debugger。调试一个用例动则花上几小时,因为页面上的错误往往不能简单对应记录下的代码。很多人修改代码时,干脆重新记录。这不是浪费是什么?不是折磨是什么?
SilkPerformer没有一个活跃的社区支持。要得到点技术帮组很难。到Google上搜BDL, 搜SilkPerformer,都得不到多少有用的信息。搜索返回的页面大都和培训或营销有关。Segue自己有个技术支持站点,可惜不对外公开。不知道别人怎么样,反正我用BDL的时候觉得自己是头21世纪的恐龙,孤独,茫然,感觉被时代淘汰。

总的来说, SilkPerformer对测试自动化的支持极为原始。要想搭建出健壮而实用的测试模块,还是不用SilkPerformer为好。

你可能感兴趣的:(搜索引擎,笑话,编程,JavaScript,Web)