Overview・Software test objectives and test types
- 1. The type of test to be performed is decided according to the purpose of the test.
- 2. Types of tests considered along the development phase
- 3. Types of tests considered from the creation of source code
- 4. Types of tests considered to confirm individual features
- 5. Types of tests by system test category
- 6. Classification of design verification and validation
- 7. Classification of tests to detect potential bugs and guarantee that there are no bugs
- 8. Equivalence partitioning, boundary value analysis and path coverage
- 9. Which test to do is important
The type of test to be performed is decided according to the purpose of the test.
There are various types of software tests, such as unit tests , system tests , abnormal system tests , quasi-normal system tests , RAS function tests, and long-term stability tests . Do you have? There are various types of tests, but if you are aware of the purpose of the test, such as what kind of idea the type is attached to, in other words, what you want to confirm , which one is used when designing the test? You will not be wondering if you should adopt the test. Here, I would like to introduce the types of tests used by Father Gutara.
Types of tests considered along the development phase
The easiest to understand is the type attached along with the software development phase . It 's a type of test that is often used in waterfall models and V-shaped models . Unit testing , integration testing , system testing type that is common. This type of test is common and easy to use, but be aware that the definition may differ slightly from organization to organization . Especially for unit tests, the definition may be quite different depending on the organization, so it is recommended to check the definition first when proceeding with software development with other organizations.
Types of tests considered from the creation of source code
The next most frequently used type is the normal system , quasi-normal system , and abnormal system, which were added from the creation of the source code. A normal system test is to check whether the operation when a normal input is given is as designed . The quasi-normal system test is to confirm that the error handling corresponding to the error state that was conceived at the time of design works correctly . Anomalous testing is to confirm that the software continues to operate even when an abnormality occurs as you did not think at the time of design . Since the quasi-normal system test is a test in a state where an error has occurred, there is an idea that it will be included in the abnormal system test, so it is important to confirm the definition of the abnormal system test.
Types of tests considered to confirm individual features
The functions installed in the software are described as functional requirements in the requirement specifications and requirement definition documents. In recent software development where everything is required to be connected to the Internet, it has become more important to keep moving stably at all times . Therefore, as for testing, testing for RAC function and security in the functional requirements is becoming more important. The purpose of the RAS function test is to confirm that the device itself operates stably by testing for Reliability, Availability, and Serviceability . A security test is a test of the ability to protect a device from external attacks . Being connected to the Internet always poses a risk of being attacked by cyber attacks, so the purpose is to check whether the software is designed so that it cannot be easily hijacked and used as a stepping stone.
Types of tests by system test category
The most important test to guarantee the quality of software is system test . It is important to think concretely about the contents of this system test for various purposes, but at that time, my father Gutara was referring to Chapter 6 of the book The Art of Software Testing 15 The type of system test category . In this book, system tests are classified into the following 15 types according to the purpose of the test, and the test types are named and their contents are defined.
Facility Testing, Volume testing, Stress Testing, Usability Testing, Security Testing, Performance Testing, Storage Testing, Configuration Testing, Compatibility Testing, Installability Testing, Reliability Testing, Recovery Testing, Serviceability Testing, Documentation Testing, Procedure Testing
This book is more than 40 years old when the first edition was published in 1979, but it describes software testing in a very easy-to-understand manner from the aspect of its practice, and the concept of testing itself is still large 40 years ago. Hasn’t changed, so it’s a very useful book to read now. In fact, it has been revised up to the 3rd edition so far, and the description about agile and mobile has been added.
At the time this book was written, the software was mainly for the core systems of companies running on large computer systems, so the system test category is also a little difficult to use for embedded software today. Gutara’s father used to select some from this system test category and read the definition according to the embedded software depending on the item .
Classification of design verification and validation
Another outer concept of test types, but the names of the test classifications , design verification test and validation test, should also be kept in mind when considering tests. It is sometimes abbreviated as design verification and validation, but in English, it is Design Verification Test and Validation Test.
The design verification test is a test to confirm that the designed contents are surely implemented in the execution software and operate as designed . Various tests are used to confirm whether the functional requirements and non-functional requirements written in the requirement specifications and requirement definition documents are installed in the software that actually operates. In other words, it is a test aimed at confirming that the design and implementation are performed correctly, so we do not confirm items that are not in the required specifications .
On the other hand, validation test is whether or not reasonable as a product to verify. From the standpoint of the user who actually uses the product, we test the product from the perspective of whether there are any problems with its functions, performance, stability, or usability . Therefore, the validity of items that are not written in the requirement specifications , such as “It is difficult to know where and how to touch because the GUI design showing the operation procedure is not unified" is validated. It may be detected as a defect in the test.
Classification of tests to detect potential bugs and guarantee that there are no bugs
The test will have two purposes, the soft part of the debugging tasks as finding a potential bug and the purpose of, part of the quality assurance of software as to ensure that absent remaining bug is the purpose of. Depending on the development organization, the test to find potential bugs is performed by the development department responsible for design and implementation, and the test quality assurance department to guarantee that no bugs remain is performed. There are also things.
In the early days of software development transitioning from the implementation phase to the testing phase, testing is focused on finding potential bugs . Testing helps find as many bugs as possible at an early stage and runs a debug cycle by designers and implementers to help improve the quality of the software . Immediately before the final release of software development, tests are conducted to ensure that there are no more bugs left and to guarantee quality . In many cases, it is judged that the quality of the software can be guaranteed by the fact that no bug is found in the test, and the software is allowed to be released.
Equivalence partitioning, boundary value analysis and path coverage
This is not the type of test, but the name of the test condition identification method and test method, but the name of equivalence partitioning and boundary value analysis , instruction coverage (C0 coverage), branch coverage (C1 coverage), and condition coverage (C2 coverage ). ) Is often used when designing tests, so I will introduce it here as well.
Equivalence partitioning and boundary value analysis are the names given to the method of selecting test conditions by focusing on the input value. Both give at the time of the test in the way of time to determine the input value to. Equivalence splitting is a method of dividing input values into a group of values with the same meaning and selecting representative values one by one. Boundary value analysis is a method of selecting the value that becomes the boundary between two groups when the equivalence is divided and the values before and after it as test values.
Instruction coverage, branch coverage, to determine whether conditions exhaustive program code is executed path test code in, whether it is determined that exhaustive case all satisfy any test condition, that method of determining the coverage in This is the name given. Instruction coverage is 100% if all instruction codes are executed at least once. For branch coverage, the coverage rate is 100% if all branch codes are executed at least once. Condition coverage is 100% coverage by implementing all combinations of conditional branches.
Which test to do is important
There are many types of tests other than those introduced here. When deciding which type of test to perform, it is easier to wonder which test to use if you are aware of what kind of test is intended to confirm what. .. Each test will be introduced in detail in a separate article in turn, but it is not yet known when all the articles will be available. I’m sorry, but please wait for a while.