| || |
I have a query, please give your solution regarding this concept.
There should be at least two kinds of stress test:
1) Synchronised, scripted, multi-threaded testing explicitly aimed at trying to cause/identify VFS failures in the event of specific types of simultaneous access by multiple clients.
2) Asynchronous, randomly-selected, multi-threaded testing in which each robot randomly selects and plays back scenarios from a pool of possible scenarios. These tests can be left running indefinitely (at least for several days). There will be various possible pools of scenarios depending on the types of test we want to perform. For example, perhaps you have one pool which focuses on performing as many possible operations as we can think of on a single specific file. This will stress the VFS to make sure that it can handle simultaneous file access appropriately. Another pool might contain a much broader range of operations which would more closely mimic real-life usage in a corporate network.
The key thing is that the scenarios you have listed in the spreadsheet are more like operations. We need to perform as many possible combinations of these operations in parallel to really stress the VFS. So for example we might want one robot script to be toggling read-only flags of a file while another is renaming the directory that contains that file, another is trying to unseal that file, and another process is trying to edit and reseal that file. We can script some situations like this (as in the type 1 testing outlined above) but since there are many, many possible combinations of possible operations, we also need to augment these scripted scenarios with randomly-generated activity as in the type 2 testing outlined above.
Is it possible to implement this concept using Vuscripts? I know only how to generate vuscripts using Rational Robot. I don't know how to use vusers in the script.
Is it possible to assign different activities to different virtual users? If so, how to do? If you have any scripts regarding this concept, please help us.
Please let me know how to implement this concept.
I feel great If I get a solution.
Thanks a lot.
Re: Regarding VUScripts
Where did you get that quote? It interests me. The concepts are sound, but I don't like the terminology.
Can you do it the way it is written? Yes. Would it be hard - probably. Is there a better way to do the same sort of thing? Yes.
1) is what I refer to as either "spike" or "hammer" testing. Very easy to do with VU Robot. It's just a matter of playing back your scripts with unreasonably high load and/or unreasonably fast pacing and/or unreasonably well alligned activities.
2) I wouldn't do it quite that way. I would do all those different types of tests, but not in a single test execution. There are references in there to several types of stress tests to include "extended peak load" and "narrow functionality load", and there is also a reference to true Performance (User Experience) testing. Doing these seperately is pretty easy. Rolling them into a single (days long) test is possible, but...
b) risky (you can't have logging and something is bound to fail and keep you from ever actually retrieving your results)
c) unrepeatable - tests need to be exactly repeatable to be useful.
How familar with Robot are you? I recommend you reading my User Experience, not Metrics series on www.perftestplus.com
Scott Barber, Sr. Performance Engineer