Total Throughput（附带测试总结）

loadrunner中Total Throughput (bytes)所统计数量是，在整个测试过程中，从服务器返回给客户端的所有字节数，与发送请求的字节数无关！那么 average  Throughput 的含义也一样，所以在测试上传一类的接口时，通过lr是无法统计的。

我的处理方法是用lr记录时间，手动记录发送过去的字节数。

一、最主要的收获:
1.学会了拿lr当作一个真正的工具使用，获取自己想要的数据。代码可以写的很漂亮，但是最主要的还是适用，测试的最初阶段就是陷入了这个误区。
2.脚本中能不检查就不检查，能不参数化就不参数化，因为这些或多或少都会影响真实的效率。比如访问是否成功，lr自己会判断，不用再去用web_get_int_property(HTTP_INFO_RETURN_CODE)多此一举的判断一遍。

二、遇到的主要问题和解决办法：

1）cookie问题，问题描述：
测试的系统一定时间段内仅支持5个用户同时登录，于是用lr测试并发或者不测并发，仅仅测几个用户，多测几次就把服务端弄死锁，登录不进去了。

解决方法：用cookie模拟，在init时用web_add_cookie 加上登录后每次访问时所需带的cookie值，cookie值的获取方法就是用一些浏览器插件，比如火狐的httpfox，或者google浏览器的一个什么插件。

缺点：cookie也是有实效的，今天的cookie也许明天就没有了，或者服务端重启下，这个cookie也失效了，所以可能每天要在浏览器里手动捕获一次这个cookie，而且为了测试的有效性，还有清理服务端，重新，又得重新手动获取，然后copy，paste，甚是麻烦！

尝试的解决办法：能否实现测试20个vuser时，只有第一个vuser登录，其他vuser都是用第一个vuser登录的cookie呢？于是我就写了一个函数，把第一次登录后的cookie传出来，以后的vuser使用web_add_cookie加上这个cookie。但是我不知道要怎么判断哪个是第一个vuser，最终该方案难产。用vuser_id不知道能否实现？

2）web_submit_data使用过程中遇到到问题：当参数中含有文件地址时，web_submit_data提交的header比浏览器提交的header多出了一些字符，导致提交失败

代码如下：
        web_submit_data("UploadFile",
           "Action=http://kortide.tonidoid.com/dyn/ecloud/r.php?proxyMethod=UploadFile",
           "Method=POST",
           "EncType=multipart/form-data,uft-8",
           "RecContentType=application/json",
           "Mode=HTTP",
           ITEMDATA,
           "Name=path", "Value=e:\\test2\\file{filename}.doc",  ENDITEM,
           "Name=uploadFile", "Value=e:\\test1\\test4M.txt","file=yes","ContentType=application/octet-stream" ,ENDITEM,
           LAST);
这样一个简单代码，最初一直通不过，但是这个接口如果在浏览器中用post方法提交，又是正确的，找了很长时间原因，开发人员也帮忙，最终比对lr提交的数据和浏览器提交的数据发现，用lr提交的数据header长度比浏览器直接提交的header长度长了几个字符，导致服务端一直在等待这几个字符，从而失败。
浏览器提交的header：
POST /dyn/ecloud/r.php?proxyMethod=UploadFile HTTP/1.1
Content-Type: multipart/form-data; boundary=---------------------------7d025e2b16b064e
Cache-Control: no-cache
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Connection: Keep-Alive
Host: wuling.tonidoid.com
Cookie: tonido-login-seed-10001=fb225103-d624-4167-8bfa-19882c6967d8; tonido-login-hash-10001=1032200b93ab95337447ca83f089a2485cdddd12; tonido-login-user-10001=wuling@tonidoid.com
Content-Length: 2235
tonido-relay: 1,0
X-Forwarded-For: 210.22.155.237

-----------------------------7d025e2b16b064e
Content-Disposition: form-data; name="path"

e:\test.c
-----------------------------7d025e2b16b064e
Content-Disposition: form-data; name="uploadFile";filename="test4M.txt"
Content-Type: application/octet-stream

用lr提交的headr：

POST /dyn/ecloud/r.php?proxyMethod=UploadFile HTTP/1.1
Content-Type: multipart/form-data; boundary=---------------------------7d025e2b16b064e
Cache-Control: no-cache
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT)
Accept-Encoding: gzip, deflate
Accept: */*
Connection: Keep-Alive
Host: wuling.tonidoid.com
Cookie: tonido-login-seed-10001=fb225103-d624-4167-8bfa-19882c6967d8; tonido-login-hash-10001=1032200b93ab95337447ca83f089a2485cdddd12; tonido-login-user-10001=wuling@tonidoid.com
Content-Length: 2335
tonido-relay: 1,0
X-Forwarded-For: 210.22.155.237

-----------------------------7d025e2b16b064e
Content-Disposition: form-data; name="path"

e:\test.c
-----------------------------7d025e2b16b064e
Content-Disposition: form-data; name="uploadFile";filename="e:\test1\test4M.txt"
Content-Type: application/octet-stream

开发人员解释说，是因为php的http协议不支持这种全路径导致，而且标准协议也是不支持全路径的，因为不安全。忘了告诉大家，服务端接受接口处理的入口时php写的。

尝试解决办法：我想既然标准协议不支持全路径，那么lr能不能避免这种事情的发生呢？我试着用    web_add_header("Content-Disposition", "filename="e:\test1\test4M.txt");但是无济于事。也弄了很长时间，最终难产。

最终解决办法：没办法让开发人员改了代码。

3)：我写了很多通用函数，最后发现，不用这些通用函数其实也挺方便的，用的话每次还得加到globals.h中，一忘记加，就出红字，不爽。