如何在 LoadRu nner 脚本中做关联 (Correlation) 当录制脚本时，VuGen 会拦截client 端（浏览器）与server 端（网站服务器）之间的对话，并且通通记录下来，产生脚本。在VuGen 的Recording Log 中，您可以找到浏览器与服务器之间所有的对话，包含通讯内容、日期、时间、浏览器的请求、服务器的响应内容等等。脚本和 Recording Log 最大的差别在于，脚本只记录了 client 端要对server 端所说的话，而 Recording Log 则是完整纪录二者的对话。 当执行脚本时，您可以把 VuGen 想象成是一个演员，它伪装成浏览器，然后根据脚本，把当初真的浏览器所说过的话，再对网站伺服器重新说一遍，VuGen 企图骗过服务器，让服务器以为它就是当初的浏览器，然后把网站内容传送给 VuGen。 所以纪录在脚本中要跟服务器所说的话，完全与当初录制时所说的一样，是写死的（hard-coded）。这样的作法在遇到有些比较聪明的服务器时，还是会失效。这时就需要透过「关联（correlation ）」的做法来让 VuGen可以再次成功地骗过服务器。 何谓关联（correlation）？ 所谓的关联（correlation）就是把脚本中某些写死的（hard-coded）数据，转变成是撷取自服务器所送的、动态的、每次都不一样的数据。 举一个常见的例子，刚刚提到有些比较聪明的服务器，这些服务器在每个浏览器第一次跟它要数据时，都会在数据中夹带一个唯一的辨识码，接下来就会利用这个辨识码来辨识跟它要数据的是不是同一个浏览器。一般称这个辨识码为 Session ID。对于每个新的交易，服务器都会产生新的Session ID 给浏览器。这也就是为什么执行脚本会失败的原因，因为 VuGen 还是用旧的Session ID 向服务器要数据，服务器会发现这个 Session ID 是失效的或是它根本不认识这个 Session ID，当然就不会传送正确的网页数据给 VuGen 了。 下面的图示说明了这样的情形： 当录制脚本时，浏览器送出网页 A 的请求，服务器将网页 A 的内容传送给浏览器，并且夹带了一个 ID=123的数据，当浏览器再送出网页 B 的情求时，这时就要用到ID=123 的数据，服务器才会认为这是合法的请求，并且把网页 B 的内容送回给浏览器。 在执行脚本时会发生什么状况？浏览器再送出网页 B 的请求时，用的还是当初录制的ID=123 的数据，而不是用服务器新给的ID=456，整个脚本的执行就会失败。 要对付这种服务器，我们必须想办法找出这个 Session ID 到底是什么、位于何...
