Like software developers create a software architecture describing how to software is built from a very high level perspective, you can do the same from a testing point of view.
In my cases (involving software testing), the test architecture contains many elements which are also present in the software architecture diagram.
It differs from the software architecture in those elements which you want to replace for testing purposes, e.g. you could replace hardware by a simulator. For the same reason, I often have many test architecture diagrams, each differing in a small number of components replaced by a simulator for testing a specific aspect of the product.
Next, a test architecture may includes a setup for load testing. From that diagram, one should be able to figure out how much hardware/software you need in order to generate the load.
In my latest test architecture, I use virtualization in order to store specific states and versions of the software product. From the test architecture it is possible to figure out how many states I expect, what disk space is needed and how many CPUs and how muh RAM the virtualization server is expected to have.
The test architecture described before is mainly for PC software. This may differ for embedded products, e.g. you may want to explain how the device's inputs and outputs are triggered (e.g. via Labview) or how you want to test power surges and what additional hardware is needed to create those surges.
You may also want to describe the data flow, e.g. way you get test data into the device and results out of the device.