关于参数化与虚拟用户的疑问，请大家指点下

minervayl

关于参数化，我个人认为就是模拟实际用户的使用数据，尽量跟实际应用靠拢。

如果我需要测试一个网站的登录事件：
1.脚本录制完毕
2.参数化用户名及密码，但这个参数我只输入一个用户名及密码
3.添加50个虚拟用户，10个用户并发
4.执行测试

脚本跑过，没什么问题。
这里我就有个疑问
疑问1：我这就设置了1个用户名及密码，那么50个虚拟用户相当于都是用同一个参数，10个用户并发也一样。这样的测试结果会存在什么问题？

疑问2：如果我这里测试的是一个用户工作日志的提交过程，用户每天就只能提交一篇日志。参数化一个日志信息（同样登录只有一个用户及密码），10个虚拟用户并发，该用户下至始至终就只会有1篇日志。

那么参数化的意义何在？
有虚拟用户，何必还需要参数化？

mymagic

1、就是测试登录并发而已。
2、用多个用户登录、提交日志，就凸显出参数化的作用了。虚拟用户的登录用户名、密码不是参数化来的?

minervayl

回复 2# mymagic


1.10个虚拟用户，1个参数跟10个参数，有什么区别？

2.10个虚拟用户若都用1个账号密码测试登录，那么这个能称为并发么？这样的并发会不会存在问题？

   虚拟用户参数化后，用同样的用户登录，提交同样的日志，反复提交的都是同样的日志，这个日志记录到数据库就是一个字段，我理解为不断的插入同一个位置同样的字段。
   那么这样的虚拟用户，或并发，也会不会存在问题么？

3.10个虚拟用户，用同样的账户名密码登录后，在同样的日志提交处，输入同样的数据，到了集合点，并发提交，实际数据库内就能看到1条日志。这样的并发，有问题么？

还是对虚拟用户这个概念不是很懂。。。。。。

mymagic

1、10个虚拟用户，1个参数跟10个参数，有什么区别？
   本质上没区别。就好像10个人用同一款手机与10个人用10款手机的区别一样。

2、难道不是并发？只要你的系统支持用户多次登录就行了。
   虚拟用户就是用来并发的。

3、这个问题应该是你的程序有控制或者参数化的有问题，为啥非得用1个参数呢？10个虚拟用户用10个参数如果出错了还能知道哪错了呢。

zxc189891

你提的这个情况要看一个根本的问题，是你所测试的系统是否支持多个用户用同一账号登陆，像有的系统是限制了用户登陆，如果一个用户在其他地方再次登陆，会把上个登陆T掉，就如QQ一样。所以，真实的环境一般是不同的用户（即虚拟用户）用不同的账号（个人私有账号，用参数化导入）登陆，并发指的就是虚拟用户在同一操作，在同一时间上处理

19931024

看到楼主的困惑--参数化的意义何在？
我说下自己的看法
1、尽可能的模拟真实场景。
     为一个系统测试，我们需要完整的系统，生产环境下的软硬件配置、网络等。
     但是这还是不够的，假设对于一个登陆，可能用户ABC后台处理是不一样的，比如登陆要要校验用户身份，     并根据不同的用户采取不同的处理。
     这时候我们就要通过参数化，模拟真实环境下的用户比例。有多少普通用户，多少VIP...
2、将测试的输入散列开来，规避系统非正常处理
      比如，测试DB2的查询，并发1000个用户，使用同样的查询条件进行测试，由于DB2缓存机制，这样子是其实DB2只在数据表中，查询了一次。如果要真正的测试数据库的性能，就需要将测试，查询条件散列开来。
      再比如，还是登陆测试，一般系统都要有用户和密码校验，假如不允许一个用户多个终端同时在线呢？

这种散列在银行系统中还是比较常用的，因为用户，账户，卡，机构，柜员，都是密切的关系，
不可能一张卡，同时在300个ATM上取钱。

19931024

1-模拟真的测试环境
2-规避非正常输入照成的系统异常处理
    瓶颈不能在我们的测试数据

mr.bee

你可以简单的把这个理解为lr为各种业务系统考虑到的需要，用不上就不用也没关系

dionysus

测试的时候尽量和实际场景保持一致，一般用户登录系统时应用服务器都会到数据库中搜索相关数据处理做检查，判断状态是否合法，权限是什么样的，以便展示前端菜单等。
如果所有并发用户都是一个，首先实际场景中可能根本就不存在这样的情况，其次应用程序对数据库的操作上也会快很多，这样测试出来的结果是有问题的。

minervayl

感谢大家回复，茅塞顿开。
我理解最终还是要模拟现实场景，虚拟的只是操作步骤，最终还是要通过参数来模拟实现不同的业务流。

虽然可以不用参数化也能虚拟出那么多用户，但实际上性能测试出的结果，不止跟测试程序有关，还与支持该程序的系统与数据库有关。
尽量模拟现实环境，能更真实的反应出测试数据。