Test environment

from Wikipedia, the free encyclopedia

A test environment ( English Test Environment ) is the technical and organizational infrastructure that the testing of software is used.

General

In general, test environments should meet two basic principles:

  • The test environment should be separated from the production environment as far as possible so that the software to be tested cannot cause any damage to productive operation. See also sandbox .
  • On the other hand, the test environment should be as similar as possible to the production environment so that problems in connection with the technical process environment can be identified (and resolved) during the test.

Complete fulfillment of both requirements is rarely found in practice for economic reasons.

Test environments and their organization can differ considerably depending on the technical basis on which the developed software is to be used and other factors:

  • In large organizations with a powerful IT infrastructure and for large projects , the planning, setting up and operation of test environments is a highly complex task with many responsible persons and a great deal of coordination.
  • On the other hand, simple PC applications, possibly with only local scope of use, usually do not require a large or special test infrastructure.
  • For test environments across several technical platforms, production-like structures and interfaces often cannot be created or can only be created with great effort.
  • Different test environments with different equipment may be required for different test levels.
  • Test environments can be operated exclusively for one project or for several / many / all projects, only temporarily (for the duration of the project) or permanently.

Test environments that are independent of the production system are usually operated with components (computers, storage capacities, etc.) that are smaller (compared to the production environment ) and are therefore also less expensive. Examples: A PC instead of a server, a single server instead of a server cluster, virtualization software (e.g. from VMware ). Depending on the computer system, test environments u. It may only be operated independently to a limited extent, but in technically separate system areas (terms for this: region, task, domain, etc.).

Characteristic features

With regard to their technical basis, test environments are similar to systems in productive use. Nevertheless, a TU and its operation differs in many ways from 'IT production' - which can also be regarded as requirements for test environments :

  • Programs can be transferred quickly and easily to the test environment.
  • In the tests, the 'test objects' (programs to be tested) are mixed together with other components .
  • The time dimension is handled flexibly in order to be able to test functions with a time reference (a whole working day, change of month or year) independently of the real course of time.
  • Interfaces to other (also external) systems should be available whenever possible. Alternatively, they are simulated if necessary.
  • The execution of programs is usually not controlled fully automatically (e.g. at certain dates, in a strictly defined sequence), but activated and controlled individually by the testers.
  • The functions to be tested are i. d. Usually carried out many times in a row, each time in different constellations (as defined in the test cases).
  • To check test results , these must be made 'visible' and preserved with the help of special tools after the end of the test.
  • System settings, system identifications (path names etc.) and parameters must (can) be modified due to technical conditions as well as for test purposes (several constellations). For test purposes, on the other hand, as few adjustments as possible (compared to the later productive version) should be necessary, because new error risks are 'dormant' in these modifications.

Special requirements must be observed when operating common test environments for several projects:

  • The assignment of test data to certain test levels , test types , projects, etc. must be regulated - in order to prevent mutual changes in data and thus incorrect test results.
  • The tests (especially in the case of large projects) must be planned in terms of content, sequence and time (often on an hourly basis) and coordinated with those involved in your own or other projects.

In companies and organizations operating outside the company, changes to the software often require special precautions and rules, according to which those involved can / must test in a coordinated manner. See example Bundesbank.

Especially for websites and web applications based on client-server architectures are based, test environments were developed by many manufacturers as a staging area ( English Staging Environment ) are referred to. While the associated database server is filled with test data that is filtered as a sample from the productive data according to certain criteria, the actual test server is based on a mirror technology that enables tests of changes analogous to the productive version under different working environments and then enables automatic migration of the productive environment.

Components

A test environment generally consists of the following components:

  • The hardware required for testing and the operating system (with all components required for testing) form the technical basis of the test environment.
  • The administrative infrastructure must be available and installed for the specific test. Examples: test libraries, flow control components (such as JCL ), test databases, test clients, test users, access and rights concepts, test time slices, etc.
  • The programs to be tested (new or modified versions in maintenance projects) must be available in the test environment.
  • Other applications / programs required to perform the tests must also be available. Examples: Central sub-programs, programs that have not been changed (in maintenance tests ), applications for displaying result data, applications for further processing test results; they are not test objects, but tools.
  • Test tools are required to prepare, conduct and control tests, e.g. B. for test case documentation, test data manipulation, test automation and monitoring ( debugger ), for automatic data comparisons, etc.
  • Substantial part of the test environment are required for testing and content tailored to them test data .
  • In a broader sense, the defined test cases also belong to the test environment.

Focus on test data

Test data are a special focus for test environments and testing in general. A distinction must be made here between input data for tests (in the variants described in the test cases) and data that is 'only' accessed in the test ; both types must go together. In addition, there is the data generated during testing - as test results to be checked, which can possibly be compared with target result data .

For test data and the necessary provision processes ( test data management ), the following issues are of particular importance:

  • Test data and test cases should be precisely coordinated and defined in such a way that unintentional changes (e.g. in other test cases) are avoided. Documenting the relationship between test cases and test data is useful: Which test data is used for test case X - and vice versa?
  • Test data must - in addition to the characteristics / constellations required according to the test case specifications - also be logically consistent with one another. Example: Order data match customer and article data.
  • This consistency is also necessary across platforms in test environments across multiple technical platforms.
  • In the interests of optimal test effort and efficient test controls, the test data volume should be as small as possible and only as large as necessary.
  • By using productive data as test data, practical data combinations can be achieved. However, the mere use of such data (in which the test constellations are dependent on chance) does not allow any quality statements (completeness) about the tests and i. d. Usually high effort to check results. Often these data must i. d. Usually anonymized for testing .
  • For test repetitions, it should be possible to reset test data globally or individually to old statuses. This is particularly necessary after so-called "aging" or "time travel", where z. B. a change of year (several times) must be tested.
  • For performance tests, full stocks may be processed, possibly in the production environment.
  • In the event of data structure changes (e.g. when using test data in regression tests ), the test data may have to be structurally adapted to the newer program version.

Individual evidence

  1. ↑ Bundesbank test environment [1]
  2. ↑ Staging Environment in the Ryte company wiki (ryte.com)
  3. ↑ Description from Microsoft
  4. ↑ Stefan Selge: Without bugs from the idea to implementation. ( Memento of the original from November 14, 2017 in the Internet Archive ) Info: The archive link was automatically inserted and not yet checked. Please check the original and archive link according to the instructions and then remove this notice. 5 Anker GmbH, January 18, 2017 @1@ 2Template: Webachiv / IABot / docs.5-anker.com