The meaning of software testing requirements
the meaning of test requirements
Whether for development or testing, a fully accurate and predictable design is the prerequisite for a successful project. In the actual project operation, it is often felt that the testing process has various problems:
1, the product quality dimension is not comprehensive, the test type is not complete;
2, the test specification design is more random, the test decomposition distribution is more arbitrary;
result in the test process, often there will be missing requirements, test design omission of the problem;
Therefore, a detailed and accurate test requirements analysis is helpful to solve these problems.
Definition of test requirements
Software requirements define what functionality is required for a product to be implemented, and the term industry does not have an authoritative definition, and the majority of the opinions suggest that test requirements define the scope of the test (i.e., the question of what the main solution is, and to what extent), that it is too general, in other words, testers based on initial functional requirements, Evaluate what function points need to be tested, what type of tests each function point requires, how much each function point test is passed, and assess the size, complexity, and risk of the test, as well as a preliminary estimate of which link needs to be provided by the development colleague.
The more detailed and precise the design of the test requirements, the deeper the understanding of the software for the test, the deeper the understanding of the various test methods, but this often requires the designer of the test requirements to have some experience in testing.
Process for testing requirements
Acquisition of test requirements
The most direct sources of testing requirements are:
1, software requirements specifications;
2, industry Agreement specification;
3, Test experience database;
4, for the old version of the software testing , but also need to consider the requirements of inheritance testing.
To comb the above content, form the original test requirements table, the contents of the list includes requirements identification, the original test requirements description, the source of information, as follows:
source number |
test original demand number |
test original requirements Description |
development features |
demand identification |
requirement description |
demand priority |
Test Specification analysis Engineering method |
DR001  |
EMAIL-001  |
EMAIL  |
or_mkt.00010 |
|
|
|
Testers need to collate the development requirements, first of all need to confirm the correctness of software requirements, and secondly to ensure the testability of software requirements. The so-called testable refers to the existence of a well-defined result, which can be judged and validated by a certain method. "In principle, all software requirements should be testable, because if a tester does not have an accurate understanding of the requirements (i.e., the inability to produce definitive results), then the developer is equally unable to produce an accurate understanding of the same requirement." Each test requirement needs to ensure that a requirement contains only one test content, so a software requirement can often correspond to multiple test requirements.
The most important point of this stage is to pay attention to the universality and comprehensiveness, to collect as much as possible the original demand, no omission, and to expand the demand appropriately, these needs should not only be limited to the above five source types, but also not limited to a variety of documents and materials.
Analysis of test requirements
After the test requirements are collected, a demand table is not optimized, and the original requirements table needs to be initially planned:
1, remove redundant duplication of demand, there is no excessive intersection between the requirements;
2, the need to cover business processes, functions, non-functional aspects of the needs;
Business process: Any set of software will have a certain business flow, that is, users use the software to achieve their actual business of a process. Simply put, the following categories need to be listed in the test requirements analysis:
1) Common or prescribed business processes
2) Traversal of each business process branch
3) clearly defined non-use business processes
4) Business processes that are not explicitly specified but should not be executed
5) Other abnormal or non-conforming operations
1, need to consider the interaction between the functional modules analysis;
2, determine the test characteristics (i.e. test function points);
3, determine the requirements of the test type;
1, determine the quality of demand attributes;
2, determine the phase of this version of the test belong to;
Testing phase: Different stages of the product, the requirements for the testing phase are not the same. For the initial version of the product, more focused on: whether the function of the implementation (the function of the normal scenario is smooth), the more mature stage, will focus on: whether the function is sufficient to achieve (abnormal scenario, whether normal processing), more mature will pay attention to, whether through the various pressure test scenarios.
Test demand Tracking Matrix
The test requirement tracking matrix is established to manage the test requirements. Fill in the test tracking requirements matrix with the above step analysis, identified development requirements, test requirements, and test types.
The test requirement tracking matrix is established to manage the test requirements. Fill in the test tracking requirements matrix with the above step analysis, identified development requirements, test requirements, and test types.
Implement management of requirements change by testing requirements tracking matrix. Once the software requirements change, it is necessary to maintain the requirements tracking table, initiate the configuration management process, and change the content related to the software requirements changes synchronously.
Test Requirements Review
Content of the review:
Integrity review: Should ensure that test requirements can adequately cover the various features of the software requirements, focusing on functional requirements, data definition, interface definition, performance requirements, security requirements, reliability requirements, system constraints and so on, but also should pay attention to whether the developer omitted, the system implied requirements;
Accuracy review: The described content should be guaranteed to be consistent understanding of the relevant parties, there is no contradiction and conflict between the test requirements, the requirements of the test are in full consistency, each test requirements can be used as the basis for test case design.
The meaning of software testing requirements