89
edits
QA/Sync/Test Plan/grinder tests: Difference between revisions
Jump to navigation
Jump to search
→Test Cases
| Line 20: | Line 20: | ||
== Test Cases == | == Test Cases == | ||
=== We are trying to answer the following questions === | |||
*How does the app fail under high load conditions? How does it fail? | *How does the app fail under high load conditions? How does it fail? | ||
**From a large data input? | **From a large data input? | ||
| Line 32: | Line 32: | ||
** More Users | ** More Users | ||
=== This translates roughly to the following test scripts === | |||
* Create Users | * Create Users | ||
* Large Sync (initial sync) | * Large Sync (initial sync) | ||
| Line 40: | Line 40: | ||
These test cases need to mimic the way the actions of firefox look to the sync server as closely as possible. Data is all encrypted so testing different types of data (bookmarks vs history) is irrelevant as far as the server is concerned. | These test cases need to mimic the way the actions of firefox look to the sync server as closely as possible. Data is all encrypted so testing different types of data (bookmarks vs history) is irrelevant as far as the server is concerned. | ||
=== Script use pattens === | |||
We currently have the ability to go through the logs and see how the sync server is being used. We can generate a profile based on this and do load testing that way. In addition, we can add scenarios that model other use cases. For example: | We currently have the ability to go through the logs and see how the sync server is being used. We can generate a profile based on this and do load testing that way. In addition, we can add scenarios that model other use cases. For example: | ||
* A period with above normal registrations | * A period with above normal registrations | ||