QA/Sync/Test Plan/grinder tests: Difference between revisions

QA/Sync/Test Plan/grinder tests (view source)

410 bytes added , 25 May 2011

89

edits

@@ Line 50: / Line 50: @@
 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.
-== Issues ==
+== Technologies ==
-* In order to validate data we need to store that data. In order to validate a sync servers worth of data we will need a lot of storage. (Some optimizations may be able to take place).
+* Grinder
-* We need to parallelize the load generation over multiple machines to match the capability of the server
+** This will be the main test harness. We will write scripts against it using jython and use its built in tools in order to distribute the tests to multiple load generators
-** Grinder supports multiple hosts
+** Advantages
-** We need help to get the adequate hardware for this task
+*** Distributed (We can use multiple machines to hit a server)
+*** Performant (No overhead of booting firefox)
+*** Built with HTTP based testing in mind (ideal for REST services including SYNC and beyond)
+* MongoDB
+** A database with a REST api will be used for data verification. A percentage of requests will get stored in a Mongo database in effort to make sure that our data is accurate at all loads
+** Advantages
+*** Heavy - it is built to handle many reads/writes per second
+*** REST api we can perform the same steps to communicate with sync as we can to communicate with the database