Introduction
Handle test metadata in an efficient way.
Contact: Petr Šplíchal
Stones
These are essential corner stones for the design:
- Text files under version control
- Keep common uses cases simple
- Use hiearchy to organize content
- Prevent duplication where possible
- Metadata close to the test code
- Solution should be open source
- Focus on essential use cases
Stories
Important user stories to be covered:
- As a tester or developer I want to easy read and modify metadata and see history.
- As a tester I want to select a subset of test cases for execution by specifying a tag.
- As a tester I want to specify which environment is relevant for testing.
- As a user I want to easily define metadata for multiple cases to simplify maintenance.
- As a user I want to provide specific definition for selected tests to complement generic metadata.
- As individual tester and test contributor I want to execute specific single test case.
- As an automation tool I need a metadata storage with good api, extensible, quick for reading.
Choices
- Use git for version control and history of changes.
- Yaml format easily readable for both machines and humans.
Naming
A dedicated file name extension fmf to easily find all metadata files:
- main.fmf
- smoke.fmf
Objects
Objects are identified by path from the git root directory.
Special file name main.fmf works similarly as
index.html:
| Location | Identifier |
|---|---|
| wget/main.fmf | wget |
| wget/download/main.fmf | wget/download |
| wget/download/smoke.fmf | wget/download/smoke |
Features
Let's demonstrate the features on a simple wget example with the following directory structure:
wget ├── download ├── protocols │ ├── ftp │ ├── http │ └── https ├── recursion └── smoke
Simple
The most common use cases super simple to read & write. Test metadata for a single test look like this:
description: Check basic download options tester: Petr Šplíchal <psplicha@redhat.com> tags: [Tier2, TierSecurity] requires: [httpd] time: 3 min
Hiearchy
Hiearchy is defined by directory structure (see example above) and explicit nesting using attributes starting with "/". Defining metadata for several tests in a single file is straightforward:
/download:
description: Check basic download options
tester: Petr Šplíchal <psplicha@redhat.com>
tags: [Tier2, TierSecurity]
requires: [httpd]
time: 3 min
/recursion:
description: Check recursive download options
tester: Petr Šplíchal <psplicha@redhat.com>
tags: [Tier2, TierSecurity]
requires: [httpd]
time: 20 min
Content above would be stored in wget/main.fmf file.
Inheritance
Metadata is inherited from parent objects:
tester: Petr Šplíchal <psplicha@redhat.com>
tags: [Tier2, TierSecurity]
requires: [httpd]
/download:
description: Check basic download options
time: 3 min
/recursion:
description: Check recursive download options
time: 20 min
This nicely prevents unnecessary duplication.
Elasticity
Use a single file or scatter metadata across the hiearchy, whatever is more desired for the project.
wget/main.fmf
tester: Petr Šplíchal <psplicha@redhat.com> tags: [Tier2, TierSecurity] requires: [httpd]
wget/download/main.fmf
description: Check basic download options time: 3 min
wget/recursion/main.fmf
description: Check recursive download options time: 20 min
This allows reasonable structure for both small and large projects.
Leaves
When searching, key content is used to define which leaves from the metadata tree will be selected. For example, every test case to be executed must have the "test" attribute defined, every requirement to be considered for test coverage evaluation must have the "requirement" attribute defined. Otherwise object data is used for inheritance only.
description: Check basic download options test: runtest.sh time: 3 min
The key content attributes are not supposed to be hard-coded in the Flexible Metadata Format but freely configurable. Multiple key content attributes (e.g. script & backend) could be used as well.
Virtual
Using a single test code for testing multiple scenarios can be easily implemented using leaves inheriting from the same parent:
description: Check basic download options
tags: [Tier2, TierSecurity]
requires: [httpd]
test: runtest.sh
time: 3 min
/nofips:
/fips:
description: Check basic download options (in fips mode)
extra wow options: --fips
In this way we can efficiently create virtual test cases.
Examples
Relevancy
Test Case Relevancy can be naturaly integrated:
description: Check basic download options tags: [Tier2, TierSecurity] relevancy: - "distro < rhel-7: False" - "arch = s390x: False"
Note that, because of YAML parsing, relevancy rules have to be enclosed in quotes. Another option is to use text format:
description: Check basic download options
tags: [Tier2, TierSecurity]
relevancy: |
distro < rhel-7: False
arch = s390x: False
Which seems a bit more clear.
Coverage
Test coverage information can be stored in a single file, for
example wget/requirements.fmf:
/protocols:
priority: high
/ftp:
requirement: Download a file using the ftp protocol.
coverage: wget/protocols/ftp
/http:
requirement: Download a file using the http protocol.
coverage: wget/protocols/http
/https:
requirement: Download a file using the https protocol.
coverage: wget/protocols/https
/download:
priority: medium
/output-document-pipe:
requirement: Save content to pipe.
coverage: wget/download
/output-document-file:
requirement: Save content to a file.
coverage: wget/download
/upload:
priority: medium
/post-file:
requirement: Upload a file to the server
coverage: wget/protocols/http
/post-data:
requirement: Upload a string to the server
coverage: wget/protocols/http
Or split by functionality area into separate files as desired, for
example wget/download/requirements.fmf:
priority: medium
/output-document-pipe:
requirement: Save content to pipe.
coverage: wget/download
/output-document-file:
requirement: Save content to a file.
coverage: wget/download
Or integrated with test case metadata, e.g.
wget/download/main.fmf:
description: Check basic download options
tags: [Tier2, TierSecurity]
requires: [httpd]
time: 3 min
/requirements
requirement: Various download options working correctly
priority: low
/get-file:
coverage: wget/download
/output-document:
coverage: wget/download
/continue:
/timestamping:
/tries:
/no-clobber:
coverage: wget/download
/progress:
/quota:
/server-response:
/bind-address:
/spider:
In the example above three requirements are already covered, the rest still await for test coverage (attributes value is null).
Strategist
Here's an example implementation of test-strategist data for openscap using the Flexible Metadata Format:
/probes:
description: Probes
/offline:
description: Offline scanning
/online:
description: Online scanning
/scanning:
description: Reading and understanding source datastreams
/oval:
influencers:
- openscap/probes/offline
- openscap/probes/online
/ds:
influencers:
- openscap/scanning/oval
- openscap/scanning/cpe
/cpe:
influencers:
- openscap/scanning/oval