使用winsocket+oracle(2-tier)测试遇到的一些问题
http://www.51testing.com/?uid-1800-action-viewspace-itemid-6506
问题一：
WINSOCKET协议录制脚本时，应用服务器动态端口问题。
现象：发现在访问应用服务器的公共端口后，服务器返回了一个动态端口，导致脚本再次运行时出现错误。
解决：关联。
1、使用函数lrs_save_searched_string。将访问公用端口后应用服务器返回的动态端口进行关联。然后再下次连接时，将脚本中录制的固定的端口改为新建的参数即可。
2、可以在树形脚本中，找到要关联的端口，点击右键，选择“create Parameter”,指定参数名，使用参数的socket、要参数化的Buffer、左右边界即可。
系统生成的函数为：lrs_save_searched_string( "socket0", LRS_LAST_RECEIVED, "Parameter1", "LB/BIN=PORT=", "RB/BIN=))", 1, 0, -1 );如果不指定左右边界，就会生成lrs_save_param函数。
3、lrs_save_param也可以，不过端口必须指定长度，对于返回的端口长度确定的可以使用。
如：lrs_save_param("socket0", LRS_LAST_RECEIVED, "oracleport", 57, 4);
问题二：使用lrs_save_param时，如何计算偏移量。
解决：1、在data.ws中，选择要计算偏移量的BUFFER,按F7，会出现EBCDIC Translation表，每行第一个字符的偏移量是本行最前面显示的数字，后面的依次累加就可以得到。
2、在树形脚本中，找到要计算偏移量的端口，右键，点击“go to offset”。
问题三：端口参数化后打印出来，不是对应的端口，而是作为字符打印出来了。
解决：使用lr_message_output函数，当时尝试了N次，都不成功，将参数打印出来，发现捕捉的不是端口号，最后才发现原来是参数的表示写错了。
查看：tools->general options->parameterization里使用的是< >,而我脚本中使用的是{ }。所以我打出来的是“{parameter}”,而不是我想要的“1878”
问题四：协议选择问题
现象：开始初步确定系统是三层结构，使用WINSOCKET协议录制脚本。发现在访问数据库的1251端口后，服务器返回了一个动态端口，导致脚本再次运行时出现错误。
分析：其实这里面有个错误，如果是标准的三层结构，录制的脚本是不会直接访问1251端口的，所以客户端应该有直接访问数据库的部分，此时不应该采取单个WINSOCKET协议，但由于没有经验，所以就努力地解决动态端口的问题。
后来解决了动态端口问题后，重新回放脚本，发现一些BUFFER发送了几百字节，但接收回来的为0，并且是很多连续的Mismatch，发送的和接收的相关很大。
如：vuser_init.c(84): lrs_receive(socket1, buf31)
vuser_init.c(84): Mismatch (expected 290 bytes, 0 bytes actually received)
查找附近的脚本，发现接收的buffer中很多都会出现：“ORA-01403:未找到数据”的错误。
最后结论：可以协议选择不正确。后面采取了winsocket+oracle(2-tier)协议解决。并且也没有了返回动态端口的问题。
问题五：SOCKET关闭问题
现象：在录制并回放脚本时并没有错误，但在controller迭代多次回放时出现，报错：找不到socket.
分析：在脚本中create socket0是写在INIT脚本中，而close socket0是写在ACTION脚本中，而INIT脚本只执行一次，在第一次运行时ACTION中已经关闭了此socket,再次迭代时，就会报错了。
解决：将close socket0放在END脚本中，在整个迭代过程中此 socket一起保持，不关闭
问题六：
在CONTROLLER中运行脚本时，有一台 AGENG总是报错，错误是脚本中ORALEXEC时的错误（具体不记得了）。由于脚本都一样，所以考虑是网络原因。 但三台AGENG中，有两台是同一网段。并且使用TRACERT进行跟踪，不同网段的施压机都是接在同一个交换机上的。
最后将AGENG机子上的HOST中都添加了数据库服务器，搞定。 不过有点奇怪的是：IP在前，主机名在前，居然不识别。
问题七 ：用QALOAD测试，整个ACTION是交易响应时间非常长，但包含的子交易（检查点的方式设置）的响应时间都很短。子项目的响应时间和与整个 ACTION的响应时间不相等的。后来设置时间戳，把整个ACTION中的事务记录下来，发现还是不相等。 最后，才发现原来是施压机和受测程序在不同的网段，并通过多个路由器，导致网络连接时间过长，不过QALOAD中没有看到细分图， 比较难分析。
问题八 ：由于网络的原因，疲劳测试运行24时都不在现场，等90个小时后去查看，发现有一个GRADUAL EXITING 的用户始终没有退出，不管是不是受测程序的问题，但总觉得要是选择STOP IMMEDIATLY会不会好些。
问题九：BUFFER的MISMATCH问题。
接收BUFFER时，报MISMATCH。有几种情况：
1、协议错误。我开始全部使用WINSOCKET协议录制，回放时，在查询ORACLE时全部报MISMATCH，并且在实际接收的BUFFER中出现ORACE错误---未找到数据。经查证，是由于客户端直接与数据库服务器通讯，而不是通过应用服务器来通讯，而录制脚本时只是监控客户端与应用服务器间的通讯，所以报错。
此时的MISMATCH在连续很多个接收的BUFFER中都报出。并且实际接收到的BUFFER字节为0。
2、传输时丢失（可能）。在测试时，遇到广播消息时，每次都报MISMATCH，期望字节为26，实际收到24,但每次都一样，可能是传输时丢失，也可能是实际收到的广播信息和录制时不同，这个不太清楚，不过不用理它就行了。
也可以指定接收字节的长度来解决，由于最后我删除了与广播相关的脚本，所以这些MISTATCH也就没有处理了。
3、实际的情况的确不符合。由于在发送的脚本中使用了参数，不同参数返回的内容是不同的，所以录制的接收和实际的接收不一致，这是正确的。
在代码开始时增加了函数：lrs_set_timeout(1,0);lrs_set_timeout2(1,0);将MISMATCH的超时从10秒改为1秒，就OK了。
fyi,
Beginning Winsock Programming - Simple TCP server
http://www.codeproject.com/KB/IP/winsockintro01.aspx
Beginning Winsock Programming - Simple TCP client
http://www.codeproject.com/KB/IP/winsockintro02.aspx
http://www.tenouk.com/Winsock/Winsock2example.html
http://www.powercam.cc/slide/218
http://apps.hi.baidu.com/share/detail/34919518
LR中点鼠标做关联(winsock协议)-Zee
http://www.51testing.com/?17369/action_viewspace_itemid_14091.html
