At this time, we do not have plans to release or open source our automated testing scripts. I recommend visiting http://appium.io/ to understand how you could write your own for your offline application. Setup is similar to other webdriver/selenium based UI testing framworks, but with the added requirement of a server and device to run on, and as we have found, setting this up and maintaining it is more costly than standard browser-based testing due to a higher frequency of OS updates and slightly longer development cycles.
Overall, automated load testing offline is difficult and costly to set up. You can simulate the server load from offline devices by capturing the network traffic off of the device using Fiddler 2 remote proxy capture, or another network diagnostic tool.
Often, trying to set up a remote HTTPS proxy connection will trip man-in-the-middle security checks. You may need to install security certificate on the machine running the diagnostic proxy and add it to your domain so that the device will accept the SSL connection.
If you have a set of network traffic that you with to replicate to put the server under load, you can use a tool like JMeter to generate the traffic. In the case of Pega Offline, you will need to create an operator for every connection you wish to open, and you may need to generate new transaction ids. JMeter and other tools like Grinder, Gatling or TSung are built to help you do this.
You can drive a Pega Offline application on an actual device. For iOS, this requires an iOS device tethered an OSX server via usb cable. For Android, the device can be tethered to an OSX, Windows or Linux server. Appium.io provides a framework similar to webdriver that lets you drive interactions on the physical mobile device over a network. We have driven such scripts using Ruby/RSpec/Capybara. These scripts can be executed either on the server, or from a client machine over the network. This configuration works far better as a continuous integration system. It takes quite a lot to set it up, then it requires regulare maintenance as new versions of iOS, Android, OSX and Windows keep coming out. It is not a configuration that can be set aside for any amount of time and then picked back up without incurring significant reconfiguration the longer it sits.
Automation aside, the best way to run a physical test is the gather a number of devices together, login and sync, go offline, do a large number of actions, wait until everyone is done, have everyone go online at the same time and sync up. This would put a large bulk of offline work on the server in a short amount of time. You should be able to measure the spikes effect through SMA.
I hope this helps. My ultimate suggestion is to start with the manual load test to test out your test script and instrumentation, then automate the script with JMeter and take the physical devices out of the equation. I also recommend waiting until primary development is complete before automating to avoid having to recapture the network traffic and update the JMeter script.