added coverage and usage sections to README

jmeter_tests/README.markdown

@@ -9,6 +9,51 @@ Currently, tests for each service description are the only implemented functiona
 however, a library of utility functions has been created to easily create other black-box
 functional tests should they become useful and/or necessary.
 
+## Coverage
+
+The tests cover each of the individual service descriptions available on a running node.
+Each service description is extracted from the `/services` url, then compared against
+a javascript object containing the expected values. The expected values in these ojbects
+have been assigned according to each respective Network Node Service Description Data Model
+found in version 0.24 of the LR Technical Specification. 
+
+When appropriate, hard-coded values
+are used as expected values and simple comparisons are made. For example, the `service_type`
+property is part of a fixed vocabulary ("publish", "access", etc.) and thus a static assertion is made.
+
+In cases where a value is required by the spec but can be dynamic (such as a timestamp), an
+appropriate function is applied to assert that the value is indeed in the range of valid inputs.
+Properties marked as optional in the specification are also accounted for, and are evaluated
+only when returned from the server.
+
+Optionally, an extra check can be made for extra keys not defined as part of the spec. This
+assertion will raise an error if a key-value pair is returned from the server but not found
+as part of the expected object. Since the Network Node Service Description Data Model is allowed
+to have additional custom fields, this check is currently OFF by default.
+
+The current commit also includes a separate test for the `/policy` data model that functions
+in a manner identical to the aforementioned service description tests while testing for
+the appropriate values for that service.
+
+## Usage
+
+The node to be targeted can be set using the LRNodeAddress and LRNodePort User-Defined Variables,
+which means that running the test is very flexible with regard to environment. Because of its independence 
+from the actual source code, unlike the python nosetests,
+a user can decide whether to test a remote node or one found locally with minimal configuration changes.
+That being said, it is also to be noted that these tests are NOT designed to be a replacement for the
+nosetest unit tests, which provide a much more complete and robust way of testing an existing
+Learning Registry installation.
+
+This test was designed and developed using the GUI version of jmeter 2.6 on Windows. When finished,
+the configurable pathnames were changed to work with a headless version of jmeter running on 
+Ubuntu Server 10.01. Each functioned identically; however with the headless version, an output file
+must be specified to view the passes/failures. The latter of the two configurations is what
+can be found in this repo.
+
+Please refer to the [jmeter project page](http://jmeter.apache.org) for more information on how
+to properly install, configure, and run jmeter.
+
 ## Structure
 
 ### File Hierarchy