89
edits
QA/Sync/Test Plan/grinder tests: Difference between revisions
→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? | |||
**From a large data input? | |||
**From a lot of connections? | |||
*Which functions and potential use cases create a particularly high amount of load? | |||
**High amounts of registration? (and corresponding initial sync?) | |||
**Lots of empty requests? (as generated by instant sync?) | |||
*Are any functions effected sooner by high load? (I.E. Are there any unexpected bottlenecks?) | |||
*How do these services scale to | |||
** More Features | |||
** More Users | |||
;This translates roughly to the following test cases | |||
* Sustained Load | |||
* Spike Load | * Spike Load | ||
** There are currently client side issues that we need to keep track of with this. Based on the architecture the only place that a high amount of connections can hurt us is at the load balencer stage. Firefox needs to be able to deal with us saying "No you may not sync right now because we are busy" | ** There are currently client side issues that we need to keep track of with this. Based on the architecture the only place that a high amount of connections can hurt us is at the load balencer stage. Firefox needs to be able to deal with us saying "No you may not sync right now because we are busy" | ||