We ran into problems with synthetic TCP generators when testing stateful packet-filtering firewalls because the firewalls tracked session state. The tool didn't properly shut down TCP connections, so the firewall maintained them in an open state, and packets that were lost were never regenerated, causing the connections to remain open. The traffic generator reused initial sequence numbers, causing overlap when the ISN and IP address matched existing connections. All these issues combined made for lots of troubleshooting--and this warning to learn from our pain by vetting your tools before you use them!
Synthetic traffic also resides on fully functional IP stacks, but the transactions are synthetic--they simply mimic a transaction. Synthetic application testing works fine for Layer 4 devices where the IP stack behaves as intended and the transactional packets are of varying sizes, but devices that are application-aware are unlikely to process these transactions properly. For example, application-proxy firewalls won't process synthetic application traffic correctly because they track application state.
When testing application-layer devices, like application proxies and HTTP load balancers, you must generate real application traffic; otherwise, you'll run the very real risk of the SUT failing to treat the traffic properly. Many vendors claim in their marketing literature that their tools support application-level traffic, but the proof is whether the test tool and the server can interact.
The best way to determine if a test tool functions properly is to first understand how the protocol is supposed to work. Whip out your packet analyzer and capture and analyze a trace or two. Then, using the test tool, capture and analyze that traffic. Look for anomalies, such as sequence numbers starting at "1" and increasing, unusual protocol flag combinations, and other odd behavior.
Test tools can test application functionality, performance or both. What you want to measure is going to dictate the chosen tool. Functional testing can be as simple as checking to ensure that all the pages in a Web application are available, or as complex as in-depth quality-assurance testing to determine if the application is stable and to ferret out bugs.
Performance testing, also, can take on many forms.