Software testing basics and knowledge

Software testing Basics

 

I. Software Testing Overview

Software testing is an important part of the software development process and is used to confirmProgramWhether the quality or performance meets the requirements raised before development. The purpose of software testing is to first confirm the quality of the software. One side is to confirm that the software has done what you expect (do the right thing ), on the other hand, make sure that the software did the event in the correct way ). The second is to provide information, such as feedback to developers or program managers and information prepared for risk assessment. Third, software testing is not only testing software products, but also the software development process. If many problems are found after a software product is developed, the software development process may be defective. Therefore, the third purpose of software testing is to ensure that the entire software development process is of high quality.
Software quality is measured in several aspects:

1. Use the correct method to make a job right (doing the right things right at the right time.) at the right time .).

2. meet the requirements of some application standards, such as the different operation habits and requirements of users in different countries, the maintainability and testability of the project, and so on.

3. Quality itself means that the software meets the initial requirementsCodeThe elegant or exquisite technique does not represent the high quality of the software (quality is defined as conformance to requirements, not as "goodness" or "Elegance ".).

4. Quality also indicates that it meets the customer's needs (quality also means "meet customer needs ".). As a software testing industry, the most important thing is to look at the product from the customer's needs and from the customer's perspective. How can customers use this product, what problems will be encountered during use. Only when these problems are solved can the quality of software products be said to be improved.
Tasks of testers during software development:
1. Search for bugs;
2. Avoid defects in the software development process;
3. measure the quality of software;
4. Focus on user needs.

The overall goal is to ensure the quality of the software.

2. Common Software Testing Methods

1. Black box testing

As the name suggests, the black box test regards the system to be tested as a black box, and obtains input from the outside world before output. The entire test is based on the requirement document to see if all requirements in the requirement document can be met. Black box testing requires that the tester cannot use knowledge or experience related to the internal structure of the tested system during testing. It is suitable for testing the functions of the system.

 

Black box testing has the following advantages:
1) it is relatively simple and does not need to know the code and implementation in the program;
2) It has nothing to do with the internal implementation of the software;
3) from the user's perspective, it is easy to know what functions the user will use and what problems it will encounter;
4) based on the software development document, you can also know which functions are implemented in the document;
5) It is more convenient for automated software testing.
Black box testing has the following Disadvantages:
1) it is impossible to cover all the code. The coverage rate is low, and it can only reach 30% of the total code volume;
2) the reusability of automated testing is low.

2. white box testing

White-box testing refers to the testing of the structure of the tested object and the content of the tested code. It needs to know the internal design structure and specific code implementation of the program, and design test cases based on this. The following code is used:
Hresult play (char * pszfilename)
{
If (null = pszfilename)
Return;
If (state_opened = currentstate)
{
Playthefile ();
}
Return;
}
After reading the code, you can check whether a string is empty and then perform the corresponding action based on the current status of the player. You can design some test cases like this: for example, what will happen if the string (File) is empty; what will happen if the player status is just opening the file; what will happen if the file is already playing. That is to say, many different test cases can be designed based on the different internal states of the player. These are things that may not be possible in purely black box testing.

 

The direct advantage of white-box testing is to know where the design test cases are ignored at the code level.

White box testing has the following advantages:

1) Help Software testers increase code coverage

2) Improve code Quality

3) discover hidden problems in the code
Disadvantages of white box testing:
1) The program runs in many different paths and it is impossible to test all the running paths;
2) The test is based on the Code and can only test whether the developer is right or not, but does not know whether the design is correct or not. Some functional requirements may be missed;
3) when the system is large, the test overhead will be very high.

3. Risk-based testing

Risk-based testing refers to the evaluation of the test priority. A high-priority test is performed first. If time or energy is insufficient, a low-priority test can be performed temporarily. As shown in the following figure, the horizontal axis represents the impact, and the vertical axis represents the overview rate. Based on the characteristics of a software, determine the impact of a function on the entire product, what is the probability of a failure in this function? If there is a high probability of a problem and the problem has a great impact on the entire product, it must be covered during testing. For a feature rarely used by a user, the probability of a problem is very small, and the impact of the problem is not very great. If the time is tight, you can consider not to test it.

Two deciding factors based on risk testing are: the impact of a feature problem on the user, and the probability of a problem. Other influencing factors include complexity, availability, dependence, and modifyability. Testers mainly determine the focus of testing based on priorities.

4. Model-Based Testing

In fact, a model is used to describe the behavior of a system in a language, and define its possible states and the conversion relationships between them, that is, the state transition diagram. A model is a system abstraction. Model-based tests use models to generate corresponding test cases, and then test the system based on the differences between the actual results and the expected results, as shown in the process.

Iii. Types of software testing

Common Software Testing types include:

BVT (build verification test)
BVT is performed after all development engineers have checked their own code. The project team compiles and generates the version of the current day to verify whether the latest software version is fully functional, whether the main software features are correct. If there are no major problems, you can perform functional tests. BVT has the advantage of short time and verifies the basic functions of the software. The disadvantage is that the test coverage rate is very low. Because of the short running time, it is impossible to test all the cases.

Scenario tests(Tests based on actual application scenarios of users)
During the BVT and function tests, the test may mainly focus on a module or relatively separate function. When a user uses this application, each module is used as a whole. Therefore, when testing, it is necessary to imitate the user's real use environment, that is, the user's usage, what will be done with this application, and what the operation will be like. After these test cases are added and combined with BVT and functional testing, the software can meet the requirements of users. The advantage of scenario tests is that it focuses on user needs, but sometimes it is difficult to really imitate the real usage of users.

Smoke test
If a problem is found during the test, a bug is found, and then the developer will fix the bug. In this case, if you want to know whether the bug of the program is solved or whether it will affect other modules, You need to perform a special test on the problem. This process is called smoke test. In many cases, smoke test is a series of chained reactions of other functional modules when developers try to solve a problem, the reason may be that you only focus on the problem at the beginning, and ignore other problems, which can lead to new bugs. Smoke test has the advantage of saving test time and preventing build failure. The disadvantage is that the coverage rate is relatively low.

In addition, application compatibility test aims to ensure compatibility with third-party software and ensure the normal operation of third-party software, so that users are not affected. The Accessibility test (software suitability test) ensures that the software can be used normally for certain persons with disabilities, but has a low priority. Other tests include functional test, security test, stress test, performance test, and regression test) and Setup/upgrade test (installation and upgrade test.

4. Microsoft Software Testing

1. Basic Information

Testing is a very important task in Microsoft, where Microsoft invests a lot. Microsoft attaches great importance to testing in the composition of engineering development teams. The ratio of Microsoft Project Managers, software developers, and testers is or, the ratio of developers to testers is. The emphasis on testing is also manifested in the fact that when the final product is to be released, all relevant departments of the product must sign, and testers have absolute veto power.
Testers are divided into two positions. The software development engineer in test (the software development engineer in the test group) is actually a developer who has the ability to write code and the experience of developing tool software, focuses on developing automated testing tools and testing scripts to automate testing. Software Test Engineer (Software Test Engineer) is responsible for testing software products, mainly for manual testing and installation and configuration testing.

2. Test Plan

Test Plan is an effective tool for testers to manage test projects and find bugs in software. The test plan has two main functions: one is to judge the test coverage rate and efficiency of the team, so that the test work can be organized gradually. Second, it facilitates communication with project managers and developers. With the test plan, they will be able to know how you conduct the test, and they will also give a lot of useful suggestions to ensure that the test work goes smoothly. In short, with a test plan, you can better complete the test and ensure user satisfaction.

 

Testers should obtain the following documents before preparing the test plan:
1) product function manual or product development plan prepared by the program manager;
2) Development Schedules provided by the program manager or developer.

 

Based on the product features and development schedule, the tester develops a specific test plan. A Test Plan generally includes the following:
1)Test objectives and release conditions:
A. provide a clear description of the test objectives;
B. Define the product release conditions, that is, the specific version of the product can be published only when the test target is met.
2)Product Scope to be tested:
A. Main features/functions of the software, that is, the list of main features of the software to be tested;
B. A list of features/functions for testing. All features, dialogs, menus, and error information should be covered for testing, and key functions to be considered in each test scope should be listed.
3)Test method description:
A. Define the testing methods used to test software products;
B. Describe the test scope that each specific test method can cover.
4)Test schedule:
A. Define test milestones;
B. Define the detailed test progress for the current milestone.
5)Test resources and related program managers/development engineers:
A. define the persons involved in the test;
B. Describe the responsibilities of each tester;
C. Provide information about the test-related program manager/Development Engineer.
6)Configuration scope and test tool:
A. lists all the computer platforms used for testing;
B. Describe the hardware covered in the test;
C. Main testing tools used for testing.

 

In addition, the possible risks and test dependencies during the test should be listed, that is, whether the test depends on a product or a team. For example, if this test depends on the Windows operating system, and this system can be completed in May next February, this test may only be completed in May next May, so there is a dependency relationship. If the team's development plan is pushed back, the test will also be postponed.

3. Test Case Development

A good test case is to have a reasonable probability to locate bugs. Do not redundant them. Be specific. A test is only for one thing. Especially during functional testing, if one test is to test two functions, then if the test result fails, you do not know which function is faulty.

 

The main technologies used in test case development include equivalence classification, boundary value analysis, and error guessing testing.

 

Equivalence classes are divided into two or more subsets Based on Input and Output conditions and some of their own features to reduce the number of test cases to be tested, in addition, a small number of test cases can be used to cover many cases, reducing the redundancy of test cases. In the division of equivalence classes, the most basic division is a valid class and an invalid class.

 

The boundary value analysis uses a rule, that is, the most common error of a program is near the boundary value. It depends on the type of the variable and the value range of the variable. Generally there are n variables, there will be 6 N + 1 test cases, values are min-1, Min, min + 1, normal, max-1, Max, Max + 1 combination. The disadvantage of boundary value analysis is that it does not work for logical variables and Boolean variables, and may ignore some input combinations.

 

Error guessing testing relies entirely on experience. The test cases designed are often called guesses. If you feel that a software error may occur somewhere, design the corresponding test cases. This is mainly based on the experience and knowledge accumulated in actual work. The advantage is that the test case can be quickly designed as long as you want it. The disadvantage is that it is not systematic and cannot know the coverage rate. It is very likely that some testing fields will be omitted.

 

In fact, Microsoft uses some specialized software or tools to manage test cases. Some test information can be recorded, such as the simple description of test cases and on which platforms to execute them, manual or automatic testing: the frequency of running is once a day or once a week. In addition, there are clear criteria for passing or failing tests, as well as detailed records of each test step.

4. BUG Tracking Process

In software development projects, one of the most important missions of testers is to effectively track and manage all known bugs to ensure that all problems in the product can be effectively solved. Generally, the process of discovering, locating, processing, and finally solving a bug by the project team includes four phases: bug report, bug evaluation and allocation, bug handling, and bug closure:
1) after discovering a new Bug During the test, the test engineer should report the location, performance, current status and other information of the bug to the project team. The project team adds the bug record to the bug database.
2) The development manager conducts a concentrated discussion on detected bugs, evaluates the priority of bugs based on the impact of bugs on software products, and develops bug correction strategies. According to the priority of bugs and the work arrangement of developers, the Development Manager allocates all bugs that need to be handled immediately to the corresponding development engineers.
3) The Development Engineer handles specific bugs according to the arrangement, finds out the cause of errors in the code, modifies the code, and regenerates the product version.
4) after the development engineer processes the bug, the tester needs to verify the result. After verification, it confirms that the correctly handled bug is marked as closed. The test engineer needs to verify whether the bug has been corrected, and determine whether the developer has introduced the new bug while modifying the code.

5. Different bug Handling Methods

In some cases, the bug has been handled and does not mean the bug has been fixed. Developers can delay bug fixes, or tell test engineers after analysis that this is not actually a real bug. That is to say, after a specific bug is handled by a development engineer, the bug may include the following states.
Corrected: The Development Engineer has corrected the corresponding program code and the bug does not appear.
Deferred: the bug is of low importance and does not affect the main functions of the current version to be submitted. It can be processed in the next version.
Design problem: the bug has nothing to do with program implementation. The behavior shown by the bug fully complies with the design requirements and should be submitted to the program manager for handling.
No modification required: the bug is very low in importance and does not affect the functions of the program. The project team does not have to waste time on these bugs.

5. Requirements for becoming an excellent test engineer

To become an excellent test engineer, first of all, you must have a good understanding of the basic knowledge of computers and be proficient in one or moreProgramming LanguageHave certain program debugging skills and master the Development and use technologies of test tools. At the same time, we should be more careful, arrange our work according to the priorities of the task, and have good communication skills. In addition, we should be good at thinking about problems in unconventional ways, participate in software testing projects as much as possible, learn skills and accumulate experience in practice, constantly analyze and summarize the possible errors in the software development process. In this way, a good test engineer will stand out from the practice of software testing.

Conclusion:Microsoft's software development experience has been profound, and the lectures by Microsoft engineers are vivid and colorful. Some of the content is detailed with the programming code, which is difficult to be summarized and refined in introductory words, in addition, due to the limited ability and energy, I can only extract some of the essence of the content to write it to readers, so it is inevitable to miss a thousand, or even make mistakes, please stay tuned for this seriesArticleUnderstanding and correction. Finally, I would like to express my sincere gratitude to the Microsoft teachers for their hard work!

 

Reprinted statement: This article from http://yueyelmm.blog.163.com/blog/static/2981247320099993240603/

========================================================== ============================================

 

Software testing knowledge

 

The history of software development and use has left us with many lessons that result from huge financial and material losses due to Software defects. These lessons force our testing engineers to take strong detection measures to detect hidden Software defects that have not been discovered.

The final purpose of production software is to meet the customer's needs. We take the customer's needs as the criteria for judging the software quality. The specific meanings of Software defects include the following factors:
1. Features and performance that the software does not meet the customer's requirements;
2. The software is out of the scope of customer requirements;
3. software errors that cannot be tolerated by customers;
4. The use of the software fails to meet the customer's habits and work environment.

Considering design and other factors, we can also consider that Software defects can also include software design non-compliance, failure to reach the optimal level under specific conditions (such as funding and scope. Unfortunately, many of us are more inclined to regard Software defects as running problems and think that software testing is only after the program is submitted.

In the current domestic environment, we almost cannot see complete and accurate customer requirement manuals, and the customer's requirements are constantly changing, making it impossible to pursue perfect tests. Therefore, as an excellent tester, it is our purpose to pursue the perfection of software quality, but to clarify the gap between the software testing reality and the ideal, and learn to make trade-offs and concessions in software testing, there is no harm to software testing.

The following are some common knowledge of software testing. understanding and application of these common sense will help us better grasp the Software Testing Scale during software testing.

1. The test is incomplete (the test is incomplete)

Obviously, because of the incompleteness of software requirements, the combination of software logic paths, the large amount of input data, and the diversity of results, even an extremely simple program, to exhaust all logical paths, it is very difficult to input data and verify all results. Let's take a simple example, for example, to calculate the maximum common divisor of two integers. The input information is two positive integers. However, if we test the number of the entire positive integer domain, we can prove that such a test is not feasible in our real life, even if we were able to exhaust the program one day, we were afraid that we and even our children would have been old. As a software test, we generally use equivalence classes and Boundary Value Analysis to perform actual software tests. Finding the minimum set of use cases is a necessary way to streamline the complexity of testing.

2 test immunity (software defect immunity)

Software defects, like viruses, have a terrible "immunity". The more tested by testers, the stronger their immunity, and the more difficult it is to find more Software defects. We can draw this conclusion from the mathematical probability theory. Assuming that a 50000-line program contains 500 Software defects and these software errors are evenly distributed, one software defect can be found in each 100 lines. Let's assume that the tester spent some way looking for Software defects is X hour/100 lines. According to this, when the software has 500 defects, it takes x hours to find a software defect. When the software has only five errors, it takes x hours to find a software defect. Practice has proved that the actual test process is more rigorous than the above assumptions. Therefore, we must replace different test methods and test data. This example also illustrates that using a single method in software testing cannot efficiently and fully target all Software defects. Therefore, software testing should adopt as many approaches as possible for testing.

3. testing is a "generic concept" (full test)

I have been opposed to software testing only after the program is completed. If we simply call the stage after the design stage software testing, the defects in the demand stage and design stage will increase the amplification effect. This is not conducive to ensuring software quality. Requirement defects and design defects are also Software defects. Remember that "Software defects have fertility ". Software testing should span the entire software development process. Requirement verification (self-check) and design verification (self-test) can also be counted as a software test (recommended: requirement test and design test. Software testing should be a generic concept that covers the entire software lifecycle so that each stage of the cycle can be prevented from being tested. At the same time, the test itself also needs to be evaluated by a third party (information system audit and software engineering supervision), that is, the test itself should also be tested to ensure the reliability and efficiency of the test itself. Otherwise, it is difficult to convince people.

In addition, it should be pointed out that software testing is necessary but not adequate for improving the quality of software products. software testing is the most direct and quickest way to improve product quality, but it is by no means a fundamental means.

4 80-20 principles

80% of Software defects often exist in 20% of the software space. This principle tells us that if you want to make software testing effective, remember to visit its high-risk areas frequently ". There are many possibilities for discovering Software defects. This principle is of great significance for Software testers to improve testing efficiency and defect discovery rate. Smart testers will quickly find out more defects based on this principle, while stupid testers are still searching aimlessly.

Another case of the 80-20 principle is that we can detect and avoid 80% of Software defects during system analysis, system design, system implementation review, and testing, subsequent system tests can help us identify 80% of the remaining defects. The final 5% of Software defects may be exposed only after the system is delivered and used for a long time. Because software testing can only detect as many Software defects as possible, but cannot discover all Software defects.

The 80-20 principle also reflects the automation of software testing. Practice has proved that 80% of Software defects can be discovered through manual testing, and 20% of Software defects can be discovered through automated testing. Because of the crossover between the two, about 5% of Software defects need to be discovered and corrected in other ways.

5 test for benefits

Why do we need to implement software testing to improve the quality and efficiency of the project and ultimately improve the overall efficiency of the project. Therefore, it is not difficult to figure out the degree we should master in implementing software testing. Software testing should strike a balance between software testing costs and software quality benefits. This balance point is what we should observe when implementing software testing. The unilateral pursuit will inevitably damage the value and significance of the existence of software testing. In general, we should try our best to keep the software testing simplicity in software testing, and never complicate the software testing too much. In the words of the physicist Einstein, keep it simple but not too simple.

6. inevitability of defects

In software testing, not all Software defects can be repaired due to the Association of errors. Although some Software defects can be repaired, New Software defects will inevitably be introduced during the repair process. Many software defects conflict with each other. The disappearance of a conflict will inevitably lead to another conflict. For example, we tend to have execution efficiency defects after solving general defects. Moreover, in the process of defect repair, we are often limited by time and cost, so we cannot effectively and completely repair all Software defects. Therefore, the importance and scope of impact of Software defects should be evaluated, and a compromise scheme should be selected or non-software factors (such as improving hardware performance) should be selected) considering Software defects is a fact we must face when facing Software defects.

7 The software test must have the expected results

Tests with no expected results are unreasonable. Software defects are produced by comparison. This is the same as the measurement cannot be performed without standards. If we do not know or cannot affirm the expected results, we will not be able to understand the correctness of the test. It is easy to feel like a blind person. Many testers often judge the occurrence of Software defects based on their own feelings, the result is often determined based on seemingly incorrect results.

8 significance of software testing-post-event analysis

Is software testing so easy to discover defects? If it is "yes", I am sure that similar software defects will occur in the next software test of the new project. The old saying goes well. "People who do not know the history will surely make the same mistake again ". Without a careful analysis of the software testing results, we cannot understand the Causes and Countermeasures of the defects. The result is that we have to spend a lot of manpower and material resources to find Software defects again. Unfortunately, most of the testing teams did not realize this, and the test report lacks the test result analysis link.

Conclusion:
Software testing is a process that requires "conscious". As a tester, we have a correct understanding of how to calmly control the scale and fundamentally cope with software testing, I hope this article will help readers understand software testing.

 

Reprinted statement: This article from http://yueyelmm.blog.163.com/blog/static/2981247320099993142749/

========================================================== ============================================