Test Classification summary and case analysis

Test Type

Software testing is a complex system engineering. Different methods can be divided from different perspectives. Classification of testing is to better clarify the testing process, measure the test taker's knowledge about what to do and try to perform a full test.

2.1 From the Perspective of whether to execute the tested software

From the perspective of whether to execute the software to be tested, it can be divided into static testing and dynamic testing. The former uses no computer to run the program to be tested, and other means to achieve the purpose of testing, such as code review. (I think it is mainly for testers to analyze potential errors that cannot be found by the compiler, such as invalid endless loops and redundant variables ), dynamic Testing is achieved by running the tested software.

2.2 division by phase 2.2.1 unit test

Unit testing is a test of the basic components in the software, such as a module and a process. It is the most basic and important part of software dynamic testing, and its purpose is to verify the correctness of the basic components of the software. Because unit testing requires a detailed knowledge of internal program design and coding, it is generally done by programmers rather than testers. It is often necessary to develop test driver modules and pile modules to assist in unit testing. Therefore, it is particularly important to have a well-designed architecture of the application system. The correctness of a software unit is relative to the specification of the unit. Therefore, unit testing is based on the specification of the unit to be tested. The main unit test methods include control flow test, data flow test, troubleshooting test, and domain-based test.

 

2.2.2 integration test

The purpose of integration testing is to check whether the interfaces between software units are correct. According to the integration test plan, it combines modules or other software units into an increasingly large system while running the system to analyze whether the system is correct and whether the components are co-occurrence. There are two policies for integration testing: top-down and bottom-up.

2.2.3 System Test

System testing is a thorough test of the integrated software system to verify that the correctness and performance of the software system meet the requirements specified in its statute, it is not a simple task to check whether the software's behaviors and outputs are correct. It is called the "crowdsourced Security Testing ". Therefore, the system test should be carried out according to the test plan, and its input, output and other dynamic operation behaviors should be compared with the software specification. There are many methods for testing software systems, including functional testing, performance testing, and random testing.

2.2.4 Acceptance Test

The purpose of the acceptance test is to demonstrate to the software purchaser that the software system meets the needs of its users. The testing data is usually a subset of the testing data of the system test. The difference is that there is often a buyer representative of the software system in the acceptance test, or even in the field where the software is installed and used. This is the final test of the software before it is put into use.

2.2.5 regression testing

Regression testing is a test performed after the software is modified in the software maintenance phase. The purpose is to check whether the modifications made to the software are correct. Here, the correctness of the changes has two meanings: first, the changes have achieved the intended purpose, such as correct errors and adapting to the new running environment; second, it does not affect the correctness of other functions of the software.

2.2.6 Alpha test

Test the application system when system development is nearing completion. After the test, there will still be a small number of design changes. Such tests are generally completed by end users or other personnel and cannot be completed by programmers or testers.

 

2.2.7 beta test

Tests are performed when development and testing are complete, and the final errors and problems need to be found before the final release. Such tests are generally completed by end users or other personnel and cannot be completed by programmers or testers.

 

2.3 Division by test method 2.3.1 white box testing

 

A white-box test, also known as a structure test or a logic-driven test, refers to a test based on the internal logic knowledge of an application code, that is, a test based on covering all code, branches, paths, and conditions, it is to know the internal working process of the product. It can be tested to check whether the internal actions of the product are normal in accordance with the specifications, and to test the program according to the internal structure of the program, check whether each path in the program can work correctly according to the predefined requirements, regardless of its function, the main white box testing methods include logic-driven, baseline testing, etc., mainly used for software verification.

The "white box" method provides a comprehensive understanding of the internal logic structure of the program and tests all logical paths. The "white box" method is to test the exhaustive path. When using this scheme, the tester must check the internal structure of the program and obtain the test data starting from the logic of the program. The number of independent paths throughout the program is astronomical. However, even if each path is tested, errors may still occur. First, the exhaustive path test cannot identify that the program violates the design specifications, that is, the program itself is a wrong program. Second, the exhaustive path test cannot identify errors caused by missing paths in the program. Third, some data-related errors may not be found in the exhaustive path test.

White box testing can be completed using tools such as JUnit framework and jtest.

 

2.3.2 black box testing

　

Black box testing refers to testing based on requirements and functionality without any knowledge of internal design and Code. It is also called functional testing or data-driven testing, it is a function that should be available in a known product. It is tested to check whether each function can be used normally. During the test, the program is regarded as a hacker that cannot be opened, without considering the internal structure and features of the program at all, the tester tests the program interface and only checks whether the program functions are normally used according to the requirements of the Specification, whether the program can properly receive input saw to generate correct output information, and maintain the integrity of external information (such as database or file. Black box testing methods include equivalence classification, edge value analysis, result graphs, and incorrect speculation. They are mainly used for software validation testing. The black box method focuses on the external structure of the program, does not consider the internal logic structure, and tests the software interface and software functions. The "black box" method is a testing of input. Only when all possible input is used as a test can all errors in the program be detected in this way. In fact, there are infinite number of tests. People should not only test all valid inputs, but also test those illegal but possible inputs.

You can also use some tools such as winrunner, quicktestpro, and rational robot for black box testing.

 

2.3.3 ALAC (Act-like-a-customer) test

ALAC testing is a testing method developed based on the knowledge of the customer's products. ALAC testing is based on the principle that complex software products have many errors. The biggest beneficiaries are users who find and correct defects and target the customers who are most likely to encounter errors.

 

2.4 case-in-site search test

First, this test is a system test.

1. In terms of functions, can you find the correct and complete results based on the specified conditions? for details:

1.1 The input conditions are normal keywords, words, and statements for the query results, and the retrieved content and links are correct;

1.2 The input conditions are keywords, words, and statements that cannot be found;

1.3 The input conditions include some special content, such as null, special characters, punctuation marks, and limit values. You can introduce methods for dividing equivalence classes;

 

2. In terms of performance, you can use testing tools or various testing methods to consider the performance of functions in various aspects, specifically:

2.1 stress testing: performance under the pressure of different concurrent users (evaluation indicators such as response time)

2.2 load test: Check the maximum number of users that can be used normally at the same time

2.3 stability test: How long can stability be maintained under normal pressure?

2.4 memory test: Memory leakage

2.5 large data volume testing: such as simulating search results from a large amount of data, or listing results of a search volume, to see how it works.

 

3. ease of use:

3.1 There will be related user-friendly prompts based on different query results. Will they be notified when the query fails? Check the number of statistics and inform? If any input conditions are suspected to be incorrect, the system prompts that the input items may be correct;

3.2 The query results are listed in an orderly manner, such as by click rate or other sorting rules. Make sure that the results are listed by rules for easy positioning, and the font, font size, and color are displayed for easy identification;

3.3 is the actual search method, such as title query, full-text search, fuzzy query, fault-tolerant query, and multi-Keyword organization query (separated by spaces) normal?

3.4 is the style design and location placement of the Control entering the search criteria eye-catching so that users can notice it? Is there a user-friendly design such as quick viewing methods such as snapshots?

 

4. In terms of compatibility, the normality of cross-platform, multi-language, and other diverse environments can be tested. Specifically:

4.1 Windows/Linux/Unix and other operating systems and applications under different versions

4.2ie/Firefox/Google/360/QQ and other applications in various browsers, versions, and display resolutions

4.3sql/Oracle/DB2/MySQL and other database storage compatibility tests

4.4 compatibility testing for software platforms in simplified Chinese, traditional Chinese, and English

4.5 compatibility tests for iPhone/iPad, Android, and other mobile app platforms

4.6 compatibility tests with related monitoring programs, such as input methods, anti-virus, monitoring, and firewall tools

 

5. Security aspects are often overlooked. Details:

5.1 whether security control design exists for deleted, encrypted, and authorized data that cannot be found;

5.2 enter reserved characters for some database queries, such as single quotes and %, which may result in a vulnerability in the query SQL concatenated statements, such as detecting all data, in this regard, there should be some hacker attack ideas and some tools and technologies, such as crawling.

5.3 use white-box testing technology to check whether there are security risks in programming;

5.4 filtering and control of content related to national security and prohibited by law;

 

6. abnormality test, impact test of various destructive operations, details:

6.1 network interruption and shutdown during Query

6.2 page suspension during Query

6.3 killing related processes in the Query Process

Test Classification summary and case analysis