Prepare a server that enforces RDP-security by setting Security Layer to "RDP", not "Negotiate" and not "SSL(TLS1.0)". Depending on the OS this can be done via Group Policy, Remote Desktop Session Host configuration or by editing the registry.
connect using the command xfreerdp /v:servername and don't specify any other options, especially not the /sec:xxx option.
verify that xfreerdp prints out messages confirming that nego was retried
on the server, immediately after the connection, use tcpview or netstat to verify that the amount of established tcp connections on 3389 equals the amount of connected rdp clients.
on the client do the same, e.g. using the command lsof -i :3389

Detect Network Failures [TSTCLTNF]

connect to a remote server in windowed mode: xfreerdp /v:servername /size:640x480
make sure that the xfreerdp window is not focused and the mouse pointer is outside the window (freerdp should not generate any input that is sent to the server)
pull the network cable on the client machine and wait
xfreerdp should terminate with the message "Network disconnect" within a few seconds
restart this test but this time continue clicking inside the xfreerdp window immediately after pulling the network cable (freerdp should try to send data to the server)

xfreerdp should terminate with the message "Network disconnect" within a few seconds

Note: depending on the kernel version the following test might not succeed
Do the same tests again but instead of pulling the network cable set a firewall rule: iptables -A INPUT -p tcp --source-port 3389 -j DROP; iptables -A OUTPUT -p tcp --destination-port 3389 -j DROP; (you can clear the tables again using iptables -D INPUT x ; iptables -D OUTPUT y; x, y are the rule numbers, see iptables --line-numbers -L)

Automatic Reconnection [TSTCLTAC]

connect using the command xfreerdp /v:servername +auto-reconnect
in the session open Sysinternal's TCPView, right-click the corrct connection and select "Close Connection"
verify that xfreerdp prints the message "Network disconnect", "Attempting reconnect (1 of 20)"
in TCPView verify that the you really got a new tcp connection (e.g. by comparing the remote port or the packet counter)
ideally you should not even notice the disconnect/reconnect inside the xfreerdp session
now try the same test but terminate the socket on the client side: run sudo tcpkill port 3389 wait some seconds until xfreerdp tries to reconnect and then ctrl-c the tcpkill command.
test automatic reconnection under the network failure scenarios of test [TSTCLTNF]

Server-Transport

Sample Server (RFX only) [TSTSRVSMP]

In FreeRDP source code directory: cd server/Sample
run WLOG_LEVEL=DEBUG ./sfreerdp-server
note the listening unix domain socket (output Listening on socket /tmp/tfreerdp-server.0 )
test connection to the unix socket using xfreerdp /rfx /v:/tmp/tfreerdp-server.0
test connection to the sample server remotely using windows 7/8/rt mstsc and xfreerdp clients

Shadow Server [TSTSRVSHD]

enable xdmcp on your linux server's display manager
use the virtual X11 server Xephyr to open a connection to your local display manager:
Xephyr -screen 1024x768x32 -query localhost :99
log in with some test user, open a terminal, cd server/shadow and run WLOG_LEVEL=DEBUG ./freerdp-shadow -auth
on your real desktop (not inside the Xephyr window) cd client/X11 and try if you can open 10 concurrent xfreerdp sessions to the shadow server: for i in `seq 1 10`; do ./xfreerdp /v:realipaddress /cert-ignore & done (don't use localhost or 127.0.0.1)
test connecting to the shadow server using Microsoft's Android, Mac OSX, iOS, Windows CE/RT/XP/Vista/7/8 clients

Clients

X11: xfreerdp

Fullscreen

FIXME: multi-head test setup howto (xrandr, fakexinerama, Xephyr, ...)
FIXME: description and various test cases for /f
FIXME: description and various test cases for /span
FIXME: description and various test cases for /multimon
FIXME: description and various test cases for /multimon /monitors:n1,n2,...
FIXME: description and test cases for full screen toggling (Ctrl+Alt+Enter)

Smart Sizing

Microsoft's description of that feature: http://blogs.msdn.com/b/rds/archive/2008/08/07/smart-sizing-the-ts-client.aspx
Support in FreeRDP was added with this PR: https://github.com/FreeRDP/FreeRDP/pull/2240

Basic usage:

make window resizable, scaling contents: xfreerdp /v:servername /smart-sizing
create a 1024x768 session but display the session down-scaled in a 640x480 window: xfreerdp /v:servername /size:1024x768 /smart-sizing:640x480
create a 640x480 session but display the session up-scaled in a 1024x768 window: xfreerdp /v:servername /size:640x480 /smart-sizing:1024x768

Fullscreen-toggling

If the session was started with /smart-sizing and you enter fullscreen mode via Ctrl+Alt+Enter the session is expected to get scaled to the fullscreen dimensions.
If you leave fullscreen mode again the window should resize to the dimension it had before switching to fullscreen.

Inital fullscreen-scaling

if /f is specified in combination with /smart-sizing:WxH we run the session in the /smart-sizing dimensions scaled to full screen
Example xfreerdp /v:servername /f /smart-sizing:320x200 This should create a 320x200 rdp session scaled to your full screen dimensions

Virtual Channels

File System

Channel name: RDPDR
Specification: MS-RDPEFS

Smartcard

Channel name: RDPDR
Specification: MS-RDPEFS
Specification: MS-RDPESC

Printer

Channel name: RDPDR
Specification: MS-RDPEFS
Specification: MS-RDPEPC

Serial and Parallel Port

Channel name: RDPDR
Specification: MS-RDPEFS
Specification: MS-RDPESP

Clipboard

Channel name: CLIPRDR
Specification: MS-RDPECLIP

Audio Output

Channel name: RDPSND
Specification: MS-RDPEA

Audio Input

Channel name: AUDIO_INPUT
Specification: MS-RDPEAI

Video Redirection

Channel name: TSMF
Specification: MS-RDPEV

setup a windows server to support video redirection
set the WLOG_FILTER environment variable to com.freerdp.channels.tsmf.client:DEBUG, and launch xfreerdp with /bpp:32 /multimedia:audio:system, system can be pulse or alsa
watch a movie with Window Media Player, the movie should be encoded with a codec that is supported locally (hint: it's not the case with the wild life sample shipped with Seven)
you should see some debug messages from the TSMF channel, the server-side load should be very low

Remote Programs

Channel name: rail
Specification: MS-RDPERP

Multitouch Input

Channel name: Microsoft::Windows::RDS::Input
Specification: MS-RDPEI

Graphics Pipeline

Channel name: Microsoft::Windows::RDS::Graphics
Specification: MS-RDPEGFX

Display Update

Channel name: Microsoft::Windows::RDS::DisplayControl
Specifications: MS-RDPEDISP

Echo Extension

Channel name: Echo
Specification: MS-RDPEDYC

USB Devices

Channel name: URBDRC
Specification: MS-RDPEUSB

Multiparty

Channel name: encomsp
Specification: MS-RDPEMC

Remote Assistance Protocol

Channel name: Multiple: "RC_CTL", "70", "71", ".", "1000.", "RA_FX"
Specification: MS-RA

Remote assistance requires the multiparty channel therefore the following test should cover the main parts of both channels (this was tested with Windows 7):

connect to the windows host
Start the Windows Remote Assistance and execute the following steps
"Invite someone you trust to help"
"Save this invitation as file"
copy/remind the password
copy the saved file to the test PC where FreeRDP is run\
keep the windows 7 connection open
on the test PC start xfreerdp with the incident file as first and with the assistance password as second parameter

xfreerdp Invitation.msrcIncident /assistance:XXXXXXXXXXXX

If everything works as expected the remote assistance should start and the mirrored display should be shown.
To test "remote control" press "ctrl+alt+c" in xfreerdp the shadowed session should get a prompt to allow control. If it works it's possible to control the desktop in xfreerdp.

https://github.com/FreeRDP/FreeRDP.wiki.git