Software Quality Assurance and Testing Classroom Knowledge Points Recall

Table of contents

Please introduce active testing and passive testing

Introduce the distribution of software defects at different stages

What is the approximate proportion of errors at each stage?

How to understand, focus on errors, and strengthen tests?

Introducing regression testing

How to understand the word regression in the above "regression test"?

Introduce decision-condition coverage

Can you give me an example?

In coverage, does the coverage condition determine the decision or the decision determines the coverage condition?

Introducing statement coverage

Look here for the path-condition test below. The statement inserted in this intermediate program segment must be related to the if-else.

At that time, if it is only combined coverage, it is very likely that the path coverage is not complete, that is to say, the test cases are not very comprehensive, and it is enough to fill in the missing path.

I just finished reviewing the basic coverage, but there are still some small points in it, we will continue to review tomorrow.

Please introduce active testing and passive testing

Active testing and passive testing are two commonly used testing methods in software testing, and they differ in testing strategies and execution methods. Below I will introduce the basic concepts and characteristics of active testing and passive testing:

Active Testing: Active testing refers to the purposeful execution of test cases and operations by testers to verify the functionality and performance of the system . In active testing, testers actively intervene in the system, triggering different actions and inputs to simulate the behavior of actual users. Active testing typically includes the following features:

Purposeful: Testers formulate test cases based on requirements and test plans, and perform test operations in a targeted manner.
Execution Control: Testers control the conduct of tests, select test cases and sequences of operations, and record test results.
Active intervention: Testers actively intervene in system behavior by inputting data, clicking buttons, performing operations, etc., to detect system response and functional correctness.
Verification function: Active testing is mainly used to verify whether the function of the system meets the requirements and specifications, and to detect the correctness and consistency of the system.

Passive Testing: Passive testing means that testers observe and record the operating behavior and output results of the system without directly intervening in the operation and input of the system . In passive testing, testers act as observers, monitoring the operating status of the system and collecting relevant information. Passive testing typically includes the following features:

Observation and recording: Testers observe system operation behavior, output results, log records, etc., and record relevant information for subsequent analysis and evaluation.
No intervention: The tester does not actively interfere with the operation and input of the system, but passively receives and analyzes the output of the system.
Monitoring and Analysis: Passive testing focuses on system behavior and performance metrics, and evaluates system reliability, stability, and performance characteristics by monitoring and analyzing data.

The choice of active testing or passive testing depends on the purpose of testing, testing requirements and testing strategy. Active testing is suitable for verifying the functional and logical correctness of the system, and discovering potential problems and errors by simulating user behavior and input. Passive testing is suitable for monitoring and analyzing the operating status, performance indicators and output results of the system to evaluate the reliability and performance characteristics of the system.

To sum up, active testing and passive testing are two commonly used methods in software testing. They are different in the way of testing execution and role positioning, but both evaluate and verify the function and performance of the system. According to the specific testing needs and goals, choosing the appropriate testing method can improve the test effect and coverage, thus helping to ensure software quality and user satisfaction.

Introduce the distribution of software defects at different stages

It is a common phenomenon that software defects are distributed in different stages of the software development life cycle. The following is the distribution of software defects in several common stages:

Requirements Analysis Phase: In the requirements analysis phase, deficiencies mainly focus on the definition and understanding of requirements. The following problems may exist:

Requirements are unclear or incomplete: Requirements documentation may be ambiguous, vague or missing, leading to confusion and errors in subsequent development stages.
Requirements Conflict: A situation where there are contradictions or inconsistencies between different requirements, causing problems in subsequent development stages.

Design phase: In the design phase, defects may involve aspects such as software architecture, module design, and interface definition. Common problems include:

Design errors: There may be logic errors, data flow problems, inconsistent interfaces, etc. in the software design.
Scalability issues: The design may not be sufficient to cope with future demand changes or expansions, resulting in difficulties in subsequent development.

Coding phase: In the coding phase, defects may involve syntax errors, logical errors, algorithmic errors, etc. Frequently asked questions include:

Syntax Error: The code does not conform to the syntax specification of the programming language.
Boundary Condition Error: The boundary conditions of the input were not handled correctly, resulting in abnormal or erroneous behavior.
Logical Errors: Logical errors in the code cause the program to not behave as expected.

Testing phase: During the testing phase, defects are found and reported. Frequently asked questions include:

Functional error: The function of the software does not work as required by the requirements specification or design document.
Performance issues: The software does not perform well when dealing with large amounts of data or high concurrency.
Compatibility Issues: The software is not compatible with a particular operating system, browser, or hardware platform.

It should be noted that although the distribution of software defects in different stages has certain rules, the specific situation will be affected by factors such as project characteristics, development process, and team quality management. To reduce the risk of software defects, appropriate quality control and testing activities should be performed at each stage, and defects should be fixed and verified in a timely manner.

What is the approximate proportion of errors at each stage?

The distribution of software defects in various stages can vary by project and organization. Typically, the following is a common estimate:

Requirements analysis stage: about 10-15% of total errors.
Design phase: about 20-25% of total errors.
Coding stage: about 50-60% of total errors.
Testing phase: about 10-15% of total errors.

This is an approximate estimate only and actual conditions may vary. For example, if an agile development methodology is employed in a project, more frequent testing and validation may be done in earlier stages, reducing the number of bugs found in later stages.

Furthermore, finding and fixing bugs early reduces the cumulative effect of bugs in later stages, where bugs found may require more cost and effort to fix. Therefore, it is crucial to focus on quality control, testing and quality assurance activities with continuous error prevention and correction throughout the development process.

How to understand, focus on errors, and strengthen tests?

"Fault concentration, test strengthening" means that in the process of software development, the quality and reliability of the software can be improved by performing more intensive tests on the areas or modules where errors occur intensively.

This idea is based on the observation that in software development, some functional areas or modules may be more prone to bugs or defects, while other areas may be relatively stable. By performing more in-depth and detailed testing on areas where bugs are concentrated, these issues can be caught and fixed earlier, reducing software bugs and failures in production environments.

Specifically, "error concentration, test strengthening" can include the following aspects:

Risk analysis: Conduct risk analysis to determine which functional areas or modules have higher risks and may have more errors or defects.
Testing strategy: According to the risk analysis results, formulate corresponding testing strategies, and focus more testing resources and attention on high-risk areas.
Test design: For high-risk areas, design more detailed and comprehensive test cases, including various boundary conditions, abnormal conditions and load tests, etc.
Automated testing: Use automated testing tools and frameworks to automate testing in high-risk areas to improve testing efficiency and consistency.
Strengthen the testing process: Strengthen the testing process for high-risk areas, such as adding code review, static analysis, performance testing, etc., to more comprehensively discover potential problems.

By concentrating energy and resources on more intensive testing, the number of errors and defects in the software can be effectively reduced, and the stability and quality of the software can be improved. This approach can be applied throughout the software development cycle, from requirements analysis, design, coding to testing and maintenance phases to ensure the quality and reliability of software delivery.

Introducing regression testing

Regression testing is a key testing activity in the software development process to verify whether the effect of modified or added code on existing functionality introduces new bugs or breaks existing functionality. It is primarily used to ensure that software continues to work as intended after modifications or updates are made.

Regression testing usually includes the following steps:

Select Test Cases: Based on the changes that have been made or the addition of functionality, select a set of test cases that cover the affected functionality or modules.
Execute Test Cases: Run selected test cases to verify that the software behaves as expected after making modifications. This can include functional testing, performance testing, security testing, etc.
Compare Results: Compare the results of the regression tests with the baseline results to check whether new bugs have emerged or existing bugs have been fixed.
Analyzing issues: If regression testing finds new bugs, or existing bugs are not fixed, these issues need to be reported to the development team so they can be fixed and verified.

The purpose of regression testing is to ensure that the modification of the software will not have a negative impact on the original functions, and to improve the stability and reliability of the software. It is a testing activity that is performed periodically and can be performed at different stages of the software development cycle, such as at each iteration, before a new release, or after a major fix.

Automated testing tools play an important role in regression testing as they speed up the testing process and increase the accuracy of testing. By writing automated test scripts, regression testing can be performed repeatedly, and any introduced errors can be found in time to improve test efficiency and quality.

How to understand the word regression in the above "regression test"?

In software development, "regression testing" refers to re-running old test cases after the software has been modified, updated, or new features added to ensure that bugs that have been fixed do not recur and that new changes do not introduce new ones. erroneous or lead to the degradation of the original function.

The word "regression" in regression testing comes from its literal meaning, that is, to return to a previous state . In software development, when modifications, updates, or changes are made, the system may return to a previous state or function, and these modifications may affect other parts of the system. Therefore, by performing regression testing, we can verify that the system still works properly after the modification, and that the previous functionality and performance have not been affected.

Regression testing usually includes the following steps:

Collect old test cases: Select suitable test cases from previous test suites that cover key functions and scenarios of the system.
Execute Test Cases: Run selected test cases to confirm that the system still functions properly after modification and that previous functionality has not been broken.
Check the results: Compare the test results to find out whether new errors have occurred or whether previous errors have been fixed.
Debugging and Fixing: If new bugs are found or previous bugs reappear, you need to debug and fix the problem.

Through regression testing, we can ensure that the software remains stable and reliable after undergoing modifications or updates. It helps prevent changes from introducing new bugs or causing old bugs to recur, maintaining the overall quality and functional integrity of the software. Regression testing is a very important part of the software testing process, which can help development teams and quality assurance teams catch and fix potential problems, thereby improving software reliability and user experience.

Introduce decision-condition coverage

Decision-Condition Coverage (Decision-Condition Coverage), also known as decision coverage or condition coverage, is a coverage criterion in software testing, which is used to determine whether the test cases fully cover the various decisions and conditions of the program.

The goal of decision-condition coverage is to test the two possible outcomes (true and false) of each decision in the program, while also covering all possible values of each condition. It requires that the test case must make each decision true at least once, and each condition can take every possible value. By satisfying this coverage criterion, potential logic errors and condition-related problems can be found as much as possible.

Decision-condition coverage usually follows these steps:

Understand the logical structure of the program: Study the program carefully to understand the decision statements and conditional statements in it, as well as the relationship and dependence between them.
Divide judgments and conditions: divide the judgments and conditions in the program, and determine the possible values of each judgment and condition.
Build test cases: Based on the partition results, build test cases to ensure that each decision is true at least once, and each condition covers all possible values.
Execute test cases: Run test cases and record the execution results of each decision and condition.
Check coverage: By comparing the actual execution results with the expected coverage judgments and conditions, determine whether the judgment-condition coverage requirements are met.

Decision-condition coverage can help testers find conditional logic errors, boundary cases and boundary value problems in the program. By ensuring the coverage of every decision and condition, you can improve the quality and completeness of your test cases and reduce the risk of undiscovered bugs. However, decision-condition coverage cannot guarantee to find all errors, and other coverage criteria and test methods also need to be used comprehensively to improve test results.

Can you give me an example?

When it comes to decision-condition coverage, let's consider a simple example: a test of a login function.

Let's say we have a login page where the user needs to enter a username and password to successfully log in. In this scenario, we can use decision-condition coverage to ensure that each decision and condition is covered by the test case.

The following is a possible example test case:

Test case 1:
- Enter a valid username and password
- Expected result: successful login
Test case 2:
- Enter valid username, invalid password
- Expected result: Login failed
Test case 3:
- Enter invalid username, valid password
- Expected result: Login failed
Test case 4:
- Do not enter username and password
- Expected result: Login failed

In this example, we override the various predicates and conditions for the login function:

Judgment 1: Check that the username and password are valid
Condition 1: Cases where the username is valid and invalid
Condition 2: When the password is valid and invalid

Through the above test cases, we ensure that each judgment is true at least once, and each condition covers all possible values. This way, we can test the login functionality more thoroughly, uncovering potential issues and bugs.

It should be noted that decision-condition coverage is not required to cover all possible combinations, but to ensure the coverage of each decision and condition. In the actual test, according to the specific needs and situations, it may be necessary to further supplement and adjust the test cases to improve the quality and coverage of the test.

In coverage, does the coverage condition determine the decision or the decision determines the coverage condition?

In test coverage, it is the coverage conditions that determine the decisions.

Coverage conditions refer to the conditions that need to be met during the test process, and are usually related to judgment statements (such as if statements, switch statements) in the program. Coverage conditions determine which branches or paths a test case needs to cover.

Judgment refers to the decision result during program execution, that is, the path of program execution is judged according to the coverage condition. The result of the judgment may be True (True) or False (False), which determines the execution flow of the program.

So, in coverage, we first design test cases based on coverage conditions to cover different conditions and branching paths. Then, when the test case is executed, the result of the judgment determines the specific path of program execution, thereby verifying whether the test case covers specific conditions and branches.

Therefore, the coverage condition determines the design of the test case, and the decision determines the coverage of the test case when it is executed.

Introducing statement coverage

Statement coverage is a basic test coverage criterion that aims to ensure that every statement (line of code) of the program under test is executed during testing. With statement coverage, we can check whether each statement is executed and whether there are potential errors or defects.

The basic idea of statement coverage is to require a test case to execute each statement at least once. By covering each statement, we can ensure that every line of code is executed, reducing the chance of unexecuted code or potential logic errors.

Here is a simple example to illustrate statement coverage:

Suppose you have a calculator program that contains the following code segment:

def add(a, b):
    result = a + b
    if result > 10:
        print("The result is greater than 10.")
    else:
        print("The result is less than or equal to 10.")

def subtract(a, b):
    result = a - b
    if result < 0:
        print("The result is negative.")
    else:
        print("The result is non-negative.")

For the above code snippet, we can write the following test cases to achieve statement coverage:

Test case 1:
- Enter a = 5, b = 3
- Expected result: output "The result is less than or equal to 10."
Test case 2:
- Enter a = 8, b = 6
- Expected result: output "The result is greater than 10."
Test case 3:
- Enter a = 10, b = 5
- Expected result: output "The result is greater than 10."

Through the above test cases, we can ensure that each statement is executed at least once. For example, test case 1 covers if result > 10the case, test case 2 covers elsethe branch, and test case 3 covers if result < 0the case.

It should be noted that statement coverage is only a basic coverage criterion, and it cannot guarantee to find all errors or defects. In actual testing, it may be necessary to combine other coverage criteria and testing techniques to improve the effectiveness and coverage of testing.