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\).*succeout 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对测试自动化的支持极为原始。要想搭建出健壮而实用的测试模块,还是不用SilkPerformer为好。