To use Test Center, you need to understand these functional testing concepts that the API makes available in its URL resources and data.
- Test suites. Test suites combine functional test cases and configure their settings.
- Stateful test suites. In stateful test suites, a test run executes included test cases in the set order. Cookies and session information are retained for subsequent test cases.
- Locked test suites. Locked test suites can be modified only by their editors and owners. Test Center users who create locked test suites automatically become their owners, but they can also designate other owners. Editors can modify locked test suites (except for the Locked status), add new functional test cases to them, and remove those already included. If the test suites are also stateful, editors can reorder included test cases. Owners can additionally manage the locked test suites' edit access and remove them. Every Test Center user can send a request for edit access to the test suite's owners. Owners are notified about the request with an email. Once they approve or reject the request, the user also gets a notification email.
- Variables. Variables allow you to reuse specific values in a test request's URL and request headers and conditions. They enable you to create test cases with complex metadata and run very specific tests.
Each variable consists of a name and an assigned value. You can add and edit variables as well as delete those created by users of your account. - Functional test cases. Functional test cases are the smallest units of testing. Each test case includes one test request, one condition, and one client profile. Test cases must be unique at the level of a test suite. It means that a test case can be included in only one test suite.
- Test requests. Test requests combine fully qualified URLs and an optional set of custom request headers. By default, the test request URL is requested with whatever default headers are normally sent by the browser used by the client profile.
- Client profiles. Client profiles combine a browser type, geographic region, and IP version that characterize the client used to make a test request. There are two client profiles provided that you can use. Both of them use Chrome as the browser type and the United States as the geographic region. They differ by IP versions — one is for IPv4 and the other one is for IPv6.
- Conditions. Conditions are the criteria you want to evaluate on the HTTP response. They correspond to the test request or a specific config setting applied to the test request. Conditions have a sentence-like structure. For example: Response header 'foo' has a value that equals 'bar' or Caching option is no-store. Each element of such sentence is a value of a node. You can find all nodes and their descriptions including available values in the Test catalog template.
- Test catalog template. You use the test catalog template to construct condition statements.
- Property versions. Property versions refer to Property Manager property versions. All operations performed on property versions are saved only in Test Center. They don't affect properties in Property Manager. By associating a property version to a test suite with it, you're saying that the functional test cases in the test suite are regression test cases for the property version. To use a property in Test Center, you need to add it first to Property Manager. To learn how to do it, check the Property Manager API documentation: Create a new property version and Create a new activation or deactivation.
- Test runs. A test run executes one or more objects against a selected environment.
- Executions. An execution is an instance of a resource used in a test run.
- Test results. Test results for functional testing show you the expected and actual values. To learn more about it, see Functional testing results.