SilkPerformer的十一宗罪(下）

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