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里大量的隐藏<input>，JavaScript合成的XML，HTTP Header里携带的额外信息，通通暴露在测试员面前。哪怕让记录器录下的一个测试用例勉强可以被重用，我们都要阅读上千行代码，引入几十个变量。新的发布往往让上百个测试用例当调。SilkPerformer还没有debugger。调试一个用例动则花上几小时，因为页面上的错误往往不能简单对应记录下的代码。很多人修改代码时，干脆重新记录。这不是浪费是什么？不是折磨是什么？
SilkPerformer没有一个活跃的社区支持。要得到点技术帮组很难。到Google上搜BDL, 搜SilkPerformer，都得不到多少有用的信息。搜索返回的页面大都和培训或营销有关。Segue自己有个技术支持站点，可惜不对外公开。不知道别人怎么样，反正我用BDL的时候觉得自己是头21世纪的恐龙，孤独，茫然，感觉被时代淘汰。
总的来说, SilkPerformer对测试自动化的支持极为原始。要想搭建出健壮而实用的测试模块，还是不用SilkPerformer为好。
