Unit testing is the testing of software components. Its purpose is to test the correctness of the basic components of the software. The object of the test is the smallest unit of software design: the module. Also known as module testing.

Testing phase: post-coding or pre-coding ( TDD )

Test object: the smallest module

Tester: white box test engineer or development engineer

Test basis: code and comments + detailed design documents

Test method: white box test

Test content: module interface test, local data structure test, path test, error handling test, boundary test

2.3 System Test

Think of a software system as a system of tests. This includes testing the functionality, performance, and the hardware and software environment in which the software runs. Most of the time is spent in system test execution phase, including regression testing and smoke testing.

Testing phase: after the integration tests pass

Test object: the whole system (software, hardware)

Tester: black box test engineer

Test basis: requirements specification document

Test method: black box test

Test content: function, interface, reliability, usability, performance, compatibility, security, etc.

2.4 Regression testing

Regression testing refers to retesting after modifying old code to confirm that the modification did not introduce new bugs or cause other code to generate errors. Automatic regression testing will greatly reduce the cost of system testing, maintenance and upgrades and other stages.

It occupies a large proportion of workload in the entire software testing process, and multiple regression tests will be performed at each stage of software development. With the size of the system, the cost of regression testing is increasing, it is very meaningful to improve the efficiency and effectiveness of regression testing by choosing the correct regression testing strategy.

2.5 Smoke test

This term originates from the hardware industry. Power up the device directly after making a change or repair to one piece of hardware or a hardware component. If there is no smoke, the component has passed the test. It can also be understood that this kind of test takes a short time, and only one bag of cigarettes is enough.

The object of the smoke test is each newly compiled software version that requires formal testing. The purpose is to confirm that the basic functions of the software are normal and that subsequent formal testing can be carried out. The executor of the smoke test is the version compiler.

Example: After buying a new mobile phone, the first thing is to try the commonly used functions, and the second thing is to try all the functions

The smoke test is generally sent to the tester for testing after the developer has completed the development. The tester will first conduct the smoke test to ensure that the basic functions are normal and will not hinder subsequent tests.

2.6 Acceptance testing

Example: When you buy a new mobile phone, there is usually a 7- day guarantee for return and a one-month guarantee for replacement. We will try our best to try all the functions of the mobile phone within 7 days.

Acceptance testing is the last testing operation before deploying software. It is the final stage of technical testing, also known as delivery testing. The purpose of the acceptance test is to ensure that the software is ready, and to demonstrate to the software purchaser that the software system meets the original requirements in accordance with the project contract, mission statement, and acceptance basis documents agreed by both parties.

Test phase: After the system test is passed

Test object: the entire system (including hardware and software).

Testers: mainly end users or demand side.

Test basis: user requirements, acceptance criteria

Test method: black box test

Test content: same system test ( function ... various documents, etc. )

3. Organize by test implementation

3.1 Alpha Testing _

The last test before the mobile phone leaves the factory, developers and testers do not participate.

Alpha testing is a test conducted by a user in a development environment, and it can also be a test conducted by users within the company in a simulated actual operating environment. The purpose of alpha testing is to evaluate the FLURPS ( i.e. functionality, localization, usability, reliability, performance and support) of a software product

Large-scale general-purpose software usually requires Alpha and Beta testing before it is officially released. Alpha testing cannot be done by programmers or testers.

3.2 Beta Testing _

After purchasing a new mobile phone, the person who participates in the test is the buyer, and the place and environment of use are no longer the environment and place of the handset manufacturer.

Beta testing is a type of acceptance testing. Beta testing is performed by end users of the software at one or more locations.

The difference between alpha testing and beta testing:

Different testing places: Alpha testing refers to inviting users to the developer's site for testing , and beta testing refers to testing at one or more user's sites.

The environment of Alpha testing is controlled by the developer , the number of users is relatively small , and the time is concentrated. The beta testing environment is not controlled by the developer , the number of users is relatively large, and the time is not concentrated.

Alpha testing is performed prior to beta testing. General-purpose software products require large-scale beta testing , and the testing cycle is relatively long.

third party testing

Organizational testing between developers and users.

4. According to whether it is running or not

4.1 Static testing

The static method refers to not running the program under test itself, but only checking the correctness of the program by analyzing or checking the syntax, structure, process, interface, etc. of the source program. Perform structural analysis, flowchart analysis, and symbolic execution on requirements specifications, software design specifications, and source programs to find errors. analyse as below

Inspection items: code style and rule review; program design and structure review; business logic review; walkthrough, review and technical review manual.

Static quality: The standard on which the measurement is based is ISO9126 . In this standard, the quality of software is measured by the following aspects, namely, Functionality, Reliability , Usability , Effifficiency , Maintainability , and Portability (Portability) .

Code static analysis and document testing are both static testing

4.2 Dynamic testing

The dynamic testing method refers to checking the difference between the running results and the expected results by running the program under test, and analyzing performances such as running efficiency, correctness and robustness.

This method consists of three parts: constructing test cases, executing the program, and analyzing the output of the program.

Most software testing work is dynamic testing

5. According to whether manual division

5.1 Manual testing

Manual testing is to input use cases one by one by people, and then observe the results, corresponding to machine testing, which is a relatively primitive but necessary step.

To summarize the pros and cons:

Advantages: Automation cannot replace exploratory testing, testing of divergent thinking results.

Disadvantages: slow execution efficiency, large volume and error-prone.

5.2 Automated testing

It is to run the system or application program under preset conditions and evaluate the operation results. The preconditions should include normal conditions and abnormal conditions. Simply put, automated testing is a process of transforming human-driven testing behavior into machine execution.

Automated testing such as functional test automation, performance test automation, security test automation

Commonly referred to as automation refers to functional test automation

Automated testing is divided according to the test object, and can also be divided into interface testing, UI testing, etc. The ROI (output-input ratio) of interface testing is higher than that of UI testing.

Automated implementation steps:

1. Complete the function test, the version is basically stable

2. According to the characteristics of the project, select the automation tool suitable for the project and build the environment

3. Extract test cases from manual tests and convert them into automated test cases

4. Realize automatic construction input through tools and codes, and automatically detect whether the output results meet expectations

5. Generate automatic test report

6. Continuous improvement, script optimization.

6. Divided by whether to view the code

6.1 Black box testing

Black-box testing is also called functional testing. During the test, the software under test is treated as a black box. It does not care about the internal structure of the box, but only cares about the input data and output data of the software.

6.2 White box testing

White box testing is also known as structural testing, transparent box testing, logic-driven testing or code-based testing. White box refers to opening the box to study the source code and program results inside.

Interface testing is also a type of white box testing.

6.3 Gray box testing

Gray box testing is a test between white box testing and black box testing. Gray box testing is mostly used in the integration testing phase, not only focusing on the correctness of output and input, but also paying attention to the internal situation of the program.

7. Divided by test area

7.1 Internationalization testing

Software internationalization and software localization are two processes of developing software systems for users in different regions of the world. Localization testing and internationalization testing are tests for such software products. Due to the globalization of software and the rise of the software outsourcing industry, software localization and internationalization testing has become a unique testing field.

Localization and internationalization testing differ from other types of testing in many ways. Here are some key points for localization and internationalization testing.

1. Whether the appearance of the localized software is very different from the original version, whether the appearance is uniform and not out of shape

2. Whether all interface elements have been localized, including dialog boxes, menus, toolbars, status bars, prompt information (including sound prompts), logs, etc.

3. Whether the interface is displayed normally under different screen resolutions.

4. Whether there are different font sizes and whether the font settings are appropriate.

5. Whether the date, number format, currency, etc. can adapt to the cultural customs of different countries. For example, Chinese is Year Month Day, while English is Month Day Year.

6. Whether the sorting method takes into account the characteristics of different languages. For example, Chinese is sorted according to the pinyin order of the first character, while English is sorted according to the first letter.

7. Whether the software can adapt and convert different measurement units in different countries.

8. Whether the software can run normally on different types of hardware, especially popular hardware sold in the local market.

9. Whether the software can run normally on the local version of Windows or other operating systems.

10. Whether the online help and documents have been translated, and whether the translated links are normal. Whether the text translation is correct and appropriate, and whether there are grammatical errors.

Software localization and internationalization testing is a type of testing that combines the translation industry and the software testing industry. It requires testers to have a certain translation ability, language and culture, as well as the basic skills of testers.

7.2 Localization testing

In addition to international testing, others are

8. Divided by test object

8.1 Business Test

It is a process in which testers connect the various modules of the system to run, simulate the actual workflow of real users, and meet the functions defined by user needs for testing.

For example:

Check Mail:

Log in to the website - enter the user name and password to log in - enter the inbox - find the email - click to open - view - close the email - exit the mailbox - close the website

Business testing focuses on requirements and users

8.2 Interface Test

Interface test (referred to as UI test ) is to test whether the layout of the functional modules of the user interface is reasonable, whether the overall style is consistent, whether the placement of each control is in line with the customer's usage habits, and also to test the convenience of interface operation and easy-to-understand navigation. The availability of page elements, whether the text in the interface is correct, whether the naming is unified, whether the page is beautiful, whether the combination of text and pictures is perfect, etc.

8.3 Fault tolerance test

Fault-tolerance testing is a means to check whether the software itself has protective measures or some kind of disaster recovery under abnormal conditions. When a system error occurs, can the error be corrected and the system restarted within a specified time interval.

Fault tolerance testing includes two aspects:

1. Enter abnormal data or perform abnormal operations to verify the protection of the system. If the system has good fault tolerance, the system will only give a hint or digest it internally, without causing the system to make mistakes or even crash.

Gentle fault-tolerance tests usually construct some unreasonable inputs to induce software errors, for example:

1 ) Enter the wrong data type, such as " monkey " year and " horse " month.

2 ) Input a value outside the defined domain, the " thirteen o'clock " that Shanghainese often say is also a kind of

The rough fault tolerance test is commonly known as the " gorilla " test, except that you can't punch, kick and bite, you can use any tricks

2. Disaster recovery testing. By various means, let the software fail forcibly, and then verify whether the user data saved by the system is lost, and whether the system and data can be restored as soon as possible.

From the concept of fault tolerance testing, it can be seen that how to carry out failover and restore useful data when software fails is very important.

8.4 Documentation testing

1) Development documents: feasibility study report, software requirements specification, data requirements specification, outline design specification, detailed design specification, database design specification, module development file.

2) User documentation : user manual, operation manual, the role of user documentation: to improve the ease of installation; to improve the ease of learning and use of the software; to improve the reliability of the software; to reduce the cost of technical support.

3) Management documents: project development plan, test plan, test analysis report, monthly development progress report, and project development summary report.

Documentation testing concerns:

Documentation Terminology

correctness of documentation

Document integrity

Documentation Consistency

Documentation Ease of Use

8.5 Compatibility testing

Web testing

APP test

Compatibility mainly refers to whether the software can operate well, whether there will be any impact, whether the software and hardware can work efficiently, and whether it will affect the crash of the system.

platform test

browser test

Whether the software itself is forward or backward compatible

Test whether the software is compatible with other related software

Data Compatibility Test

8.6 Usability testing

Ease of use ( is the concentrated expression of the adaptability, functionality and effectiveness of the interaction. Ease of use belongs to the category of ergonomics.

8.7 Installation test

Test program installation and uninstallation

Typical app installation and uninstallation

8.8 Security Testing

Security testing is a relatively independent field that requires more expertise. For example , web security testing requires familiarity with various network protocols TCP\HTTP, firewalls, CDNs , vulnerabilities in various operating systems, routers, etc. In terms of software, he is familiar with various attack methods, such as SQL injection, Xss , etc.

8.9 Performance testing

Check that the system meets the performance specified in the requirements specification.

Usually manifested in the following aspects:

Accurate measurements of resource utilization such as memory, processor cycles, etc.

pair execution interval

Log events (such as interrupts, errors)

Response time

Throughput ( TPS )

Auxiliary storage (such as the size of buffers, workspaces, etc.)

Monitoring of processing accuracy, etc.

8.10 Memory leak test

There are too many things opened on the computer, the machine responds slowly or even freezes, it will be fine after restarting, and the same problem will appear later

Many software systems have the problem of memory leaks, especially programs written in " unmanaged " languages that lack automatic garbage collection mechanisms , such as C , CH , Delphi, etc.

From the user's point of view, the memory leak itself will not cause any harm, and the average user may not feel the memory leak at all.

The presence. But memory leaks are cumulative, and as long as they are executed enough times, they will eventually exhaust all available memory, making the software

The execution gets slower and slower, and finally stops responding. This kind of software problem can be compared to the " chronic disease" of the software.

There are many reasons for memory leaks, the most common are the following:

Forgot to reclaim the memory after allocating it.

There is a problem with the way the program is written, which makes it impossible to recycle.

Some API functions are used incorrectly, resulting in memory leaks.

It was not released in time.

Detection of memory leaks:

1. For different programs, different methods can be used to check memory leaks, and some special tools can also be used to check memory problems, such as MemProof. AQTime, Purify , BundsChecker , etc. Some development tools themselves have a memory problem checking mechanism. To ensure that the programmer turns on these functions when writing the program and compiling the program

2. Check through code scanning analysis tools

[Test] Division of software testing

1. Test classification

2. Divided by development stage

2.1 Test Pyramid and Business Test Analysis

2.2 Unit testing