89
edits
QA/Sync/Test Plan/grinder tests: Difference between revisions
→Test Cases
| Line 32: | Line 32: | ||
** More Users | ** More Users | ||
;This translates roughly to the following test | ;This translates roughly to the following test scripts | ||
* | * Create Users | ||
* | * Large Sync (initial sync) | ||
** | * Small Sync (regular sync) | ||
* Empty Sync (I'm checking in without data) | |||
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 irrelavant as far as the server is concernt | |||
* | ;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: | ||
* | * A period with above normal registrations | ||
* A period with high amounts of data payload | |||
* Lots of small requests (what instant sync would give us) | |||
The possibility to test different scenarios is limitless. One of the main uses for this down the road could be to test the potential impact of new services as they are developed. | |||
These test cases need to mimic the actions of firefox as closely as possible. We will use grinder to simulate the actions of a firefox client. | These test cases need to mimic the actions of firefox as closely as possible. We will use grinder to simulate the actions of a firefox client. | ||