|
Author
|
Topic: Test Plan for Load Testing
|
allogene
Advanced Guru
Posts: 921
Registered: Jun 2001
|
posted 03-01-2002 08:23 AM
    
I know there are similiar posts but I am looking for opinions rather how to.Our department has put together a scaled down version of a test plan for load testing. It is a high level view of the testing for a product. What do you think? Is it enough information? Is there something fundamental we are missing? Any thoughts would be appreciated. ------------------
Simple minds, Simple thoughts! Doug
|
Yury
Guru
Posts: 308
Registered: Dec 1999
|
posted 03-03-2002 05:18 PM
I believe requirements for "transactional throughput" should be added.
Transactional throughput and the number of concurrent users (VUsers) are independent parameters.
|
allogene
Advanced Guru
Posts: 921
Registered: Jun 2001
|
posted 03-04-2002 06:55 AM
quote:
Originally posted by Yury:
I believe requirements for "transactional throughput" should be added.
Transactional throughput and the number of concurrent users (VUsers) are independent parameters.
Yury can you clarify what you mean by Transactional throughput? Do you mean the amount of throughput produced by each transaction? Total throughput by test, user, etc.? ------------------
Simple minds, Simple thoughts! Doug
|
Yury
Guru
Posts: 308
Registered: Dec 1999
|
posted 03-04-2002 09:12 AM
quote:
Originally posted by allogene:
What you mean by Transactional throughput?
It might be total throughput or throughput per user.
It depends on your taget values from SLA.
For example it might be:
100 typical serches per minutes,
50 quotes per hour,
10 sales per minute
5 MB of files (invoices, etc.) downloaded per second,
500 hits per min (in case of a simple site),
etc.[This message has been edited by Yury (edited 03-04-2002).]
|
MHarman
Member
Posts: 9
Registered: Feb 2002
|
posted 03-04-2002 10:37 AM
Doug,You might also include inforamtion on managing test data- population of the database before the test, cleaning up after the test, tables that the tool uses for data input, etc. Also, we've found it helpful to include system diagrams at the beginning of our test plans. It helps people to understand the various moving parts. Marcy ------------------
|
rstens
Guru
Posts: 321
Registered: Aug 2000
|
posted 03-04-2002 01:01 PM
For whom is this document intended?
The content demands will vary greatly if you have a different audience in mind.I am not really sure why you would want to have a scaled down document. Does this mean you scale down your planning and thinking as well? ------------------
Roland
|
QAGirl
Moderator
Posts: 2424
Registered: Aug 2001
|
posted 03-04-2002 01:52 PM
quote:
Originally posted by rstens:
I am not really sure why you would want to have a scaled down document. Does this mean you scale down your planning and thinking as well?
Does the length of any test plan necessarily correlate to the amount of time or effort that went into planning and thinking? I agree that knowing the audience would be helpful, but 'scaling back' the size or length of any document doesn't necessarily imply that there is less thought or planning - only less writing in a formal sense.  ------------------
~ Annemarie Martin ~
annemarie[dot]martin2[at]verizon[dot]net Let us strive on to finish the work we are in; to bind up the nation’s wounds; to care for him who shall have borne the battle, and for his widow and his orphan — to do all which may achieve and cherish a just and a lasting peace, among ourselves, and with all nations.
|
allogene
Advanced Guru
Posts: 921
Registered: Jun 2001
|
posted 03-04-2002 02:22 PM
quote:
Originally posted by rstens:
For whom is this document intended?
The content demands will vary greatly if you have a different audience in mind.I am not really sure why you would want to have a scaled down document. Does this mean you scale down your planning and thinking as well?
Basically this document is to cover overall testing. It was created for the manager of the product so they can have a general idea of the tests we run. ------------------
Simple minds, Simple thoughts! Doug
|
allogene
Advanced Guru
Posts: 921
Registered: Jun 2001
|
posted 03-04-2002 02:24 PM
quote:
Originally posted by Yury:
[QUOTE]Originally posted by allogene:
[b] What you mean by Transactional throughput?
It might be total throughput or throughput per user.
It depends on your taget values from SLA.
For example it might be:
100 typical serches per minutes,
50 quotes per hour,
10 sales per minute
5 MB of files (invoices, etc.) downloaded per second,
500 hits per min (in case of a simple site),
etc.[This message has been edited by Yury (edited 03-04-2002).][/B][/QUOTE] Thanks. It is good information to add. Perhaps have a section for goals. Instead of number of users. Or both. ------------------
Simple minds, Simple thoughts! Doug
|
allogene
Advanced Guru
Posts: 921
Registered: Jun 2001
|
posted 03-04-2002 02:26 PM
quote:
Originally posted by MHarman:
Doug,You might also include inforamtion on managing test data- population of the database before the test, cleaning up after the test, tables that the tool uses for data input, etc. Also, we've found it helpful to include system diagrams at the beginning of our test plans. It helps people to understand the various moving parts. Marcy
Also good information to add. Diagram may help as well. Would help get everyone on the same page. Thanks. ------------------
Simple minds, Simple thoughts! Doug
|
rstens
Guru
Posts: 321
Registered: Aug 2000
|
posted 03-04-2002 03:50 PM
quote:
Originally posted by QAGirl:
Does the length of any test plan necessarily correlate to the amount of time or effort that went into planning and thinking?
No, but if this document represents "The Performance Test Plan" then I am concerned.
If it is, as Doug states, to just brief a manager on what is being done, then it's fine. ------------------
Roland
|
rstens
Guru
Posts: 321
Registered: Aug 2000
|
posted 03-04-2002 03:58 PM
quote:
Originally posted by allogene:
Basically this document is to cover overall testing. It was created for the manager of the product so they can have a general idea of the tests we run.
OK, fair enough that makes it very targeted audience. For a moment I was worried that this was your full meal deal! But I would add not only what you are doing, but also why. For example, if you run a 500-user stress test, brief your manager in terms that relate to earlier identified risks. I found quite often that the manager is not so interested in the actual technical details but more in what it will do for the understanding of where the product is at.
And as testers that is our job.
------------------
Roland
|
Yury
Guru
Posts: 308
Registered: Dec 1999
|
posted 03-05-2002 08:01 AM
quote:
Originally posted by Yury:
Transactional throughput and the number of concurrent users (VUsers) are independent parameters.
For example:
- For stateless web site number of cuncurrent users is irrelevant. Only total hits/sec value is important.
- For Oracle Financials every logged in user needs several MB of a "Forms server" memory regardless of what he is doing (even when a transactional throughput is zero).[This message has been edited by Yury (edited 03-06-2002).]
|
allogene
Advanced Guru
Posts: 921
Registered: Jun 2001
|
posted 03-06-2002 09:45 AM
I am curious to find out how often you write test plans for your porducts. Do you write them for every test requested? If so, do you write a full blown test plan, or a smaller condensed one? Or is your test plan included in the test plan for all testing? We seem to have created two test plans, one for functional testing and one for load/stress testing. I am looking to see if anyone else does it this way, and if you do, how do you do it in your company? ------------------
Simple minds, Simple thoughts! Doug
|
rstens
Guru
Posts: 321
Registered: Aug 2000
|
posted 03-06-2002 11:15 AM
quote:
Originally posted by allogene:
I am curious to find out how often you write test plans for your porducts. Do you write them for every test requested? If so, do you write a full blown test plan, or a smaller condensed one? Or is your test plan included in the test plan for all testing? We seem to have created two test plans, one for functional testing and one for load/stress testing. I am looking to see if anyone else does it this way, and if you do, how do you do it in your company?
For a new product, I typically create a full size new performance test strategy/plan. For updates to the product, I'll do up a lean and mean plan just specifying what is planned for this release and any differences with the original plan. We write different plans for our functional and performance testing. However, we occasionally try to consolidate them into one document and one plan.
------------------
Roland
|
