Introduction --the introduction will introduce the feature under test. This does not have to be extensive. Its purpose is twofold: provide sufficient description of the feature under test that readers of the test plan understand the remainder of the document. Secondly, the feature description should call out the key use cases of the new feature so that reviewers, developers, etc. can verify that the feature's value to end-users is understood and going to be covered by the test plan.
HW Requirements --identify the hardware that will be required to execute the tests covered by the plan. Some kind of table or bulleted list is appropriate here.
SW Components --identify all the software components involved in the test, including the software under test, test frameworks, 3rd party tools, code developed specifically for testing this feature, etc.
Test Design --The test design will include a system level diagram showing hardware, software and test components. The diagram will illustrate the interactions between the components sufficient to understand the overall design of the tests. If the test plan requires development of any new complex test code the design of these test components, algorithms used, etc., are documented using traditional software design/architecture mechanisms (e.g. UML).
Test Matrix --The core of the document is a table mapping product features (or use cases) to tests. An example use case might be that it is possible to take a snapshot while I/O is ongoing. The matrix would list test cases that verify this feature e.g. take a snapshot of a container while HDF5 file housed in the container is being updated by application X.
Opens/Limitations --in table form list any unresolved issues, or limitations of the testing.