QA/Sync/Test Plan/grinder tests/technical documentation

Testing Technologies

• Grinder
  • 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
  • Advantages
    • 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. Hopefully we won't be load testing MongoDB.
    • REST api we can perform the same steps to communicate with sync as we can to communicate with the database

Current Architecture

• load-auth.services
  • Current load Target
  • No Captcha
  • No mechanism for creating users
• client[4-9].scl2.svc
  • Runs grinder load generater
  • Has jython installed
  • Direct access to load-auth.services
• Console Controller (any linux/windows computer connected to MPT)
  • Controls test execution
  • Has created a reverse ssh tunnel into the above grinder client so that the clients can see the grinder console

See the following link for a graphical picture of how grinder systems are setup: The Grinder Processes n.b. In terms of grinder lingo client[4-9].scl2.svc are agents with multiple workers each.

Scripts

• Two Modes
  • Console mode (dispatched console)
  • Command line (single run, for testing)
• Libraries
  • Grinder 3
  • Jython 2.5.2 (this is important, older versions won't work properly)
  • Jyson 1.01 (json parser written in java for jython - only works on jython 2.5+)

n.b. In terms of grinder lingo client[4-9].scl2.svc are agents with multiple workers each.